03.09.02: Personnel Termination and Transfer

Personnel movement creates the most predictable access-control failures: accounts that remain active after termination, privileges that carry over to a new role, and CUI stored on endpoints or in personal cloud locations that no one reclaims. NIST SP 800-171 Rev. 3 includes 03.09.02: Personnel Termination and Transfer to force disciplined, auditable offboarding and role-change handling for nonfederal systems that process, store, or transmit Controlled Unclassified Information (CUI). ¹

For a Compliance Officer, CCO, or GRC lead, operationalizing this requirement means turning “HR tells IT someone left” into an engineered control: clearly defined triggers, a standardized checklist, a system of record, and retained evidence that an assessor can follow from the personnel event to the exact access changes and asset recovery actions taken. This page gives you requirement-level guidance you can implement quickly: scope, procedures, step-by-step workflow, artifacts, audit questions, common mistakes, and a practical execution plan that aligns HR, IT, Security, and program leadership.

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.09.02 (Personnel Termination and Transfer).” ¹

Operator interpretation (what you must do):
You must run a controlled process whenever personnel are terminated or transferred so that:

• Access to CUI systems and locations is removed, disabled, or re-scoped to the new job need.
• Organization assets and credentials are recovered (or invalidated) so they can’t be used later.
• The actions are tracked and retained as evidence.

This is assessed as an operational control: auditors will look for consistency, completeness, and proof that the process works across identity systems, endpoints, collaboration tools, and any third parties that provide access paths.

Plain-English interpretation of the requirement

03.09.02 expects you to prevent “access hangover.” The moment someone leaves, or their role changes, your environment must reflect the new reality. For terminations, that usually means rapid revocation of all access and recovery of assets. For transfers, it means removing access that is no longer justified and granting only what’s needed for the new role, with approvals.

Transfers are where teams fail most often. A transfer can keep the same user but change the risk profile: new data sets, new projects, new CUI enclaves, new external sharing, or separation-of-duties concerns. Your process must handle those changes as rigorously as a termination.

Who it applies to (entity and operational context)

Applies to:

• Federal contractors and subcontractors operating nonfederal systems that handle CUI. ¹
• Any organization using NIST SP 800-171 Rev. 3 as a contractual or program requirement for CUI protection. ¹

Operational context (where you must implement it):

• Identity providers and directories (for example, SSO/IdP, directory services).
• Email and collaboration platforms.
• Endpoint fleet (laptops, mobiles, VDI).
• Privileged access paths (admin accounts, cloud consoles, break-glass access).
• CUI repositories (file shares, case tools, ticketing attachments, document management).
• Third-party services that provide access to CUI environments (managed service providers, consultants, staffing firms).

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

Step 1: Define the triggers and scope

Create explicit triggers for the workflow:

• Termination (voluntary or involuntary)
• Internal transfer (new manager, new department, new program)
• Contract/program change (moving on/off a CUI program)
• Extended leave or suspension (if your policy treats this as access removal)

Scope the workflow to accounts, devices, and data locations that touch CUI.

Step 2: Build a single “system of record” workflow

Pick one system to track each event end-to-end (commonly HRIS + ITSM integration, or ITSM as the execution record). The system of record must capture:

• Who the subject is (name, username, identifiers)
• Event type (termination vs transfer)
• Effective date/time
• Approver(s)
• Checklist completion and timestamps
• Exceptions and compensating controls

A practical pattern: HR initiates the event, IT executes access actions, Security validates high-risk steps, and the manager/program owner attests to CUI/data return steps.

Step 3: Standardize the offboarding/transfer checklist (minimum content)

Use a checklist that is short enough to run every time, but complete enough to satisfy an assessor. Include:

Access actions

• Disable interactive login for enterprise identity.
• Revoke SSO sessions and tokens (where supported).
• Remove from CUI-specific groups/roles and shared drives.
• Disable or rotate any local/shared credentials the person knew.

Privileged access

• Remove privileged roles.
• Rotate shared admin passwords and service credentials if exposure is plausible.
• Review recent privileged activity for anomalies (targeted, not “boil the ocean”).

Endpoint and asset recovery

• Recover laptop, mobile, badge, hardware tokens.
• Confirm device encryption status and remote-wipe capability; wipe when policy requires.
• Recover removable media issued by the organization.

CUI handling

• Identify CUI repositories the person accessed.
• Ensure CUI is in approved locations and not in personal storage.
• Transfer ownership of files, mailboxes, shared folders, and project workspaces to the manager or program owner.

Third-party access paths

• Notify managed service providers or external administrators to remove access tied to the user.
• Remove guest accounts and external shares created for the user.

Step 4: Define timing expectations and “same day” controls (without inventing metrics)

You need an internal standard for how quickly actions occur after the trigger. Don’t rely on informal norms. For higher-risk cases (involuntary termination, privileged users, or CUI program staff), require immediate coordination between HR, IT, Security, and the manager so disabling access is not delayed.

Step 5: Add transfer-specific guardrails

Transfers require a “remove then add” mindset:

• Remove access tied to the old role first (especially CUI enclaves and privileged rights).
• Require manager/program owner approval for new access.
• Confirm separation of duties where applicable.
• Re-train the user on any new CUI handling rules for the new program boundary (if your program has enclaves or segmented repositories).

Step 6: Implement verification, not just execution

Build a verification step that is independent of the person who performed the change:

• Security or IAM team verifies the account state (disabled vs enabled, group membership).
• Endpoint team verifies asset return or wipe status.
• Program owner verifies file ownership transfer and removal of inappropriate sharing links.

