03.09.01 Personnel screening: requirements and evidence

What 03.09.01 personnel screening requires before anyone reaches CUI

03.09.01 requires that every individual is screened before the organization authorizes access to a system that holds CUI, and that the screening is repeated under conditions the organization defines. If a contract or assessment asks for NIST SP 800-171, the question you will have to answer is simple to state and hard to prove: were the people with system access screened first, and do you have a defined rule for when they are screened again? The requirement is drawn from the personnel screening control PS-3 in SP 800-53 Rev. 5, and it addresses insider access to CUI, where a trusted person with legitimate access is the risk rather than an outside attacker. The Rev. 3 wording leaves the rescreening triggers to the organization, so the policy and the records must show what those triggers are.

The requirement has one organization-defined parameter (ODP): the conditions that require rescreening. NIST does not assign a value to it. If a federal agency does not specify the conditions in the contract, the nonfederal organization must set them to complete the requirement. Typical decisions include rescreening after a change to a role that grants new CUI access, after a break in service, or at a fixed interval, but the value you choose must match your own policy and be written down. The SP 800-171A Rev. 3 assessment also checks that this ODP value is defined, so an empty or vague policy fails before any sample of records is pulled. Confirm with the contracting officer or your assessor whether any ODP values are already specified for your contract.

This is harder in practice than the wording suggests. HR and legal teams often set limits on background checks by jurisdiction, and contractors and subcontractor staff may be screened by a different employer altogether, so you need written agreements that cover them. Many organizations also screened people years ago without keeping records that link a screening result to a system account. Under Rev. 2, this requirement appears as 3.9.1, and NIST's change analysis classifies the move to Rev. 3 as minor. That matters for CMMC Level 2, which still scores 3.9.1 as PS.L2-3.9.1 worth 3 points, and a POA&M cannot be used to cover it for Conditional status under 32 CFR 170.21. Treat missing screening evidence as a gap to close before the assessment, not one to explain afterward.

Which people, systems and third parties fall under personnel screening

Before screening starts, the organization has to decide who counts as a person with access, which systems sit inside the boundary, and what events should trigger rescreening. Each decision changes how many people go through the process and how much evidence the assessor will ask to see for 03.09.01 Personnel screening.

Employees with access to CUI

Every employee who can reach the system, its CUI repositories or its administrative consoles falls within 03.09.01. The practical check is to pull the identity provider group list and the access reviews for the CUI enclave, then compare them with the screening records. Gaps usually appear among staff who were granted access through a shared group rather than a named request, so confirm that every grant maps to a screened individual.

Administrators and privileged accounts

System administrators, database operators and security staff often hold broader access than general users, so their screening should be at least as thorough. Assessors commonly test whether privileged accounts appear in the screening records, not only standard user accounts. Confirm whether break-glass or service accounts are tied to a named, screened person and who is accountable for them.

Managed service and contractor staff

Staff employed by a managed service provider or a staffing agency who administer or support the CUI system are individuals with access, even though a different company employs them. The contract should state which screening the provider performs, how records are shared with the organization, and what happens when a provider employee is reassigned. Check that the evidence the organization receives covers those individuals, not just the provider's general screening policy.

Third-party support with remote access

Vendors who troubleshoot, patch or maintain the system through remote sessions can reach CUI even when they never hold a standing account. Map each vendor access path, including vendor-managed VPN accounts and remote maintenance tools, and decide whether the vendor's personnel need the same screening. Ask for named individuals rather than a generic vendor login, because the screening evidence must point to a person.

Systems and enclaves in the boundary

The screening scope follows the system boundary in the system security plan. A CUI enclave that is separated from the corporate network narrows the population, but only if the separation is real and documented, including shared identity services, backup operators and help desk access. Confirm with the assessor how the boundary is drawn before building the list of screened individuals.

Organization-defined rescreening conditions

03.09.01 has one organization-defined parameter: the conditions that require rescreening. The organization sets these conditions, such as a change in role, a transfer into the CUI enclave, or a period since the last screening, and records them in its personnel security policy. Because NIST does not assign values, an undefined or vague condition leaves the requirement incomplete. Document the chosen conditions, the triggers that start the process and who approves the outcome.

How an assessor tests 03.09.01 under SP 800-171A Rev. 3

