03.09.02: Personnel Termination and Transfer

03.09.02 is a requirement you can’t “policy” your way through. Assessors look for operational proof that people who separate from the company, or move to a new position, stop having the wrong access to systems that store, process, or transmit CUI. The highest-risk failures are predictable: HR never notifies IT in time, access is removed in one place but not another, and “transfer” events are treated as harmless even though the user keeps old entitlements.

This page translates 03.09.02 into a fast, defensible implementation pattern: an end-to-end joiner-mover-leaver (JML) process anchored in an authoritative identity source, with automation where you can and verification where you must. You’ll also get an audit-ready evidence list, common assessor questions aligned to NIST SP 800-171A expectations, and a practical execution plan to get from “inconsistent offboarding” to “repeatable, testable control.”

Primary sources: NIST SP 800-171 Rev. 3, its landing page, and NIST SP 800-171A assessment requirements. ¹

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.09.02 (Personnel Termination and Transfer).” ²

What the operator must do (requirement-level meaning):
You must have an enforced, repeatable process that:

1. triggers on personnel termination and personnel transfer,
2. promptly removes, disables, or adjusts logical access to CUI-relevant systems based on the event, and
3. produces evidence that actions were completed and verified across the environment.

Treat the “transfer” half as equal to termination: the user’s access must be re-aligned to the new job function and need-to-know. Your SSP should state how your organization performs these actions, what systems are in scope, and who owns each step. ²

Plain-English interpretation

If someone leaves, they should not be able to access CUI systems afterward. If someone changes roles, they should not keep access that no longer matches the new role, and they should only gain new access through your normal approval path. This is an identity governance control, but it’s also a data protection control because stale access is a common path to CUI exposure.

Who it applies to (entity and operational context)

Applies to nonfederal organizations that handle CUI, including federal contractors and subcontractors, and any environment where your people (employees, temps, interns) access CUI through corporate endpoints, VDI, cloud services, on-prem systems, or third-party platforms integrated into your workflows. ²

Operationally, it applies whenever:

• HR records a termination (voluntary or involuntary)
• A contract ends for a staff augmentation resource
• A person transfers teams, projects, programs, or CUI enclaves
• A person changes employment status (e.g., conversion, leave scenarios that should disable access)
• A person changes identity attributes that drive access (department, cost center, manager)

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

Step 1: Define scope and the “authoritative trigger”

1. List in-scope identities: employees, interns, temps, and any other personnel with accounts in CUI systems.
2. Define the authoritative source for status and role: typically HRIS for employment status and org structure; IAM/IdP for identity lifecycle state.
3. Document the trigger events: termination date/time, last day worked, immediate termination, transfer effective date, manager change, department change.

Deliverable: a short control statement in the SSP describing your JML trigger and the systems covered. ²

Step 2: Build a system inventory for deprovisioning coverage

Create (and keep current) a list of every system where access must be changed:

• Identity provider (SSO), directory service, MFA platform
• Email and collaboration (mailbox, shared drives, SharePoint/Teams equivalents)
• VPN/ZTNA, remote access gateways
• Endpoint management and disk encryption consoles
• Ticketing, code repos, CI/CD, secrets vaults
• CUI repositories and program-specific systems
• Privileged access (admin consoles, break-glass accounts, PAM)
• Any third-party systems with CUI access paths

This list is where many teams fail: offboarding works in the IdP but not in “long tail” SaaS. Track the inventory as an artifact and map it to your SSP boundary. ²

Step 3: Implement termination workflow (disable first, then clean up)

A defensible termination pattern:

1. Immediate access cut-off: disable primary account in IdP/directory; revoke sessions/tokens where supported; enforce MFA reset where needed.
2. Privileged access removal: remove privileged group memberships; disable admin accounts; rotate shared/admin credentials the person knew.
3. Remote access shutdown: disable VPN/ZTNA accounts and device certificates.
4. Data access containment: remove from shared drives, project workspaces, CUI repositories; transfer mailbox and file ownership if needed.
5. Asset return and sanitization: coordinate retrieval of endpoints, badges, tokens, and any removable media governed by your procedures.
6. Closeout verification: a second person (or automated control) confirms access removal in the key systems list.

Operational note: build “emergency termination” handling where HR or Security can trigger immediate disablement outside business hours.

Step 4: Implement transfer workflow (re-authorize, don’t accumulate)

Transfers should result in least privilege for the new role, which typically means:

1. Trigger: HRIS/manager initiates transfer; effective date recorded.
2. Access review: identify entitlements tied to old role (groups, app roles, privileged memberships).
3. Removal first: remove old role access on transfer effective date (or earlier if job duties change sooner).
4. Add via standard request: grant new access only through your normal approval process with manager and data owner approval.
5. Verification: confirm entitlements match the new role profile; confirm old access is gone.

If you use role-based access control (RBAC), build role profiles for major functions and treat transfer as moving between profiles.

Step 5: Tie it to measurable criteria (what “done” means)

Define “implementation criteria” that you can test repeatedly, such as:

• Which systems must show the account disabled for a termination to be complete
• Which logs or admin screens prove removal (directory status, group membership changes, IdP audit logs)
• Who signs off and where that record lives (ticket completion + reviewer)

This is where teams often stop at “we have a policy.” Your criteria should be specific enough that an assessor can sample records and replicate your check steps. ³

Step 6: Evidence collection and governance (SSP + POA&M)

