Position Risk Designation

To meet the position risk designation requirement, you must classify every role that can affect your FedRAMP system by risk level, define the screening checks required for people in each risk level, and revalidate those designations on a set cadence. This is a PS-2 expectation in NIST SP 800-53 Rev. 5 and should be operationalized through HR onboarding, access provisioning, and role change workflows. ¹

Key takeaways:

• Build a complete role inventory, then assign each role a documented risk designation tied to system impact.
• Map each designation to required screening criteria, and enforce it through hiring and contractor onboarding gates.
• Review and update designations on an organization-defined frequency, triggered by system and role changes. ¹

“Position Risk Designation” sounds like a paperwork control until an assessor asks you to prove two things: (1) every position with access or influence over the FedRAMP boundary has been risk-rated, and (2) you consistently screen people into those positions based on that rating. PS-2 is explicit that you need all three components: risk designations for all positions, screening criteria for individuals filling them, and periodic review and updates at a defined frequency. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PS-2 as a join between your HR job/role catalog and your identity and access management (IAM) role-based access controls. If HR titles do not align to access roles, you will struggle to show coverage and consistency. If screening is handled outside your control (staffing firms, subcontractors, or a parent company), you still need contractable requirements and evidence.

This page gives you requirement-level implementation guidance you can execute quickly: who must do what, how to define risk levels without overengineering, how to embed checks in workflows, and what evidence you will need in an assessment.

Regulatory text

Requirement (PS-2): “Assign a risk designation to all organizational positions; establish screening criteria for individuals filling those positions; and review and update position risk designations at an organization-defined frequency.” ¹

Operator interpretation: You need a documented method to (a) label every position with a risk designation, (b) define the screening checks required for individuals placed into each designation, and (c) revalidate that labeling on a defined cadence, plus whenever roles or systems change in a way that affects risk. The assessor will test both design quality and operational execution. ¹

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

PS-2 requires that you make staffing risk explicit and controllable. If a role can materially affect confidentiality, integrity, or availability of the FedRAMP system (or its supporting processes), you must:

• Pre-classify the role (not the person) by risk.
• Apply screening that matches the role risk before granting the role (or the access that comes with it).
• Keep the classification current as responsibilities, architecture, and access patterns evolve. ¹

A practical way to think about it: PS-2 is “role risk + screening gates + periodic refresh.”

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) operating a FedRAMP Moderate authorized or in-process system.
• Federal agencies operating systems aligned to the FedRAMP Moderate baseline. ¹

Operational scope you should include:

• Employees, contractors, interns, temporary labor, and other non-employees who perform roles affecting the system.
• Third parties who administer, develop, secure, operate, monitor, or support the system (including managed service providers), if they fill organizational “positions” in your operating model.

Where teams get tripped up: limiting PS-2 to “IT admins only.” PS-2 says all organizational positions, so your method must cover the full role catalog, with special attention to roles that can touch the FedRAMP boundary. ¹

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

Step 1: Define your position universe (the inventory)

Create (or export) a list of positions/roles from:

• HR job catalog (titles, job families, levels)
• IAM role catalog (privileged roles, admin groups)
• SDLC roles (developers, release managers)
• Security roles (SOC, incident responders)
• Operations roles (SRE, database admin)
• Support roles (customer support with production access, support engineers)
• Third-party roles (contractor job descriptions, MSP admin roles)

Output: “Position Inventory” with a unique identifier per position and an owner.

Step 2: Create a simple, auditable risk designation scheme

You need a scheme that your HR and IT teams can apply consistently. A common model is three tiers (for example, Low/Moderate/High), but PS-2 does not prescribe tiers; it requires that you assign designations and can justify them. ¹

Minimum decision criteria to document:

• Does the role require privileged access?
• Does it have ability to change production configurations/code?
• Does it handle sensitive system data or security logs?
• Does it approve access, keys, or security exceptions?
• Does it influence incident response, vulnerability remediation, or audit evidence?

Output: “Position Risk Designation Standard” describing tiers and decision rules.

Step 3: Assign a risk designation to every position

Apply the standard to each position in your inventory.

Practical mapping examples (adjust to your environment):

• High: cloud platform admins, IAM admins, security engineers with key management, DBAs with production write access, release managers with deploy authority.
• Moderate: developers with merge rights, support engineers with temporary production access, SRE on-call with break-glass access.
• Low: roles with no system access or only general corporate IT access.

Output: “Position Risk Register” (or spreadsheet/table) showing each position, designation, rationale, and approval.

Step 4: Establish screening criteria per risk level

PS-2 requires you to establish screening criteria for individuals filling those positions. ¹

What “screening criteria” should look like in practice:

• A table that states, per designation:
  • required identity verification steps
  • background screening requirements (as allowed by law and jurisdiction)
  • reference checks or employment verification expectations
  • additional checks for privileged roles (for example, conflict-of-interest disclosures, enhanced review)
  • required training prerequisites before access is provisioned

Keep this implementable. If criteria are too complex, HR and your staffing firms will bypass them.

Output: “Screening Matrix by Position Risk Designation,” plus procedures that explain who initiates, who approves, and what evidence is retained.

Step 5: Embed gating into onboarding, role change, and access provisioning

Designations and screening are meaningless unless they stop access from being granted prematurely.

Implement gates in the workflows you already run:

• Hiring / contractor onboarding: offer letter or SOW cannot proceed to system access until screening evidence exists for the role’s designation.
• Transfers / promotions: role changes trigger re-screening if the new designation is higher, and a review even if equal.
• Privileged access: IAM workflow requires a “PS-2 screening complete” attestation or evidence link before adding to privileged groups.

