PS-5 Personnel transfer: requirements and evidence

What PS-5 personnel transfer requires and why transfers cause access drift

PS-5 requires that when an individual is reassigned or transferred, the organization reviews and confirms that the person still needs each logical and physical access authorization tied to the old role, starts the defined transfer actions within a defined period, modifies access as needed, and notifies defined personnel within a defined time. In other words, a transfer is a trigger for an access review, not just a change of job title. The organization sets the periods and chooses who gets notified, so the first task is to write those down in the personnel security procedures, where an assessor will look for them. NIST's catalog and the SP 800-53A procedure both leave these values to the organization, so any number you adopt should come from your own risk decisions and be documented as such.

Transfers cause access drift because people accumulate permissions and rarely lose them. A new manager adds a directory group, a project needs a temporary share, a shared mailbox is granted for coverage, and nobody removes the earlier entitlements. Termination has a single hard stop: the account is disabled and credentials are revoked. A transfer has no equivalent stop, so the old access stays live while the new access is added, and the person keeps the union of both roles. Physical access follows the same pattern, with badge zones and key assignments from a previous post remaining active. Because the person is still an active employee, the gap rarely triggers an alert or a helpdesk ticket.

Before the next assessment, confirm three things: whether your HR system emits a transfer event that your identity and facilities teams actually receive, whether access is granted by role or by ticket (role-based grants are easier to remove and to show), and who signs off on continuing need for each affected authorization. Ask your identity provider or directory team to report entitlements held by employees who changed position in the last period, and compare them with what the new role requires. Evidence assessors expect includes the transfer records and the list of access authorizations for the person, so keep both. Implementation partners can prepare these workflows and reports, but the organization owns the decisions about who keeps what access.

Which systems, roles and teams fall under PS-5 transfer actions

PS-5 only works if the organization agrees on what counts as a transfer and which access it reaches. The cards below cover the decisions that define the population of accounts and facilities a transfer review must touch, and the points where external personnel move into PS-7.

Authorization boundary systems and facilities

Start from the authorization boundary documented in the system security plan, then list every system inside it and every physical space that holds boundary components, such as data centers, network closets and secure rooms. Each one is a place where a transferred person may still hold rights. Check that the inventory matches the boundary a current assessor would examine, and record any system that is shared with another boundary so its access owner is named.

HR events that count as transfers

Decide which HR records trigger a PS-5 review. Typical triggers include a change of department, cost center, manager, job family or work location, and a move to a role with different duties. Leaves of absence and temporary reassignments are often missed, so decide whether they trigger a review too. Confirm that the HR system sends these events to the identity system, because a transfer that HR records but the identity system never sees will not start any action.

Account types in scope

Transfers affect more than named user accounts. Service accounts owned by a person, shared administrator accounts, privileged accounts, group memberships, role assignments and physical badges all carry access that outlives a reassignment. Write down each account type, its owner of record and whether the transfer review covers it. Accounts whose owner has moved but whose credentials remain active are a common finding in PS-5 assessments.

Roles that own each review step

PS-5 assigns work to several roles: the personnel function that records the transfer, the managers who confirm continuing need, and the account management staff who change authorizations. Name each role in the procedure and state who has the final say when a manager does not respond. Assessors interview people in these roles, so the names and responsibilities in the procedure should match what those people actually do.

Contractors and external personnel

Contractors and service provider staff are usually not in the HR system, so a transfer for them is a change of assignment managed by the sponsoring organization or provider. PS-7 governs the provider's duty to give notice of staff transfers and terminations, while PS-5 governs the organization's own review. Decide which party sends the notice, how quickly, and which system records the change, and check that the contract or agreement says so.

Exceptions and time-bound access

Some access should continue after a move, such as a time-limited project grant or access needed to hand over work. Record each exception with an approver, an end date and a reason, and make sure the review confirms it. Without a documented exception path, teams tend to keep access by default, which is the accumulation that periodic certification reviews are designed to catch.

How an assessor tests PS-5 under SP 800-53A

This table maps the four SP 800-53A determination statements for PS-5 to the assessment methods an assessor uses, the evidence they will ask for and the findings that commonly appear. Read each row as one thing the assessor must confirm, then check whether your transfer process produces records that answer it.

