03.09.02 Personnel termination and transfer requirements

What 03.09.02 personnel termination and transfer asks for

A contract that requires NIST SP 800-171 puts 03.09.02 in front of three teams at once: HR, IT and whoever runs offboarding. The requirement is triggered by two events. The first is employment ending, where the organization must disable system access within a defined time, revoke authenticators and credentials, and retrieve security-related property such as badges, tokens and laptops. The second is a reassignment or transfer, where the organization must review whether each person still needs their logical and physical access and change it to match the new role. The defined time is an organization-defined parameter, so the organization must set it and be able to show the value it chose. Assessors check that value exists as part of the requirement, so a policy that says "promptly" will not carry the weight alone.

The main risk is the orphaned account: an identity that still works after its owner has left, or a former role's permissions that survive a move. These are hard to see because the leaver event rarely has one owner. HR records the exit, the manager asks for access removal, and IT may only learn about it days later. Shared accounts make this worse because no single credential maps to one person, and access granted outside the central identity system, such as local application logins, vendor accounts or cloud roles created by hand, is never touched by a disable step in the directory. An illustrative check: pick five recent leavers and confirm that every account they held, including those outside the directory, was disabled and that their authenticators and tokens were recovered.

This requirement differs from 03.09.01 Personnel screening. Screening happens before a person is authorized and again under defined conditions, and it asks whether the person should have access at all. Termination and transfer asks whether access that once was right is still right, and whether it has been removed when it no longer is. Rev. 3 wording differs from Rev. 2: the Rev. 2 equivalent is 3.9.2, and the Rev. 3 change analysis classifies the change as significant, with more detail and foundational tasks. CMMC Level 2 still uses Rev. 2 and assesses 3.9.2 as PS.L2-3.9.2, so a DoD contractor is assessed against the Rev. 2 wording, and its 5 points under the scoring methodology cannot be placed on a POA&M for Conditional status. Confirm with the contracting officer which revision governs the contract before you map the work.

Which accounts, systems and people this requirement reaches

Before anyone can show that access is removed or adjusted on departure or transfer, the organization has to decide which accounts, facilities and people fall inside the CUI boundary. Each decision below changes the population of access records an assessor will sample, so each one changes the evidence set.

Logical accounts across the CUI system

Every account that can reach a system that stores, processes or transmits CUI is in scope, including local accounts on servers, database accounts, administrative accounts and accounts in security tools. Identity providers often hold the main directory, but local break-glass or appliance accounts frequently sit outside it. Check whether each account has an owner, a documented disable step and a termination record. An assessor will usually pick a departed employee and trace whether every one of those accounts was disabled within the period the organization defined.

Connected applications and federated access

Applications that accept logins from the CUI system, or that hold copies of CUI-related user data, extend the scope of the termination process. When a user loses access to an application, that access must also end in the application itself, not only at the central login. Map which applications receive accounts from the directory, whether provisioning is automatic or manual, and how deprovisioning is logged. Manual application accounts are a common gap because no single system shows that they were removed.

Physical access credentials at CUI facilities

Badges, keys, PIN codes and visitor credentials that open rooms or areas where CUI systems or media are kept fall under the same termination requirement as logical access. Physical credentials are often managed by facilities or security staff, outside the IT team that disables accounts. Confirm who receives termination notices for physical access, how badges are collected or deactivated, and whether the physical access list is updated in the same cycle as system access. Ask for records that link a departure to both kinds of removal.

Contractors and subcontractor staff

Contractors, consultants and subcontractor personnel who hold accounts on the CUI system are people with access, so their end-of-engagement must be handled like an employee departure. The contract end date often does not match the date access is removed, and the organization may not receive a notice from the subcontractor. Record each external account with a sponsor and an end date, and confirm that the flow-down terms require the subcontractor to report personnel changes. Evidence should show the removal date and who performed it.

Service and shared accounts

Service accounts, scheduled jobs and shared administrative logins have no single person to terminate, so departures can leave them untouched. The termination process should identify any account whose credentials a departing person knew or could reach, then rotate those credentials and revoke the associated tokens or keys. Keep an inventory that names an accountable owner for each non-personal account. An assessor will ask how the organization knows which shared credentials a leaver could have used, and records should answer that question.

Transfers from teams outside the enclave

A person who moves into a role that touches the CUI enclave from a team that was never in scope still creates an access decision. Their previous access may have been broad, and that history may not be visible to the enclave owner. The transfer review should compare the person's current access across all systems with what the new role needs, and it should cover any inherited group memberships or entitlements. Confirm that the enclave owner receives transfer requests, and that transfers into the enclave are reviewed as additions, not only as changes.

How an assessor tests 03.09.02 with seven determination statements

This table groups the seven determination statements for 03.09.02 by the action each one checks, then adds the ODP check for the disabling time. Read each row as the question the assessor asks, the evidence they pull and the gap they most often record. Confirm the statement-level method assignments in SP 800-171A Rev. 3 before you build your evidence list.

Determination area	Methods and objects reviewed	Common finding when missing or stale
Termination policy and procedures exist	Examine personnel security policy and termination procedures. Interview personnel with personnel security responsibilities.	Termination steps live in a helpdesk checklist with no owner, approval or review date.
Access is disabled within the defined time	Examine termination records and the list of system and facility access authorizations. Test the termination process with a sample of departures.	Leaver accounts remain active past the organization's own deadline, found by comparing HR exit dates to directory status.
Authenticators and credentials are revoked	Test whether tokens, certificates, API keys and shared-account passwords tied to the leaver stop working. Interview account management staff.	Service credentials, VPN certificates or SSH keys are not on the leaver checklist, so they survive the account disable.
Security-related property is retrieved	Examine termination records for return of laptops, badges, tokens and media. Interview personnel handling offboarding.	Return of hardware and badges is not logged, so the assessor cannot confirm recovery for any departure.
Transfers trigger a review of ongoing access need	Examine records of personnel transfer actions and the procedures for personnel transfer. Interview personnel with account management responsibilities.	Transfers are logged in HR, but no one in IT is notified, so the old role is never reviewed.
Access is modified to match the new role	Compare access authorization lists before and after recorded transfers. Test the transfer process with sample moves.	Transferred staff keep prior group memberships and gain new ones, producing access accumulation.
Physical access is reviewed on transfer	Examine facility access authorizations and transfer records. Interview personnel with information security responsibilities.	Badge and facility access lists are not part of the transfer workflow, so former duties keep building access.
ODP: disabling time period is defined	Examine the documented time period for disabling system access and confirm it is set, approved and referenced in procedures.	The period is missing from the policy, so the team cannot show what the assessor should test against.

How to implement termination and transfer controls in order

This sequence turns 03.09.02 into a working process: one defined disable-access period, every access path tied to a leaver or transfer event, and records that show each step happened. Each step ends with the artifact an assessor will ask to see.

