Personnel Screening

To meet the FedRAMP Moderate personnel screening requirement, you must screen every individual before granting them access to the system and then rescreen them based on conditions and a cadence you define and enforce. Operationalize this by documenting screening criteria, integrating screening into onboarding and access provisioning, and retaining auditable proof for each person with system access. 1

Key takeaways:

  • You cannot provision system access until required screening completes and is recorded. 1
  • “Rescreening” is mandatory, but you must define the triggers and frequency and then follow them consistently. 1
  • Auditors will look for end-to-end traceability: person → screening result → access approval → rescreen events → access changes.

Personnel screening is an access control dependency, not an HR nice-to-have. In FedRAMP Moderate environments, the control expectation is simple: screen individuals before authorizing access to the system, then rescreen based on organization-defined conditions and frequency. 1 The operational challenge is equally simple: teams often run background checks, but they fail to connect them to access decisions, fail to define rescreen triggers, or cannot prove coverage for contractors, temporary staff, or third-party operators.

This requirement page is written for the Compliance Officer, CCO, or GRC lead who needs to implement PS-3 without ambiguity. You will leave with (1) a workable policy position, (2) a step-by-step process you can drop into onboarding and access provisioning, (3) a clean evidence list for audits, and (4) common “gotchas” that cause FedRAMP assessment findings.

This guidance stays at requirement level: what you must decide, what you must do, and what you must retain to show you did it.

Regulatory text

Requirement (PS-3): “Screen individuals prior to authorizing access to the system; and rescreen individuals in accordance with organization-defined conditions requiring rescreening and the frequency of rescreening.” 1

Operator interpretation:

  1. No screening, no access. Your process must prevent system access approval until screening completes (or until a documented, approved exception is granted under defined terms). 1
  2. Rescreening must be real, not aspirational. You must define rescreening triggers and a rescreening frequency, then execute against that definition with evidence. 1
  3. “Individuals” includes more than employees. Treat any human with authorized access as in scope: employees, contractors, interns, admins, support staff, and third-party personnel who access the system under your authority (for example, staff augmentation or managed services).

Plain-English requirement: what PS-3 means in practice

PS-3 is asking you to prove two things:

  • Before access: you made a risk-based trust decision about the person and documented it before granting access to the FedRAMP system boundary. 1
  • After access: you periodically reaffirm that trust decision, and you also re-check it when certain events happen (role changes, long gaps, adverse findings, or other triggers you define). 1

You get to choose the specific screening methods, the conditions that trigger rescreening, and the frequency of rescreening. You do not get to skip defining them, and you do not get to define them and then ignore them. 1

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating FedRAMP Moderate systems. 1

Operational scope (practical):

  • Anyone with logical access (SSO, VPN, console access, application accounts, privileged roles).
  • Anyone with administrative access (cloud platform admins, IAM admins, database admins, CI/CD admins).
  • Anyone with physical or facility access that could reasonably enable system access paths (if your environment ties physical access to system access decisions).
  • Third-party personnel who access the system as part of service delivery under your control (contractors, subcontractors, staff augmentation).

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

Step 1: Define your screening standard (policy-level)

Write a short “Personnel Screening Standard” that answers:

  • Who is in scope: roles and populations (employees, contractors, third-party personnel with access).
  • What “screened” means for each population: the screening checks you require (don’t over-specify in a way you cannot execute).
  • What constitutes “passed,” “failed,” and “review required.”
  • Who can approve exceptions and the compensating controls required if you ever allow time-bound access pending screening results (be conservative here).
  • Rescreening frequency and triggers: list the events that require rescreening and the cadence you will follow. 1

Deliverable: a controlled document with an owner, versioning, and an effective date.

Step 2: Wire screening into onboarding and access provisioning (process-level)

Make screening a gating item in the access workflow:

  • Joiner: HR/TA initiates screening request at offer-accept; IT/IAM provisions accounts only after “screening cleared” status is recorded.
  • Mover: role change triggers a check: does the new role require additional screening or an out-of-cycle rescreen?
  • Leaver: termination triggers immediate access revocation; record the termination event and downstream deprovision tasks.