This table breaks down how SP 800-171A Rev. 3 tests 03.09.01 by method, showing the objects an assessor examines, interviews or tests and the findings that commonly come up. Read each row as a checklist of what to have ready before the assessment. The main takeaway is that the assessor will check both the written rescreening conditions and proof that screening happened for every person with access.

Assessment element	What the assessor looks at	Evidence to have ready	Common finding
Determination statements (two)	Whether individuals are screened before access is authorized and rescreened under the defined conditions	Screening procedure, dated screening records tied to each account holder, and a rescreening schedule or trigger log	Access granted before screening is completed, with no record of the exception
ODP check (one)	Whether the rescreening conditions are defined by the organization	Written list of rescreening triggers, such as role change, periodic interval or cause for concern, approved by the system owner	Rescreening conditions referenced in policy but never specified
Examine: policy and procedures	Personnel security policy and the procedures for screening and rescreening	Approved policy, procedure version history and the owner who signed it	Procedure is generic and does not name the systems holding CUI
Examine: records of screened personnel	Whether records exist for each person with access to the system	Screening records matched against the current access list, including contractors and subcontractor staff	Screening records missing for contractors or temporary staff
Interview: personnel security and information security staff	Whether those responsible can explain the screening and rescreening steps and who triggers them	Named roles, responsibilities and a short walkthrough of a recent screening	Staff describe the process differently or cannot name the rescreening triggers
Test: screening and rescreening process	Whether the process runs as written, from request to approval to record	Sample of recent screenings and at least one rescreening, with timestamps and approver	Process exists on paper but has not run for the rescreening conditions

How to implement personnel screening in the order assessors expect

This sequence moves from deciding when rescreening happens to producing the records an assessor will examine for 03.09.01. Each step ends with a named artifact, so the screening program can be shown to be defined, applied and kept current.

Define the rescreening conditions
Start by deciding which events trigger rescreening of an individual. 03.09.01 leaves this to the organization through its one organization-defined parameter, so the conditions must be chosen, written down and approved by the people accountable for the system. Examples might include a change to a role that grants access to CUI or a change in the individual's status, but these are illustrative and the list should reflect your own risk assessment. The step is done when a named owner has signed off on the conditions. The output is a short ODP decision record that states each condition and why it was chosen, because the assessment procedure checks that the parameter value is defined.
Document screening procedures in the policy
Write the personnel screening procedure and place it in the personnel security policy. The procedure should say who is screened before access is authorized, what the screening covers in your organization, how rescreening is triggered by the conditions from the previous step, and where results are recorded. Assessors look for both the policy and the operating procedure, so the two should cross-reference each other. The step is complete when the policy has been approved and communicated to the people who run screening. The output is an approved personnel security policy with a screening and rescreening procedure section.
Map roles to screening tasks
Assign each screening task to a named role. Typical tasks include requesting screening, performing or verifying it, deciding whether access may be authorized, monitoring the rescreening conditions, and keeping the records. Assessors interview personnel with personnel security responsibilities and personnel with information security responsibilities, so each role must be able to describe its part. Where a task is outsourced to a background screening provider, record who owns the decision and who reviews the provider's output. The output is a responsibility matrix that shows every task has an owner and a backup.
Identify the access population
Build the list of individuals who will hold access to systems that process, store or transmit CUI, including employees, contractors, administrators and staff at managed service providers. Compare this list with the account inventory from the access control work, so no account exists without a person being traced to it. Screening must happen before authorization, so this list also sets the order of work for new and existing users. The step is complete when the list is reconciled with the identity directory and the owner signs it off. The output is an access population register tied to the screening status of each person.
Screen individuals before authorizing access
Apply the screening procedure to each person on the register before their access is authorized. The screening check, its scope and its result should be recorded against the individual, and access should be granted only after the screening decision is recorded as favorable or approved through the documented process. For existing users, schedule the screening work and keep access under review until it is complete, following the procedure your policy sets. The output is a screening record for each individual that shows the date, the decision and the approver. Confirm with your legal and HR advisers which checks are lawful in your jurisdiction before you run them.
Run and record rescreening
Monitor the defined rescreening conditions and trigger a rescreening whenever one occurs. Each rescreening should follow the same procedure as the original screening and produce its own record, linked to the triggering event. Review the register on a cycle set in your procedure to catch conditions that were missed. The step is done when a sample of recent condition events shows a matching rescreening record. The output is a rescreening log that links each trigger to the action taken.
Collect screening evidence for the SSP
Gather the policy, the ODP decision record, the responsibility matrix, the access population register, the screening and rescreening records, and a description of how the process operates into the system security plan. The SSP should state how 03.09.01 is implemented for this system and point to where each artifact is held. Ask your assessor which samples they will request and check that each artifact can be produced quickly. Independent assessors make the final determination, and an implementation partner can prepare the evidence but cannot issue the assessment result. The output is an SSP section for 03.09.01 with an evidence index.