Assessment focus	How the assessor tests it	Evidence requested	Common findings
Transfer procedures exist and address reassignment	Examine the documented personnel transfer procedures and confirm they cover review of access, transfer actions, access changes and notifications.	Current transfer procedure, its owner, approval and review date, and the workflow it describes.	Procedure covers hiring and termination but is silent on internal moves, or is outdated relative to the current identity system.
Continuing need for access is reviewed after a transfer	Examine transfer action records and interview the people who approve access reviews to see how the reviewer decides which access stays.	Transfer tickets or review records showing the reviewer, the access items reviewed and the decision recorded for each.	Reviews confirm the new role but never check access carried over from the previous role.
Access is modified and transfer actions start within the defined period	Examine the list of system and facility access authorizations for a sample of transferred individuals and test the workflow with a transfer scenario.	Authorization lists before and after the move, timestamps showing when actions began and completed, and facility access logs.	Timeframes are defined in policy but not measured, or physical badge access is not part of the transfer workflow.
Defined personnel are notified within the defined time	Interview personnel security and account management staff about who receives notice, then test a transfer to confirm the notice is sent.	Notification records, distribution lists matching the organization's defined recipients, and sent messages or tickets.	Notification depends on a manager remembering to tell someone, with no record that it happened.

How to implement a transfer access review step by step

This sequence turns a reassignment into a documented access review, so each person keeps only the logical and physical access their new role needs, and the organization can show when and why each change was made.

Define the transfer trigger and review periods
Start by writing down what counts as a transfer for your organization: a change of department, job family, manager, facility or project. Set the defined period within which transfer actions must start and the defined period for notifying personnel, and record who owns each. Confirm these values with your policy owner and with the PS-1 policy and procedures so they match what assessors will examine. The output is a short written transfer procedure with named owners and the periods approved by the organization. You know it is done when the HR system or workflow can trigger a transfer event and the procedure is approved and version controlled.
Inventory the access tied to the person
Build a list of every logical and physical access grant the individual holds before the move. For logical access, pull group memberships, application roles, privileged accounts, directory objects and SCIM-provisioned assignments from your identity provider and directories such as FreeIPA. For physical access, pull badge zones, facility authorizations and key or safe holdings from the facility team. Include access the person controls indirectly, such as shared credentials or service account ownership. The output is a per-person access inventory, which doubles as the list of system and facility access authorizations an assessor will ask to examine.
Confirm continuing need with the new manager
Send the inventory to the gaining manager and ask, item by item, whether the person needs each access for the new role. Ask the losing manager to confirm which items were tied to the former role. Record each decision as keep, modify or remove, with a short reason and the approver's name and date. Items with no answer stay pending and escalate to the access owner. The output is a signed-off review record for that transfer. You know it is done when every inventory line has a decision and no line is left unassigned.
Start the transfer actions
Open the defined transfer actions in your ticketing or identity workflow, one ticket per person, linked to the review record. Assign each ticket to the system owner for the affected application or facility, and set the target date that follows from your defined period. Include actions that are not access changes, such as moving the person into the correct access certification campaign or updating approval routing. The output is a set of tracked actions with owners and status. You know it is done when each transfer event shows initiated actions that can be traced back to the trigger.
Modify authorizations and remove stale access
Carry out the approved decisions. Remove groups and roles the new position does not need, add the access the new role requires under its approval path, and update physical badge zones and facility authorizations. Where directories and identity providers drive downstream provisioning, make the change at the source and confirm it propagates, for example through SCIM provider sync to target applications. Verify that the person can no longer reach removed resources, and check that privileged and shared credentials the person held are reassigned. The output is changed authorizations with before and after state captured. You know it is done when a post-change inventory matches the approved decisions.
Notify defined personnel within the defined time
Send notifications to the personnel your procedure defines, which commonly include the losing and gaining managers, system owners, facility security and the people who approve access. State what changed, the effective date and any follow-up they must perform, such as revoking local credentials or retrieving property. Log the time each notification was sent so you can compare it with the defined period. The output is a notification record for each transfer. You know it is done when every defined recipient group has a logged notice inside the defined time.
Keep transfer records for assessment
Store the trigger, inventory, decisions, tickets, change evidence, post-change inventory and notification log together under one transfer identifier. Include the approver for each decision and the dates. Use this record to test your own process: sample recent transfers and check that each step happened in order and inside the defined periods. Where a midPoint style certification campaign or periodic review is used, feed its results back into the next transfer. Ask your assessor which format they expect, because the records must be examinable. The output is a retrievable transfer file per person. You know it is done when a reviewer can reconstruct any transfer from the record alone.

