03.09.01: Personnel Screening

NIST SP 800-171 Rev. 3 requirement 03.09.01 (Personnel Screening) expects you to screen personnel before granting them access to systems and environments that process, store, or transmit CUI, then retain proof the screening happened and is tied to access decisions. Operationalize it by defining screening levels by role risk, embedding checks into onboarding, and enforcing “no screen, no access.” ¹

Key takeaways:

• Screen people based on role risk before access to CUI systems, facilities, or projects is granted. ¹
• Make screening an access control gate: HR/People Ops completion must trigger IT provisioning approvals. ¹
• Keep defensible evidence: screening outcomes, adjudication decisions, and the linkage between “cleared” status and account enablement. ²

Personnel screening is one of the few controls where the failure mode is binary: an unvetted person gets access to CUI, and your other safeguards become harder to defend during an assessment. 03.09.01 sits in the Personnel Security family of NIST SP 800-171 Rev. 3 and is typically assessed through interviews plus artifacts that show your process is consistent, role-based, and actually used in onboarding and access provisioning. ³

For a Compliance Officer, CCO, or GRC lead, the fastest path to “audit-ready” is to treat screening like a control gate with owners on both sides: HR (completion and adjudication) and IT/Security (access is impossible without the screening status). Your documentation must show (1) what screening is required for which roles, (2) when it occurs (before access), (3) who can approve exceptions, and (4) how you retain evidence without leaking sensitive HR data into your SSP repository. ¹

Daydream (or any GRC system you use) becomes valuable here when it ties the requirement to your SSP narrative, control owner, and recurring evidence requests so screening doesn’t become a once-a-year scramble. ²

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.09.01 (Personnel Screening).” ¹

Operator interpretation: You must implement a personnel screening program appropriate to the role and risk, and you must complete the required screening before the person is granted access to CUI and the supporting system environment. In practice, assessors look for: documented screening criteria, consistent execution, and evidence that screening is tied to access decisions. ³

Plain-English interpretation (what 03.09.01 requires)

03.09.01 means you do not give someone access to CUI systems, CUI workspaces, or CUI projects until they’ve passed the screening level you require for that role. Screening must be consistent, documented, and proportionate: a software engineer with admin access to the CUI enclave should not be screened the same way as a short-term visitor with no access. ¹

This is not just an HR policy. It is an access control dependency. If your identity and access management process can enable accounts while HR screening is “in progress,” you should assume an assessor will treat the control as not implemented. ²

Who it applies to

Entities: Nonfederal organizations that process, store, or transmit CUI, including federal contractors and subcontractors where NIST SP 800-171 is a contractual requirement. ¹

Operational context (where it shows up):

• Employees (full-time, part-time) with any access to CUI systems or CUI projects
• Contractors/consultants (including staff augmentation) who touch CUI, administer systems, or can access CUI environments
• Interns/temporary workers if they have access pathways (accounts, shared drives, ticketing systems containing CUI)
• Privileged roles (system admins, security admins, backup admins) supporting CUI environments, even if they “don’t read CUI” in their normal work

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

Step 1: Define screening tiers tied to role risk

Create a simple matrix that maps role categories to screening requirements and access eligibility. Keep it role-based to avoid ad hoc decisions.

Example role-to-screening matrix (customize):

Role category	Typical access	Screening requirement	Access rule
No CUI access	No logical or physical access to CUI areas	Basic identity verification	No CUI system accounts
CUI user	Reads/creates CUI in approved apps	Background check + identity verification	Must be “cleared” before account enablement
Privileged (CUI admin)	Admin rights in CUI enclave, logging, backups	Enhanced screening + documented adjudication	Must be “cleared” before privileged group assignment
Third-party support	Remote support tools, system maintenance	Screening + contractual personnel requirements	Must be screened before remote access enabled

Document who owns the matrix (HR + Security) and who approves changes (Compliance/GRC or CISO). ¹

Step 2: Put screening into onboarding as a hard gate

Build a workflow where screening completion is a prerequisite for access provisioning.

Minimum gating pattern:

1. Hiring manager requests role and access profile.
2. HR initiates required screening package for that role tier.
3. HR records outcome (“meets requirements” / “does not meet” / “exception approved”) in a system of record.
4. IT provisions accounts only after HR status is “meets requirements” (or exception is documented and approved).
5. Security reviews privileged assignments before activation where applicable.

If your ITSM/IAM tools can’t enforce the gate automatically, enforce it procedurally with a required HR approval artifact attached to the access request ticket. ²

Step 3: Define adjudication and exception handling

Screening programs fail in audits when “exceptions” are informal.

Create a short adjudication standard:

• What outcomes disqualify access to CUI roles
• Who adjudicates borderline results (named role, not a person)
• What documentation is required for an exception
• Compensating controls for exceptions (for example, restricting to least privilege roles, heightened monitoring, or limiting access scope)

Ensure exceptions are time-bound and reviewed. Use your POA&M if an exception represents a known gap that requires remediation, not a permanent workaround. ¹

Step 4: Cover transfers, rehires, and role changes

Add triggers beyond new hires:

• Promotion into privileged roles
• Transfer into a CUI program
• Contract renewals for staff augmentation
• Rehires after a break in service

Operationally, the requirement is met when your access provisioning process re-checks screening eligibility at the time access is granted or expanded. ²

Step 5: Define rescreening logic (event-driven)

Avoid unsupported “every X years” claims unless your contract or internal policy requires it. Use event-driven rescreening:

• New privileged access
• Extended leave followed by reactivation
• Policy violations or HR investigations
• Change in contract/customer requirements for a specific program

Document the triggers and who evaluates them. ¹

Step 6: Map it into the SSP and operationalize evidence collection

In your System Security Plan:

• Describe screening tiers and the access gate
• Identify in-scope systems (CUI enclave, identity provider, HR system of record, ITSM)
• Name control owners (HR owner + Security/IAM owner)
• Point to where evidence lives and how it is protected

In Daydream, treat 03.09.01 as an evidence-driven control with recurring requests to HR/IAM for proof of operation (for example, a sample of onboarding tickets showing screening approval before access). This keeps evidence current and reduces end-of-quarter drills. ²

Required evidence and artifacts to retain

Keep evidence that proves screening happened before access and was appropriate to role. You also need to balance this with HR confidentiality.

Recommended artifacts:

• Personnel screening policy and role-based screening matrix (approved, versioned) ¹
• Onboarding workflow documentation showing screening as a prerequisite (HR SOP + IT provisioning SOP) ²
• Access request tickets (or IAM approvals) with an attached HR screening approval indicator ²
• Screening completion log or HR system report (redacted to minimum necessary fields)
• Exception register with approvals and compensating controls
• Samples for contractors and third-party personnel (showing screening requirements flowed down contractually if applicable to your environment)

Evidence hygiene tip: Store full background reports in HR systems, not in GRC folders. In GRC, store an attestation or status record plus a pointer to the authoritative HR record. ²

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me that screening is completed before CUI access is granted.” ²
• “How do you decide what level of screening applies to each role?” ¹
• “How do you handle contractors and third-party support staff?” ¹
• “Where is the evidence, and how do you protect HR-sensitive information?” ²
• “What happens if someone fails screening after an account was created?” ²

Hangups that slow audits:

• HR says “screening is done,” but IT can’t prove it was done before account activation.
• Screening is performed, but role definitions are fuzzy, so the “appropriate” part can’t be defended.
• Contractors are handled outside normal onboarding, so the gate is bypassed.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating screening as a policy statement only.
   Fix: Make it an access control gate in ITSM/IAM with required HR approval evidence. ²

2. Mistake: One-size-fits-all screening with no role linkage.
   Fix: Maintain a role-based matrix that ties screening depth to access risk and privilege. ¹

3. Mistake: No documented adjudication for exceptions.
   Fix: Create an exception register with named approvers and compensating controls, and connect long-lived gaps to POA&M items. ¹

4. Mistake: Contractors bypass HR workflows.
   Fix: Route third-party personnel through an equivalent gate, either through your HR process or a contractual attestation plus verification before access is enabled. ¹

5. Mistake: Evidence is over-collected and leaks sensitive HR details.
   Fix: Store screening status and decision metadata in GRC; keep detailed reports in HR systems with restricted access. ²

Risk implications (why operators should care)

Personnel screening reduces the chance that a malicious insider, someone using a false identity, or an undisclosed conflict enters a CUI environment with legitimate credentials. Operationally, weak screening also raises second-order risks: incident response scope grows, access reviews become less trustworthy, and disciplinary actions are harder to execute consistently. For CUI programs, screening gaps frequently cascade into findings across access control and auditability because the organization cannot show that only authorized, vetted individuals were granted access. ³

Practical execution plan (30/60/90)

Use a staged plan to get to “operating and evidenced,” then harden.

First 30 days (establish the gate)

• Define in-scope population: all roles with CUI access paths (logical and physical). ¹
• Publish a role-based screening matrix and assign owners (HR + Security/IAM). ¹
• Update onboarding workflow so accounts cannot be enabled without screening status approval evidence. ²
• Start an exception register and require named approvals.

Days 31–60 (prove it operates)

• Run a sample-based internal check: pick recent hires and confirm timestamps show screening completed before account activation. ²
• Expand coverage to contractors and third-party support, including contract language and access request workflow alignment. ¹
• Add role-change triggers (promotion to admin, transfer into CUI project) into HR/IT workflows. ²
• In Daydream, set recurring evidence tasks: onboarding tickets, HR screening status reports (redacted), exception approvals. ²

Days 61–90 (harden and reduce audit friction)

• Validate privileged access assignments: confirm enhanced screening is consistently applied before admin access. ¹
• Document rescreening triggers and align them to HR and Security processes. ¹
• Update SSP language to clearly describe the workflow, system boundaries, and evidence sources. ²
• Close gaps through POA&M: track remaining tool limitations, contractor edge cases, and evidence weaknesses with owners and closure criteria. ¹

Frequently Asked Questions

Does 03.09.01 require background checks for every employee?

The requirement is personnel screening appropriate to risk and access. Define screening tiers by role, then enforce the tier before CUI access is granted. ¹

Can we provision accounts before screening completes if we keep them disabled?

That can work if your process proves the account cannot be used to access CUI until screening is approved. Keep evidence that enablement occurred only after screening status was cleared. ²

How do we handle contractors from a third party who claim they already screened the person?

Treat it as a control dependency: require a contractual obligation and an attestation or evidence that meets your screening tier before you grant access. Document how you validate and retain proof without collecting unnecessary HR details. ¹

What evidence should we show an assessor without exposing sensitive HR information?

Provide a screening status record (completed/approved, date, role tier, approver) and a pointer to the HR system of record for details. Keep full reports in HR-controlled repositories with restricted access. ²

What’s the fastest way to fail this control in an assessment?

Having even a small set of users with CUI access where you cannot show screening was completed before access. Assessors test this through sampling of onboarding and access grant records. ²

How should we reflect personnel screening in the SSP and POA&M?

In the SSP, describe the screening tiers, the access gate, owners, and evidence locations. If parts are not yet enforced or have exceptions, track them in the POA&M with closure criteria and validation steps. ³

Footnotes

1. NIST SP 800-171 Rev. 3

2. NIST SP 800-171A

3. NIST SP 800-171 Rev. 3; Source: NIST SP 800-171A