This is where most audit findings are avoided: you can prove the control worked, not just that you intended it to work.

Step 7: Make it auditable with recurring evidence collection

For assessment readiness, schedule recurring sampling:

• Pull a list of terminations/transfers for a period.
• For each, collect the workflow record and proof of access change.
• Track exceptions and close them with documented remediation.

Tools like Daydream can help you map 03.09.02 to a clear control narrative, assign evidence owners, and run recurring evidence requests so you do not scramble during an assessment.

Required evidence and artifacts to retain

Retain artifacts that let an assessor trace the personnel event to each control action:

People event record

• HRIS or HR ticket showing termination/transfer details and effective date/time.
• Manager notification/approval (for transfers and access changes).

Access revocation / modification proof

• ITSM tickets with checklist completion and timestamps.
• IAM/IdP admin logs or screenshots showing account disabled, groups removed, roles changed.
• Privileged access management records showing role removal and credential rotation steps.

Asset and endpoint proof

• Asset return form or chain-of-custody record.
• Endpoint management record showing last check-in, remote wipe (if applicable), encryption status.
• Badge deactivation confirmation (if integrated/available).

CUI-specific proof

• Evidence of file ownership transfer and removal of external sharing links where relevant.
• Confirmation that CUI was moved to approved repositories if remediation was needed.

Exception handling

• Approved exception with compensating controls, expiration date, and closure evidence.

Common exam/audit questions and hangups

Assessors tend to press on consistency and blind spots:

• “Show me three recent terminations and the evidence that access was removed across all systems in scope.”
• “How do you handle transfers so that access doesn’t accumulate?”
• “What about contractors, interns, and third-party users?”
• “How do you ensure privileged access is removed and shared credentials are rotated?”
• “Where is the system of record? Who signs off?”
• “How do you detect missed offboarding events?”

Hangups usually appear where HR and IT do not share a workflow, or where some systems are outside SSO and require manual steps.

Frequent implementation mistakes and how to avoid them

Mistake	What it looks like	How to avoid it
Offboarding is “disable AD” only	SaaS apps, email, and shared drives stay accessible	Maintain an application inventory for CUI scope and bind it to the checklist
Transfers treated as benign	User keeps old program access and gains new access	Require removal of old groups/roles before granting new ones
No coverage for third-party accounts	Guests and MSP accounts are forgotten	Include guest/external identities and third-party administrators in scope and sampling
No proof, only policy	You can describe the process but can’t show tickets/logs	Make the workflow system the evidence store; require attachments/links to logs
Shared credentials ignored	Departing admin knew a shared secret	Ban shared credentials where possible; otherwise rotate after sensitive departures
Exceptions never expire	“Temporary” access persists	Require time-bound exceptions with owner, rationale, and closure tracking

Risk implications (why assessors care)

Poor termination and transfer controls create direct paths to unauthorized access to CUI: former personnel logging in with still-valid credentials, access via active sessions, continued mailbox forwarding, or retained device access. Transfers can also violate least privilege, expanding who can see CUI beyond the need-to-know boundary. NIST SP 800-171 assessments typically test this control through sampling and corroborating logs because it is operationally observable. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an owner for 03.09.02 (usually IAM or Security GRC) and name execution owners in HR and IT.
• Document the workflow triggers and define the system of record (HRIS/ITSM).
• Publish a single checklist for termination and transfer, including privileged access and CUI repositories.
• Run a pilot on recent events to find missed systems (guest accounts, niche SaaS, shared drives).

Next 60 days (Operationalize and verify)

• Integrate HR events to ITSM ticket creation, or enforce a manual intake with required fields.
• Build an application/access inventory for CUI scope and map each to a deprovisioning step.
• Add an independent verification step and define what “done” means for each checklist item.
• Start recurring evidence sampling and store artifacts in a consistent location (with naming conventions).

By 90 days (Assessability and resilience)

• Expand coverage to third-party identities, shared admin credentials, and non-SSO systems.
• Establish exception governance (approval, time bounds, compensating controls, closure).
• Create a transfer access review step tied to role change approvals.
• Use a control-to-evidence mapping in Daydream so each sampling cycle produces assessor-ready packets without ad hoc chasing.

Frequently Asked Questions

Does 03.09.02 apply to internal transfers, or only terminations?

It covers both termination and transfer events, and transfers are a common source of privilege creep. Treat transfers as a required access re-authorization, not just an HR change.

What counts as acceptable evidence that access was removed?

Keep the workflow record (ticket/checklist) plus system evidence, such as IAM/IdP logs showing disablement and group removal. If a system is manual, retain screenshots or admin audit logs tied to the ticket.

How do we handle involuntary terminations where timing is sensitive?

Pre-stage coordination between HR, IT, and Security so access disablement happens in lockstep with the personnel action. Require heightened steps for privileged users, including session revocation and credential rotation where applicable.

Are contractors and third-party users in scope?

Yes if they have access to your CUI environment or supporting systems. Apply the same workflow triggers tied to contract end dates and access removal confirmations.

What if our SaaS apps are not connected to SSO?

Treat those as high-risk manual deprovisioning steps and list them explicitly in the checklist. Track completion with admin logs or screenshots and periodically test that no active accounts remain after offboarding.

How should we handle shared mailboxes and file ownership during a transfer?

Require the manager or program owner to attest that ownership and access were reassigned appropriately and that external sharing links were reviewed. Keep the attestation with the transfer ticket for audit traceability.

Footnotes

1. NIST SP 800-171 Rev. 3