Operational tip: If you cannot integrate systems quickly, use a manual control with a ticket template that requires (a) position designation, (b) screening completion evidence, and (c) approver sign-off.

Step 6: Set the “organization-defined frequency” and define triggers

PS-2 requires review and update at an organization-defined frequency. ¹

Make it defensible and tied to change:

• Define a periodic review cadence (document it).
• Define event-based triggers, such as:
  • major system architecture change
  • new production environment or expansion of FedRAMP boundary
  • IAM role redesign
  • acquisition of a new third party that will administer the system
  • creation of a new job family or material job description change

Output: “PS-2 Review Procedure” and review logs showing decisions and updates.

Step 7: Test the control (spot checks)

Before an assessment, run spot checks:

• pick a sample of individuals in high-risk positions
• confirm their screening evidence matches the matrix
• confirm access grants occurred after screening completion
• confirm position designation exists and is current

This gives you a fast read on whether PS-2 is operating or only documented.

Required evidence and artifacts to retain

Aim for evidence that ties together role → designation → screening → access decision:

1. Position inventory with unique role IDs and owners.
2. Position risk designation standard (definitions, criteria, approval authority).
3. Position risk register listing all positions and designations, with rationale and approval.
4. Screening criteria matrix mapped to each designation. ¹
5. Procedures/work instructions for HR, Security, and hiring managers.
6. Workflow evidence (tickets, HRIS/IAM records) showing screening completed before access.
7. Review and update records showing periodic review occurred at the defined frequency. ¹
8. Third-party contract artifacts (SOW language, onboarding checklists) requiring screening to your criteria for third-party personnel in designated positions.

If you use Daydream to manage control operations, treat Daydream as the system of record for the role inventory, designation register, evidence links, and review tasks, so you can answer assessor sampling requests quickly without hunting across HR, ticketing, and IAM tools.

Common exam/audit questions and hangups

Assessors and auditors tend to focus on consistency and completeness:

• “Show me your complete list of organizational positions and their risk designations.”
  Hangup: incomplete inventory or only IT roles.

• “How do you decide whether a role is high risk?”
  Hangup: no written criteria; decisions live in someone’s head.

• “Show evidence that screening was performed for these sampled individuals before they were granted access.”
  Hangup: screening exists, but timestamps do not align with access grants.

• “What is your defined frequency for reviewing position risk designations, and show the last review?” ¹
  Hangup: frequency not documented, or review not performed.

• “How do you handle contractors and third-party admins?”
  Hangup: reliance on third parties without contractual requirements or retained evidence.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Confusing job titles with access roles.
   Fix: maintain a crosswalk between HR positions and IAM groups, and designate based on actual access potential.

2. Mistake: Screening criteria are vague (“background check required”).
   Fix: define what “complete” means operationally (who runs it, what artifact proves it, where it’s stored).

3. Mistake: No re-screening or review when roles change.
   Fix: make promotions/transfers trigger a PS-2 check, and require review for any designation increase.

4. Mistake: Treating PS-2 as a one-time spreadsheet exercise.
   Fix: operationalize review cadence and change triggers; keep a review log.

5. Mistake: Contractors are out of scope.
   Fix: require screening alignment in contracts and onboarding checklists; retain evidence.

Risk implications (why operators care)

If you mis-designate roles or fail to enforce screening gates, you create a predictable path for insider risk: privileged access is granted without the organization’s intended level of scrutiny. In FedRAMP contexts, this also creates an assessment failure mode because PS-2 is easy to sample and disprove with a small number of mismatches between access records and screening evidence. ¹

Practical execution plan (30/60/90-day)

First 30 days (Immediate)

• Name an owner for PS-2 (often GRC with HR + Security partners).
• Build the initial position inventory by merging HR + IAM + SDLC roles.
• Draft the risk designation standard and get Security + HR approval.
• Create the first version of the position risk register for all roles in scope of the FedRAMP boundary.

By 60 days (Near-term)

• Publish the screening matrix by designation and align it to HR and staffing workflows.
• Implement gating in at least one workflow (ticket template or HRIS/IAM check) for privileged access roles.
• Backfill evidence for current high-risk role incumbents, or document gaps and remediation actions.

By 90 days (Operationalize and prove)

• Expand gating to transfers, promotions, and contractor onboarding.
• Run a PS-2 internal sample test (role → screening → access timing) and fix failures.
• Execute the first documented review cycle and capture review minutes/approvals.
• Centralize artifacts and evidence pointers (Daydream can serve as the control hub for registers, tasks, and evidence links).

Frequently Asked Questions

Do we have to assign a risk designation to roles with no system access?

PS-2 says “all organizational positions,” so your method should cover the full catalog. The practical approach is to designate low-risk roles explicitly and focus screening gates on roles that can affect the FedRAMP system. ¹

Can we use existing HR job levels (L1–L7) as the risk designation?

You can, but only if job level reliably correlates to system impact and access. Most teams still need an access-informed overlay so privileged roles are consistently captured.

What counts as “screening criteria” under PS-2?

PS-2 requires defined criteria for individuals filling designated positions, plus evidence that you follow it. Your criteria should be specific enough that HR and third parties can execute it and produce consistent artifacts. ¹

How should we handle third-party personnel who administer our cloud environment?

Treat them as filling organizational positions in your operating model. Contractually require screening that meets your criteria, and retain evidence or verifiable attestations aligned to your process.

What should trigger an out-of-cycle update to position risk designations?

Any change that materially affects access or impact should trigger review: new privileged IAM roles, boundary changes, new production support model, or a new third party with administrative responsibilities.

What evidence do assessors usually ask for first?

The position risk register, the screening matrix, and a sample set showing screening completion before access was granted for high-risk roles. They also ask for proof of periodic review at your defined frequency. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5