• SSP mapping: document the control implementation, owners, and system components for 03.09.02. ²
• POA&M tracking: if any system is not covered by automated deprovisioning or consistent tickets, log the gap with dates, risk, and closure validation steps. ²

Practical: Daydream is useful here because it forces requirement-to-SSP mapping, assigns control owners, and keeps recurring evidence and POA&M closure proof together, which is what assessors ask for during 800-171 aligned reviews.

Required evidence and artifacts to retain

Keep artifacts that show trigger → action → verification:

Governance / design

• JML / offboarding procedure (termination + transfer)
• Access control policy references for role changes and least privilege
• System inventory for deprovisioning scope (CUI-relevant apps and infrastructure)
• SSP control statement and boundary notes for 03.09.02 ²

Operational records (sampleable)

• HR or manager initiation record (termination/transfer request)
• Offboarding/transfer tickets with timestamps, approvers, and completion notes
• IAM/IdP audit logs showing disablement and group removals
• PAM logs showing privileged removal and credential rotation events, if applicable
• Evidence of session revocation where available
• Verification/QA checklist completed by IT/Security
• Exceptions documentation (e.g., legal hold mailbox access) with approval and compensating controls

Assurance

• Periodic access reviews that include moved users and privileged roles (ties to broader access control controls, but supports 03.09.02 testing)
• Internal test results: sampled terminations/transfers with findings and remediation notes ³

Common exam/audit questions and hangups

Expect questions in these buckets (aligned to how assessments are executed under NIST SP 800-171A): ³

• Trigger reliability: “How do you know IT is notified for every termination and transfer?”
• Timeliness: “What happens for immediate terminations or after-hours?”
• Coverage: “Show me removal in the IdP and in these three SaaS tools where CUI is stored.”
• Transfers: “Prove the user lost old access, not just gained new access.”
• Privileged access: “How do you handle admin roles, shared accounts, and break-glass credentials?”
• Verification: “Who validates completion, and where is that recorded?”
• Boundary clarity: “Which systems are in scope for CUI, and how do you ensure those are included in offboarding?”

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix that works in practice
Offboarding only disables SSO	Users retain direct accounts in SaaS or local apps	Maintain an app inventory and integrate or manually deprovision long-tail apps with checklists
Transfers treated as “add access”	Permission creep breaks least privilege	Remove old role access first, then add new access via approval workflow
No evidence beyond a policy	Assessors sample transactions	Store tickets + IAM logs + verifier sign-off per case
Shared credentials not rotated	Departed users retain knowledge	Put shared credentials behind PAM; rotate on separation
Contractors missed	Different onboarding/offboarding path	Force all personnel through the same identity lifecycle controls, regardless of HR category

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The risk remains operational and contractual: failure to control termination/transfer access increases the likelihood of unauthorized CUI access and creates assessment findings that can drive remediation obligations and customer trust issues under CUI handling expectations. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name control owners: HR process owner, IAM owner, Security verifier, app owners.
• Document the termination and transfer workflows and the authoritative trigger source.
• Build the in-scope system inventory for CUI access paths.
• Update the SSP control statement for 03.09.02 and identify gaps for POA&M. ²

Days 31–60 (cover the environment)

• Integrate HRIS → IAM trigger where feasible; otherwise enforce ticket creation from HR.
• Implement “disable first” actions in IdP/directory and remote access.
• Add long-tail apps to the checklist and assign an owner for each.
• Stand up a verification step with a second set of eyes (or automated audit report) and make it mandatory for closure.
• Start collecting evidence in a consistent repository for assessment readiness. ³

Days 61–90 (prove it works repeatedly)

• Run a sample-based internal test of recent terminations and transfers; document results and remediations.
• Reduce exceptions: move shared credentials into PAM and formalize rotation steps.
• Operationalize reporting: weekly exceptions report (open offboarding tickets, overdue deprovisioning, transfer mismatches).
• Close POA&M items with validation evidence and update SSP narratives to reflect the final operating process. ²

Frequently Asked Questions

Does 03.09.02 apply to contractors and temporary staff?

Yes, treat any personnel with access to CUI systems as in scope. If they can authenticate to the environment, you need a termination/transfer trigger and deprovisioning evidence for them. ²

What counts as a “transfer” for this requirement?

Any role, team, program, or duties change that affects what CUI the person should access qualifies operationally. Your process should remove old entitlements and require re-approval for new access aligned to the new need-to-know. ²

We disable the IdP account. Is that sufficient?

Only if disabling the IdP actually prevents access everywhere CUI exists. Assessors often test long-tail SaaS or direct accounts, so keep an inventory and evidence that those accounts are also disabled or removed. ³

How do we show “verification” to an assessor?

Pair each termination/transfer ticket with system logs or admin screenshots showing the account disabled and groups removed, then record a reviewer sign-off. NIST SP 800-171A-style assessments favor observable evidence over statements. ³

What about mailboxes and files for terminated users under legal hold?

Preserve data under legal hold, but still disable interactive access. Document the exception, the approver, and the compensating controls (who can access the preserved data and how). ²

Where should this live in our SSP and POA&M?

In the SSP, describe the workflow, triggers, tools, and system coverage for 03.09.02. In the POA&M, track any app not consistently deprovisioned, missing evidence sources, or gaps in verification with target closure steps. ²

Footnotes

1. NIST SP 800-171 Rev. 3; NIST SP 800-171 Rev. 3 landing page; NIST SP 800-171A

2. NIST SP 800-171 Rev. 3

3. NIST SP 800-171A