NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control PS.L2-3.9.2 requires organizations handling Controlled Unclassified Information (CUI) to ensure that individuals no longer needing access—due to termination, transfer, or role change—have their access removed or adjusted in a timely, auditable way; this post shows how to design a step-by-step offboarding checklist that satisfies the Compliance Framework while remaining practical for small businesses.
Why PS.L2-3.9.2 matters for the Compliance Framework
At its core PS.L2-3.9.2 enforces timely removal of access to systems and CUI to reduce insider and post-employment threats; failing to implement it exposes the organization to data exfiltration, accidental disclosure, lateral movement by threat actors using orphaned credentials, and contractual or regulatory penalties. For organizations following the Compliance Framework, demonstrating documented, repeatable offboarding processes—ideally automated and auditable—is essential evidence during assessments or CMMC audits.
Step-by-step offboarding checklist (high level)
1) Pre-termination preparation
Maintain a current employee inventory that maps individuals to privileges, owned assets, and CUI touchpoints. For each role track: AD/AzureAD username, SSO identity (Okta/OneLogin), cloud accounts (AWS/GCP/Azure), VPN access, SSH keys, MFA devices, code repo access (GitHub/GitLab), and physical access (badge/card). Keep this inventory in a secured CMDB or HR-integrated system so offboarding tickets can auto-populate with the exact list of items to act upon.
2) Termination / transfer day actions
On the effective date, perform a coordinated set of actions and record timestamps: disable user accounts (AD, AzureAD, Okta), revoke cloud IAM credentials and API keys, remove repo membership and deploy keys, revoke VPN access and certificates, deprovision MDM-managed devices (remote wipe if necessary), deactivate physical access cards, collect signed asset-return forms, and secure any CUI in the employee’s possession. Use a single offboarding ticket (ServiceNow/Jira/Trello) as the evidence record and require completion before closing.
3) Post-termination follow-up
Rotate shared credentials and service account secrets that the departed employee might have accessed, review logs for anomalous activity in the 30 days before/after termination, archive the user’s mailbox per retention policy (or forward to a manager if required), and ensure backups of approved user data are stored encrypted in a secure repository. Schedule an access validation 7–14 days after termination to confirm no lingering privileges remain.
Technical implementation details and example commands
Automate as much as possible. Examples: disable an AD account via PowerShell: Disable-ADAccount -Identity "jsmith"; Azure AD (AzureAD module): Set-AzureADUser -ObjectId user@company.com -AccountEnabled $false; AWS CLI to deactivate access keys: aws iam update-access-key --user-name jsmith --access-key-id AKIA... --status Inactive. For GitHub remove a user from an org via the Admin REST API or GitHub Enterprise console; for HashiCorp Vault remove policies and rotate secrets with vault kv delete/rotate commands. If you use Okta/SCIM, configure deprovisioning to disable accounts automatically when HR sets termination in the HRIS. For MDM (Intune/Jamf) issue a remote wipe and then reassign device inventory in the asset register.
Real-world small-business scenarios
Scenario A: A small dev shop uses Google Workspace + GitHub + AWS. Offboarding checklist items: suspend Workspace account (prevent login), revoke AWS access keys via AWS console/CLI, remove GitHub org membership and delete/rotate any deploy keys, and wipe the MacBook via Jamf. Scenario B: A small manufacturer with onsite CUI uses badge access and a local Windows AD. Actions: collect badge and sign return form, disable AD account, change shared SCADA passwords, and confirm that any CUI on USB drives has been returned or securely destroyed. Real breaches often start with a forgotten cloud key or an active personal SSH key—these scenarios show why thorough, role-specific offboarding matters.
Compliance evidence, audit tips, and what to log
For Compliance Framework evidence collect: the offboarding ticket, timestamps showing when each access was removed (screenshots or system logs), signed asset return form, screenshots of disabled accounts, change history from IAM systems, and any secret-rotation logs. Ensure centralized logging (SIEM) retains records long enough to satisfy contractual evidence requests; at minimum record discrete logs for account disablement, key revocation, and MDM wipes. If automation is used (SCIM or HRIS-triggered workflows), export workflow run logs as audit evidence.
Risk of not implementing PS.L2-3.9.2 and best practices
Risks include unauthorized access to CUI leading to breach notifications, contract termination or monetary penalties, and loss of trust with DoD or prime contractors. Best practices: apply least privilege so offboarding has fewer touchpoints; use role-based access control (RBAC) to simplify revocation; automate deprovisioning via SCIM/HRIS integrations; implement multi-factor authentication so disabled credentials have fewer residual risks; and run quarterly access reviews to find orphaned accounts. Maintain an offboarding runbook mapped to the Compliance Framework controls and revise it when systems change.
Summary
Meeting PS.L2-3.9.2 under the Compliance Framework requires a repeatable, auditable offboarding process that covers accounts, keys, devices, physical access, and CUI handling. Build a role-mapped inventory, automate deprovisioning where possible, use a single ticketing record for evidence, rotate shared secrets after departures, and retain logs to demonstrate timely actions during audits. For small businesses, implementing these steps reduces risk, simplifies audits, and helps maintain eligibility for contracts that require NIST SP 800-171 / CMMC compliance.
