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.
\n\nAt 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.
\n\nMaintain 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.
\n\nOn 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.
\n\nRotate 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.
\n\nAutomate 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.
\n\nScenario 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.
\n\nFor 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.
\n\nRisks 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.
\n\nMeeting 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.
", "plain_text": "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.\n\nWhy PS.L2-3.9.2 matters for the Compliance Framework\nAt 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.\n\nStep-by-step offboarding checklist (high level)\n1) Pre-termination preparation\nMaintain 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.\n\n2) Termination / transfer day actions\nOn 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.\n\n3) Post-termination follow-up\nRotate 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.\n\nTechnical implementation details and example commands\nAutomate 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.\n\nReal-world small-business scenarios\nScenario 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.\n\nCompliance evidence, audit tips, and what to log\nFor 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.\n\nRisk of not implementing PS.L2-3.9.2 and best practices\nRisks 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.\n\nSummary\nMeeting 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." }, "metadata": { "description": "A practical, actionable guide for building an auditable offboarding checklist that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control PS.L2-3.9.2, with technical examples for small businesses.", "permalink": "/how-to-create-a-step-by-step-offboarding-checklist-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-psl2-392.json", "categories": [], "tags": [] } }