If you rely on a third party for screening, define the handoff:

  • who submits the request,
  • how results are transmitted securely,
  • who reviews adjudication,
  • where evidence is stored.

Step 3: Implement rescreening operations (calendar + triggers)

You need two mechanisms:

  1. Time-based rescreening: a scheduled campaign that identifies all in-scope individuals due for rescreening and routes them through the same evidence capture path. 1

  2. Event-based rescreening: automatic or manual triggers such as:

  • promotion into privileged access,
  • break in service or rehire,
  • long inactivity followed by reactivation,
  • credible adverse information reported through HR/security channels,
  • contractual changes for third-party staff (new employer, subcontractor change).

Your triggers must be documented, and you must be able to show they fired and were handled. 1

Step 4: Connect screening outcomes to access decisions (control enforcement)

Define what happens on each outcome:

  • Cleared: proceed with access approval.
  • Review required: route to an adjudicator (HR/security) and keep access blocked until decision.
  • Not cleared: deny access; if the person already had access (rescreen), suspend or revoke promptly based on your risk decision.

Tie this to IAM:

  • privileged access requests must reference a valid screening record,
  • access reviews should flag accounts with missing or expired screening status.

Step 5: Build an auditor-ready evidence model (traceability)

Assessors want to sample people and see proof. Create a single roster view that shows:

  • person identity (name/ID),
  • role(s) and access level,
  • date screening initiated,
  • date screening completed,
  • decision (cleared/exception),
  • rescreen due date,
  • last rescreen date,
  • link to evidence.

If you manage this in Daydream, map each system user to a screening evidence object and track rescreen due status as a compliance task. The goal is quick sampling and clean closure when auditors ask for “five admins and their screening records.”

Required evidence and artifacts to retain

Keep artifacts in a way that supports sampling and does not expose unnecessary sensitive data.

Minimum evidence set (typical):

  • Personnel Screening policy/standard (current and prior versions).
  • Screening workflow documentation (joiner/mover/leaver and access request steps).
  • Roster of in-scope individuals with screening status and rescreen due dates.
  • Per-person evidence of screening completion and adjudication outcome (store results securely; retain the decision record even if raw reports are restricted).
  • Exception approvals (if any) with rationale, scope, and expiration.
  • Rescreening campaign records (who was due, who completed, who was overdue, what actions were taken).
  • Third-party contracts/clauses or onboarding checklists requiring screening before access for third-party personnel.

Common exam/audit questions and hangups

Expect these, and prepare your evidence package to answer them fast:

  • “Show me five individuals with privileged access and their screening records prior to access.” 1
  • “How do you prevent account provisioning before screening clears?”
  • “What are your defined rescreen conditions and frequency, and where are they documented?” 1
  • “Show me proof you rescreened people when the trigger occurred (role change, rehire, contractor swap).”
  • “How do you handle third-party personnel screening when they are not your employees?”
  • “Where is the authoritative roster of who has access to the FedRAMP boundary?”

Typical hangup: teams present an HR background check process but cannot prove it is a precondition to system access.

Frequent implementation mistakes (and how to avoid them)

  1. Screening happens, but access is granted first.
    Fix: make “screening cleared” a required field/workflow gate in IAM ticketing or identity governance before provisioning.

  2. Rescreening is defined vaguely (“periodically”).
    Fix: define a specific cadence and specific triggers in your standard and track due dates in a roster. 1

  3. Contractors and third-party operators are missed.
    Fix: require proof of screening (or equivalent) as a prerequisite in third-party onboarding, and include them in the access roster.

  4. Evidence is scattered across HR, email, and shared drives.
    Fix: centralize pointers to evidence in a system of record (GRC tool, ticketing system, or controlled repository). Daydream works well when you need structured, sample-ready evidence with owners and renewal tasks.

  5. Over-collection of sensitive screening details.
    Fix: store adjudication outcomes and completion confirmation; restrict raw reports to HR/security with need-to-know access.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page. Practically, PS-3 failures create two immediate risks:

  • Unauthorized or untrusted access to federal information processed in your environment.
  • Assessment findings when you cannot prove screening was completed prior to access or rescreening occurred as defined. 1

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

  • Publish the Personnel Screening Standard: scope, screening definition, rescreen triggers, rescreen cadence, exceptions, owners. 1
  • Build the authoritative “in-scope access roster” for the FedRAMP boundary.
  • Identify gaps: people with access but missing screening evidence, unclear contractor coverage, or no rescreen schedule.