Evidence that passes a PS-5 transfer review

An assessor testing PS-5 looks for a traceable chain from the transfer event to the access change and the notifications that followed. The cards below cover the records that connect those steps, and how to keep them current between assessments so the evidence reflects how transfers actually happen.

Transfer action records with dates

Keep one record per transfer showing the individual, the old and new positions, the date the transfer was initiated and the date it was completed. Assessors compare these dates against the defined transfer period in your PS-5 parameters, so the dates must be captured at the time of the event, not reconstructed later. Confirm that the record links to the HR action that triggered it.

Access review sign-offs

Each transfer should produce a documented review in which the reviewer confirms whether the person still needs each existing logical and physical access right. Record the reviewer's name, role, date and decision for every access item. A sign-off that says only "reviewed" with no decision per item will not show that continuing need was actually evaluated.

Before-and-after access lists

Export the person's account entitlements, group memberships and physical access grants before the transfer and again after the change. The difference between the two lists is the evidence that access was modified as needed. Check that removed access was revoked from target applications, not only from the directory, and that the export comes from the system of record rather than a spreadsheet.

Notification records

PS-5 requires notifying defined personnel within a defined time, such as the former manager, the new manager, system owners and facility security staff. Keep the notification log with recipients, send time and channel. Confirm the recipient list matches the roles your organization defined, since assessors check the notifications against those definitions.

Transfer procedure and exception log

Keep the current written procedure for personnel transfer, with its owner, approval and review date, so assessors can compare what staff did against what was documented. Pair it with an exception log for transfers that missed the defined period, showing the cause, the approver and the corrective action. Missing exceptions often signal that the procedure is not followed in practice.

Keeping evidence current between assessments

Evidence gathered once before an assessment goes stale quickly. Schedule periodic exports of transfer tickets and access snapshots, and run a sample of recent transfers through the full chain yourself to find gaps early. Ask your identity platform and any access certification tool which logs they retain and for how long, so the retention period covers your assessment window.

What meeting PS-5 costs in money and effort

This table breaks down the money and effort behind PS-5 by cost component, showing who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Read it as a list of questions to bring into a quote, since no supplied figures set prices or durations for these items.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Identity tooling or licenses	Software vendor or open-source project staff, if a support contract applies	Recurring if commercial; open-source core has no license fee	Self-hosted open source such as authentik, FreeIPA or midPoint removes most license spend; confirm support terms and hosting costs
HR-to-identity integration engineering	Internal engineers or an implementation partner building the transfer trigger from HR records	One-time build, then recurring maintenance	Number of HR source systems, quality of job-change data and whether transfers are event-driven or batch
Access model and role mapping	Identity engineers and application owners defining which access follows which job	One-time, revisited on reorganizations	Count of applications and role types; fewer, well-defined roles reduce review and rework
Manager review time	Line managers and application owners confirming continuing need after a transfer	Recurring with every transfer event	Transfer volume, how many systems each person touches and whether reviews are queued or self-service
Access certification campaigns	Designated reviewers working through revocation or keep decisions within a set timeframe	Recurring at the campaign cycle chosen	Campaign frequency, size of review items and automated pre-filtering of routine decisions
Evidence upkeep	Compliance or security staff keeping transfer records, notifications and access lists current	Recurring, ongoing	Whether logs and tickets are generated automatically and retained in one place
External review and auditor sampling	Independent auditor or assessor who samples transfer records and interviews staff	Recurring at each assessment cycle	Population size of transfers, record completeness and how quickly samples can be produced
Notification and exception handling	Security and HR staff following up on late or missing transfer actions	Recurring, variable	Timeliness of automated notifications and clarity of the defined response windows set by the organization

Which self-hosted tools support PS-5 transfer evidence

authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. When a transfer changes a person's group membership in authentik, the provider can carry that change to connected applications, which supports the PS-5 requirement to modify access when a person is reassigned. The provider also runs a full sync every hour and deprovisions users from the target when they lose access to the application, so a removed group membership should leave a trace in the sync behavior and in the application's account state.

Transfer-driven changes: Group changes made in authentik can be reflected in each downstream application, so the assessor can compare identity records against application accounts.
Sync cadence: The documented hourly full sync defines the maximum delay between a directory change and its propagation. Record that delay in your PS-5 procedure.
Deprovisioning behavior: Users who lose application access are removed from the target, which you can show with sync logs and before-and-after account listings.
Scope limits: Applications without a SCIM endpoint need a manual or scripted step, and that step needs its own evidence.
Logs as records: Retain provider and sync logs under your audit retention rules so transfer actions can be traced later.

Confirm with your team which target applications support SCIM 2.0 and whether a transfer leaves ongoing access in any system that is not connected.

Where PS-5 transfer reviews usually fail

PS-5 transfer reviews rarely fail because nobody cares about access. They fail at the handoffs: HR to IT, the access review itself, the time limits that were never written down, and the systems that sit outside the identity process. Each card below names one of these gaps and the check that closes it.

HR does not notify IT

The transfer starts in an HR system, but the access team only hears about it when a manager remembers to open a ticket. Until the notice arrives, the person keeps the access of the old role. Check whether HR transfer events feed the identity system automatically, or whether a named person must relay them, and test one real transfer end to end and time it against your defined period.

Accumulated access never removed

People who move between roles usually keep the groups and entitlements they picked up earlier. Assessors look for evidence that access was reviewed against the new position, not only that new access was added. Ask for a sample of transferred users and compare their current group memberships with the access their new role requires. Any difference is a finding.

Transfer periods not defined

PS-5 requires transfer actions within a defined period, and the organization sets that period. Many programs never set one, or set it in a policy that no procedure or ticket template references. Confirm that the period is written down, approved, and tied to a specific trigger, so an assessor can compare actual transfer dates against it.

No notification records

PS-5 expects defined personnel to be notified within a defined time, such as the new manager, the security team and system owners. When notifications are sent by email and never logged, the organization cannot show that they happened. Check that each notification has a timestamp, a recipient group and a closed ticket or record, and keep those records for assessors.

Access outside the identity system

Local accounts on servers, network devices, database consoles and building access badges often sit outside the central directory. A transfer that updates the directory leaves these accounts untouched. Build an inventory of systems that authorize access without the directory, then decide for each whether it is integrated, scheduled for a periodic review, or closed. Confirm the list with system owners rather than assuming it is complete.

No independent review of changes

When the same administrator who processes a transfer also confirms that the old access was removed, nobody checks the work. Periodic access certification, where a designated reviewer keeps, changes or revokes each access item, provides that second look. Confirm who reviews transfer-driven changes, how often, and whether the reviewer can see the access items they approve.

PS-5 transfer questions buyers ask before hiring help

How much effort does it take to implement PS-5 personnel transfer?

The effort depends mostly on how many systems, applications and facilities hold access that must be reviewed after a move, and on whether a written transfer process already exists. PS-5 asks for four things: confirming continuing need for existing access, starting defined transfer actions within a defined period, modifying access where needed, and notifying defined personnel within a defined time. Each of those steps needs a named owner, a trigger from HR or the business, and a record. If the organization has an identity source that knows about role changes, most of the work is mapping those changes to access reviews. If it does not, the first effort is building that signal. Ask any partner to split its estimate into discovery of access paths, process design, tooling changes and evidence setup.

How long does a PS-5 transfer control take to put in place?

No researched duration applies to PS-5, so treat any timeline as something to confirm in writing. The schedule is driven by the number of directories, applications and physical access systems in scope, the state of role data, and how many approval paths the transfer process has to cross. Organizations with a single directory and clear role groups usually have a shorter path than those with local accounts on many hosts. Ask for a timeline tied to a fixed scope, with milestones for process approval, integration testing with real transfer cases, and evidence collection. A fixed-scope engagement lets both sides agree on those dates before work starts.

What does our team need to provide before an engagement starts?

