When a developer moves to another team, review all their current access, remove what the new role does not need, add what it does, and tell the affected owners. NIST SP 800-53 control PS-5 describes the same pattern: confirm need, act within a defined period, change authorizations, notify. Skipping it is how access creep begins.
Why movers are the forgotten group
Offboarding gets a checklist. Onboarding gets a checklist. A transfer often gets a Slack message. The person keeps the old repositories, the old cloud roles and the old on call rotation, and adds the new ones. After three moves they hold access to half the company.
Auditors know this. A leaver sample is easy to evidence, but a mover with stale permissions is a common finding.
What PS-5 asks for
The control, as summarized from the NIST catalog, requires an organization to do four things when someone is reassigned or transferred:
- Review and confirm that current logical and physical access is still operationally needed.
- Start defined transfer actions within an organization-defined period after the formal transfer.
- Change access authorizations to match any change in operational need.
- Notify defined personnel or roles within a defined period.
The supplemental guidance says it applies to permanent or long term reassignments, and gives examples such as closing old accounts and creating new ones, changing system privileges and preserving access to official records. The time periods are for you to define. NIST does not fix them.
A mover procedure for engineering
- Trigger. The HR system or manager change should open a mover ticket automatically. Do not rely on someone remembering.
- Snapshot. Export the person's current groups, repository roles, cloud roles and secrets access.
- Decide. The old manager and new manager each mark items as keep, remove or transition. Keep needs a reason.
- Apply. Remove first, then add. Reversing the order briefly gives the person both sets.
- Handover. Transfer ownership of services, alerts, pull request reviews and CODEOWNERS entries from the person to a team.
- Notify. Tell service owners and the security contact that the move happened.
- Verify. After a set number of days, compare the snapshot to the current state.
Decision table for common access
| Access type | Typical mover decision |
|---|---|
| Old team repositories | Remove or reduce to Read unless a transition period is agreed |
| Production on call | Remove at handover date |
| Shared secrets | Rotate if the person knew them and the new role does not need them |
| Admin roles | Reapprove from scratch |
| Tools unique to the old team | Remove |
Set the clock
Choose a period you can meet, such as completing the mover actions within a few business days, and write it in the procedure. A control you define and then miss is worse than a longer one you keep.
Try it yourself
Use the framework mapping demo to see how one control maps to several frameworks, which helps you reuse mover evidence across audits.
Click through it at your own pace, or open it full screen.
Quick check
Does PS-5 set a deadline?
No. It leaves the periods for the organization to define, so write yours down and meet it.
Is a promotion a transfer?
If duties change, review access. Treat any meaningful change of operational need as a trigger.
Safeguard's compliance and evidence automation can help gather mover and leaver evidence for review. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