Set the disable-access period as a defined value
The organization owns this decision. Its personnel security leadership assigns the time period within which system access must be disabled after employment ends, because 03.09.02 has one organization-defined parameter for exactly this. NIST does not supply the value, and if a federal customer specifies one, use that. Write the value into the termination procedure and the policy that governs it, so the number an assessor tests against is the number staff follow. Output to show the assessor: the approved personnel security policy and termination procedure with the ODP value stated, plus the approval record.
Map every access path to a leaver event
Build a register that lists each route into the environment: the central directory, individual applications, VPN and remote access, cloud consoles, privileged and administrative accounts, shared service accounts, hardware tokens, physical badges and keys. For each path, record the system of record, the owner who removes access, and whether removal is automatic or manual. Automated deprovisioning is worth evaluating where a central identity source can drive it. Output to show the assessor: the access path register, reviewed against the current application inventory and signed off by the account management owner.
Build the revocation and authenticator retirement steps
Write the runbook that disables the identity at the source, then confirms removal in each downstream application. Include steps to revoke active sessions, retire passwords, one-time codes, API keys and certificates tied to the person, and reclaim or deactivate hardware tokens. Where a directory such as FreeIPA holds identities, or an identity provider such as authentik or Keycloak fronts applications, confirm which actions propagate automatically and which require a manual ticket. Test the runbook on a non-production identity before relying on it. Output to show the assessor: the runbook, change records from test runs, and a sample of completed leaver tickets with timestamps.
Run the property return checklist
Security-related property includes laptops, mobile devices, tokens, badges, keys, removable media and any documents holding CUI. HR, the manager and IT jointly complete a checklist before the final working day or as close to it as the process allows. Record each item as returned, accounted for as lost, or waived with an approver's name. Reconcile the checklist against the asset inventory so unreturned devices are visible to the security team. Output to show the assessor: completed checklists for a sample of departures and the reconciliation report against the asset inventory.
Trigger the transfer review on role change
When someone moves to a new role, the transfer event should start a review of ongoing need for logical and physical access. The reviewer compares the person's current group memberships, application roles, privileged rights and facility authorizations against what the new role requires, then removes what is no longer needed and adds what is justified. Access that stays is documented with a reason. Keep the review separate from the HR paperwork, so the old access is not left in place because no one asked. Output to show the assessor: transfer records that list the before and after access and the reviewer's decision.
Certify ongoing access on a schedule
Periodic certification catches access that accumulated through transfers and exceptions. Access certification campaigns, such as those in midPoint, have designated reviewers decide within a set timeframe whether to keep, change or revoke each access item. Set the cadence and the timeframe in the policy, and confirm the tool supports the review evidence you need. Track overdue reviews and escalate them. Output to show the assessor: campaign definitions, completed reviewer decisions, and the list of revocations that followed.
Test the process and keep the evidence trail
Sample real leavers and transfers each cycle and trace each one from the HR event through revocation, property return and access review. Log exceptions and the corrective action taken. Confirm the access path register still matches the systems in production, since new applications are a common source of gaps. Ask an independent assessor which samples they expect, because the examine, interview and test methods in SP 800-171A Rev. 3 shape what evidence is persuasive. Output to show the assessor: test records, exception logs and a dated register review, all retained with the system security plan.

Evidence that shows leavers lose access on time

An assessor testing 03.09.02 looks for proof that the written procedure ran on real termination and transfer events, not just that the procedure exists. The cards below cover the records that prove it, and each one notes how to keep it current between assessments so the evidence is not rebuilt in a scramble before an audit.

Written termination and transfer procedure

This is the document that names the time period within which system access must be disabled, which is the one organization-defined parameter for 03.09.02. Set that value in the procedure and make sure it matches what the directory and identity tools actually enforce. Review it on a fixed schedule and after any change to HR or identity systems, and record the review date and approver so the version history shows it was maintained.

Timestamped termination event records

Each separation should leave a record from the HR system showing the effective end date and the time the account change was requested and completed. Auditors compare these timestamps against the defined period to test whether the procedure was followed. Confirm that HR exports feed the identity system automatically, and sample a few leavers each quarter to check that the gap between separation and disablement stays within the defined time.

Deprovisioning logs and directory change history

Directory and provisioning logs show which accounts were disabled, deleted or removed from groups, and when. For example, an authentik SCIM provider run that deprovisions a user from a target application produces a change that should appear in its logs. Keep these logs centrally, protect them from edits, and confirm the retention period with your security and records teams so the evidence covers the whole assessment window.

Authenticator and token revocation records

Disabling a directory account does not revoke everything a person holds. Keep records showing that passwords were reset or invalidated, MFA devices were removed, API keys and tokens were revoked, and active sessions were ended. For single sign-on, confirm that revoking the identity also stops new tokens from being issued by the federated apps. Build a checklist that the operations team completes and attaches to each termination ticket.

Property return checklists signed by managers

Security-related property includes laptops, badges, hardware tokens, removable media and any device that holds CUI. The checklist should list each item issued to the person, show when it came back, and carry the manager's signature. Reconcile the list against the asset inventory so unreturned items are flagged, and set a rule for how long a missing item stays open before escalation.

Transfer records with before and after access lists