The work needs decisions from the organization, not only access to systems. Your team has to define the transfer period and the notification window, name the personnel who must be told about a transfer, and agree which roles require re-approval. HR must be able to send a reliable event when someone changes position, and system owners must confirm which access they are accountable for. Your team also needs read access to the identity provider, directory and relevant application consoles, plus a list of physical access systems in scope. Without these inputs, the partner can build tooling but cannot prove the control runs. The organization still owns the policy and the decisions behind it.

Can we implement PS-5 transfer controls in-house without a consultant?

Yes, many organizations do this in-house, provided the people doing the work have identity engineering skills and clear authority over HR, IT and business owners. The in-house path makes the most sense when an identity platform already holds role data and the team already runs access reviews. Outside help usually adds value in three places: designing the transfer workflow across HR and IT, connecting provisioning tools so that access changes follow role changes, and preparing assessment evidence against the examine, interview and test methods NIST describes. Whichever path you choose, the organization owns the control. An assessor will still interview your staff, not the consultant.

What drives the cost of a PS-5 transfer implementation?

Cost is driven by scope and by how far the current process is from working. The main cost components are: discovery of where access is granted, design of the transfer workflow with HR and system owners, integration work for identity and provisioning tools, testing with realistic transfer cases, and evidence preparation. Some costs are one-time, such as design and integration. Others recur, such as periodic access reviews, notification handling and tool upkeep. Cost rises with the number of applications that hold local accounts, the number of HR systems that must signal changes, and the number of physical access systems that must be updated. Ask for a quote that lists each of these as separate line items, and separate one-time work from recurring support.

What will an auditor sample when testing PS-5 transfer?

An assessor testing PS-5 will usually start with the written procedures for personnel transfer, then request records of actual transfer actions and the current list of system and facility access authorizations. Under the SP 800-53A Rev. 5 procedures, the assessor also interviews staff with personnel security responsibilities and staff with account management responsibilities, and tests whether the transfer process works as written. Expect them to pick a sample of recent transfers and trace each one: was need for existing access confirmed, were changes made within the defined period, and were the defined personnel notified within the defined time? Keep records that link the HR event, the access change and the notification, because gaps in that chain are where findings usually appear. Confirm the exact defined periods with your own system security plan, since those values are set by the organization.

Which open-source tools can produce PS-5 transfer evidence?

Several self-hosted open-source tools can support the transfer process, but none of them satisfies PS-5 on its own. authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access. FreeIPA uses 389 Directory Server to store users, groups and hosts, with centralized access control and delegated administration. midPoint access certification campaigns let designated reviewers keep, change or revoke access items within a set timeframe, which supports the need-confirmation step. Confirm each tool's behavior against your own environment before relying on it, and keep the sync logs and campaign outcomes as evidence.

How DeployOpen scopes and prepares PS-5 transfer evidence

DeployOpen plans and implements self-hosted identity and access tooling inside the client's own infrastructure, and prepares the procedures and evidence that show PS-5 is operating. It does not decide whether the organization meets the control, and it does not issue an audit report or certification. The organization owns PS-5, its transfer procedure and the decisions about who keeps which access. An independent assessor tests the result against the SP 800-53A procedures and reaches the conclusion. Engagements run under a fixed written scope, so the boundary between what the client decides, what DeployOpen configures and what the assessor tests is agreed before work starts.

In practice, the scope usually covers the identity provider and directory that hold transfer-relevant attributes, the connectors that propagate group and role changes to target applications, and the access certification workflow that asks managers to confirm continuing need. Physical access groups tied to facility authorizations, which PS-5 also reaches, are often handled by a separate team and should be named explicitly in the scope. The written scope should list the systems in and out, the transfer triggers the client recognizes, the defined periods that the organization must set for initiating transfer actions and notifying personnel, and who signs off on each evidence item. Ask the implementation partner to show how each component produces records that an assessor can examine, such as transfer tickets, group membership history and certification decisions.

The first step is a scoping workshop in which the client's security, HR and access owners agree on the transfer trigger, the defined periods and the personnel to notify, and DeployOpen reviews the current identity and access configuration against those decisions. Ask for the output in writing: a scope statement, a gap list keyed to the four SP 800-53A determination statements for PS-5, and a proposed evidence map that names the owner of each artifact. Confirm with your assessor before the workshop which records they expect to examine, so the evidence design matches their test plan rather than the other way around.

PS-5 Personnel transfer