PS-2: Position Risk Designation

To meet the ps-2: position risk designation requirement, you must assign a documented risk level to every organizational position (not just people) and use that designation to drive screening, access decisions, and ongoing personnel controls for roles with higher security impact. Make the designations auditable, tied to job codes, and maintained through HR and IAM change processes. ¹

Key takeaways:

• Risk-designate positions (roles), then enforce role-based personnel requirements consistently across HR, security, and hiring workflows. ¹
• Evidence matters: auditors look for a complete position inventory, a clear designation method, and proof the designations affect real decisions (screening, access, transfers). ¹
• Operationalize through “joiner/mover/leaver” and requisition processes so designations stay current without manual clean-up. ¹

PS-2 is a deceptively simple control with a common failure mode: organizations describe “high-risk roles” in a policy, but they cannot show a complete, maintained mapping of every position to a risk designation, or they cannot prove the designation changes what happens in hiring and access provisioning. PS-2 expects you to treat risk as a property of the position itself, independent of who fills it, and to keep that classification current as roles evolve. ¹

For a CCO, Compliance Officer, or GRC lead, PS-2 is a coordination control. HR owns job structures and requisitions, security owns access and system privileges, and business owners define what the job actually does. Your job is to force a single, auditable source of truth: a position inventory with risk tiers, clear criteria for assigning those tiers, and workflow hooks so the tier drives downstream controls (screening depth, approval levels, access constraints, monitoring, and reassessment on role changes). ¹

This page gives requirement-level implementation guidance you can hand to HR, IAM, and system owners to operationalize PS-2 quickly and survive assessment questions without scrambling. ¹

Regulatory text

Requirement excerpt: “Assign a risk designation to all organizational positions;” ¹

Operator interpretation: You need a documented classification (risk designation) for every position in scope, and you must be able to show (1) how you determined it, (2) who approved it, (3) where it is recorded, and (4) how it is used to trigger personnel and access-related safeguards. “All organizational positions” means you cannot limit this to IT admins or executives; you need a complete population for the organization/system boundary you’re assessing. ¹

Plain-English interpretation (what PS-2 is really asking for)

PS-2 requires you to answer: “If this role is compromised or abused, how much damage could it cause?” Then you assign a risk tier to the role and treat the role accordingly.

A practical way to think about “position risk”:

• Privilege risk: Does the role administer systems, manage identities, approve payments, or bypass controls?
• Data risk: Does the role access regulated, sensitive, or mission-critical information?
• Process risk: Can the role initiate/approve high-impact business actions (releases, changes, disbursements, exceptions)?
• Trust risk: Does the role interface with government customers, hold signing authority, or act as a control owner?

PS-2 does not dictate how many tiers you must use. It does require that your approach covers every position, is consistently applied, and is kept current. ¹

Who it applies to (entity and operational context)

PS-2 is commonly assessed where NIST SP 800-53 is the governing framework, including:

• Federal information systems and the organizations operating them. ¹
• Contractors handling federal data (for example, environments supporting federal programs where NIST SP 800-53 controls are flowed down). ¹

Operationally, PS-2 applies anywhere you have:

• Defined roles/positions (HR job codes, positions in an org chart, or standardized titles).
• Access provisioning tied to roles (IAM groups, RBAC roles, privileged access management).
• Hiring, onboarding, and transfer workflows where you can insert control gates.

If your assessed boundary is a specific system or business unit, scope the position inventory to roles that can access or materially affect that boundary. Document the boundary decision so auditors understand what “all positions” means in your context. ¹

What you actually need to do (step-by-step)

1) Define the risk designation model (make it usable)

Deliverables:

• A short standard (one page is fine) that defines risk tiers and assignment criteria.
• A rule for ties and exceptions (who decides, how to document).

Practical model:

• Use three tiers (Low/Moderate/High) or equivalent labels that match how your organization makes decisions.
• Define criteria in checkboxes, not paragraphs. Example criteria for “High”: privileged admin access, ability to approve financial transactions, access to sensitive federal data, ability to change production configurations.

