CMMC Level 2Implementation GuideJuly 3, 2026· 8 min read
How to Implement CMMC Level 2 Personnel Security (PS) Requirements
Two practices. That makes PS the smallest domain in CMMC Level 2. But 3.9.2 (the termination and transfer practice) consistently generates findings because the process it requires sits at the intersection of HR, IT, and security, and organizations frequently assume someone else is handling it. This guide covers both practices, how to build a compliant process, and the evidence an assessor will expect.
Why Two Practices Can Still Create Findings
Two practices. Sounds easy. Then you discover that the employee who left eight months ago still has an active Microsoft 365 account.
The PS domain covers the human layer of your security program: who you let in (3.9.1) and what you do when they leave or change roles (3.9.2). The risks addressed are real. Insider threat incidents frequently involve personnel who either should not have been granted access in the first place, or who retained access long after they no longer needed it.
The gap assessors find most often is not that organizations are careless about hiring. Most do run background checks. The gap is in the offboarding process. Access revocation depends on HR notifying IT promptly, IT having a complete list of all systems to revoke, and someone verifying that revocation actually happened. When any of those three steps breaks down, a departed employee has live credentials. That is a 3.9.2 finding, a potential data exposure, and exactly the kind of thing that shows up in breach investigations.
Scope reminder: PS applies to personnel with access to systems containing CUI, which includes contractors and vendors with system access, not just employees. A contractor who VPNs into your network to access project files is subject to the same screening and offboarding requirements as an employee.
Practice 3.9.1: Screen Personnel Before Authorizing CUI Access
3.9.1
Screen individuals prior to authorizing access to organizational systems containing CUI
Before granting any individual access to systems within your CUI boundary, verify that they are who they say they are and that they do not present an unacceptable risk. The specific screening elements are not mandated by NIST 800-171, but the screening must be risk-commensurate and consistently applied.
What a defensible screening process includes:
Identity verification: Confirm the individual's identity through government-issued ID. This sounds obvious and usually is, but it should be documented in your onboarding process
Employment history verification: Confirm prior employment, particularly for roles with elevated access or sensitive responsibilities
Criminal background check: A 7-year criminal history check covering federal and state records is the common baseline. Some organizations extend to 10 years for privileged roles
Education verification: For roles where credentials matter (claimed security certifications, technical degrees) verify the credential is real
Credit check: For roles with financial access or access to financial CUI, a credit check is appropriate and increasingly expected by assessors
Reference checks: Professional references for roles with significant security responsibility
Documentation requirements:
Your personnel security policy must describe what screening is performed and for which roles
Maintain records confirming that screening was completed for each individual before access was granted. These records should be retained for the duration of employment plus your defined retention period
If you use a third-party screening service (HireRight, Checkr, Sterling, etc.), retain the completion confirmation and results summary. You do not need to store the full background check report indefinitely in most cases, but you need evidence that screening occurred
Common mistake: Running background checks as part of the hiring process but not connecting the completion of screening to the granting of system access. If an employee starts and receives CUI system access on day one but the background check results are not back until week three, that is a gap. Access to CUI systems should be conditional on screening completion, not on start date.
Practice 3.9.2: Protect CUI During Terminations and Transfers
3.9.2
Ensure CUI is protected during and after personnel actions such as terminations and transfers
When an employee leaves or changes roles, their access must be adjusted immediately. 3.9.2 is both a data protection practice and an access control practice. The CUI risk is real: a departing employee with live credentials can exfiltrate data, sabotage systems, or simply retain access they are no longer authorized to have.
Termination checklist (what a compliant offboarding process covers):
Disable all Active Directory / Entra ID accounts on or before the termination date, not after. Same-day revocation is the expectation
Revoke all individual application access that is not tied to the directory account: SaaS applications with separate logins, VPN credentials, cloud console access, shared accounts the employee used
Collect all physical access credentials: keycards, badges, hardware tokens, company-issued mobile devices, and laptops
Revoke any certificates or SSH keys assigned to the individual
Change passwords on any shared accounts the employee had access to
Review and disable any API keys or service accounts created by the individual for personal use
Recover and preserve any CUI the employee may have stored locally or in personal cloud storage used for work purposes
Document all revocation steps completed and by whom, with timestamps
Transfer / role change process:
When an employee changes roles, conduct a role-change access review: remove access from the previous role's systems and grant access appropriate to the new role only
Do not simply add new access on top of old access without reviewing what should be removed. Employees who have been in multiple roles accumulate privileges that no single role justifies (this is privilege creep, and assessors look for it)
Document role-change access reviews as you would any other access change
Common mistake: Relying on a manual notification chain where HR emails IT when someone leaves. If IT does not act on that email for three days, or the email goes to someone on vacation, the departed employee has live credentials for days. Automate the trigger where possible: HR system integration with your identity provider so that account deactivation is triggered by the HR action, not by a manual handoff.
Building the Process That Connects HR and IT
The PS domain is inherently cross-functional. The controls live in HR process (screening, offboarding checklists) and IT execution (account deactivation, access revocation). The gap is almost always in the handoff between them. A few things that close it:
Define SLAs: Your policy should specify how quickly access must be revoked after termination notification. Same-day is the standard expectation. Document it
Build a complete access inventory: You cannot revoke access to systems you do not know the employee had. Maintain a system access inventory per employee, updated when access is granted or changed
Use an offboarding checklist: A documented checklist that HR initiates and IT completes, with both parties signing off, creates the audit trail assessors expect
Verify revocation: After completing offboarding, verify that the account is actually disabled, not just that the ticket was closed. Spot-check recently offboarded accounts in Active Directory to confirm deactivation
Address contractors separately: Contractor offboarding often falls through the cracks because it is managed by the contracting relationship rather than HR. Make sure contractor offboarding triggers the same access revocation process as employee offboarding
Quick win: If you use Microsoft Entra ID (Azure AD), enable the lifecycle workflows feature. You can configure automatic account disabling triggered by the employee's end date in the HR system (Workday, BambooHR, etc.) via HR-to-Entra provisioning. This removes the manual handoff entirely for the most critical step: directory account deactivation.
Need the Policy Document?
Our CMMC Level 2 Personnel Security Policy template covers both PS practices in formal policy language. Includes pre-employment screening requirements by role, offboarding access revocation procedures, transfer role-change review process, and contractor coverage provisions. Editable .docx, ready to customize in under an hour.
NIST SP 800-171 practice 3.9.1 requires screening individuals prior to authorizing CUI access but does not prescribe a specific check type. Common baseline: identity verification, employment history verification, and 7-year criminal background check. For privileged roles, extend to credit checks and longer history windows. Document what your screening includes so assessors can verify it is applied consistently.
Yes. Practice 3.9.1 applies to any individual authorized to access systems containing CUI, including contractors, subcontractors, and vendor personnel with system access. Your personnel security policy should address how contractors are screened, either through your own process or by requiring attestation from the contracting organization that equivalent screening was completed.
NIST SP 800-171 does not specify a time limit, but the intent of 3.9.2 is immediate revocation: on or before the employee's last day, ideally at the moment of termination notification. Best practice and common assessor expectation is same-day revocation for all system access, with documented verification. Delays of even a few days are flagged as process gaps.
Practice 3.9.2 covers both terminations and transfers. For transfers, this means adjusting access to reflect the new role: removing access to systems the employee no longer needs and adding access appropriate to the new role. Without this review, employees accumulate privileges across roles, a pattern assessors specifically look for.
For 3.9.1: personnel security policy, pre-employment screening procedure, and records confirming screening was completed before access was granted. For 3.9.2: offboarding procedure, access revocation records with timestamps for departed employees, and transfer access review records. HR system exports and Active Directory account status reports are useful supporting evidence.