When someone changes role, the evidence is a pair of access lists, one captured before the move and one after, with a record of the reviewer who confirmed that the remaining access still matches the new duties. This is the artifact that proves the ongoing need for access was reviewed, not just added to. Access certification campaigns in midPoint can produce these decisions as a campaign record, and the reviewer's decisions can be exported for the file.

Periodic reconciliation against the HR roster

Compare the list of active accounts in each system against the current HR roster on a regular schedule. Any active account without a matching employee, contractor or approved service owner is a finding to investigate and close. Record the date, the systems compared, the number of exceptions and how each was resolved. Running this check monthly, rather than only before an assessment, shows the control operates continuously.

What meeting 03.09.02 costs in money and effort

This table lists the cost components of meeting 03.09.02, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No price or duration is stated because none is supplied for this requirement, so use the table to structure quotes and ask each vendor or partner for figures against the same components.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Identity tooling or licenses	Software vendor or reseller, if commercial	Usually recurring (per user or per application, check the vendor's terms)	Up: number of users and connected applications. Down: self-hosted open-source identity platforms may remove license spend, but hosting and support still need budget
Engineering time to connect applications and automate deprovisioning	Internal platform or IT staff, or an implementation partner under a fixed-scope agreement	One-time for initial connectors, then recurring for changes	Up: number of applications without standard protocols, shared accounts and local-only logins. Down: applications that support SCIM, OpenID Connect or SAML
HR process change	Internal HR, IT and security staff	One-time to define the termination and transfer workflow, then recurring for review	Up: multiple HR systems, contractors managed outside HR, and unclear ownership. Down: a single authoritative identity source feeding all access decisions
Recovery of authenticators and security property	Facilities, IT and line managers	Recurring, with each departure and transfer	Up: physical credentials such as badges, tokens and keys, and remote staff who must return equipment. Down: tracked inventory tied to the identity record
Transfer access reviews	Managers and access reviewers	Recurring, with each transfer and at any scheduled review cycle	Up: frequent role changes and access accumulation. Down: role-based access and scheduled certification campaigns with named reviewers
Evidence upkeep	Internal compliance or IT staff	Recurring, with each assessment cycle	Up: manual tickets and screenshots, and records split across systems. Down: logs and workflow records kept in one place and retained automatically
External testing or review	Independent testing firm or consultant, if used	Recurring at each test cycle	Up: number of systems in scope and depth of test. Down: a documented scope agreed before work starts
Assessor effort	Assessor or assessing body, under the agreement with the contracting agency or auditor	Recurring at each assessment	Up: incomplete evidence, unclear ownership and missing ODP values. Down: a defined disable time, written procedures and ready records. Confirm fee basis with the assessor

Which self-hosted tools automate deprovisioning and access review

Removing access on time is easier when one system drives the change everywhere it matters. The four tools below cover different parts of that job: provisioning into applications, the central directory, periodic review of granted access, and single sign-on. Each produces different evidence, and each depends on what your applications actually support.

authentik SCIM provider for deprovisioning

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. For 03.09.02, the sync log and the target account state can show that a removed person no longer holds an account. Confirm that each target application supports SCIM 2.0 and which attributes it accepts, because applications without SCIM need manual or scripted removal. The license is MIT.

FreeIPA and 389 Directory Server

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Centralized access control and delegated administration let you assign disabling rights to a specific team and keep a single record of who can administer what. Confirm the directory is the authoritative source for user identity in your environment, and test whether disabling an account there reaches every system that relies on it. FreeIPA is licensed under GPL-3.0-or-later.

midPoint access certification campaigns

midPoint access certification campaigns assign designated reviewers who decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This addresses access that accumulates after transfers, which is the part of 03.09.02 that asks you to review ongoing need on reassignment. Records of each decision, the reviewer and the deadline are the evidence an assessor will examine. Confirm who owns the review timeframe you set and what happens to items not decided in time. midPoint is licensed under EUPL-1.2+.

Keycloak single sign-on

Keycloak provides single sign-on so users authenticate with Keycloak rather than each application, and it supports OpenID Connect, OAuth 2.0 and SAML 2.0. It can also broker logins to existing OpenID Connect or SAML 2.0 identity providers. Disabling a user in Keycloak cuts off sign-in to every application that relies on it, which shortens the window in which a departed person can reach systems. Confirm that each application truly uses Keycloak and that local accounts or long-lived tokens cannot bypass it. Keycloak is licensed under Apache-2.0.

Who runs termination and transfer work and who checks it

Your organization owns requirement 03.09.02. HR and IT leaders must agree on what counts as a leaver event, who is notified, and how fast access must end once employment ends or a role changes. The defined time period is an organization-defined parameter, so the value is your decision and should be written into the personnel security procedure. Your team also runs the periodic access review that confirms transferred staff no longer hold access they do not need.

Procedure ownership: HR and security set the termination and transfer procedure, including the trigger, the owner of each step and the time limit.
Authenticator and property recovery: Facilities and IT track return of badges, tokens, laptops and other security-related property.
Transfer reviews: Managers confirm which access a moved employee keeps, changes or loses, and IT records the decision.
Records: Keep dated tickets or HR system entries that show when each step happened.
Check to make: Confirm that someone named on your staff can produce a leaver record for any recent departure within a few minutes.

Where organizations usually fall short on termination and transfer

Most failures under 03.09.02 are not missing policies. They are gaps between the HR event and the systems that hold access, and gaps in the records that would prove timing. The cards below cover the places assessors most often find those gaps and the fix for each.

No defined disable time

03.09.02 has one organization-defined parameter: the time period within which system access must be disabled. Many organizations never write a number down, so the requirement has no value to test against. Set the period in the personnel termination procedure, state it in the system security plan, and confirm that the ODP value is defined, since assessors check for that as well.

Directory disabled, application accounts live

Disabling a person in the directory often leaves local accounts, SaaS logins, API keys and cached sessions active. Map every system that holds CUI or grants access to it, then confirm each one is disabled or federated to the directory. Where provisioning is automated, verify that deletions and deactivations actually reach each target application, not just the identity source.

Contractor accounts without end dates

Contractors, vendors and temporary staff often sit outside the HR system, so no termination event ever fires for them. Give every non-employee account an expiration date tied to the contract or engagement, and assign a named sponsor who must confirm continued need. Review these accounts on the same schedule as employee transfers so they do not drift.

Transfers that add access only

When people change roles, new groups are usually granted while old ones remain. The requirement asks for a review of ongoing need for logical and physical access, followed by changes to match. Build a transfer checklist that lists the prior role's entitlements, requires the new manager to approve what stays, and removes the rest. Periodic certification of role assignments catches what the checklist misses.

Credentials and property not tracked

Authenticators, hardware tokens, VPN certificates, shared-account passwords the departing person knew, and laptops, badges and keys are often not logged against the individual. Keep an inventory that links each person to their issued authenticators and security property, collect them on the last day, and record the return. Rotate shared credentials the person could have known.

No record of timing

Assessors test 03.09.02 by examining termination records and transfer actions, then interviewing the staff who run them. If the HR event date, the ticket and the actual disable time are not logged together, the organization cannot show the requirement was met, even when it was. Store these timestamps in a system that the organization controls, and sample them before an assessment.

What buyers ask about termination and transfer controls

How much effort does meeting 03.09.02 take, and what drives it?

The effort depends mostly on how many systems hold CUI, how many of them already read from a central identity source, and how well HR and IT agree on when an employment change takes effect. A small environment with one directory and clear offboarding steps needs far less work than a estate where accounts are created by hand in dozens of applications. The requirement itself is short, but meeting it means defining the disable window, documenting termination and transfer procedures, collecting authenticator and property return records, and running periodic access reviews. No public cost figure for this control was supplied, so ask any provider to price each of these items separately in a written scope.

Can our own team meet 03.09.02 without an implementation partner?

Yes, an organization can meet this requirement with its own staff, as the control owner is always the organization. The work splits into policy and procedure (HR, security and managers), system configuration (identity and account administrators), and evidence collection (whoever answers the assessor). Teams without an identity provider or directory often find the hardest part is automating deprovisioning across applications, not writing the procedure. A partner can help prepare systems and evidence under a fixed written scope, but only an independent assessor can issue an assessment result. Ask the partner to state exactly which artifacts they will produce and which remain your responsibility.

How long does this work usually take to complete?

The timeline depends on the written scope and the environment, including the number of identity sources, applications holding CUI and the state of existing offboarding records. No duration was supplied for this control, so do not accept a timeline that is not tied to a written scope. Ask for milestones covering procedure approval, identity configuration, a test termination and a test transfer, and evidence capture. Expect the work to run in parallel with other requirements in the same system security plan, which can shift dates in both directions.

What do HR and managers need to provide for termination and transfer controls?

HR must send timely, reliable notice of every departure and role change, and managers must confirm the access their staff still need after a transfer. Without these signals, the disable window in the procedure cannot be met, and the assessor will find the gap in the records. Practical inputs include a standard termination form, a transfer request that lists old and new roles, and a named owner for returning badges, laptops and tokens. Interviews are part of the assessment method for this requirement, so the people in these roles must know their steps and be able to describe them.

Must the agency or the organization set the time period for disabling access?

The time period is an organization-defined parameter, so the organization must define it unless the federal agency specifies a value in the contract or agreement. NIST notes that if an agency does not specify ODP values, the nonfederal organization must assign them to complete the requirement. Check the contract for any stated value before setting your own, because a contract value overrides the internal choice. Whatever value you set, the assessor will check that it is defined and that your records show it is applied.

Does Rev. 2 or Rev. 3 of SP 800-171 apply to 03.09.02?

The answer depends on the contract. Rev. 3 numbers this requirement 03.09.02, while Rev. 2 numbers its equivalent 3.9.2, and NIST classifies the change as significant. A recent DoW class deviation names Rev. 2 for contracting officers, and CMMC Level 2 is built on Rev. 2 with 3.9.2 scored at 5 points. A proposed FAR rule would move contractors to Rev. 3, but it was not final as of October 2026. Confirm with the contracting officer which revision your contract cites before building evidence.

What will the assessor ask for first on this requirement?

Assessors typically begin with the written personnel security policy and the termination and transfer procedures, then request records of recent departures and transfers. They will compare the list of system and facility access authorizations against the people who left or moved, and they will interview the staff who run those steps. The SP 800-171A procedure lists examine, interview and test methods, so expect a walkthrough of a live termination or transfer. Prepare a sample of real records with dates, the authenticator revocation evidence and the property return sign-off.

How DeployOpen scopes and prepares termination and transfer evidence

DeployOpen works on 03.09.02 by preparing the identity and access systems that disable accounts, revoke credentials and adjust access on transfer, and by producing the records an assessor will examine. The organization keeps ownership of its personnel policy and its termination and transfer decisions, while DeployOpen prepares the systems and evidence behind them.

How we scope

Written scope names the systems, applications and directories where 03.09.02 access must be disabled or adjusted.
The scope records which parties own HR triggers, account administration and sign-off on the organization-defined disable time.
Scope lists the evidence sources an assessor would examine, such as termination records, transfer actions and access authorization lists.

How we build

Identity sources and provisioning connectors are configured so a departure or role change propagates to target applications.
Authenticator and credential revocation paths are documented and tested for each in-scope system before handover.
Periodic access review campaigns are set up with named reviewers to confirm continued need after transfers.

How we hand over

Deliverables include configuration records, runbooks for termination and transfer, and the defined disable time as a documented parameter.
Test results show deprovisioning and access changes working end to end, with the records a reviewer would need to check.
Handover includes a walkthrough with the people who interview for 03.09.02, so they can explain the process consistently.

How we support

Ongoing support and upgrades of the identity platform are available as a retainer, so the process stays current.
Continuous testing of deprovisioning paths can be added when the organization wants regular proof they still work.
Ask your assessor early which evidence they will accept, and confirm the final evidence package with them, since only an independent assessor issues findings.