Keep the model aligned to how access is granted. If “High” roles exist but do not map to different approval or screening steps, you will fail the “operationalized” test in an assessment. ¹

2) Build a complete position inventory for the in-scope organization/system

You need a population that is defensible:

• Start with the HR system of record: job codes, positions, departments, and employment types (employee, contractor).
• Add non-HR identities that still function as positions: shared service accounts should be handled under technical controls, but “contractor roles” and “staff augmentation roles” still need position designations if they represent recurring access patterns.

Output: a position register (spreadsheet or GRC object) with a unique identifier for each position, title/job code, owner, and risk tier. ¹

3) Assign initial risk designations using a repeatable workflow

Run a structured workshop:

• HR provides job descriptions and the authoritative list of positions.
• System owners and control owners identify access and impact.
• Security/IAM validates privilege assumptions.
• Compliance/GRC records rationale and approvals.

Minimum required fields per position:

• Risk tier
• Rationale (one sentence tied to criteria)
• Approver(s) and date
• Systems/data in scope (high-level references)

If you cannot finish all positions quickly, prioritize those with privileged access and sensitive data first, but track the remainder as a dated remediation item with accountable owners. ¹

4) Wire the designation into HR + IAM processes (where audits are won)

You need the designation to change operational steps. Common hooks:

• Requisition / job posting: risk tier must be selected before posting; it drives screening requirements.
• Background screening / pre-employment checks: risk tier determines screening package and adjudication steps (your organization decides the depth; document it).
• Offer approval: higher-risk positions require additional approvals (for example, security, data owner, or compliance sign-off).
• Joiner provisioning: IAM uses the position tier to require stronger approvals for high-risk access and to route privileged access via PAM instead of direct assignment.
• Mover events: when a person changes roles, the new position tier triggers re-screening or re-approval where your policy requires it.
• Leaver events: ensure access removal is consistent, and confirm privileged access is removed first for high-risk positions.

Auditors will ask for examples across joiner/mover flows. Prepare a few completed tickets showing the tier present and used. ¹

5) Establish a maintenance cadence tied to change management

PS-2 breaks when job duties drift. Set maintenance rules:

• HR must notify Security/GRC when a job description materially changes.
• New positions cannot be created in HRIS without a provisional risk tier.
• Periodic review by HR + Security + business owners to confirm tiers remain accurate.

Avoid a “once-and-done” spreadsheet. If you use Daydream, map PS-2 to a control owner, a simple implementation procedure, and recurring evidence artifacts so the control stays in an assessable state across quarters. ¹

Required evidence and artifacts to retain

Keep evidence that proves completeness, correctness, and operation:

Core artifacts

• Position Risk Designation Standard (tier definitions, criteria, roles/responsibilities). ¹
• Position inventory/register with risk tier for every in-scope position. ¹
• Approval record for the model and for bulk assignments (meeting minutes, e-sign approvals, change tickets). ¹

Operational proof (what examiners ask for)

• Samples of requisitions showing risk tier selected and approvals routed accordingly.
• Samples of onboarding tickets showing tier-driven access approval steps.
• Samples of mover/transfer tickets showing re-approval when the tier increases.
• Evidence of periodic review or change-triggered updates to the position register.

Traceability aids

• Crosswalk from job codes to IAM roles/groups for high-risk positions.
• List of positions designated “High” with associated privileged access paths (PAM enrollment, break-glass procedures if applicable).

Common exam/audit questions and hangups

Expect questions like:

• “Show me the population. How do you know this is all positions in scope?” Bring HRIS extracts and your scoping memo. ¹
• “Who decided the risk tiers, and what criteria did they use?” Show the standard and approvals. ¹
• “Pick a high-risk role. Prove the designation changes hiring or access.” Provide a requisition, screening record reference, and provisioning ticket. ¹
• “How do you keep this current?” Show the trigger (new role, job change) and periodic review evidence. ¹

Hangups that stall assessments:

• HR titles do not match IAM roles.
• Contractors are off-system in HRIS, so they are missing from the “all positions” population.
• The organization designates risk but cannot show any downstream action differences.

Frequent implementation mistakes (and how to avoid them)

1. Designating people instead of positions.
   Fix: tie the designation to job code/position ID, then inherit it for incumbents. ¹

2. No documented criteria, just “tribal knowledge.”
   Fix: write criteria that a new reviewer can apply consistently; store rationales per position. ¹

3. Incomplete population.
   Fix: reconcile HRIS positions to IAM active user populations, including contractor identity sources, and track exceptions explicitly. ¹

4. Static spreadsheet that rots.
   Fix: add gates to HR position creation and mover workflows so changes force an update. ¹

5. No evidence of impact.
   Fix: define which controls change by tier (screening, approvals, privileged access routing) and retain sample tickets for each. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not expect a case-law style trail specific to PS-2 in this write-up.

Risk-wise, PS-2 is a prevention control for insider threat, privilege misuse, and hiring into sensitive roles without appropriate safeguards. If you cannot prove high-risk roles are identified and treated differently, auditors often conclude your personnel security controls are not risk-based, which can spill into findings for access control and identity management during the same assessment. ¹

Practical 30/60/90-day execution plan

You asked for speed. Here is an execution plan that fits real operating constraints; adapt milestones to your assessment calendar and HR/IAM release cycles.

First 30 days (design + population)

• Assign a control owner (often GRC with HR and Security as key contributors) and define RACI.
• Draft the risk tier model and approval workflow.
• Extract the in-scope position list from HRIS and validate scope with system owners.
• Pilot the model on a small set of roles (privileged IT, finance approvals, security admins) to test criteria clarity.
• Stand up the evidence repository (GRC system or controlled drive) and name the recurring artifacts you will retain. ¹

By 60 days (initial designation + workflow hooks)

• Complete initial designations for the full in-scope position inventory, including rationale and approvals.
• Implement at least one hard gate: new position creation or requisition intake requires a risk tier selection.
• Implement IAM routing differences for high-risk positions (extra approver, PAM requirement, or documented exception).
• Produce an assessment-ready evidence pack: standard, inventory, approvals, and a few operational samples. ¹

By 90 days (sustainment + audit readiness)

• Add mover/transfer triggers so risk tiers are re-evaluated when job duties change.
• Run the first maintenance review and document outcomes (updates, exceptions, remediation tasks).
• Reconcile HR positions vs IAM user populations to detect missing role designations (especially contractors).
• If you run Daydream, formalize the PS-2 control record with mapped owners, procedures, and a recurring evidence schedule so the control stays continuously assessable. ¹

Frequently Asked Questions

Do we have to assign a risk designation to every employee?

PS-2 is about positions, not individuals. In practice, people inherit the designation of the position they occupy, and the designation must exist for every in-scope position. ¹

What counts as a “position” if we don’t have formal job codes?

Use whatever structure you consistently grant access by: standardized titles, role families, or IAM role templates. The key is a complete, auditable inventory with a stable identifier and a maintained risk tier. ¹

How many risk tiers do we need for PS-2?

NIST does not prescribe a number in the PS-2 excerpt. Pick tiers that produce real operational differences (screening, approvals, privileged access routing) and document the criteria. ¹

Do contractors and third parties need position risk designations?

If they occupy an organizational role with defined duties and access to in-scope systems or data, treat that role as a position for PS-2 purposes and designate its risk. Track exceptions explicitly if a population is out of scope. ¹

What evidence is most persuasive to auditors?

A complete position register with approvals, plus a few end-to-end workflow samples where the tier clearly changed approvals or access steps. Auditors respond well to traceability from job code to IAM role to ticket evidence. ¹

We designated roles, but nothing changes operationally. Is that still compliant?

Risk designations that do not drive any downstream action are hard to defend in an assessment because PS-2 is typically evaluated in the context of personnel and access controls. Tie tiers to concrete gates (requisition, provisioning, PAM) and retain proof. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON