PS.L2-3.9.1 Screen individuals: CMMC requirements and evidence

What PS.L2-3.9.1 screen individuals requires before CUI access

PS.L2-3.9.1 requires that individuals are screened before the organization authorizes their access to systems that contain CUI, and the type of screening is set by the position and role each person fills. Picture a new engineer or a subcontractor's technician who needs an account on a system holding CUI. The compliance lead must be able to show that a screening decision was made and recorded before that account was granted, not after. The requirement is a basic personnel security control taken from NIST SP 800-171 Rev. 2, and the assessment objective in NIST SP 800-171A is narrow: screening happens before authorization. The depth of screening is the organization's decision, so the assessor will look for a defined basis for it.

Under the CMMC Scoring Methodology, PS.L2-3.9.1 is a 3-point requirement, deducted from the maximum score of 110 if it is NOT MET. Because it carries more than 1 point, it cannot be placed on a plan of action and milestones, so it must be MET before the organization can reach Conditional or Final Level 2 status. A gap here cannot be carried forward as a dated remediation item. The risk it addresses is an individual with access to CUI who was never checked against the responsibilities that access carries, which weakens the identity assurance that IA.L2-3.5.2 depends on. The CMMC Assessment Guide ties screening to that authentication role, so the two requirements should be reviewed together.

In practice this requirement is hard for two reasons. The first is that many organizations have never written down role criteria: no document says which positions handle CUI, which screening steps apply to each, or who approves an exception. The second is missing records. Assessors look for screening procedures and records of screened personnel, and they interview the staff who run screening. A contractor that screens people informally, or that cannot match a screening record to a specific account, will struggle to show the objective is met. Start by listing every role that can reach a CUI system, writing the screening requirement for each role, and confirming that each active account links to a completed record. Confirm the final wording of the objective and its assessment objects against NIST SP 800-171A before you finalize the procedure.

Which people, systems and third parties fall under screening

PS.L2-3.9.1 does not ask for background checks on every employee. The population you screen is the set of people who can reach systems that store, process or transmit CUI, and that set should match the boundary written in your system security plan. The cards below cover the groups that most often change the scope.

Users with access to CUI systems

Start with the accounts that can reach systems storing, processing or transmitting CUI, including engineers, program staff and anyone with access to shared repositories or file stores that hold CUI. Pull these from your identity provider groups and access reviews rather than from job titles, because titles often understate access. Confirm that each account holder has a screening record before the account is enabled, and that the record ties to the position and role that justified the access.

Administrators and privileged users

Administrators, domain controllers operators, cloud tenant owners and anyone who can change security settings or read audit logs usually need a more demanding screening type than general users. Because they can alter the controls that protect CUI, an assessor will expect your screening criteria to reflect that elevated risk. Compare the privileged account list against your screening records each time a privileged role is granted.

Managed service providers and external staff

Managed service providers, outsourced help desks and vendor engineers with remote or onsite access to CUI systems fall inside the requirement even though you do not employ them. Decide whether the screening is performed by your organization or by the provider, then write that split into the contract and confirm it with records you can produce. An assessor will ask who screened the people who administer your environment, so the answer must be documented.

Temporary and contract staff

Temporary workers, contractors and interns who are granted accounts on CUI systems are in scope for the same reason as permanent staff. Staffing agency arrangements are a common gap, because the agency may screen candidates to its own standard while your organization never receives the records. Ask for evidence of the screening that was performed, confirm it meets the type your position and role require, and tie account expiration to the end of the engagement.

The system security plan boundary

The screening population should match the boundary of the CUI environment described in your system security plan. If a system is inside the boundary, the people who can administer or access it are in scope, and if it is outside, they generally are not, provided the boundary is enforced by segmentation and access controls. Review the plan whenever a system is added, moved to a new cloud tenant or connected to the CUI environment, and update the screening list at the same time.

Position and role screening criteria

Because the requirement leaves screening types to the organization, you need a written mapping from each position and role to a screening type and to the access it unlocks. Keep the mapping short enough that managers can apply it, and review it when job functions change. Ask your assessor early which evidence they expect to see for this mapping, since the decision logic is what they test, not only the completed checks.

How an assessor tests PS.L2-3.9.1 under NIST SP 800-171A

This table shows how an assessor tests the single PS.L2-3.9.1 objective, which methods apply, what evidence to have ready, and where screening requirements usually fail. Read it as a checklist of what to prepare before an assessment, since each row names the evidence an assessor will ask to see in final form.

Assessment element	What the assessor checks	Evidence to prepare	Where it usually fails
Assessment objective	Individuals are screened before access to systems containing CUI is authorized	A written screening requirement tied to CUI system access	Screening is described in HR policy but not linked to system access approval
Examine: screening procedures	Whether the documented procedure defines who is screened, what screening types apply, and when screening occurs	Current personnel screening procedure with version and approval date	Procedure is a draft or does not mention CUI system access
Examine: role-to-screening mapping	Whether screening types are set by position and role, as the requirement's organization-defined approach expects	Matrix mapping each role with CUI access to its required screening type	Mapping is missing, or roles with CUI access are not listed
Examine: screening records	Whether records exist for individuals with current CUI access and show completion before access date	Completed screening records with dates, reviewer and outcome, kept under the stated retention rule	Records are incomplete, undated or stored only as verbal confirmations
Interview: personnel security staff	Whether staff know the procedure, who triggers screening, and how exceptions are approved	Named owners for HR, security and hiring managers, plus their role descriptions	Staff describe a different process than the written procedure
Test: sampled hires	Whether a sample of recent hires with CUI access was screened before their access was granted	Access grant timestamps alongside screening completion dates for the same individuals	Access is granted on day one while screening finishes weeks later
Test: contractors and third-party staff	Whether contractors, consultants and vendor staff with CUI access are screened or covered by a documented flow-down	Contract clauses or subcontractor attestations, plus screening evidence for each person with access	No evidence exists for contractors, or screening is assumed to be the vendor's responsibility without proof
Test: exceptions and re-screening	Whether exceptions, role changes and access expansions trigger screening and are approved	Exception log with approver, reason and closure date	Role changes grant new CUI access without any new screening step

How to implement screening in a CUI environment

This sequence turns the screening requirement into a repeatable process: roles are defined first, screening is set per role, and no account reaches a CUI system without a completed screening record. Each step produces an artifact an assessor can examine.

Define the positions and roles that need CUI access
Start by listing every position and role that can reach organizational systems containing CUI, including administrators, engineers, help desk staff, and anyone with read access to CUI repositories. Security and HR leads build this list from the system security plan boundary and current access reviews, not from job titles alone. The output is a role matrix that names each role, the systems it touches, and the CUI it can reach. You know this step is done when every account with CUI access maps to a listed role.
Set screening types and criteria for each role
With HR and legal counsel, decide which screening type applies to each role and what criteria are disqualifying. Because the CMMC Assessment Guide treats screening as organization-defined and tied to each position, the criteria should reflect the sensitivity of the access, not a single default. Legal review confirms that the checks comply with employment law in every jurisdiction where staff work. The output is an approved screening standard that lists each role, its screening type, and the decision rules. Confirm with counsel which checks your jurisdictions allow before you finalize it.
Write and approve the screening procedure
Turn the standard into a written procedure that states who initiates screening, who performs it, how results are recorded, who decides on exceptions, and how re-screening is triggered. The assessment objective for 3.9.1 is narrow, but the assessor will also examine the procedure itself as an assessment object. Management approval should be recorded with a version number and an owner. The output is an approved screening procedure. You know this step is done when a named person can explain each decision point without consulting the author.
Run screening and file a record for each individual
Carry out the screening defined for each person's role before any access is granted, and keep a record that shows the date, the screening type performed, the outcome, and the approver. Store records where access is restricted to personnel security staff, and avoid storing more personal data than the procedure requires. Where a third party performs part of the check, keep the provider's confirmation in the same file. The output is a set of individual screening records, one per person. Sample a few records to confirm each one is complete and in final form.
Gate account provisioning on a completed screening record
Connect the identity workflow to the screening record so that no account with CUI access is created, and no CUI group membership is granted, until the record shows an approved outcome. This check is what makes the requirement operational: it prevents an engineer from getting access on the day they start while screening is still open. Many organizations implement the gate as a ticket step or a required field in the identity provisioning workflow. The output is a provisioning checklist and evidence that the gate runs for new accounts and role changes. Test it by attempting provisioning for a person with an open screening record.
Extend the same rule to third parties through contract terms
Contractors, managed service providers, and other third parties who reach CUI systems fall under the same requirement. Write the screening obligation into the contract or statement of work, specifying the screening type for each role and the evidence the provider must supply, such as confirmation that screening was completed before access. Your procurement and legal teams own this language, and your security team verifies it during onboarding. The output is contract language and a third-party onboarding checklist. Confirm with counsel how existing agreements can be amended.
Run periodic spot checks against the roster
Reconcile the current list of accounts with CUI access against the screening records on a schedule your procedure sets. Spot checks look for accounts without a matching record, records past their re-screening date, and role changes that did not trigger a new screening. Record the results, the exceptions, and the corrective action. The output is a dated spot-check log that shows the control operates after the initial rollout. Assessors often ask for this log to show the gate has held over time, so keep it current.

Why screening strengthens identification and authentication

The CMMC Assessment Guide for Level 2 ties screening to the authentication performed under IA.L2-3.5.2, the identification and authentication requirement for users. The reason is simple: an account identifier is only as trustworthy as the person behind it. If the organization has not confirmed that a person is who their records say they are, and that the person is suited to the position they hold, then a strong password or multifactor prompt proves control of a credential, not the identity of the individual. PS.L2-3.9.1 supplies the verified person that the identifier is meant to represent. Assessors read the two requirements together for this reason, but each is scored and tested on its own, so the screening evidence should stand up without relying on the authentication evidence to support it.

Practically, the link runs through three records. The HR or sponsoring-office record shows that a person was screened, which screening types applied to their position, and when the screening was completed and approved. The identity provisioning record, usually the directory entry created in the identity provider, shows that the account was issued to that same person and carries a unique identifier that matches the HR record. The access review record shows that the account's CUI entitlements were confirmed against the screening requirement for the role at a defined interval. Confirm with your HR and identity teams that the employee identifier, not just a name, is carried from HR into the directory, because name matches are the weakest point in this chain.

Assessors may pick any account with access to a CUI repository and ask the organization to trace it back to a screening record. Expect the request to run from the account in the directory, to the provisioning ticket, to the HR screening entry for that individual, and to the access approval for the role. A gap at any step, such as a contractor account created by an administrator with no sponsoring record, is the kind of finding that makes the screening requirement appear unmet even when the screening process exists. Before an assessment, run this trace yourself on a sample of accounts, including service-linked and third-party accounts, and decide who owns each record. Work with your assessor or your implementation partner on the format of the evidence, but the screening records themselves must come from your own HR and security processes.

Which screening records pass an assessment

An assessor tests PS.L2-3.9.1 by reading the screening procedure, the matrix that ties roles to screening types, and records showing that screening happened before access was granted. The cards below list the artifacts that carry that proof and explain how to keep them current between assessments, since a requirement worth 3 points must be MET and cannot go on a POA&M.

Written personnel screening procedure

The organization's own procedure states who is screened, when, by whom, and what happens when screening is not completed. It needs an owner, an approval signature and a date, and it should reference the current version of the system security plan. Assessors check that the procedure is the approved, final version in use, not a draft or a template that nobody adopted. Confirm that the procedure's stated screening steps match what HR and security staff actually do.

Role-to-screening-type matrix

This matrix maps each position or role with access to CUI systems to the screening type required for it, because CMMC leaves the screening type to the organization based on each position's requirements. A role missing from the matrix is a common finding. Review the matrix when job descriptions change, when new CUI systems are added, and on a fixed schedule set in the procedure, and record each review with a date and approver.

Completed screening records for sampled personnel

Assessors select individuals from access lists and ask for proof that each one was screened according to the matrix. Records should show the screening type, the completion date, the person or vendor who performed it, and the outcome. Store them with restricted access, because they contain sensitive personal data. Pull a sample of current users from the CUI system's account list and confirm that each one has a matching record before you start an assessment.

Access provisioning ticket showing screening first

The strongest proof of sequence is a provisioning ticket in which the screening completion is recorded before the account or access group was approved. Build this into the workflow so the approver cannot grant access until the screening field is complete. An assessor who sees an account created before the screening date treats the requirement as NOT MET for that individual, so check ticket timestamps against screening dates.

Third-party contract clauses requiring screening

When a managed service provider, staffing firm or subcontractor's staff can reach CUI systems, the contract should require that provider to screen its personnel to the organization's matrix and to supply evidence on request. Keep the signed clauses and the provider's attestation or screening summaries on file. Ask providers to confirm in writing that re-screening follows the same triggers you use internally.

Records of approved exceptions

Some individuals may need access before a full screening is complete. Any such case needs a written exception that names the individual, the access granted, the compensating controls, the approving official and an expiry date. Unapproved exceptions are a direct path to NOT MET. Review open exceptions at each matrix review and close them once screening is finished, so the file shows no access outlasting its approval.

What meeting PS.L2-3.9.1 costs in money and effort

This table lists each cost component of screening for PS.L2-3.9.1, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no dollar figures are published here. The main takeaway is that most of the cost sits in HR, legal and screening vendor work, and open-source tooling only reduces the engineering and evidence share.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Role matrix and screening criteria	HR and legal staff, sometimes outside employment counsel	One-time, then reviewed periodically	Number of CUI roles, number of distinct position types, and jurisdiction-specific rules on background checks
Background screening vendor fees	Third-party screening provider, billed per check	Recurring with each new hire, transfer into a CUI role, or rescreen the organization requires	Screening depth set for each role, hiring volume, turnover, and whether checks are repeated for existing staff
Engineering to link provisioning to a screening gate	Internal IT or platform engineers, or an implementation partner under a fixed-scope agreement	One-time build, with ongoing maintenance when identity or HR systems change	Number of systems that grant CUI access, identity provider complexity, and whether the HR system feeds the identity system automatically
Evidence upkeep	HR, security and compliance staff who keep screening records and approvals current	Recurring, tied to each hire, role change and review cycle	Volume of personnel changes, how records are stored, and how quickly reviewers must produce a sample
Third-party contract review	Legal staff reviewing staffing, managed service and subcontractor agreements	Recurring at contract signature and renewal	Number of third parties who staff or administer CUI systems and whether their screening terms are written into contracts
Assessor sampling effort	Internal staff who pull records for the assessor, plus the independent assessor's time	Recurring at each assessment cycle	Number of CUI users in scope, the sample size the assessor selects, and how well records are indexed
Open-source tooling	Internal or partner engineers to deploy and configure self-hosted tools	One-time setup, recurring operation	Platform choice and integration depth. Tooling reduces record-keeping and workflow effort but does not replace screening vendor fees or HR and legal work
Quote scope to request	Ask the provider or auditor to itemize each line above	Set at quote time	Confirm which items are fixed-scope and which are billed on usage, and whether screening vendor fees are passed through at cost

Who owns screening, who prepares evidence, and who assesses it

Your organization owns PS.L2-3.9.1. The requirement asks you to screen individuals before you authorize their access to systems that contain CUI, and the decision about who is screened, how deeply, and under which policy sits with you. Screening types are organization-defined and should follow the duties of each position and role, so the people who understand those duties (hiring managers, HR, and the security lead) need to define the criteria together. Legal counsel decides what checks are lawful in each jurisdiction and what candidates must be told and asked to consent to.

Screening policy: A written standard that maps each role with CUI access to the screening types required for it.
HR and legal approval: Documented sign-off that the screening process complies with employment law and internal policy.
Screening records: Dated records showing each individual was screened before access was granted, kept where an assessor can review them.
Access gate: A rule that no account with CUI access is provisioned until the screening record exists.
Ongoing ownership: Someone named to review the policy when roles change or contracts add new requirements.

Before an assessment, check that each record is final, dated before access began, and traceable to a named role.

Where screening programs usually fall short

Most gaps in PS.L2-3.9.1 are not missing policies but timing, scope and records. Assessors test whether screening happens before access is granted, whether it covers everyone who touches CUI systems, and whether the paper trail matches what staff actually do.

Screening after access is granted

Many organizations provision accounts on the first day and let screening finish later, sometimes weeks later. PS.L2-3.9.1 is met only when screening is completed before authorization to systems containing CUI. Check the sequence in your onboarding workflow: the access ticket should not be approved until the screening record is marked complete. Ask whether any account was enabled ahead of a pending check, and record the exception if one exists.

Undefined criteria for roles

The requirement leaves the screening type to the organization, based on each position and role. When job families have no written screening tier, reviewers apply their own judgment and the results cannot be defended. Map each role that can reach CUI to a named screening type, such as the checks used for administrators versus general staff, and keep that mapping in the system security plan so an assessor can trace a person to a required check.

Contractors and subcontractor staff left out

Managed service providers, temporary staff, and subcontractor personnel often sit outside the HR system, so they are screened by a different team or not at all. Any person who can authenticate to an in-scope system counts for this requirement, whoever employs them. Require screening evidence from staffing firms and subcontractors in their contracts, and keep a roster of external users with access to CUI systems.

Records scattered across HR systems

Screening results may sit in an applicant tracking tool, a background check vendor portal, a spreadsheet kept by HR, and a paper file. An assessor who asks for proof for a sample of users may get four answers. Choose one authoritative record per person that links to the screening type, completion date, and approver, and confirm that the identity system only grants access when that record exists.

No re-screening or role-change trigger

A person screened for a general role who later moves into an administrator role may now need a different screening type, but nothing prompts the check. Build a trigger into the transfer process so that a change in position or elevated privilege returns the person to the screening step before the new access is granted. Confirm with your HR and identity teams which events generate this trigger, since the rule for transfers is tested alongside PS.L2-3.9.2.

Procedures that do not match practice

A written procedure that describes a three-step check, while staff actually skip one step for speed, fails interviews and record reviews. Assessors test the process by comparing the documented steps with the records and speaking with the people who run them. Walk through the procedure with the HR and security staff who perform it, correct the document to match reality or correct the practice, and retain records that show the steps were completed.

Questions buyers ask about PS.L2-3.9.1 screening

How much does personnel screening for CMMC cost?

No supplied figure sets a price for screening, so the cost depends on what your organization already runs. Most of the spend is internal: HR time to define screening types by position, legal review of the policy, and the background checks themselves, which are usually bought from a screening provider and billed per check. The main cost drivers are the number of people with access to systems containing CUI, the depth of screening each role requires, and whether checks must be repeated. Expect one-time work to define the policy and recurring work to screen new hires and re-screen where your policy requires it. Ask any provider for a written quote that separates the policy work, the per-person checks, and any recurring monitoring, and confirm with your legal team which checks are permitted in your jurisdiction.

How long does it take to set up CMMC personnel screening?

The setup time depends on how many position types you have and how quickly HR and legal can approve a policy, so no fixed duration applies to every organization. Setup usually follows three steps: classify roles that touch systems with CUI, set the screening type for each role, and record the results. Screening results must exist before access is granted, so the policy has to be in place before the next hire or contractor is given a login. Because PS.L2-3.9.1 is a 3-point requirement that cannot go on a POA&M, the records must be complete before any assessment. Build the schedule backward from your planned assessment date and confirm each step with HR, legal and your assessor's expectations.

Can our own team handle CMMC personnel screening in-house?

Yes, many organizations run PS.L2-3.9.1 entirely in-house, because the requirement is about your own screening policy and records rather than a specific tool. The work that usually stays with HR and security is defining screening types by position and role, documenting the process, and keeping screening records tied to each user account. Internal teams often need outside help with the legal review of permitted checks, with building the access workflow so that no account is created before screening is recorded, or with the evidence package for an assessment. An implementation partner can prepare these systems and records, but the organization owns the policy and the decisions about who is screened and how deeply.

