CMMC Level 2 Practice 3.9.1: Screen individuals prior to authorizing access to organizational systems containing CUI

CMMC Level 2 Practice 3.9.1 requires you to screen people (employees, contractors, and other authorized users) before granting them access to systems that contain CUI, and to keep evidence that the screening happened. Operationalize it by defining who must be screened, what “screening” means in your environment, and hardwiring a pass/fail gate into onboarding and access provisioning. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Key takeaways:

• Put a documented “screening completed” checkpoint in the identity/access approval workflow for any role that can reach CUI.
• Define screening criteria by role risk (not one-size-fits-all) and apply it to employees, contractors, and third parties with access.
• Retain durable evidence: requests, approvals, screening attestations/results, exceptions, and re-screen triggers mapped to CUI scope.

The fastest path to satisfying the cmmc level 2 practice 3.9.1: screen individuals prior to authorizing access to organizational systems containing cui requirement is to treat it as an access-control gate, not an HR formality. Your assessor will look for two things: (1) a clear rule that access to CUI systems is contingent on completing screening, and (2) proof that the rule is followed in real onboarding and access changes.

“Screening” is intentionally flexible. The requirement does not prescribe a specific background check package or a single universal standard. You have to define the screening steps that fit your risk, roles, and contract reality, then prove they happen before access is granted. That proof must tie to individual identities and to the specific systems (or roles) that can access CUI.

This page gives requirement-level implementation guidance you can put into production quickly: scope decisions, a step-by-step workflow, evidence to retain, audit questions you’ll get, and common ways teams fail this practice even with strong IAM. Source basis is the CMMC program and its mapping to NIST SP 800-171 Rev. 2. (32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Regulatory text

Excerpt / requirement basis: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.9.1 (Screen individuals prior to authorizing access to organizational systems containing CUI).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Operator interpretation (what you must do):

• Establish and follow a screening process for individuals before you grant them access to organizational systems containing CUI.
• Make “screening completed” a condition of access approval for in-scope systems/roles.
• Keep auditable records that connect the individual, the screening event, and the access authorization decision. (NIST SP 800-171 Rev. 2)

Plain-English interpretation

If someone can access CUI (directly or through systems that store/process/transmit it), you need to check that person is appropriate to trust with that access before you turn it on. This includes full-time staff, part-time staff, temps, consultants, and any third party personnel whose accounts you authorize.

Screening is broader than “criminal background check.” In practice it can include identity verification, employment verification, reference checks, adjudication against a policy, or other pre-access checks you define. The non-negotiable part is the sequence: screen first, authorize access second. (NIST SP 800-171 Rev. 2)

Who it applies to

Entities

• Defense contractors and federal contractors that handle CUI and must meet CMMC Level 2 requirements. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational context (where assessors focus)

• Any environment where CUI exists: enclave, corporate network segments, SaaS tenants, VDI, file shares, ticketing systems with CUI attachments, backup repositories, or endpoints used to access CUI.
• Any identity type that can reach CUI: employee accounts, contractor accounts, shared admin identities (which you should avoid), break-glass accounts, service desk elevated roles, and third party support accounts. (NIST SP 800-171 Rev. 2)

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

Step 1: Define “CUI access roles” (scope the people side)

Create a short list of roles that can access CUI systems or administer them. Keep it simple and defensible:

• CUI Users: engineers, program staff, analysts who open or create CUI.
• CUI System Admins: sysadmins, cloud admins, database admins for CUI systems.
• Security/IR/Forensics: responders with privileged access to CUI logs/data.
• Service Desk with elevation rights: roles that can reset MFA, grant group membership, or re-enable accounts tied to CUI access.

Output: a role-to-system mapping that shows which roles require screening prior to access. (NIST SP 800-171 Rev. 2)

Step 2: Define screening requirements by role risk (minimum viable but real)

Write a screening standard that answers four assessor questions:

1. What checks are performed?
2. Who performs them (HR, security, third party provider)?
3. What is the pass/fail rule?
4. What happens when someone fails or is pending?

A workable pattern:

• Baseline screening for all CUI Users (identity + employment/engagement verification + policy attestation).
• Enhanced screening for CUI System Admins and elevated roles (add stronger checks and stricter adjudication).

Avoid over-promising. If you cannot run a given check for certain geographies or contract types, document an alternate approach and an exception workflow. (NIST SP 800-171 Rev. 2)

Step 3: Build the “screening gate” into onboarding and access provisioning

This is where teams either pass or fail.

Implement a control point in your access workflow such that access to CUI systems/roles cannot be approved until screening is complete. Options:

• IAM/ITSM workflow control: Access request form includes a required field “Screening status = Completed” with an attachment or HR confirmation.
• HR-to-IAM integration: HR system status “Eligible for CUI access” must be true before group assignment.
• Manual approval gate: Security (or HR) signs off on a standardized checklist before IT grants access.

Minimum control objective: a reviewer can trace each user’s access approval back to a completed screening record with dates. (NIST SP 800-171 Rev. 2)

Step 4: Address third party personnel explicitly

Many CUI environments rely on third party engineers, MSSPs, or OEM support. Your process must cover them.

Operationalize with one of these models:

• Contractual attestation model: The third party attests (in writing) that it screened assigned personnel to your standard (or an agreed equivalent). You keep the attestation and list of named individuals.
• Sponsor + verification model: Your company sponsors the third party user, verifies identity, collects required attestations, and records screening completion before provisioning.

Tie this to access expiration: third party access should end when the engagement ends, and your workflow should enforce deprovisioning. (NIST SP 800-171 Rev. 2)

Step 5: Define re-screen triggers and exception handling

Even though 3.9.1 is “prior to authorizing,” assessors commonly probe what happens when risk changes.

Document triggers such as:

• Rehire after termination
• Role change into a privileged CUI-admin role
• Extended leave with account disablement and later reactivation
• Credible adverse information reported through HR or security channels

Exceptions must be rare and controlled:

• Who can approve an exception
• Compensating controls (short-lived access, heightened monitoring, limited scope)
• Time-bound review and closure evidence (NIST SP 800-171 Rev. 2)

Step 6: Map the practice to evidence capture (assessment readiness)

Create a simple control narrative: “How 3.9.1 works here,” where the evidence lives, who owns it, and how often you review it for completeness. This aligns with the recommended approach to map the practice to documented operation and recurring evidence capture. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

If you use Daydream for control mapping and evidence collection, treat 3.9.1 as a recurring control with a standing evidence request: new hire packets, contractor attestations, and access tickets tied to CUI groups. Daydream becomes the system of record for “show me” during assessment, without relying on scattered HR inboxes.

Required evidence and artifacts to retain

Keep evidence in a way that preserves confidentiality (screening records can be sensitive) while still proving control operation.

Core artifacts (retain at least):

• Screening policy/standard defining required checks by role and the “must be completed before access” rule. (NIST SP 800-171 Rev. 2)
• Role-to-CUI-system mapping (who is in scope and why).
• Access request/provisioning tickets showing:
  • requestor, approver, date/time
  • target system/role/group
  • screening completion indicator (attachment, reference number, or HR approval record)
• Third party screening attestations, plus list of named individuals and engagement dates.
• Exception approvals with compensating controls and closure evidence.
• Periodic internal review results (sample testing that screening preceded access for a set of users).

Practical tip: Store “proof of completion” (e.g., adjudication outcome) rather than detailed background check contents, unless your policy requires retaining full reports.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me a user with CUI access. Where is the evidence they were screened before access was granted?” (NIST SP 800-171 Rev. 2)
• “Do contractors and third party support staff go through the same gate?”
• “How do you prevent emergency provisioning from bypassing screening?”
• “What systems contain CUI, and how do you ensure access to those systems requires screening?”
• “Who adjudicates screening results, and what is the decision criterion?”

Hangups that slow teams down:

• HR owns screening, IT owns access, and nobody owns the join between them.
• CUI scope is unclear, so teams can’t clearly define which roles need screening.

Frequent implementation mistakes (and how to avoid them)

1. Policy says “screening required,” but workflows allow access first.
   Fix: enforce a technical or procedural gate in IAM/ITSM approvals that blocks CUI group assignment until screening is marked complete.

2. Screening exists for employees, not for contractors/third parties.
   Fix: add a third party personnel pathway (attestation or sponsor + verification) and require named individuals.

3. Evidence is not traceable to access events.
   Fix: link screening evidence to the access ticket (ID/reference) and retain it in a controlled repository.

4. Privileged access is treated the same as basic access.
   Fix: define enhanced screening requirements for roles that administer CUI systems, and document the adjudication standard.

5. Shared accounts or informal access sharing.
   Fix: eliminate shared logins for CUI systems and require individualized authorization tied to screening records. (NIST SP 800-171 Rev. 2)

Enforcement context and risk implications

No public enforcement cases specific to this practice were provided in the source catalog, so this page does not list cases. What matters operationally is assessment risk: if you cannot show screening occurred before access for a sample of users, assessors can view the practice as not met because it is a straightforward “before/after” control with objective evidence. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2; 32 CFR Part 170)

