PS-4: Personnel Termination

The ps-4: personnel termination requirement expects you to run a repeatable offboarding process that promptly removes a terminated individual’s access, recovers organization assets, and documents completion. To operationalize it, assign an owner, define an offboarding checklist tied to identity and asset systems, and retain evidence that each termination event triggered access revocation and asset return. ¹

Key takeaways:

• Tie HR termination events to same-day identity/access actions, even for “friendly” departures.
• Evidence matters as much as execution: keep tickets, logs, approvals, and asset return records per termination.
• Make exceptions explicit (e.g., involuntary terminations, remote staff, third-party admins) and pre-approve the playbooks.

PS-4 sits in the NIST SP 800-53 Personnel Security family and is assessed as an operational control: auditors and authorizing officials want to see that termination is not a loosely coordinated HR task, but a security-relevant workflow with traceable outcomes. The control’s intent is simple: once employment ends, the individual should no longer be able to access systems, data, facilities, or third-party accounts connected to your environment. ²

In practice, PS-4 fails in predictable ways: HR notifies IT late; privileged access persists in “shadow” tools; physical badges are not recovered for remote employees; and the team cannot prove what happened after the fact. That last point is the most common exam hangup: the organization may be confident it offboards correctly, but cannot produce consistent evidence across multiple termination samples. ¹

This page gives requirement-level implementation guidance you can put into production quickly: who owns PS-4, what scope to include (employees, contractors, and third-party administrators), how to build a termination workflow that’s auditable, and what artifacts to retain so you can pass an assessment without scrambling.

Regulatory text

Control excerpt (provided): “Upon termination of individual employment:” ¹

What the operator must do

PS-4 is a trigger-based requirement: when employment terminates, you must execute defined termination actions. The excerpt is brief in the provided text, so operationalization should follow the standard NIST 800-53 expectation for “personnel termination” controls: disable accounts, revoke access (logical and physical), recover assets, and document completion so an assessor can verify consistent execution. ²

Plain-English interpretation

When someone leaves, treat it as an access revocation event. Your program must ensure the person cannot log in, cannot access data, cannot reach facilities (if applicable), and cannot act through third parties or shared credentials. You also need a record that shows: (1) the organization knew the termination happened, (2) the right teams acted, and (3) the actions finished.

Who it applies to

Entity scope

PS-4 commonly applies to:

• Federal information systems and the organizations operating them. ¹
• Contractor systems handling federal data, including service providers operating systems that store, process, or transmit federal information. ¹

Operational scope (what “personnel” should include)

Define “personnel” for your environment so scope is testable:

• Employees (full-time, part-time, interns)
• Contractors and consultants with accounts or badges
• Temporary staff and agency workers
• Third-party administrators (e.g., managed service providers) with privileged access in your tenant
• Developers with production access, even if “borrowed” for an incident

If you exclude a group, document the rationale and where their offboarding is controlled elsewhere.

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

Below is a practical, assessor-friendly workflow. Build it as a single “Personnel Termination Runbook” with system-specific sub-steps.

Step 1: Assign ownership and define the trigger

• Control owner: usually HR + IAM (identity and access management) with Security accountable for oversight.
• Trigger: an HR status change (termination date/time) or contract end date for non-employees.
• Intake channel: HRIS workflow, service desk ticket type, or GRC case that creates a unique termination record.

Operator tip: Assessors sample terminations. If your trigger is “manager emails IT,” you will lose traceability.

Step 2: Classify the termination scenario

Create a quick classification that changes the playbook:

• Voluntary with notice
• Involuntary (immediate)
• End of contract / role change
• Remote worker
• Privileged user (admin, cloud console, code repo owner)

This reduces “it depends” decisions during high-risk exits.

Step 3: Execute logical access revocation

Your checklist should include, at minimum:

• Disable primary identity (IdP directory account)
• Revoke MFA tokens and recovery methods
• Remove group memberships and role assignments
• Disable email and collaboration access (or convert mailbox per policy)
• Terminate active sessions where supported
• Rotate or invalidate credentials the user knew:
  • Shared secrets (service accounts, break-glass passwords, team vault items)
  • API keys, SSH keys, personal access tokens
• Remove access in high-risk tools that may not be federated:
  • Code repositories, CI/CD, ticketing, monitoring, customer support platforms

How auditors test this: they pick a few termination cases and ask you to prove the user was disabled and access paths were removed across systems. The gaps are usually in non-SSO tools and privileged platforms.

Step 4: Execute physical and environmental access removal (if applicable)

• Deactivate badge access and key cards
• Retrieve physical keys, building passes, parking passes
• Collect or remote-wipe endpoints where permitted (laptops, phones, removable media)
• Confirm workspace access removed (labs, cages, secure rooms)

For remote workers, define a shipment/return process and track it like an asset transfer.

Step 5: Recover organization assets and data

• Confirm return of devices, chargers, security tokens, badges
• Reassign owned resources:
  • Shared mailboxes, distribution lists, calendar access
  • Cloud resources where the user is the only owner (projects, subscriptions, DNS)
  • Code signing keys or certificate ownership
• Ensure business continuity:
  • Transfer repository ownership
  • Reassign ticket queues
  • Preserve records needed for legal hold (coordinate with Legal)

Step 6: Document completion with a single termination “packet”

For each termination event, produce one record that shows:

• Trigger source (HRIS event or ticket creation)
• Approvals (HR, manager, security for exceptions)
• Tasks completed with timestamps and assignees
• Access revocation evidence (IdP status change, role removal)
• Asset return evidence (inventory update, shipping tracking, receipt)
• Exceptions and compensating controls (if any)

This “packet” is what makes PS-4 easy to audit.

Step 7: Perform post-termination validation

Add a verification step that is independent from the person who executed the offboarding:

• Confirm the identity is disabled in IdP
• Confirm privileged roles removed
• Confirm no active accounts remain in critical non-SSO systems
• Confirm device status (returned, wiped, or otherwise addressed)

Step 8: Manage third-party access pathways

PS-4 often fails through third parties:

• If the individual had access to third-party systems on your behalf (e.g., payroll, benefits admin, outsourced IT tools), ensure those accounts are also removed.
• If a third party is offboarding their own staff who access your systems, require them to notify you and revoke access promptly. Treat this as a third-party control requirement in your contracts and access governance.

Step 9: Map PS-4 to control owner, procedure, and recurring evidence

Make PS-4 assessable by design:

• Document the owner, runbook, and evidence set.
• Define how often you test the process (for example, periodic sampling) as part of your security assurance program. ¹

Daydream fit (earned): Many teams track offboarding in tickets but struggle to assemble consistent evidence across HR, IAM, endpoint, and third-party tools. Daydream can act as the system of record for PS-4 by mapping the requirement to an owner, embedding the runbook, and standardizing the evidence packet you’ll need for assessments. ¹

Required evidence and artifacts to retain

Keep artifacts in a way that supports sampling and traceability:

Policy and procedure artifacts

• Personnel termination/offboarding policy
• Personnel termination runbook (step-by-step checklist)
• RACI matrix (HR, IT, Security, Facilities, Legal)

Per-termination evidence (your “packet”)

• HR termination notice or HRIS event record
• Offboarding ticket with timestamps, assignees, and completion status
• IdP screenshot/export or log showing account disabled
• Privileged access removal evidence (role/group change logs)
• MFA revocation record
• Asset return form / inventory system update / shipping receipt
• Endpoint management record (returned, wiped, quarantined)
• Facilities access deactivation record (badge system entry), if applicable
• Exceptions record with approvals and compensating steps

Monitoring and QA

• Periodic access review results that check for orphaned accounts
• Reports showing terminated users with any remaining active accounts
• Lessons learned for any offboarding incidents

