What PS.L2-3.9.2 personnel actions requires for CUI systems
If your company wants Conditional or Final Level 2 status, PS.L2-3.9.2 must score MET. It is a 5-point requirement under the CMMC scoring methodology, and because it is worth more than one point, it cannot be carried on a plan of action and milestones. A gap here is not a line item you can schedule for later. It has to be closed before the assessment. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.9.2, and the test basis is the assessment objectives in NIST SP 800-171A (June 2018), not the standard's narrative text. In plain terms, the requirement asks you to make sure systems holding CUI stay protected while people leave or change roles. The practical risks are familiar: a former employee's account still works in a cloud tenant, a contractor's laptop is never collected, or a transferred engineer keeps access to a CUI repository from a previous project. Orphaned accounts and unreturned equipment are the usual findings. The work is hard because the facts live in different places. HR knows the termination date, IT holds the directory and application accounts, and facilities holds badges and keys, and these records rarely line up without a deliberate process tying them together.
Assessors look for three things, mapped to the 2018 assessment objectives: a documented policy or process for ending access and credentials at personnel actions, evidence that access and credentials are actually terminated on departure or transfer, and evidence that the system is protected during and after a transfer. Useful evidence includes records of transfer and termination actions, the current list of system accounts, records of revoked authenticators, and signed exit interview records. Confirm with your assessor which of these they will sample and over what period, and test your own records before they do. Self-hosted identity platforms such as authentik and FreeIPA can drive account deprovisioning and produce much of that evidence, but the process, the HR trigger and the equipment recovery step remain your responsibility to define and prove.
Which systems, people and third parties fall under personnel actions
PS.L2-3.9.2 reaches every system that holds CUI and every person who can touch it, including people who move within the organization. The scoping choices below decide how many accounts, directories and outside administrators your termination and transfer process must cover.
Systems that store, process or transmit CUI
Scope starts with the boundary of systems that store, process or transmit CUI, including file shares, email, collaboration tools, engineering applications and endpoints. Each one holds local or federated accounts that must be disabled when someone leaves or changes role. Build an inventory that lists the system, its account source and its owner, and confirm that nothing in the CUI boundary is missing from it. Systems outside the boundary can still matter if they share credentials with systems inside it.
Directory services that govern access
In most environments, access to CUI systems is controlled by a directory, not by each application. Identity stores such as FreeIPA, which uses 389 Directory Server to hold users, groups and hosts, are where a termination takes effect first. Confirm which directory is the authoritative source, which applications rely on it, and whether any application keeps a local user table that the directory never touches.
Identity providers and single sign-on
A single sign-on layer can cut off many applications at once, but only if every application actually trusts it. Review whether users authenticate through a provider such as Keycloak or authentik, and whether applications also hold their own passwords or API tokens. Check that disabling a user at the provider also invalidates active sessions and tokens, and test that this happens in practice rather than assuming it.
Employees and contractors with access
The requirement covers every person with access to CUI, not only full-time staff. Contractors, temporary workers, interns and vendor staff with accounts must be on the same list and go through the same revocation steps. Ask HR and procurement to feed contract end dates into the access process, because contractors often leave without a standard termination event. Confirm that the list of accounts can be matched to a person.
Internal transfers and role changes
PS.L2-3.9.2 applies to people who move within the organization, not only to people who leave. A transfer from a CUI project to an unrelated team can leave the old access in place for years and accumulate privileges. Define what triggers a review on a role change, who approves removing old access, and how the old access is recorded. Access certification campaigns, such as those offered by midPoint, can help reviewers decide whether to keep, change or revoke each item.
Third-party administrators and managed service providers
Outside administrators and managed service providers can act on CUI systems with privileged access, and their staff may not appear in your HR records at all. Inventory every external account, vendor remote access path and shared administrator login, and include them in termination steps. Put notification duties in the service contract so you learn when their staff change. Your organization still owns the outcome, so verify removal rather than relying on the provider's word.
How to implement termination and transfer controls step by step
This sequence turns PS.L2-3.9.2 into a set of written procedures, account records and signed checklists that an assessor can test against the three NIST SP 800-171A objectives. Each step produces a document or record, so the organization can show that access ends on time for every CUI system.
Write the termination and transfer procedure
The organization owns this step. Leadership or the security office writes a policy and a process that define who starts a termination or transfer, which HR and IT actions follow, who approves each action, and how completion is recorded. The procedure should name every role involved, including HR, the system owners and the facilities team. It is done when the document is approved, dated and version-controlled, and staff who run the process have acknowledged it. The assessor will look for this document first, because the first assessment objective asks whether a policy or process for ending access and credentials exists.
Inventory every CUI system and account source
Build a list of every system that stores, processes or transmits CUI, then record where each system gets its accounts. Typical sources include a directory such as FreeIPA, a single sign-on provider such as Keycloak, local accounts on servers, cloud tenant accounts, and service or shared accounts. Note the owner of each account store and whether it is connected to the others. The output is a system account list for each CUI system, which the assessment guide treats as core evidence for 3.9.2. Confirm the list with each system owner, because accounts that are missing from the inventory are the most common gap at this step.
Connect HR events to deprovisioning
Define how a termination or transfer recorded in the HR system reaches each account store. Some organizations do this with an identity provider that pushes changes to target applications, for example through SCIM provisioning in authentik. Others use a documented manual ticket that IT closes against the account list. Either way, document the trigger, the expected sequence of disabling accounts, the target time for each action, and the person who confirms completion. Test the path with a non-production account before relying on it. The output is a data flow diagram with a test record showing that a disabled HR status removed access in each connected system.
Revoke access, credentials and authenticators
For each departing or transferring individual, disable the directory account, remove group and role memberships, revoke tokens and sessions, and invalidate passwords, keys, tokens and any multifactor devices registered to the account. Shared or service credentials the person knew must be rotated. Keep a record of each revoked authenticator. SP 800-171A lists records of terminated or revoked authenticators and credentials as potential evidence, so the output is a dated deprovisioning log per person, linked to the ticket that started the action.
Define equipment, badge and key return steps
Create a signed return checklist that lists company equipment such as laptops, phones, removable media and tokens, plus identification, access cards, keys and badges for CUI areas. The checklist should name who collects each item, when it is collected relative to the last working day, and how missing items are reported and tracked. Facilities staff and the system owner should both sign. The output is a completed return checklist for each separation, filed with the personnel record. Physical access changes should match the badge and key records maintained under the physical protection requirements.
Set the exit interview content
Write a standard exit interview script that reminds departing staff of their continuing obligations to protect CUI after they leave, including non-disclosure terms, return of CUI copies, and the reporting route for suspected exposure. HR runs the interview and records the date, the attendee and the acknowledgement signed by the departing person. The output is a signed exit interview record. Ask counsel to review the wording, since the obligations depend on the employment and contract terms.
Set transfer rules that remove prior access
A transfer is a termination of the old role, so define the rule that removes prior access before or as new access is granted. Use role-based groups where possible so that a move clears the old group memberships rather than adding new ones on top. Schedule periodic reviews where a reviewer confirms that each person still needs their access. Tools such as midPoint can run access certification campaigns in which designated reviewers keep, change or revoke each item within a set timeframe, which helps catch access that accumulated through transfers. The output is a transfer checklist and a review record showing that old access was removed.
Verify the sequence and keep the evidence final
Run a walkthrough with a sample of recent terminations and transfers and check that every step produced its record. Confirm that each record is final rather than a draft, because an assessor will not accept draft evidence. Ask a reviewer outside the team to test one case end to end. Correct gaps, update the procedure version, and file the evidence against the requirement ID PS.L2-3.9.2. Whether an outside assessor or auditor will check this record is a question to confirm with the assessment body before the review.
How automated deprovisioning removes access across applications
Automated deprovisioning works when one authoritative identity record drives every downstream account, so a single HR-driven change removes access everywhere at once. In a typical design, the central identity source holds the user record and group memberships, single sign-on sends users to one login point instead of each application, and a provisioning connector pushes create, change and delete events to the applications that cannot rely on single sign-on alone. In the authentik SCIM provider, for example, user and group deletions are pushed to target applications over SCIM 2.0, and a full sync runs every hour, so a removed user is deprovisioned from the target on the next sync rather than when someone remembers to act. Confirm the sync interval, the event types and the failure alerting for each connector in your own environment before you rely on them for PS.L2-3.9.2.
The assessor will not accept that the design should work. They will ask whether removal is timely and complete, which means they will pick a sample of terminated or transferred users and trace each account to the time it was disabled. Assessment objectives for 3.9.2 look for records of transfer and termination actions, the list of system accounts, and records of revoked authenticators, so your evidence should show the account inventory before and after the action. Expect questions about how long a disabled account could still authenticate, whether sessions and tokens are invalidated, and whether connectors that failed were caught. Test these yourself with a disposable account before the assessment, and record the results.
The common gaps sit outside the central directory. Shared accounts, such as a team login to a build server or a shared administrative account, have no individual owner to disable, so a departure leaves the credential in place. Local accounts on servers, network devices and appliances are often created by administrators and never linked to the identity source. Standalone application logins survive because the application predates single sign-on or its vendor does not support the connector you planned. Build an inventory of every system that holds CUI, mark which accounts authenticate through the central source, and list the exceptions with an owner and a compensating step, such as a documented manual revocation with a ticket. Confirm with each vendor whether their product supports the protocol you intend to use before you count it as covered.
How an assessor tests PS.L2-3.9.2
This table compares the three assessment objectives NIST SP 800-171A sets for PS.L2-3.9.2, what the assessor does for each, the evidence requested and the findings that most often fail. Read it as a checklist of what to prepare before a Level 2 assessment, because a requirement is MET only when every applicable objective is satisfied with final evidence, not drafts.
| Assessment objective | What the assessor does | Evidence requested | Common findings |
|---|---|---|---|
| Policy or process for ending access and credentials | Reads the written procedure and checks that it covers terminations and transfers, owners, timing and the systems in scope | Approved final offboarding and transfer procedure, with revision history and the named owner | Procedure is a draft, omits transfers, or does not name the systems holding CUI |
| Termination and revocation of access and credentials | Selects a sample of recent leavers and checks when each account, group membership, token and authenticator was disabled or removed | Account list for the sampled people, termination tickets, directory and identity provider change logs, records of revoked authenticators | Accounts still enabled after departure, shared or service accounts not reviewed, credentials outside the identity provider left active |
| Protection during and after transfers | Selects a sample of recent movers and confirms access was reduced to the new role and old entitlements were removed | Transfer records, before and after role assignments, access review or certification results for movers | Former access kept after a role change, no review step for transfers, transfer records missing |
| Disabled accounts cannot authenticate | Attempts sign-in with a sampled disabled account through the systems that hold CUI, including remote and single sign-on paths | Test results with date, tester, account tested and the observed denial, plus screenshots or log entries | Only the directory was checked, not each application, or cached sessions and API tokens still work |
| Exit interview and equipment return | Reviews the exit record for each sampled leaver, including reminder of CUI obligations, return of equipment, badges and keys | Signed exit checklists, equipment return records, badge deactivation records, interview notes | Checklists blank or unsigned, no link between the exit record and the account change |
Evidence that satisfies termination and transfer requirements
Assessors test PS.L2-3.9.2 by asking for records of what happened when people left or changed roles, and by checking that the systems actually removed access. The cards below cover the artifacts named in the assessment guidance and how to keep them current between assessments, since a requirement is MET only when the evidence is in final form.
Records of transfer and termination actions
These are dated records showing that each departure or role change triggered an access action. Assessors look for a link between an HR event and a specific change in system access. Keep the originating ticket or HR notice, the named individual, the date, and the accounts affected. Check that records exist for transfers as well as terminations, because the requirement covers both. A missing ticket for a transfer is a common gap.
Current list of system accounts
Assessors compare this list against the people who should still have access. Export the account list from each system that holds CUI, including directory, application, cloud and administrative accounts, and record the export date. Reconcile it with the HR roster and flag any account whose owner has left or changed roles. Repeat the reconciliation on a schedule you define in your system security plan, so the list reflects the current state.
Records of revoked authenticators and credentials
These records show that passwords, tokens, certificates, API keys and access cards tied to a departed or transferred person were revoked, with dates. Store the revocation log entries alongside the account change tickets so one departure can be traced end to end. Include shared secrets and service credentials the person could reach. Missing revocation timestamps weaken the case even when the account is disabled.
Exit interview records
Exit interviews show that departing staff were reminded of their continuing obligations to protect CUI. The CMMC Assessment Guide lists this reminder alongside returned equipment, identification, access cards and keys. Keep a signed or system-recorded acknowledgment with the date, the checklist used, and the name of the person who conducted it. A blank template does not show that the interview happened.
Test results from access disabling mechanisms
SP 800-171A expects evidence that the mechanisms disabling access and revoking authenticators actually work. Run a scheduled test on a test account: disable it through the identity provider, confirm it fails to sign in to each CUI application, and confirm its tokens stop working. Record the test date, the steps, the result and any defects with a remediation ticket. Repeat the test after changes to the identity stack.
Keeping evidence current between audits
Evidence ages quickly. Store each export with a timestamp and a ticket reference, and keep a dated index that maps each departure to its artifacts. Schedule periodic reviews of the account list and record who reviewed it and what changed. Confirm your retention period with your assessor and your contract terms, because the requirement is judged on evidence that is final and traceable, not on drafts or screenshots without dates.
What meeting PS.L2-3.9.2 costs in money and effort
This table lists each cost component of protecting CUI systems during terminations and transfers, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where self-hosted open-source tools change the spend, since no dollar or hour figures are supplied for this requirement.
| Cost component | One-time or recurring | What drives it and how to reduce it |
|---|---|---|
| Internal HR and IT time for the offboarding and transfer process | Recurring | Driven by headcount turnover and how many manual steps the process has. Reduce it by defining one written workflow that HR triggers and IT executes, with a checklist for each action. |
| Identity tooling licenses | Recurring | Commercial identity platforms usually charge per user or per application. Self-hosted open-source identity tools can remove license spend, but the organization still pays for hosting and administration. |
| Integration engineering | One-time, with periodic rework | Driven by the number of target applications and directories that must deprovision accounts. Reduce it by prioritizing systems that hold CUI and automating deprovisioning where a connector exists. |
| Equipment, badge and key recovery administration | Recurring | Driven by the volume of departures and the number of physical items issued. Reduce it by linking asset and badge records to the HR departure record so recovery is tracked in one place. |
| Evidence upkeep | Recurring | Driven by how often records of account removals, revoked credentials and exit interviews must be retrieved. Reduce it by keeping evidence generated automatically in the identity system and retaining it on a fixed schedule. |
| External review or testing | Recurring or per engagement | Driven by whether an independent party tests the access revocation path and how deep that test goes. Confirm scope and deliverables in writing before work starts, since DeployOpen works under fixed-scope agreements. |
| Assessor fees | Per assessment | Set by the assessing body and the scope it reviews. Ask the assessor to state in writing which systems, personnel actions and evidence sets the fee covers. |
Who owns termination controls and who can help
Your organization owns this requirement. Policy, the decision to revoke access, and the proof that a departing person no longer has CUI access all sit with your leadership, HR, IT and security staff. An outside partner can help build the mechanisms, but it cannot accept the risk or sign off on your exit steps.
- Policy ownership: A named executive or security owner approves the personnel action policy, defines which events trigger access review, and sets the deadlines for revoking access on termination and on transfer.
- HR triggers: HR systems must notify IT and security when someone resigns, is terminated or changes role. Ask who receives those notices, how fast they arrive, and what happens when a notice is missed.
- Exit sign-off: A accountable person confirms each exit step is complete, including return of equipment, badges and keys, and the exit interview that reminds the person of CUI obligations.
- Transfer reviews: Managers or system owners confirm that access no longer needed in the old role is removed when someone moves to a new role.
- Retained records: Your organization keeps the tickets, logs and signed checklists that show each action happened, because those are the records the assessor will request.
Check that the policy names owners by role and that someone outside IT can confirm HR triggers actually fire.
An implementation partner such as DeployOpen can help configure the systems that carry out revocation and prepare the evidence. The partner works inside your environment under a written scope. It does not decide whether your controls pass, and it does not issue a report or certificate.
- Deprovisioning configuration: The partner can set up automated removal of accounts from target applications, for example through a SCIM provider or central directory, so access ends when the source record changes.
- Account inventories: The partner can produce a current list of system accounts and groups, which assessors expect as evidence, and reconcile it against the HR roster.
- Evidence packages: The partner can organize logs of disabled accounts, revoked authenticators and exit checklists into a package your team reviews before it goes to an assessor.
- Revocation testing: The partner can test that disabling a user actually cuts access to each system, and document the results, so your team learns about gaps before an assessment.
- Gap remediation: Where a required step is missing, the partner can fix the configuration or document a workflow, within the agreed scope.
Confirm in writing which systems are in scope, who holds administrative credentials during the work, and who keeps the final evidence.
Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. The assessor independently tests whether each objective of the requirement is satisfied and makes the certification decision. A partner cannot perform this role for the same environment.
- Independent testing: The assessor examines policy, samples personnel actions, and tests whether access is actually removed in the systems, rather than relying on descriptions.
- Objective-level findings: The assessor checks the assessment objectives in NIST SP 800-171A for this requirement and records whether each one is met with evidence in final form.
- Certification decision: Only the assessor's findings and report determine whether the requirement counts as MET for certification.
- Independence rules: The organization and any consultant that prepared the environment must keep their roles separate from the assessor's, so ask how conflicts are handled before you engage a firm.
- Assessment timing: The current status of CMMC phases affects when and whether certification assessments are required, so check the latest DoW guidance before scheduling.
Before assessment, confirm which assessor organization you will use and that it has no conflict with your implementation partner.
Where termination and transfer controls usually fail
Most failures under PS.L2-3.9.2 are not missing policies. They are gaps between the HR process, the identity systems and the physical equipment that holds CUI access. The cards below cover the points where a departing or transferring person keeps access they should no longer have, and how to close each one with evidence an assessor can test.
HR events not wired to access removal
Terminations and transfers are often recorded in an HR system, but nothing triggers the removal of access to systems holding CUI. The gap is usually a manual ticket that depends on a manager remembering to file it. Check whether a departure in HR produces a timed, traceable action in the directory or identity provider. Connect the two with an automated provisioning feed where possible, and keep the ticket history as evidence of the action taken.
Local and shared accounts missed
The account list used for the assessment often comes from the central directory, while local accounts on servers, network devices, appliances and shared service accounts sit outside it. A person who leaves can keep working through an account nobody thought to disable. Build the list from each system's own user table, not only from the directory, and record which accounts are shared and who holds their credentials.
Transfers that keep old access
When someone moves to a new role, the new permissions are often added while the old ones stay in place. This accumulation is the transfer case that 3.9.2 addresses, because the system must be protected during and after the move. Require a documented review of the person's prior access at each transfer, and remove what the new role does not need. Periodic access reviews with a named reviewer make the removal decision and its record explicit.
Equipment and badges not tracked
Laptops, tokens, access cards and keys are frequently returned to a desk or a facilities office and never reconciled against the asset record. The CMMC Assessment Guide lists returning company equipment, identification, access cards and keys as actions that may follow a termination. Keep a checklist per departure that names each item, its serial or badge number, and the date it came back, and reconcile it against the asset inventory.
Exit interviews skipped or undocumented
Many offboarding processes do not include a reminder of continuing CUI obligations, or the reminder happens but no record survives. SP 800-171A treats records of exit interviews as potential evidence for 3.9.2. Use a standard exit checklist that covers the departing person's continuing duties regarding CUI, have the person and the manager sign or acknowledge it, and store the signed record with the termination ticket.
Evidence kept only as drafts
Offboarding records are sometimes written in a working document, edited after the fact, or left unfinished. Under the CMMC scoring rules, a requirement is met only when the evidence is in final form, not draft. Set a rule that each termination or transfer closes with a final, dated record, and that the record is retained in a location the assessor can access. Sample a few recent cases to confirm the records are complete before the assessment.
Questions buyers ask about PS.L2-3.9.2
How much effort does PS.L2-3.9.2 take to meet?
The effort is mostly process work rather than new technology, but it has to produce records that can be shown to an assessor. The requirement has three assessment objectives in NIST SP 800-171A: a documented policy or process for ending access and credentials at personnel actions, termination or transfer actions that actually remove access and credentials, and protection of the system during and after transfers. Effort rises with the number of systems that hold CUI, the number of places accounts exist (directories, SaaS applications, VPNs, build servers, shared mailboxes), and how many manual steps the offboarding process contains. Ask a partner to inventory these accounts first, because that inventory usually sets the size of the job. Because this requirement is worth 5 points under the CMMC Scoring Methodology, it must be fully MET.
Can we meet PS.L2-3.9.2 in-house?
Yes, an organization can meet this requirement with its own staff, since the organization owns its controls. The work is usually feasible in-house when HR, IT and security have clear ownership of each step and the offboarding and transfer process is written down and followed. Teams often struggle with gaps between departments, such as HR filing a termination after IT has already been told, or contractors whose accounts sit outside the normal directory. An outside partner can help by preparing systems and evidence, for example by centralizing identity so that one disable action reaches connected applications, or by setting up review of standing access. A partner cannot assess or certify the result. Only an independent assessor can do that, so the internal team must be able to explain and evidence its own process.
How long does preparation for PS.L2-3.9.2 usually take?
No preparation duration has been established for this requirement, so treat any number you hear from a vendor with caution and ask for it in writing. The main drivers are the size of the account inventory, how many systems hold CUI, whether identity is already centralized, and how many HR and IT workflows must change. Preparation is also shaped by the current CMMC timeline, which the Department of War suspended Phase II of on 13 July 2026, with a 60-day review by a CMMC Reform Task Force underway. Confirm with the contracting officer or prime contractor which obligations apply to your contracts now. For a fixed-scope engagement, ask the partner to state the schedule, the milestones and the client dependencies in the written scope before work starts.
What does PS.L2-3.9.2 need from HR and IT?
The requirement depends on HR and IT working from one trigger and one record. HR must notify IT and the security team of every termination and transfer in time for access to change, and must record the date, the reason and the exit interview. IT must disable directory accounts, revoke authenticators and certificates, remove group and role memberships, and collect or wipe equipment and access cards. Assessors look for records of transfer and termination actions, the list of system accounts, records of revoked authenticators and credentials, and records of exit interviews, which SP 800-171A names as potential evidence. The exit interview should remind departing staff of their CUI obligations. Facilities or security may also need to handle badges and keys, which the CMMC Assessment Guide Level 2 lists as possible follow-up actions.
Can a consultant or implementation partner issue our CMMC certification for PS.L2-3.9.2?
No. A partner can prepare systems, procedures and evidence, but it cannot issue a certification or a report. For Level 2 certification assessments, the assessment is performed by a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. The organization owns its controls, and the assessor must be independent of the party that helped prepare the environment. Ask any partner to describe its role in writing, and keep the implementation work separate from the assessment. Note that Level 2 certification requirements were part of the Phase II schedule that the Department of War suspended on 13 July 2026, so confirm the current requirement with your contracting officer.
Is a POA&M allowed for PS.L2-3.9.2?
No. Under the CMMC Scoring Methodology, PS.L2-3.9.2 is a 5-point requirement, and 32 CFR 170.21(a)(2) does not permit requirements worth more than 1 point to appear on a plan of action and milestones. It must therefore be MET for the organization to reach Conditional or Final Level 2 status. Plan the offboarding and transfer process to be in place and evidenced before any assessment, rather than relying on a POA&M to close gaps later. Any PS.L2-3.9.2 gap found during internal review should be fixed and documented before the assessment date.
What are the biggest risks if PS.L2-3.9.2 fails in practice?
The main risk is that a former employee, contractor or transferred user keeps access to CUI systems after their role has ended. Common causes include directory accounts that are disabled while SaaS applications, VPN accounts, source repositories or shared credentials remain active, and transfers where old group memberships accumulate. Periodic access reviews help catch this. Open-source identity tools can help, for example by using an identity provider that deprovisions users from connected applications through SCIM 2.0, or by using access certification campaigns in which designated reviewers keep, change or revoke access within a set timeframe. Confirm with each product's documentation that it covers your specific applications before relying on it.
Scoping decisions that change the size of the work
The size of the PS.L2-3.9.2 effort is set less by the requirement itself than by how many places a person's access to CUI systems can live. Each identity source, application, third-party administrator and HR system that can grant or retain access is another place where a termination or transfer must be reflected, and another place an assessor may ask to see proof. An organization with one directory feeding a short list of CUI applications has a small problem. An organization where accounts are created by hand in a dozen SaaS tools, an outsourced help desk holds administrative rights and the HR system triggers no automatic change has a large one, even if its policy text looks identical. Before estimating anything, list every source of identity and every system that stores CUI or administers it, and note who can change each one.
A clear CUI system boundary is the most direct way to shrink the account list an assessor samples. Under the assessment objectives in NIST SP 800-171A, the assessor checks that access and credentials are ended on termination or transfer and that the system is protected during and after a transfer. If the boundary is drawn around the systems that actually process, store or transmit CUI, the population of accounts that must be traced back to a termination or transfer record is limited to those systems. Confirm with your system security plan which directories, federated applications and administrator consoles fall inside that boundary, and whether any identity provider outside it can still authenticate users into it. Accounts that sit outside the boundary but can reach it are usually still in scope.
Two decisions are worth making early because they change the work for years. The first is whether a single identity provider will be the authoritative source for CUI application access, with applications receiving accounts through provisioning rather than local creation. Open-source options such as authentik, which deprovisions users from a target application through its SCIM provider when they lose access, or Keycloak for single sign-on, can reduce the number of places where removal must be verified, though the design must be confirmed against your own applications. The second is who holds administrative rights in each system, including any managed service provider. Ask for a written list of those accounts, the process each provider follows when its staff change roles, and the records it can produce on request, because those records become part of your evidence.
How DeployOpen scopes and evidences termination controls
DeployOpen plans and implements the self-hosted identity, access and logging systems that carry out termination and transfer actions for PS.L2-3.9.2 Personnel actions, inside your own infrastructure. We prepare the systems, procedures and records an assessor will review, while your organization owns the control and an independent assessor makes any determination.
How we scope
- Scope starts with a list of every system holding CUI and every account store that grants access to it.
- We agree in writing which offboarding and transfer steps are automated, which are manual, and who owns each.
- Scope also names the exit interview process, equipment and badge recovery owners, and the records each step produces.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We configure identity sources, single sign-on and provisioning so that removing a user's directory access removes application access.
- Deprovisioning tests cover disabling accounts, revoking authenticators and confirming access is gone from each connected application.
- Transfer workflows remove old role assignments so previous access does not accumulate after a move between teams.
- We document configuration and runbooks so your staff can run and explain each termination and transfer step.
How we hand over
- Handover includes the account inventory, configuration records, test results and step-by-step procedures for each personnel action.
- Evidence packages are organized by the three assessment objectives in NIST SP 800-171A, so an assessor can trace each one.
- We confirm with you which records are final and retained, since drafts and unsigned forms do not count as final evidence.
- Your team receives training on running the procedures and producing the records without our involvement.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover periodic re-testing of deprovisioning after platform upgrades or directory changes.
- Access review reports can be refreshed on a schedule you set, so revocation gaps are found before an assessment.
- DeployOpen prepares evidence but does not issue assessment reports or certifications, which only independent assessors provide.
Sources and further reading
- NIST SP 800-171 Rev. 2, Protecting CUI in Nonfederal Systems and Organizations ↗
- NIST SP 800-171A, Assessing Security Requirements for CUI ↗
- 32 CFR Part 170, CMMC Program ↗
- CMMC Assessment Guide, Level 2, Version 2.13 ↗
- authentik documentation: SCIM provider ↗
- midPoint documentation: Access certification ↗
