CMMC Level 2 Practice 3.9.2: Ensure that organizational systems containing CUI are protected during and after personnel

CMMC Level 2 Practice 3.9.2 requires you to protect organizational systems that contain CUI during personnel actions (transfer, termination, role change) and after personnel exit by promptly removing access, recovering assets, and preventing data exfiltration. Operationalize it by integrating HR offboarding with IT deprovisioning, device/media return, and documented evidence capture mapped to 800-171 3.9.2. ¹

Key takeaways:

• Treat offboarding as a controlled security process: access removal, asset recovery, and CUI containment must be repeatable and evidenced. ¹
• Scope is “systems containing CUI,” including accounts, endpoints, cloud apps, collaboration tools, and removable media paths. ¹
• Assessors will look for proof the process runs every time, not just a policy statement. ²

This requirement is where “paper compliance” fails fast: a clean policy does not protect CUI if departed users keep access through an overlooked SaaS account, a shared mailbox, a VPN token, or a personal device that still syncs files. CMMC Level 2 Practice 3.9.2 (mapped to NIST SP 800-171 Rev. 2 control 3.9.2) expects you to control personnel actions so systems containing CUI remain protected during the transition and after the person leaves. ¹

For most contractors, the operational challenge is not knowing what to do, but making it happen consistently across HR, IT, Security, and business owners—especially for contractors, temporary staff, and third parties with access. You need a defined trigger (personnel action), a standard set of technical steps (disable, revoke, rotate, wipe, recover), and evidence that you did it for every in-scope event. ²

This page gives requirement-level implementation guidance you can put into your CMMC readiness plan immediately, including step-by-step execution, artifacts to retain, common assessor hangups, and a practical 30/60/90-day plan.

Target requirement (SEO)

Target keyword: cmmc level 2 practice 3.9.2: ensure that organizational systems containing cui are protected during and after personnel requirement

Regulatory text

Framework mapping: CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.9.2: “Ensure that organizational systems containing CUI are protected during and after personnel actions.” ¹

Operator interpretation:
You must run a controlled, repeatable offboarding/transfer process that (1) quickly removes user access to CUI systems, (2) recovers or secures organization assets and authentication factors, and (3) reduces the risk that CUI leaves with the person or remains accessible after the person’s role changes or ends. The assessor expectation is operational proof that the process executes, not just a written policy. ²

What counts as “personnel actions” in practice (non-exhaustive):

• Termination (voluntary/involuntary)
• Role change or transfer (privileged to non-privileged, program change)
• Extended leave that requires access suspension
• Contractor/consultant engagement end
• Third party support access expiration

Plain-English requirement: what this control is really asking

Protecting CUI “during and after” personnel actions boils down to three outcomes:

1. No lingering access: Accounts, sessions, tokens, and credentials get revoked so the person cannot access CUI systems after the change. ¹
2. No unmanaged CUI copies: Organization data and devices are returned or secured; local sync caches and removable media risks are addressed. ¹
3. No silent backdoors: Shared accounts, service accounts, forwarding rules, API tokens, or group memberships that survive offboarding are identified and corrected. ²

Who it applies to (entity + operational context)

Applies to: Defense contractors and any federal contractor handling CUI that is seeking or maintaining CMMC Level 2 alignment. ³

Applies when you have:

• Any system containing CUI (on-prem, cloud, hybrid) used by employees, temps, or third parties. ¹
• Identity and access paths into those systems, including SSO, VPN, EDR consoles, email, collaboration platforms, ticketing tools, and file shares. ¹

Common scoping decision that drives audit outcomes:
If a SaaS platform can store, process, or transmit CUI, treat it as in-scope for offboarding steps (access removal + evidence) even if it is “just collaboration.” Assessors will test whether your process covers the real CUI pathways. ²

What you actually need to do (step-by-step)

Below is a practical workflow you can implement as a standard operating procedure (SOP). Map each step to the systems in your CUI boundary.

Step 1: Define triggers and ownership

• Trigger events: HR termination, HR transfer, contract end date, privileged role removal request.
• Owners: HR initiates; IT executes account changes; Security verifies completion; System owners confirm access removed for their apps.
• Control point: A single “offboarding/transfer ticket” becomes the record of execution. ²

Step 2: Maintain an “access inventory” for CUI systems

Create and keep current:

• List of CUI systems (apps, file shares, cloud tenants, endpoints used for CUI).
• For each system: provisioning method (SSO vs local), admin owner, deprovision steps, evidence location.
  This prevents missed apps during an exit. ¹

Step 3: Execute immediate access containment

For the impacted person:

• Disable or suspend identity (AD/Azure AD/IdP) and revoke active sessions.
• Remove group memberships that grant access to CUI repositories.
• Revoke VPN/ZTNA access and device certificates tied to the user.
• Disable email and collaboration access where CUI could be stored or forwarded.
  The goal is to stop access first; cleanup can follow. ¹

Step 4: Collect and secure organizational assets and auth factors

Create a standardized return checklist:

• Laptops/desktops used for CUI
• Mobile devices (if enrolled for CUI access)
• Removable media issued by the organization
• Badges, smart cards, hardware keys, tokens
  If assets are remote, coordinate shipment and require confirmation of receipt with chain-of-custody notes. ¹

Step 5: Address CUI data remnants and account controls

This is where assessors often probe:

• Check for mail forwarding, shared mailbox delegation, and external auto-forward rules tied to the user.
• Transfer ownership of CUI-relevant files (repositories, project folders) to a manager or functional owner.
• Confirm endpoint protections remain in place until the device is wiped/reimaged per your standard build process.
• For privileged departures: rotate credentials that the person could know (local admin, shared accounts, break-glass access) based on your environment. ¹

Step 6: Special handling for contractors and third parties

Third party exits fail because access is “informal.”

• Require time-bounded access approvals (start/end) for third parties who touch CUI systems.
• Tie third party accounts to an internal sponsor accountable for deprovision.
• Confirm third party tools (remote support portals, federated accounts) are included in the access inventory. ²

Step 7: Verification and closeout (evidence-first)

Before closing the offboarding ticket:

• Security (or IT) verifies access revocation in the IdP and in key CUI systems.
• System owners attest removal for any system not centrally managed through SSO.
• Exceptions get documented with compensating controls and an end date. ²

Step 8: Recurring evidence capture (assessment readiness)

Do not wait for the assessment:

• Periodically sample recent offboarding/transfer records and confirm artifacts are complete.
• Track “missed steps” as corrective actions and update the checklist and access inventory.
  This aligns with the need for documented control operation and recurring evidence capture. ²

Required evidence and artifacts to retain

Keep artifacts that prove the control operates for each personnel action:

Core artifacts ³:

• Offboarding/transfer ticket with timestamped tasks and approvers
• HR trigger record (termination/transfer notice) linked to the ticket
• Account disablement screenshots/log exports (IdP/AD) showing status change
• VPN/ZTNA revocation evidence (logs or admin console export)
• Asset return checklist with confirmation of receipt
• Exception records (if any) with approval and expiration

Program-level artifacts (standing):

• Offboarding SOP (roles, steps, system list, escalation)
• CUI system access inventory (what to disable where)
• RACI matrix (HR/IT/Security/System owners)
• Training/communication to managers about initiating offboarding triggers
  Assessors commonly want both the “policy/SOP” and “proof it happened.” ²

Common exam/audit questions and hangups

Assessors and internal auditors tend to focus on these:

1. “Show me the last few offboardings.” Do you have complete tickets and logs for each? ²
2. “How do you handle role changes?” Many programs only treat terminations as offboarding. ¹
3. “Which systems contain CUI?” If you cannot define the boundary, you cannot prove protection. ¹
4. “What about SaaS not tied to SSO?” Local accounts are a frequent gap. ²
5. “What about shared/admin accounts?” They can keep access alive after a user exits. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Offboarding is “email IT”	No consistent trigger, no audit trail	Require a ticketed workflow tied to HR events. 2
Only disabling AD account	SaaS/local accounts remain active	Maintain an access inventory for all CUI systems and deprovision across them. 1
Ignoring transfers	Access creep persists inside the company	Treat transfers as personnel actions; remove prior access and reapprove new access. 1
No asset chain-of-custody	Devices/media may leave with CUI	Use a standardized return checklist and confirm receipt. 1
Evidence stored ad hoc	Cannot demonstrate control operation	Define an evidence repository and recurring collection plan. 2

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this specific practice, so do not plan around case law. What you can plan around is assessment risk: weak offboarding controls are easy for assessors to validate through sampling and can expose CUI through lingering access. CMMC participation is grounded in the DoD program and the CMMC rule structure in 32 CFR Part 170. ^{3 2}

Practical 30/60/90-day execution plan

Use this as an execution sequence, not a calendar promise.

First 30 days (stabilize the process)

• Define the offboarding/transfer SOP and RACI for HR, IT, Security, and system owners. ²
• Create the standard offboarding ticket template with required evidence fields.
• Build an initial access inventory for systems that store or transmit CUI. ¹
• Run a tabletop test on a recent termination and a recent transfer; capture gaps and update the checklist.

Next 60 days (close coverage gaps)

• Expand the access inventory to include non-SSO apps, admin consoles, and support portals.
• Implement a verification step before ticket close (Security signoff or peer review). ²
• Add third party offboarding triggers: contract end dates, sponsor attestations, and access expirations.
• Start a recurring evidence capture routine so artifacts are consistently stored and retrievable. ²

By 90 days (assessment-ready operations)

• Perform an internal sample review of offboarding/transfer records to confirm completeness and consistency.
• Document exceptions and compensating controls with clear ownership and expiration.
• Update training for managers and HR partners so personnel actions reliably generate tickets. ²
• If you need a faster path to readiness, Daydream can help you map 3.9.2 to a documented control workflow and automate recurring evidence capture so you can answer assessor sampling requests quickly. ²

Frequently Asked Questions

Does 3.9.2 apply to internal transfers, or only terminations?

It applies to personnel actions broadly, including transfers and role changes, because access must remain appropriate and systems containing CUI must stay protected. ¹

What counts as a “system containing CUI” for offboarding scope?

Any system that stores, processes, or transmits CUI should be in your offboarding access inventory, including SaaS and collaboration tools if CUI can exist there. ¹

We use SSO. Is disabling the IdP account enough?

Often yes for SSO-connected apps, but it is not sufficient if you have local accounts, API tokens, shared accounts, or external support portals outside SSO. Keep an inventory and verify deprovisioning across systems. ²

How should we handle third party administrators or MSP staff with CUI access?

Treat them as personnel actions at contract end or role change, require an internal sponsor, and ensure their accounts and remote access paths are revoked and evidenced. ²

What evidence is most persuasive to an assessor?

Ticket records tied to HR triggers, system logs showing account disablement and access revocation, and an asset return checklist provide the clearest proof the process operated for real events. ²

What’s the fastest way to find hidden access paths during offboarding?

Start from your CUI system inventory and validate each system’s deprovision steps, then add checks for local accounts, forwarding rules, and privileged credentials that bypass normal user access. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170