Which evidence shows that screening happens before access and on schedule

An assessor testing 03.09.01 wants to see a written rule, a record that each person was screened, and proof that access was granted only after screening and that rescreening happened when the defined conditions were met. The cards below cover the artifacts that connect those three points, and each one needs an owner who refreshes it between assessments rather than assembling it the week before.

Personnel security policy and procedures

The written policy states who is screened, what screening includes, and who approves exceptions. The procedure sets out the steps HR and the security team follow before an account is created. Assessors examine both documents, so each should name a role, not a person, and carry a review date and version. Check that the procedure matches what staff actually do, because a mismatch between paper and practice is a common finding.

Defined rescreening conditions

03.09.01 requires rescreening under organization-defined conditions, and the organization must set those conditions itself. Write them down as a short list, such as role changes into positions with CUI access, a period of extended leave, or a security incident involving the person. Each condition should name the trigger that starts rescreening and the owner who acts on it. Record the list in the policy so an assessor can compare it against your roster.

Roster of authorized users with screening dates

Build a roster that lists every account with access to systems holding CUI, the date each person was screened, and the date of their most recent rescreening. Generate it from the identity provider or HR system where you can, and reconcile it against the accounts that actually exist. Gaps such as accounts with no screening date, or screening dates older than your own rescreening rule allows, are the first things an assessor will sample.

Screening records kept within legal limits

Keep a record that screening was completed, the date, and the outcome, but limit what you store. Local law, labor agreements and data protection rules may restrict how long background results can be kept and who can see them. Confirm retention and access rules with counsel, and store the sensitive detail separately from the roster so the roster can be shared with assessors without exposing personal data.

Access approval tickets that cite screening

Each request for access to a system with CUI should record that screening was confirmed before approval. Configure the ticketing workflow so the approver must attest to the screening status, and link the ticket to the roster entry. This shows the order of events the requirement asks for: screening first, authorization second. Sample tickets from several months and confirm none were approved before the screening date.

Rescreening logs and trigger reviews

A rescreening log records each time a defined condition was checked, what the result was, and whether rescreening was performed. Include conditions that were reviewed and found not to apply, because those entries show the trigger process runs. Review the log on a fixed schedule set in the procedure, and record the reviewer. Missing entries for known role changes are the gap most likely to appear in an assessment.

What meeting 03.09.01 costs in money and effort

This table lists the cost components of meeting 03.09.01, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. No price is given here, so use the table to build the scope you send to vendors and advisers, then compare written quotes against the same rows.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Background check vendor fees	Screening provider, billed per check or per package	Recurring for new hires, transfers and rescreens	Number of people with CUI access, check depth, and how often your rescreening conditions trigger
In-house HR and hiring manager time	Internal HR, security and hiring staff	Recurring	Volume of hires and role changes, and whether screening steps are documented and automated in your HR system
Legal review of screening scope	Employment counsel or in-house legal	One-time to set the policy, recurring when laws or role definitions change	Jurisdictions where staff sit, consent and notice language, and how many role categories you define
Engineering time to tie access to screening status	Internal identity or platform engineers, or an implementation partner under a written scope	One-time build, then recurring maintenance	Number of systems holding CUI, whether an identity provider already carries a screening status attribute, and how many approval workflows must change
Self-hosted identity tooling	Software licensing is often zero for open-source components, but hosting, patching and administration are paid to your staff or partner	Recurring operations cost	Whether you already run an identity platform you can extend. Confirm licensing and support terms with each vendor before you assume savings.
Evidence upkeep	Internal compliance or security staff	Recurring	Frequency of rescreens, number of records to keep current, and how much of the evidence is generated automatically by workflows
Assessor or consultant review	Independent assessor or certification body for assessment outcomes; an implementation partner for readiness preparation	Recurring at each assessment cycle, plus readiness work	Size of the CUI boundary, how mature the personnel records are, and how many findings need rework before review

Who screens people, who builds the evidence, and who assesses it

Your organization owns requirement 03.09.01 in full. That includes choosing values for the organization-defined parameter, which asks you to set the conditions that trigger rescreening, and deciding how screening is done for each role that can reach systems holding CUI. HR and legal decide what checks are lawful, proportionate and consistent with employment and privacy rules in the jurisdictions where your staff work. Only your people or a background screening provider you contract with can perform the checks themselves, and the results stay in your records.

ODP decisions: Document the rescreening conditions you chose, such as role change, elapsed time or a security incident, and approve them with an accountable owner.
Screening decisions: HR and legal set which checks apply to which roles and what results block access.
Performance of screening: Your HR team or a screening provider you engage carries out the checks before access is granted.
Records: You keep the screening records and make them available to the assessor.
Federal direction: If a contracting agency specifies ODP values, follow them. If it does not, you must assign them yourself.

Check that your written ODP values, your HR procedure and your access request workflow all describe the same conditions.

Where organizations fail personnel screening and how to close each gap

Most personnel screening failures are not about whether anyone was checked. They happen in the gaps between the policy, the people who hold access and the records that prove it. The cards below cover the gaps assessors most often find under 03.09.01 and the fix for each.

Rescreening conditions never defined

The requirement is to rescreen individuals under organization-defined conditions, and that parameter is yours to set. Many organizations screen once at hire and never write down what triggers a second check, such as a move into a role with CUI access, a change in clearance needs, or a contract extension. Define the triggers in writing, assign the values to the 03.09.01 organization-defined parameter, and check that the triggers match the roles in your system security plan. An assessor will look for the defined value first.

Contractors and admins outside the roster

Screening records often cover employees in HR systems while contractors, managed service staff and privileged administrators are handled by a different process or none at all. Those groups frequently hold the most access to systems that store CUI. Build one roster from identity and access data, not from HR alone, and confirm that each person with access, including vendor accounts and break-glass administrators, is either screened or covered by a documented screening obligation in the contract.

Screening not linked to access grants

Screening only counts if access is granted after it is complete. In many environments the identity platform issues accounts on the day of hire, and the screening result arrives weeks later with no control that stops access in the meantime. Connect the access request workflow to the screening status so that an account touching CUI cannot be approved until the screening record is complete. Then test it by requesting access for a person whose screening is incomplete and confirming the request is blocked.

Records missing or inconsistent

Assessors examine records of screened personnel. Problems arise when screening dates sit in one spreadsheet, rescreening dates in another, and access grants in a third, with names spelled differently across them. Keep one authoritative record per individual with the screening date, the rescreening trigger that applied, the approver and the access granted. Reconcile it against the identity provider each quarter so that an assessor asking for a sample can trace each person from screening to access without manual reconstruction.

Policy that describes practice no one follows

A personnel security policy that promises background checks for every role, or rescreening every few years, becomes a finding the moment the practice differs from the text. Assessors interview personnel with security responsibilities and test the process itself, so they will ask hiring managers and access administrators how screening works. Before finalizing the policy, walk through the actual hiring and access steps with the people who run them, then align the wording with what happens. Remove any commitment you cannot evidence.

Personnel screening questions buyers ask before hiring help

How much effort does personnel screening for NIST SP 800-171 really take?

Most of the effort is process work, not background checks: writing a screening standard, deciding which roles need it, running the checks through HR or a screening vendor, and keeping records that show it happened before access was granted. The effort scales with the number of people who touch systems holding CUI, how many roles you define as CUI-access roles, and how many conditions trigger rescreening. Your organization sets those conditions as the organization-defined parameter for 03.09.01, so the work starts with a decision, not a tool. Ask any partner to break its estimate into policy drafting, role mapping, HR process changes, and evidence collection.

Can our organization complete 03.09.01 without outside help?