A practical 30/60/90-day execution plan

Next 30 days (stabilize the gate)

• Confirm CUI system scope and identify the groups/roles that grant access to CUI.
• Publish a short screening standard: roles in scope, checks required, who approves, and “no access until complete.” (NIST SP 800-171 Rev. 2)
• Update access request workflows to require screening completion for CUI roles.
• Start collecting evidence on every new CUI access grant.

Next 60 days (close coverage gaps)

• Extend the workflow to third party personnel and temporary staff.
• Add exception handling with time-bound approvals and compensating controls.
• Run an internal sample: pick several current CUI users/admins and back-check that screening evidence exists and predates access approval. Remediate gaps.

Next 90 days (make it durable)

• Automate where possible: HR status flags into IAM/SSO group provisioning, standard reports for auditors, and recurring evidence capture.
• Add re-screen triggers to your change management and HR offboarding/rehire process.
• Centralize artifacts (policy, mappings, tickets, attestations) in a single assessment-ready location (for example, a GRC workspace such as Daydream) so you can answer “show me” quickly.

Frequently Asked Questions

Does “screening” require a criminal background check?

The requirement states you must screen individuals before authorizing access to systems containing CUI, but it does not prescribe a specific check type in the provided text. Define screening steps that fit your risk and roles, document them, and enforce completion before access. (NIST SP 800-171 Rev. 2)

Do we have to screen existing users who already have access to CUI?

3.9.1 focuses on screening before authorization, so assessors will test whether your current process prevents granting new access without screening. For existing access, run a cleanup to ensure you have screening evidence on file or document remediation and any exceptions. (NIST SP 800-171 Rev. 2)

How do we handle third party support engineers who need short-term access?

Require a named-individual screening attestation from the third party or sponsor them through your internal screening gate before provisioning. Time-box access and keep the access ticket plus the attestation linked for audit. (NIST SP 800-171 Rev. 2)

Can HR simply confirm “screened” without sharing the background report?

Yes, many programs retain an HR adjudication outcome rather than full sensitive reports. Your evidence still must show screening completion occurred before access approval and identify the person and role. (NIST SP 800-171 Rev. 2)

What’s the cleanest way to prove “screened before access” during a CMMC assessment?

Maintain a traceable chain: screening record (or HR approval) with date, the access request/ticket with date, and the provisioning event tied to the same identity and CUI role. If those are stored in one evidence workspace, retrieval becomes predictable. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Our subcontractor says they screen their staff but won’t share details. Is that acceptable?

You can accept a written attestation if it is specific (named individuals or role-based roster, screening standard met, date) and you keep it as evidence linked to the access authorization. If the attestation is vague, treat it as a risk and tighten contract language or sponsor screening yourself. (NIST SP 800-171 Rev. 2)