Next 60 days (implement gates and evidence)

  • Add a hard gate to access provisioning: no ticket closure until screening is recorded.
  • Implement rescreen tracking: due dates, trigger events, and an escalation path for overdue items.
  • Centralize evidence: link each roster entry to the screening decision record and any exception approvals.

By 90 days (operate and prove)

  • Run your first rescreening cycle (time-based) and document outcomes.
  • Test event-based triggers with real scenarios (role change into privileged access, contractor rotation).
  • Conduct an internal sample test: pick a set of admins and demonstrate end-to-end traceability in under an hour.

Frequently Asked Questions

Does PS-3 require background checks specifically?

PS-3 requires you to “screen individuals” before authorizing system access, but it does not prescribe a single screening method in the provided text. Define what screening means for your organization, document it, and apply it consistently. 1

Who counts as an “individual” for personnel screening?

Treat any human who will be authorized to access the system as in scope, including employees, contractors, and third-party personnel performing operational work. Document your scope definition and apply it to your access roster. 1

Can we grant temporary access while screening is in progress?

PS-3 states screening occurs prior to authorizing access, so temporary access pending screening creates compliance risk. If you allow exceptions, document the approval authority, scope, duration, and compensating controls, and retain the exception artifact for audit.

What rescreening “conditions” should we define?

Use conditions tied to access risk and personnel lifecycle events, such as moves into privileged roles, rehire, or third-party staffing changes. The key is to define the triggers and then retain evidence that you executed rescreening when they occurred. 1

How do we handle screening for third-party personnel if their employer performs the checks?

Require contractual or onboarding proof that screening meeting your standard occurred prior to access, and record the adjudicated outcome in your evidence set. Include third-party personnel in your rescreen triggers and tracking if they retain access. 1

What’s the single best artifact to make audits easy?

A complete access roster for the FedRAMP boundary with screening completion dates, rescreen due dates, and links to the decision evidence. It turns sampling into a quick look-up instead of a multi-team scramble.

Footnotes

  1. NIST Special Publication 800-53 Revision 5

Frequently Asked Questions

Does PS-3 require background checks specifically?

PS-3 requires you to “screen individuals” before authorizing system access, but it does not prescribe a single screening method in the provided text. Define what screening means for your organization, document it, and apply it consistently. (Source: NIST Special Publication 800-53 Revision 5)

Who counts as an “individual” for personnel screening?

Treat any human who will be authorized to access the system as in scope, including employees, contractors, and third-party personnel performing operational work. Document your scope definition and apply it to your access roster. (Source: NIST Special Publication 800-53 Revision 5)

Can we grant temporary access while screening is in progress?

PS-3 states screening occurs prior to authorizing access, so temporary access pending screening creates compliance risk. If you allow exceptions, document the approval authority, scope, duration, and compensating controls, and retain the exception artifact for audit.

What rescreening “conditions” should we define?

Use conditions tied to access risk and personnel lifecycle events, such as moves into privileged roles, rehire, or third-party staffing changes. The key is to define the triggers and then retain evidence that you executed rescreening when they occurred. (Source: NIST Special Publication 800-53 Revision 5)

How do we handle screening for third-party personnel if their employer performs the checks?

Require contractual or onboarding proof that screening meeting your standard occurred prior to access, and record the adjudicated outcome in your evidence set. Include third-party personnel in your rescreen triggers and tracking if they retain access. (Source: NIST Special Publication 800-53 Revision 5)

What’s the single best artifact to make audits easy?

A complete access roster for the FedRAMP boundary with screening completion dates, rescreen due dates, and links to the decision evidence. It turns sampling into a quick look-up instead of a multi-team scramble.

Authoritative Sources

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream
FedRAMP Moderate Personnel Screening: Implementation Guide | Daydream