Can DeployOpen issue our CMMC certification or screening attestation?

No. DeployOpen does not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and only those independent assessors issue the outcome. For PS.L2-3.9.1, DeployOpen can help you prepare the screening process, the account-provisioning steps tied to it, and the records an assessor will ask to see. Your organization still owns the control and the decision to grant access. Note that the program schedule has changed, so confirm current assessment requirements with the DoW CIO About CMMC page before you plan.

Is a POA&M allowed for PS.L2-3.9.1 if screening is not finished?

No. PS.L2-3.9.1 is worth 3 points in the CMMC Scoring Methodology, and a plan of action and milestones is allowed only for requirements worth 1 point. Under the scoring rules, the requirement must be MET to reach Conditional or Final Level 2 status. If it is NOT MET, 3 points are subtracted from the maximum score of 110. Practically, every person with access to systems containing CUI must already be screened before the assessment, and records must show that. Check the current scoring and POA&M rules in the eCFR text of 32 CFR Part 170 because the program schedule is under review.

What does PS.L2-3.9.1 need from HR and IT?

The requirement sits between HR and IT, and both have specific jobs. HR owns the screening policy: which positions need which screening types, who approves exceptions, and how results are recorded and kept. IT owns the link between the screening result and system access, so that accounts for systems containing CUI are not enabled until screening is recorded. In practice this means:

A role list that maps job titles to screening types, approved by HR and legal
A provisioning step in the identity system that checks for a recorded screening result before access is granted
Retained records that an assessor can inspect, including dates and the screened person's role
A named owner for contractors and subcontractor staff who access the environment

Confirm with your legal team what screening your jurisdiction allows before you finalize the role list.

How does PS.L2-3.9.1 screening relate to PS.L2-3.9.2?

PS.L2-3.9.1 covers the front end of access: screening people before they can reach systems containing CUI. PS.L2-3.9.2 covers the back end, protecting those systems during terminations and transfers by revoking access, recovering equipment and badges, and handling exit interviews. The two requirements share the same people records, so a single HR workflow that tracks hires, role changes and departures usually serves both. PS.L2-3.9.2 is a 5-point requirement, so it also cannot go on a POA&M. Screening results also support the authentication controls under IA.L2-3.5.2, which is why the CMMC Assessment Guide ties screening to identity. Review both requirements together so the records line up when an assessor checks them.

What should we ask a consultant before buying screening help?

Ask for a written scope that names each deliverable before work starts, such as the role-to-screening-type list, the provisioning workflow, and the record templates. Ask who performs the background checks and who pays the screening provider, because that determines the per-person cost. Ask how the partner will handle personal data, what it will not do (for example, issue attestations or certify your environment), and how it will hand over documentation you can maintain yourself. A fixed-scope agreement with clear ownership of each output is easier to verify than an open-ended retainer. Confirm all of these points in the proposal before you sign.

How DeployOpen prepares screening controls and evidence

DeployOpen works on PS.L2-3.9.1 as an implementation partner. We help your team define the screening types each position and role requires, build the supporting records inside your own infrastructure, and document the evidence an independent assessor will review. Your organization owns the screening decisions and the control, and only an independent assessor can issue an assessment result.

How we scope

We agree a written scope covering which systems hold CUI and which roles reach them.
We review the position and role categories your organization already uses for hiring and access decisions.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We help define a documented screening procedure that ties screening types to each position and role.
We configure access workflows so no account reaches CUI systems before the required screening step is recorded.
We test the screening gate against the 3.9.1 assessment objective before handover, not after.

How we hand over

We deliver the screening procedure, role matrix, and records template with clear owners and review dates.
We provide a sample evidence package showing screened personnel records linked to system access approvals.
We document the configuration and walk your personnel security and IT staff through how to maintain it.

How we support

Ongoing support, upgrades, and continuous testing are available as retainers after handover.
We can review new roles and contractor onboarding against the screening procedure on a scheduled basis.
Confirm with your assessor which evidence form they accept before finalizing records, since they decide sufficiency.