PS-3: Personnel Screening
PS-3 requires you to screen people before you grant them access to an information system, and to be able to prove that screening happened before access was authorized. Operationally, this means defining screening criteria by role/risk, embedding screening as a hard gate in onboarding and access provisioning, and retaining auditable evidence that ties each access grant to a completed screen. 1
Key takeaways:
- Make screening a provisioning prerequisite, not an HR “nice to have,” and enforce it in your access workflow.
- Define screening depth by role risk (privileged admins, developers, contractors, third parties) and document exceptions.
- Retain evidence that links “screen completed” to “access approved,” plus re-screen triggers for role changes.
The ps-3: personnel screening requirement is easy to describe and easy to fail in practice: you must screen individuals before authorizing system access, and you must be able to demonstrate that sequencing to an assessor. The gap usually appears at handoffs: HR completes a background check, IT grants access, and nobody can later show that the check was complete before the first login. Another common issue is scope. Teams apply screening to employees but forget contractors, interns, temporary staff, or third-party personnel who receive direct accounts or privileged access paths.
PS-3 is part of NIST SP 800-53 Rev. 5’s Personnel Security family and is commonly inherited into federal systems and contractor environments handling federal data. Your job as a CCO, CISO, or GRC lead is to convert the one-line requirement into an enforceable operational gate, a documented procedure, and a repeatable evidence package. Done well, PS-3 reduces insider threat exposure, lowers the chance of unauthorized access by high-risk individuals, and prevents audit findings tied to “access granted without required preconditions.” 2
Requirement: PS-3 Personnel Screening (implementation guidance)
Control intent: prevent unvetted individuals from getting access to systems by requiring screening before authorization. 1
Plain-English interpretation
PS-3 means:
- You decide what “screening” is for your environment (by role/risk).
- You complete that screening for an individual.
- Only then do you authorize access to the system. 1
For exam readiness, auditors care about two things:
- Gating: Is screening a true prerequisite, or can access be granted while screening is “pending”?
- Evidence & traceability: Can you prove the screen was completed before access approval for a sample of users?
Regulatory text
Excerpt: “Screen individuals prior to authorizing access to the system; and” 1
Operator translation: You must build a control that prevents access authorization until required screening checks are complete, then retain records that show the control operated as designed (screen completed → access approved).
Who it applies to (entity and operational context)
PS-3 is most directly applicable when you operate:
- Federal information systems, including agency-run environments. 2
- Contractor systems handling federal data, where 800-53 controls are contractually flowed down (common in ATO/FedRAMP-adjacent programs). 2
Operationally, apply it anywhere you authorize accounts or access paths, including:
- Employee onboarding (all workforce members with accounts)
- Privileged access (admins, cloud console users, security tools)
- Developer access (source control, CI/CD, production break-glass)
- Contractor and third-party personnel who receive direct credentials
- Physical/remote access that effectively grants system access (e.g., VPN, VDI)
What you actually need to do (step-by-step)
Step 1: Define screening tiers by role risk
Create a Personnel Screening Standard that maps:
- Population (employee, contractor, intern, third-party personnel with direct access)
- Role category (standard user, privileged user, developer, security admin)
- Required screening components (what checks, who performs them, what “pass” means)
- Disqualifiers and adjudication (who reviews hits and approves exceptions)
- Re-screen triggers (role change into privileged, long break in service, policy exceptions)
Keep the standard short and enforceable. If you can’t explain it to HR and IAM in one page, it won’t gate access.
Step 2: Make screening a hard gate in onboarding and IAM provisioning
Wire PS-3 into your access workflow so that “screen completed” is a required condition to provision accounts. Common patterns:
- HRIS-driven gate: HR sets a “screening complete” flag that downstream IAM requires.
- ITSM gate: Access request workflow requires an attached screening attestation or HR confirmation before approval.
- IGA/PAM gate: Identity governance or PAM system requires a screening attribute before granting privileged roles.
Key operational rule: No shared mailboxes, local accounts, or “temporary” accounts as a workaround for pending screening. If the business insists, treat it as an exception with compensating controls and documented approval.
Step 3: Handle contractors and third parties explicitly
PS-3 failures often come from external personnel. Decide which model you support and document it:
- Your screening: you screen the individual directly (common for onsite/privileged contractors).
- Employer attestation: the contracting firm attests screening completion to your criteria, and you store the attestation.
- No direct access: third-party personnel use the third party’s environment with federated access or managed service boundary, reducing direct account issuance.
Pick one per access scenario, then enforce it consistently.
Step 4: Define the “authorization” moment and control point
Auditors will ask what “authorizing access” means in your environment. Define it precisely, for example:
- Account created in directory
- Added to privileged group
- Granted console access in cloud tenancy
- Issued VPN credentials
- Enabled in PAM vault
Then ensure screening gates that moment, not a later HR milestone.
Step 5: Document exceptions and emergency access
You will have real-world pressure: incident response, urgent production support, M&A onboarding. Create an Exception Procedure:
- Who can approve (role-based)
- What compensating controls apply (time-bound access, enhanced monitoring, least privilege)
- How evidence is retained
- When screening must be completed retroactively (and consequences if it fails)
Keep exceptions rare and visible. If exceptions become normal throughput, PS-3 is not operating.
Step 6: Set ownership and recurring evidence
Assign:
- Control owner: usually HR/security compliance jointly, with IAM as operator
- Operators: HR (screening execution), IAM/IT (access provisioning gate), GRC (evidence and testing)
- Cadence: periodic sampling tests of new access grants against screening completion
If you use Daydream, map PS-3 to a control owner, a written procedure, and a standard evidence checklist so evidence collection is not reinvented each audit cycle. 1
Required evidence and artifacts to retain
Aim for artifacts that prove sequencing (screen first, access second) and scope (all in-scope populations covered).
Policy & procedure
- Personnel Screening Standard (tiers, populations, triggers)
- Access Provisioning Procedure showing screening as a prerequisite
- Exception Procedure (emergency access and compensating controls)
Operational records (auditor sampling pack)
- Screening completion record per sampled individual (or HR attestation)
- Access request / ticket showing approval timestamp and the gating field
- IAM/IGA logs showing when account/role was granted
- Contractor/third-party screening attestations (if applicable)
- Exception approvals with start/end dates and monitoring evidence
Control operation evidence
- Periodic access-onboarding sample test results (pass/fail, remediation notes)
- Metrics you track internally (qualitative is fine) showing exceptions and cleanup actions
Common exam/audit questions and hangups
Expect questions like:
- “Show five users who received privileged access last quarter; prove screening was completed first.”
- “Do contractors and third-party personnel get screened to the same standard?”
- “What is your definition of ‘authorized access’ for cloud admin roles?”
- “How do you prevent a manager from provisioning access outside the workflow?”
- “Show your exception list and how you monitor it.”
Hangups that drive findings:
- HR confirms screening “in email,” but there’s no retained artifact tied to the access ticket.
- Access was granted based on “screen initiated” rather than “screen completed.”
- The system boundary is unclear, so teams screen for corporate apps but not for production systems.
Frequent implementation mistakes (and how to avoid them)
| Mistake | Why it fails PS-3 | Fix |
|---|---|---|
| Treating screening as HR-only | IT can grant access without proof | Add a mandatory screening-complete field to provisioning approval |
| “Pending check” accounts | Screening did not precede authorization | Block provisioning until completion; route urgent needs to exceptions |
| Ignoring third-party personnel | External accounts are still individuals | Require employer attestation or screen directly before issuing credentials |
| No definition of “authorization” | Evidence can’t prove sequencing | Define the exact control point (account creation, group membership, PAM role) |
| Evidence scattered across tools | Sampling becomes painful and incomplete | Centralize evidence links in the access ticket or GRC repository |
Enforcement context and risk implications
No public enforcement cases were provided in the source material for this requirement, so don’t build your program around assumed penalty narratives.
Risk you can state plainly:
- If you can’t prove screening-before-access, you risk assessment findings, delayed ATO decisions, and increased insider threat exposure.
- Weak screening gates amplify the impact of credential theft or improper access approvals because the control fails at the earliest trust decision point. 2
Practical 30/60/90-day execution plan
First 30 days (stabilize and define)
- Name the PS-3 control owner and operators (HR, IAM, GRC).
- Write the one-page Personnel Screening Standard with role tiers and in-scope populations.
- Define “authorization moment” for your key systems (directory, cloud, PAM, VPN).
- Inventory current onboarding/provisioning paths and identify bypass routes (manual admin adds, local accounts).
Days 31–60 (build the gate and evidence trail)
- Implement the gating mechanism in HRIS/ITSM/IGA so access approval requires screening completion.
- Add contractor/third-party screening attestation intake and retention workflow.
- Draft the exception procedure and require time bounds and compensating controls.
- Build an “audit bundle” template: for any access grant, store the screening reference and timestamps.
Days 61–90 (operate, test, and harden)
- Run an internal sample test of recent hires and privileged grants; document gaps and remediation.
- Clean up bypass routes: restrict direct admin adds, enforce PAM, tighten group management.
- Train HR and hiring managers on what triggers screening and what blocks start dates or access.
- In Daydream, map PS-3 to the owner, procedure, and recurring evidence artifacts so future audits pull from a consistent source of truth. 1
Frequently Asked Questions
Does PS-3 apply to contractors and third-party personnel?
Yes if they are individuals you authorize to access the system. If you don’t screen them directly, retain an employer/agency attestation that matches your screening criteria before you issue credentials. 1
What counts as “authorizing access” for PS-3?
Define it as the point where the person can actually access the system, such as account creation, group membership, VPN enablement, or privileged role assignment. Then gate that exact step on screening completion. 1
Can we grant access while a background check is in progress if the manager approves?
That creates a sequencing failure against PS-3 unless you treat it as an exception with documented approval and compensating controls. Make “screen complete” the default prerequisite for access. 1
We use a staffing firm. Is their background check enough?
It can be, but only if you define your screening criteria and retain evidence that the staffing firm screened to those criteria before access was granted. Keep the attestation tied to the access request record. 1
How do we show evidence without storing sensitive background check details?
Store the minimum proof needed for audit: completion status, date/time, screener identity, and an attestation reference. Keep detailed reports in HR-controlled systems with restricted access and link by identifier. 1
What’s the fastest way to get PS-3 “audit-ready”?
Put the gate in the provisioning workflow and run a sample test to prove it works end-to-end. Auditors usually accept a clean trail for sampled access grants plus clear procedures and exception handling. 1
Footnotes
Frequently Asked Questions
Does PS-3 apply to contractors and third-party personnel?
Yes if they are individuals you authorize to access the system. If you don’t screen them directly, retain an employer/agency attestation that matches your screening criteria before you issue credentials. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
What counts as “authorizing access” for PS-3?
Define it as the point where the person can actually access the system, such as account creation, group membership, VPN enablement, or privileged role assignment. Then gate that exact step on screening completion. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
Can we grant access while a background check is in progress if the manager approves?
That creates a sequencing failure against PS-3 unless you treat it as an exception with documented approval and compensating controls. Make “screen complete” the default prerequisite for access. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
We use a staffing firm. Is their background check enough?
It can be, but only if you define your screening criteria and retain evidence that the staffing firm screened to those criteria before access was granted. Keep the attestation tied to the access request record. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
How do we show evidence without storing sensitive background check details?
Store the minimum proof needed for audit: completion status, date/time, screener identity, and an attestation reference. Keep detailed reports in HR-controlled systems with restricted access and link by identifier. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
What’s the fastest way to get PS-3 “audit-ready”?
Put the gate in the provisioning workflow and run a sample test to prove it works end-to-end. Auditors usually accept a clean trail for sampled access grants plus clear procedures and exception handling. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream