PS-5: Personnel Transfer

PS-5 sits in the Personnel Security (PS) family, but it is an access control problem in practice. The requirement is simple: when someone moves internally, you reassess whether they still need the access they already have. The risk is also simple: internal transfers create “access drift,” where people accumulate permissions over time that no longer match their job.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize PS-5 is to build a transfer workflow that starts with HR (or your identity governance system), routes to the right business approvers, and ends with technical enforcement in IAM and physical access control systems. You should be able to prove, for any sampled transfer, (1) when the transfer happened, (2) what access they had before, (3) what access was removed, (4) what access was added, and (5) who approved the remaining access.

This page gives requirement-level implementation guidance you can hand to IAM, Security Operations, Facilities, and HR to build a single, auditable process that stands up in a NIST SP 800-53 assessment. ¹

Regulatory text

PS-5: Personnel Transfer requires you to: “Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization.” ²

Operator interpretation (plain English)

When someone changes roles, you must:

1. Identify their current access (apps, systems, data repositories, admin roles, badges, building areas).
2. Decide what still matches the new job (keep) and what does not (remove).
3. Execute the access changes promptly through controlled workflows.
4. Retain evidence showing the review happened and the outcome was implemented.

This is not a policy-only control. Assessors expect an operational workflow with records. ¹

Who it applies to

Entities

• Federal information systems and programs assessed against NIST SP 800-53. ¹
• Contractors handling federal data (including cloud services and managed service providers) where NIST SP 800-53 is in scope via contract, authorization boundary, or customer requirement. ²

Operational context (where PS-5 breaks in real life)

PS-5 most often fails in these situations:

• Internal job changes (promotion, lateral move, backfill).
• Temporary assignments (acting roles, short-term project access).
• Transfers across business units where IT and Facilities approvals are separate.
• Contractor reassignments where the “employer” stays the same but the assignment changes.

If your transfer event does not reliably trigger an access review, you do not have PS-5 in practice.

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

Below is a workflow you can implement with HRIS + IAM + ticketing + physical access systems. Adjust the tools, keep the outcomes.

Step 1: Define the trigger and scope

• Trigger event: HR records a transfer/reassignment effective date (including manager change, cost center change, job code change, location change).
• Scope of review: logical access (SSO apps, AD/Entra groups, privileged roles, SaaS admin consoles, databases) and physical access (badge access groups, building zones, data center access, lab access). ²

Deliverable: a short PS-5 procedure that names the systems included in the review and how transfers are detected.

Step 2: Assign owners and approvals that match how access is granted

Set explicit responsibility. A workable split:

• HR: authoritative source of transfer event and effective date.
• IAM/Security: runs access inventory, executes removals in core IAM, monitors completion.
• Hiring manager (new role): approves what access is needed going forward.
• System owners / data owners: approve high-risk system access and privileged roles.
• Facilities/Security (physical): reviews and updates badge access groups. ¹

Avoid “shared inbox ownership.” Put names/roles in the procedure.

Step 3: Create an “access snapshot” at transfer time

At minimum, capture:

• Current group memberships / roles (including privileged).
• Assigned applications and entitlements.
• Current physical access groups and zones.
• Any exceptions or compensating controls tied to the user.

If you have an IGA tool, export an entitlement report at the time the workflow starts. If you do not, script an SSO/Directory group export and attach it to the ticket.

Step 4: Make a keep/remove decision using the new role as the baseline

Operationally, you need a rule: new role baseline wins.

• Map the new role to access bundles (RBAC groups) where possible.
• For anything not in the new role baseline, require explicit justification to keep it.
• For privileged access, require re-approval by the privileged role owner (separate from the manager) if that matches your governance.

A simple decision matrix you can embed in the ticket:

Access item	In new role baseline?	Risk level	Decision	Approver
Standard app group	Yes	Normal	Keep	New manager
Standard app group	No	Normal	Remove	IAM (auto) unless exception
Admin role	Yes	High	Keep	System owner + Security
Admin role	No	High	Remove	Security (mandatory)
Data center badge	Any	High	Remove unless documented need	Facilities + Security

This directly implements “confirm ongoing operational need.” ²

Step 5: Execute changes with controlled, auditable mechanisms

• Logical access: remove old department groups, remove privileged roles, add new role groups through your standard access request process, and re-run SoD checks if you have them.
• Physical access: update badge access groups; if location changes, validate building access and revoke prior site access.
• Exception handling: if a business exception is approved, record the justification, approving party, and expiration/review trigger tied to the assignment end date.

Key control design point: do not rely on “manager will email IT.” Build a workflow that produces logs and closure states.

Step 6: Close the loop with completion checks

Create a completion control so tickets cannot be closed without:

• Confirmation that removals were executed (log evidence).
• Confirmation that additions were executed (ticket/workflow evidence).
• A final reviewer sign-off (IAM/Security) for high-risk moves (role into Finance, IT admin, Security, engineering with production access).

Step 7: Monitor and test

To keep PS-5 operating:

• Run periodic QA sampling of recent transfers and compare “before snapshot” vs “after state.”
• Track exceptions and ensure they expire or are re-approved.
• Use findings to fix role baselines and automation gaps. ¹

Required evidence and artifacts to retain

Assessors typically want evidence for a sample of transfers. Maintain:

1. PS-5 procedure (who, what systems, trigger, approvals).
2. Transfer event record (HRIS change or authoritative feed record).
3. Access snapshot at time of transfer initiation (logical + physical).
4. Approval record showing review/confirmation of ongoing need (manager/system owner/Security as applicable).
5. Execution evidence:
   • IAM/Directory change logs (group removals/additions)
   • Privileged access management logs (role grants/removals)
   • Physical access system logs (badge group changes)
6. Exception records (justification, approver, start/end, review notes).
7. Testing results (internal audit or control self-testing notes, remediations).

If you want PS-5 to be “easy in an audit,” standardize this into a single ticket template and require attachments/exports.

Common exam/audit questions and hangups

Expect questions like:

• “Show me three recent internal transfers and prove you reviewed both logical and physical access.” ¹
• “How do you detect transfers reliably? What if HR enters it late?”
• “Who approves continued access to sensitive systems after a transfer?”
• “Do you remove access tied to the prior role automatically?”
• “How do you handle temporary assignments and dual roles?”
• “Do contractors follow the same process when reassigned internally?”

Common hangup: teams can show access request approvals for new access, but cannot show removal of old access tied to the prior role. PS-5 expects both.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating transfers as onboarding-only.
   Fix: Require an explicit keep/remove review of existing entitlements as part of every reassignment. ²

2. Mistake: ignoring physical access.
   Fix: Put Facilities badge groups into the same workflow or enforce a parallel ticket with cross-reference.

3. Mistake: relying on manager attestations without system evidence.
   Fix: Attach exports/logs for key systems or use IAM-generated evidence.

4. Mistake: no defined trigger for “temporary” transfers.
   Fix: Treat temporary assignment start and end as transfer events that create access reviews and removals.

5. Mistake: exceptions that never expire.
   Fix: Require an end date on any retained old-role access and re-review at assignment end.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PS-5, so you should not plan around a specific regulator headline. The practical risk is still high: transfer-driven access drift increases the odds of unauthorized data access, privilege misuse, and audit findings because access no longer matches job need. PS-5 exists to force an explicit reassessment at the moment drift is most likely. ¹

Practical 30/60/90-day execution plan

Use this as an operator’s plan. Adjust scope to your authorization boundary.

First 30 days (establish the mechanism)

• Name a PS-5 control owner (IAM or GRC) and publish a one-page PS-5 procedure aligned to the NIST text. ²
• Define transfer triggers from HRIS (job code, manager, department, location).
• Inventory systems in scope for logical and physical access review.
• Build a standard transfer ticket template with: access snapshot attachment requirement, approver fields, and closure checklist.

Days 31–60 (make it work end-to-end)

• Integrate HR transfer events to ticket creation (automation if possible; otherwise, daily report + manual creation).
• Implement default removal actions for old-role access (directory groups, shared drives, privileged roles).
• Add Facilities to the workflow, with a required badge group review for location or role changes.
• Pilot the workflow with one business unit and fix friction (missing role baselines, unclear approvers).

Days 61–90 (make it auditable and sustainable)

• Define a small set of “high-risk transfers” that require Security/system owner approval (privileged access, sensitive environments).
• Start monthly QA sampling and track findings as corrective actions.
• Operationalize evidence retention: standard exports, centralized ticket storage, and an audit-ready PS-5 evidence folder.
• If you use Daydream for control operations, map PS-5 to a control owner, the exact procedure, and recurring evidence artifacts so audits pull from one place instead of email and spreadsheets. ²

Frequently Asked Questions

Does PS-5 apply to contractors who change assignments but stay with the same third party employer?

Yes if they are “individuals” with access to your systems or facilities and their assignment changes. Treat reassignment as a transfer event and re-check logical and physical access needs. ²

Do we have to remove all access on every transfer?

You have to remove access that no longer has an operational need. Keep access that is justified for the new role, and retain evidence of the review and approval. ¹

What counts as “physical access” for PS-5?

Badge access to buildings, floors, labs, data centers, and other controlled areas. If you operate facilities access control systems, include them in the transfer review scope. ²

How do we handle employees with dual roles (matrixed teams)?

Document the dual-role requirement and tie access to named systems needed for each role. Use an exception record with an end date or a re-review trigger when the secondary assignment ends. ¹

Our managers approve access in emails. Is that acceptable evidence?

Email can be evidence, but it is fragile and hard to test at scale. A ticketed workflow with captured access snapshots, structured approvals, and system logs is easier to defend in an assessment. ¹

What’s the minimum viable PS-5 implementation if we lack an IGA tool?

Use HR transfer reports to open a standardized ticket, attach directory/SSO group exports as the access snapshot, route approvals to the new manager and system owners, then attach change logs for removals and additions. That meets the “review and confirm” expectation if it is consistent. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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