Common exam/audit questions and hangups

Expect these questions during an assessment against NIST SP 800-53:

• “Show me your termination procedure and who owns it.” ²
• “Provide evidence for a sample of recent terminations showing access was revoked.” ²
• “How do you handle immediate terminations?”
• “How do you ensure access is removed from non-SSO systems and third-party tools?”
• “How do you recover assets for remote staff?”
• “What’s your process for privileged users and break-glass credentials?”

Common hangup: evidence scattered across HR, IAM, and facilities with no single record tying actions to the termination trigger.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Offboarding starts from an email	No reliable trigger, inconsistent timing	Make HRIS or ticketing the required intake path
Only disabling the main account	Residual access persists in SaaS and tokens	Maintain a system inventory of access-bearing apps and keys
Ignoring shared credentials	Departing staff may retain secrets	Put shared secrets in a managed vault and rotate on termination
No independent validation	Errors go unnoticed	Add a second-person verification step for critical terminations
Weak third-party admin offboarding	Contractors can keep access	Contractually require notice and enforce access revocation in your IAM

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PS-4, so treat this primarily as an assessment and breach-risk control. The risk is concrete: terminated users or their compromised credentials can become a direct access path into systems, data, and third-party platforms. PS-4 also ties directly to incident response readiness: after a termination-related incident, the first question is whether access was removed and whether you can prove it. ²

A practical 30/60/90-day execution plan

No sourced timelines were provided, so treat the phases below as qualitative execution stages you can adapt to your environment.

First phase: Immediate stabilization

• Name the PS-4 owner and publish a single termination runbook.
• Require that every termination creates a ticket/case with mandatory fields (who, when, access profile, device list).
• Identify your “critical access systems” list (IdP, email, cloud console, code repo, endpoint manager, password vault).

Second phase: Near-term hardening

• Integrate HR trigger to IAM ticketing so terminations cannot be missed.
• Build a standardized termination evidence packet template.
• Add a privileged-user termination sub-playbook (role removal, token revocation, secret rotation).
• Add third-party administrator offboarding requirements to contracts and onboarding checklists.

Third phase: Ongoing assurance

• Run periodic sampling: pick completed terminations and verify there are no remaining active accounts.
• Track exceptions and measure root causes (late HR notice, missing system inventory, incomplete asset returns).
• Use GRC tooling (including Daydream where appropriate) to keep PS-4 mapping, procedures, and evidence consistent across teams. ¹

Frequently Asked Questions

Does PS-4 apply to contractors and third-party personnel, or only employees?

The excerpt references “individual employment,” but in practice you should apply the same termination controls to any person whose work ended and who had access to your systems or facilities. Define “personnel” in your policy and make third-party offboarding contractually enforceable. ²

What evidence is usually most persuasive to auditors?

A single termination packet that ties the HR trigger to ticket execution, plus system logs showing identity disabled and privileged roles removed. Scattered screenshots without timestamps or a linking ticket usually cause rework. ²

How do we handle “friendly” departures where the person is helping transition work?

Separate “employment termination” from “access needs.” If access must continue for transition, document the exception, limit access to least privilege, set an explicit end condition, and add heightened monitoring until access is removed. ²

We use SSO for most apps. Is disabling the IdP enough?

It covers many tools, but not all. You still need an inventory of non-federated apps, API tokens, SSH keys, and local accounts, plus a step that checks those systems for residual access. ²

What’s the right approach for remote employee asset returns?

Treat remote returns as an asset transfer workflow: shipping label issuance, tracking, receipt confirmation, and inventory update. If return fails, document escalation steps and compensating controls like device quarantine in endpoint management. ²

How do we operationalize PS-4 in a tool like Daydream without turning it into paperwork?

Keep the runbook short, make evidence fields mandatory, and connect tickets and system logs as attachments or references. Daydream is most effective when it standardizes the PS-4 mapping to owners, procedures, and recurring evidence packets assessors ask for. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5