Personnel Transfer

The personnel transfer requirement (NIST SP 800-53 Rev. 5 PS-5) means that every time someone changes roles internally, you must promptly review their logical and physical access and keep only what the new job still requires. Operationalize it by tying HR transfer events to an access review workflow, manager/system-owner re-approvals, and auditable records of what changed and why. ¹

Key takeaways:

• Trigger an access review from HR role-change events, not from ad hoc emails or tickets.
• Reconfirm both logical access (apps, cloud, privileged roles) and physical access (badges, facilities).
• Keep evidence that access was reviewed, approved/removed, and completed within your defined internal timeline. ¹

“Personnel transfer” is a deceptively narrow control that regularly becomes an audit finding because it sits between teams: HR knows the person moved, managers know the new job, security and IT control access, and facilities controls badges. PS-5 closes the gap by requiring a review and confirmation of ongoing operational need for existing access authorizations when a person is reassigned or transferred. ¹

For a Compliance Officer, CCO, or GRC lead in a FedRAMP Moderate environment, the fastest path to compliance is to treat transfers as a formal access governance event with a defined trigger, owners, decision points, and retained artifacts. The exam focus is usually not whether you have a policy, but whether you can prove consistent execution: “Show me the last few transfers, what access they had before, who re-approved it, what was removed, and when it was completed.”

This page gives requirement-level guidance you can implement quickly: who owns what, the workflow, the minimum evidence set, common audit traps, and an execution plan that gets you from “we do it informally” to “we can pass an assessment with confidence.”

Regulatory text

Requirement (excerpt): “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 meaning: whenever someone changes roles internally (promotion, lateral move, temporary assignment, org transfer), you must:

1. inventory their existing access (logical + physical),
2. determine what the new role needs,
3. remove access that is no longer justified,
4. explicitly re-approve any access you keep, and
5. retain evidence that the review happened.

This is an access recertification event triggered by a role change. It is not optional, and it is not satisfied by “they still work here so they can keep everything.”

Plain-English interpretation (what PS-5 is trying to prevent)

Transfers create “access drift.” People accumulate systems, data, and facility access from old jobs and keep it because nobody feels responsible for cleaning it up. PS-5 forces a decision: either the access is still needed for the new position, or it must be removed. ¹

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating under FedRAMP Moderate expectations for personnel security controls. ¹

Operational context where it matters most

• Any environment with role-based access, especially privileged access (cloud subscriptions, production access, database admin, CI/CD, security tooling).
• Mixed ownership stacks where access is split across IT, security, application owners, and facilities.
• Organizations with contractors or third parties who move between projects internally (still “within the organization” for access purposes if you administer their accounts and badges).

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

1) Define the transfer trigger (make it deterministic)

Pick the system of record that will trigger PS-5:

• HRIS change of manager, department, job code, or location
• Identity platform attribute change (department, cost center, title)
• Facilities system change (site assignment)

Control design goal: transfers should create an auditable work item automatically (ticket/workflow), not rely on someone remembering to notify security.

2) Set roles and decision rights (RACI that auditors can understand)

Minimum accountable parties:

• HR (or People Ops): records the transfer event and effective date; feeds the trigger.
• New manager: accountable to confirm what access is required for the new role.
• System/data owners: approve continued access for their systems, especially for sensitive data.
• IT/Security IAM team: executes adds/removals, validates completion, and records evidence.
• Facilities/security (physical): adjusts badge access for sites/rooms as needed.

If your environment is complex, add Privileged Access Management (PAM) owner as a required approver for admin roles.

3) Generate a “current access snapshot” (logical + physical)

For each transfer event, collect:

• Logical: SSO app assignments, group memberships, cloud IAM roles, VPN, email distribution lists if they grant data access, PAM entitlements, service-specific roles (ticketing, code repos).
• Physical: badge access groups, site permissions, datacenter/secure room access.

This snapshot becomes the baseline evidence that you reviewed “current” access, not a guessed list. ¹

4) Compare to a target access profile for the new role

Decide how you will define “what the new job needs”:

• Preferred: role-based access profiles (RBAC) mapped to job functions.
• Acceptable interim: manager attestation + system-owner approvals based on least privilege.

Practical decision matrix:

Access type	Default action on transfer	Approval needed to keep
Privileged/admin roles	Remove first, re-add if justified	System owner + security/PAM owner
Sensitive data repositories	Re-approve explicitly	Data owner
Standard productivity apps	Keep if role still requires	New manager
Physical access to restricted areas	Remove unless needed	Facilities security + new manager

5) Execute removals and re-approvals (don’t let “keep” be implicit)

A transfer review is complete only when one of these is true for each entitlement:

• Removed (with completion proof), or
• Re-approved for the new role (with approver identity and rationale)

Avoid “no response means yes.” Require explicit approvals for anything beyond baseline access.

6) Close the loop with completion checks

Before closing the transfer work item:

• Confirm deprovisioning succeeded (not just “ticket updated”).
• Confirm physical badge changes took effect.
• Record exceptions with a compensating control (for example, “access retained temporarily due to transition duties,” with an end date you track internally).

7) Trend and fix systemic drift (operational maturity)

You will learn where access accumulates. Feed that back into:

• RBAC role templates
• Joiner/mover/leaver automation
• PAM onboarding rules
• Facilities access standards

Where Daydream fits (earned mention)

If your biggest pain is evidence collection and consistency, Daydream can act as the system that ties the HR transfer signal to a standard PS-5 workflow, prompts the right approvers (manager, system owner, facilities), and packages the access snapshot + approval trail into assessment-ready evidence without chasing screenshots across teams.

Required evidence and artifacts to retain

Auditors typically want to see execution proof for a sample of transfers. Keep:

• Policy/standard for personnel transfers and access review scope (logical + physical). ¹
• Transfer trigger record (HRIS event, ticket creation timestamp, effective date).
• Access snapshot at time of transfer (export/list of entitlements and badge groups).
• Approval/attestation records:
  • new manager approval for baseline needs
  • system/data owner approvals for sensitive systems
  • security/PAM approval for privileged roles (if applicable)
• Deprovisioning completion evidence (IAM logs, ticket closure with implementation notes, access removal reports).
• Exception register for any access retained outside normal profile, with rationale and review follow-up.
• Facilities change record (badge access updated/removed).

Retention duration depends on your internal policy and program requirements; PS-5 requires the review and confirmation, and your evidence should support that conclusion. ¹

Common exam/audit questions and hangups

Expect questions like:

• “How do you detect personnel transfers reliably?”
• “Show me recent transfers and prove access was reviewed.”
• “Did you review both logical and physical access?”
• “Who approves continued privileged access after a transfer?”
• “What happens if the transfer is urgent or after-hours?”
• “How do you prevent someone from keeping old project access indefinitely?”

Hangups that drive findings:

• No consistent trigger (ad hoc emails).
• Review covers SSO apps but misses cloud IAM, local admins, or physical badge access.
• Evidence exists only as chat messages or manager memory.
• Exceptions are common but unmanaged.

Frequent implementation mistakes (and how to avoid them)

1. Treating transfers like onboarding.
   Fix: make “mover” a distinct workflow with a mandatory “remove unless re-approved” rule for elevated access.

2. Relying on manager-only approvals for everything.
   Fix: require system/data owner approval for sensitive systems, and security/PAM approval for privileged roles.

3. Forgetting physical access.
   Fix: include facilities as a required step and collect badge group evidence.

4. No access snapshot, only a checklist.
   Fix: attach exports/logs showing actual entitlements at the time of review.

5. Letting exceptions become permanent.
   Fix: record exceptions with a defined follow-up review, tracked to closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PS-5. Practically, the risk is straightforward: transfer-driven access drift increases the chance of unauthorized access to systems, sensitive data exposure, and privileged misuse. For FedRAMP environments, the immediate consequence is usually an assessment finding or POA&M item if you cannot prove reviews occurred per PS-5. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Document the PS-5 procedure: triggers, scope (logical + physical), approvers, and evidence to retain. ¹
• Pick the transfer trigger source (HRIS preferred) and create a standard “Personnel Transfer Access Review” work item template.
• Define minimum approval rules (manager + system owner for sensitive systems; add security/PAM for privileged access if applicable).
• Run the workflow for all new transfers and capture evidence consistently.

By 60 days (reduce manual work, close coverage gaps)

• Build an automated access snapshot (SSO groups, cloud roles, PAM, badge groups) attached to the transfer work item.
• Create role-based access profiles for your most common roles and systems.
• Add a basic exception register with required fields (who, what access, why, who approved, follow-up condition).

By 90 days (operational maturity and audit readiness)

• Expand role profiles to cover high-risk teams (engineering, security, finance, support).
• Add periodic QA: sample completed transfer reviews and verify removals actually occurred.
• Produce an assessor-ready evidence pack template (policy + sampled transfers + logs/approvals + exception handling).
• If tooling gaps remain, implement a workflow system (for example, Daydream) that keeps approvals, exports, and closure evidence in one place.

Frequently Asked Questions

Does PS-5 apply if the person keeps the same manager but changes responsibilities?

If the change results in different system or facility access needs, treat it as a transfer event and perform the review. Your trigger can be broader than HR’s “transfer” label as long as it captures real access-impacting moves. ¹

What counts as “logical and physical access” in practice?

Logical access includes application entitlements, group memberships, cloud IAM roles, VPN, and privileged access. Physical access includes badge permissions for sites and restricted areas you control. ¹

Can we satisfy this requirement with an annual access recertification instead?

Annual recertification helps, but PS-5 is event-driven: you must review access when the reassignment or transfer happens. Treat annual reviews as a backstop, not the primary PS-5 mechanism. ¹

Who should approve access after a transfer: HR, the old manager, or the new manager?

The new manager should attest to job need, and system/data owners should approve continued access to their systems, especially for sensitive data and privileged roles. HR’s role is to provide the trigger and effective dates, not to approve access. ¹

How do we handle temporary assignments or “acting” roles?

Run the same PS-5 review, grant only what the temporary duties require, and record the planned end condition for the additional access. When the assignment ends, treat the return as another transfer event and review again. ¹

What evidence is strongest in an audit?

A dated transfer work item that includes the access snapshot, named approvals, and system logs or reports showing actual removals/changes. Auditors trust system-generated exports and immutable logs more than informal emails. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5