Yes, in most organizations the requirement is within reach of an internal HR, legal and security team, because it asks for a defined screening process, rescreening conditions, and records. Outside help is most useful when the team has not mapped CUI access to roles, when the rescreening conditions are undefined, or when the assessment evidence has to be organized for a DoD or prime contractor review. Whatever you choose, your organization owns the control and the decisions behind it. An implementation partner can prepare the procedure and evidence, but it does not perform the checks or attest that they were done correctly.

What does 03.09.01 need from HR and legal?

HR and legal supply the parts of the requirement that a technical team cannot decide alone. HR typically owns the screening steps, the hiring and transfer workflow, and the records of screening completed before access. Legal reviews whether the screening scope complies with applicable employment and privacy law in each jurisdiction where staff or contractors are located, and whether consent and notice language is adequate. Both groups should agree on:

which roles get access to CUI and therefore need screening
what triggers rescreening, such as role changes, elevated privileges, or periodic cycles
who approves exceptions and how those approvals are recorded

Confirm these decisions with your counsel before writing them into the system security plan.

How long does it take to produce evidence for 03.09.01?

The duration depends on how far your current HR practice already matches the requirement, so no fixed timeline applies across organizations. If screening already happens before system access and the records are retrievable, the work is mostly documentation and sampling. If screening is inconsistent or records are scattered across HR systems, expect the evidence work to take longer, because records must be gathered and checked against the rescreening conditions you define. Ask a partner for a fixed-scope schedule tied to named deliverables, and ask your assessor which evidence samples it will request, since that determines how much history you need to show.

Can a consultant perform background checks for us?

No. A consultant can help you design the screening process, write the procedure, define rescreening conditions, and organize the records that show the process ran. Background checks are performed by your organization or by a screening provider you contract, subject to the law where the person works. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it does not conduct personnel screening. Assessments against SP 800-171 are judged by the federal agency or DoD assessor, not by the consultant who helped you prepare.

How does the Rev. 2 CMMC view of 3.9.1 differ from Rev. 3?

The substance is closely aligned: NIST traces Rev. 3 requirement 03.09.01 back to Rev. 2 requirement 3.9.1 and classifies the change as minor. The practical difference is in how it is scored. CMMC Level 2 still uses Rev. 2, where 3.9.1 is assessed as PS.L2-3.9.1 and carries 3 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so it must be met before the assessment. Confirm which revision your contract and CMMC level require before you plan the work.

What should we ask for in a quote for this work?

Ask for a written, fixed-scope quote that lists each deliverable and what it depends on. A useful quote separates one-time work from recurring work and states the assumptions behind the price. Ask the partner to cover:

the screening procedure and rescreening conditions, with the decisions your organization must make listed
the role-to-CUI-access mapping and the records template
how evidence will be collected and stored, and what the partner will not do
who reviews the output and who signs off, including your legal and HR owners
what happens if your assessor requests additional samples

DeployOpen quotes follow from the agreed written scope, and no price list is published.

How DeployOpen prepares personnel screening evidence for NIST SP 800-171

DeployOpen works on 03.09.01 Personnel screening as an implementation partner. We help set up the systems, records and documented procedures that show your screening and rescreening process operates, while your organization owns its controls and an independent assessor makes the determination.

How we scope

Agree in writing which systems, user groups and access paths involve CUI before any work starts.
Confirm with your organization the rescreening conditions that serve as the ODP value for 03.09.01.
Define which records, approvals and HR or identity system outputs will serve as evidence for the engagement.

How we build

Configure identity and access tooling so that access to CUI systems is tied to a recorded screening decision.
Set up logging and reporting that shows screening dates, approvals and scheduled rescreenings for review.
Prepare role-based access workflows so personnel changes trigger a documented rescreening review.

How we hand over

Deliver written procedures for personnel screening and rescreening aligned to the 03.09.01 assessment objectives.
Provide evidence packages with sample records, configurations and interview-ready process descriptions.
Document residual gaps and the owners who must close them before an independent assessment begins.

How we support

Offer ongoing support, upgrades and periodic reviews of screening evidence as a retainer after handover.
Re-verify screening workflows and records when systems, roles or contract requirements change.
Confirm with your auditor or assessor which evidence formats and sampling they expect before final handover.