What PS-7 external personnel security requires in practice
When an assessor or customer asks how contractor staff are vetted, changed and removed, the answer under PS-7 is that the organization must set personnel security requirements for each external provider, document them, require the provider to comply with the organization's own personnel security policies, and monitor that compliance. The control also requires the provider to notify defined people within a defined time when its staff holding credentials, badges or privileges transfer or leave. In short, the organization owns the rules, the provider follows them, and the organization checks that they are followed. SP 800-53B places PS-7 in the low, moderate and high baselines, not the privacy baseline, so it applies to most federal-style systems regardless of the privacy scope.
The risk PS-7 addresses is the orphaned or over-privileged outside account: a contractor's login that stays active after the engagement ends, or a vendor engineer who keeps administrative rights after moving to another client project. This is hard because the contract, the provider's staff roster and the organization's identity systems are usually owned by three different people. Procurement holds the contract terms, the provider's HR team knows who has left, and the internal platform team controls the directory and the access grants. Nobody sees the whole chain unless the organization decides who must be told and how quickly.
Start by confirming three things for each external provider: the notification contact and window written into the contract, the internal owner who receives the notice, and the access review that checks whether outside accounts still need their privileges. For self-hosted platforms, an identity provider with SCIM provisioning, such as the authentik SCIM provider, can deprovision a user from a connected application when access is removed, while a directory like FreeIPA keeps the central list of accounts and groups, and midPoint access certification campaigns can require named reviewers to keep, change or revoke outside access on a schedule. Confirm with your assessor which evidence (the contract clause, the notice log, the review record) they expect for the monitoring step, because the tools can produce some of it but the provider's notices remain a contractual matter.
Which external providers and systems fall under PS-7
PS-7 applies to any external provider whose people can reach in-scope systems or facilities. The scoping work is deciding which providers hold credentials, badges or privileges, which service models count, and how the impact baseline changes the depth of effort. Each card below is a decision or check to settle before the requirements are written.
Providers holding credentials or privileges
Start with an inventory of every external party whose staff hold accounts, administrative privileges, badges or keys to in-scope systems or facilities. Include vendor support engineers with remote administrative sessions and contractors with shared service accounts, since these are the people PS-7 expects the organization to govern. Check identity records, privileged access lists and facility badge rosters against the vendor register, because providers often appear in one source and not the others.
Service bureaus and managed service providers
Service bureaus and managed service providers usually run systems or perform operations on the organization's behalf, so their staff turnover directly affects access to those systems. Decide whether each one is in scope by asking if its personnel can administer, change or view in-scope data or infrastructure. Record the contractual point of contact for transfer and termination notices, since PS-7 depends on the organization knowing when provider staff leave.
Staff augmentation and embedded contractors
Staff augmentation places individuals inside the organization's own teams, often with the same access as employees but with a different employer. These individuals are the most likely to be missed because they do not appear in the HR system. Decide whether they are covered by PS-7 requirements in the contract, by PS-3 screening, or by both, and confirm that their identity records are disabled when the placement ends.
Cloud operators and hosting providers
Cloud and hosting providers operate the underlying platform, but their personnel access are typically governed by the provider's own controls and shared responsibility terms. Decide what the organization can require of the provider, such as notification of staff changes for administrative roles and evidence of its personnel security program, and what it must document as inherited. Confirm the exact notification commitments in the service agreement rather than assuming them.
Impact baseline sets the depth of work
SP 800-53B allocates PS-7 to the low, moderate and high baselines, so every impact level carries the requirement. The difference lies in depth: a low-impact system may need a short list of providers with simple notice terms, while a high-impact system warrants a documented requirement set, named notification windows and periodic monitoring of each provider. Confirm the system's categorization before scoping provider reviews.
How an assessor tests PS-7 under SP 800-53A
This table maps the five SP 800-53A determination statements for PS-7 to the examine, interview and test methods an assessor uses, the suggested assessment objects for each, and the evidence that usually satisfies it. Read each row as a question the assessor will ask, then check whether your contracts and monitoring records answer it.
| Determination statement | Methods and assessment objects | Evidence an assessor expects | Common findings |
|---|---|---|---|
| Personnel security requirements, including roles and responsibilities, are established for external providers | Examine: procedures addressing external personnel security, the list of personnel security requirements, acquisition documents | Documented requirements with named owners for each external provider or service category, linked to contract terms | Requirements exist only in contracts, or roles for the provider and the organization are not defined |
| Personnel security requirements are documented | Examine: procedures addressing external personnel security, the list of personnel security requirements | A current, versioned requirements list approved by the responsible owner and reviewed on a defined cycle | Requirements list is outdated or does not match the procedures |
| External providers are required to comply with organizational personnel security policies | Examine: acquisition documents. Interview: external providers and organizational personnel with account management responsibilities | Signed contract clauses or onboarding attestations that reference the organization's personnel security policies | Policies are not referenced in contracts, or providers say they were never told which policy applies |
| External providers notify defined personnel within a defined time when staff with credentials, badges or privileges transfer or leave | Examine: acquisition documents and requirements list. Interview: external providers and account managers. Test: notification processes | Notice clauses with a defined recipient and notice period, plus sample notices showing timely delivery | No notice period is defined, the recipient is unnamed, or notices arrive after access has been used |
| Provider compliance with personnel security requirements is monitored | Test: organizational processes for managing and monitoring external personnel security. Interview: account managers | Periodic compliance reviews, access reviews of provider accounts and records of follow-up on exceptions | Monitoring is informal, provider accounts are never reviewed, or exceptions have no recorded owner |
How to implement PS-7 step by step
The sequence below turns PS-7 from a policy statement into working control: requirements defined, written into contracts, a notice path that works in practice, and provider compliance checked on a schedule. Each step names the record it leaves behind for an assessor.
Define external personnel security requirements and roles
Start by listing which external providers have staff who hold credentials, badges, or privileges to your systems or facilities. For each provider type, the personnel security owner and the system owner agree on the screening, training, and acceptable use expectations that match your organizational personnel security policy, and they name who on each side is responsible for what. Done means a requirements document exists, is approved by the accountable owner, and assigns roles to named functions rather than to individuals who may change.
Write requirements into contracts and acquisition templates
Move the approved requirements into the contract, statement of work, and standard acquisition templates so every new provider inherits them. Clauses should cover compliance with your personnel security policies, the obligation to notify defined recipients when covered staff transfer or leave, and your right to review provider compliance. Legal and procurement own the wording. Done means the clauses appear in the template and in the contracts for existing providers, and you can point to the signed agreement for each in-scope provider.
Set the notice window and the notification recipients
PS-7 requires the provider to notify defined personnel within a defined time when covered staff transfer or leave, so you must set both values yourself. Decide the notice window for each provider tier, and list the recipients, typically the system owner, the account management function, and the facilities contact for physical access. Confirm the window with the provider during contract negotiation, since the provider cannot meet a window it has not accepted. Done means the window and recipient list are written into the requirements document and the contract, with a named contact at each provider.
Build the notification and access removal path
Connect the provider notice to the action that removes access. Notices arrive by a defined channel, such as a ticket queue or a monitored mailbox, and the account management team disables accounts, revokes badges, and removes group memberships. Where the provider's staff hold accounts in your identity system, a provisioning tool such as authentik's SCIM provider can deprovision them from target applications when they lose access in the source, which reduces reliance on manual steps. Confirm each connector's behavior in your environment before you rely on it. Done means a test notice produces a closed access-removal record with timestamps.
Record provider staff and their access entitlements
Keep a current register of which provider staff hold which credentials, badges, and privileges, linked to the provider and the sponsoring internal owner. An identity directory such as FreeIPA can hold users, groups, and hosts with delegated administration, so the register is generated from system state rather than typed by hand. Review the register against the contract list so that no provider account exists without a contract and a sponsor. Done means the register reconciles with the access system and each entry has a provider, a sponsor, and a review date.
Monitor provider compliance on a defined schedule
PS-7 requires provider compliance to be monitored, so set the method and frequency in the requirements document. Monitoring usually combines reviewing notices received against the window, checking that the access register matches active provider staff, and collecting provider attestations or audit results where the contract allows. Access certification campaigns in a tool such as midPoint let designated reviewers decide whether to keep, change, or revoke each provider entitlement within a set timeframe, which also limits access accumulation. Done means each review produces a signed monitoring record with findings and any corrective actions.
Review provider performance and update requirements
Feed monitoring findings back into the process. Late notices, orphaned accounts, or repeated corrective actions should trigger a review of the provider's contract terms, the notice window, or the access model. Update the requirements document and contract templates when the review changes them, and record the change and its approver. Done means the requirements document shows a revision history, the findings have a disposition, and the next review date is recorded for each in-scope provider.
How self-hosted identity tools show that provider access ends
PS-7 asks for proof that an external provider's access ends when the provider's staff leave or change roles, and that someone in the organization checks this. Self-hosted identity tools can produce that proof when provider accounts are managed from one central source rather than created by hand in each application. The core idea is simple: if the directory is the only place accounts are created, every removal in the directory has a timestamped record and a downstream effect that can be shown to an assessor. FreeIPA is a candidate for that central source. It uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups and hosts, and it provides centralized access control with delegated administration through its web UI and command line tools. Delegated administration matters for PS-7 because the organization can let a provider's sponsor manage only the groups they own, while the organization keeps the authority to set the rules. authentik can then push identity changes from its own directory to downstream applications. Its SCIM provider sends user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions a user when they lose access to the application. Confirm in your own test environment that the hourly sync interval and the deprovisioning behavior match the window your PS-7 requirement sets, and retain the sync logs as evidence. Access certification closes the loop. midPoint campaigns have designated reviewers decide within a timeframe whether to keep, change or revoke access items such as role assignments, which gives the organization a dated record that someone reviewed each provider's access. The review period is a decision you set, not a value the tool supplies, so document it in your policy and make the reviewers the people who sponsor provider work. These tools do not notify providers or staff about transfers or departures, and they do not decide who must be told. The notice obligation remains a contract and process matter, so confirm with your contract owner and your implementation partner how notices are triggered and recorded before relying on any tool for that part of PS-7.
Evidence that passes a PS-7 review
A PS-7 review tests whether external providers are governed as carefully as employees. The artifacts below connect the written requirements, the contracts that enforce them, and the records that show providers followed them. Each one needs a named owner and a refresh routine, because a snapshot taken the week before an assessment rarely survives scrutiny.
Documented external personnel security requirements
This is the written standard that defines roles, responsibilities and the personnel security expectations for external providers, such as screening, access limits and notice duties. Assessors examine it against the organization's own personnel security policy and the PS-7 requirement. Check that it names an owner, states the review cycle, and lists which provider roles it covers, including service bureaus and contractors with privileged access. Confirm the version history shows review after each significant change in provider relationships.
Contract and acquisition clauses
Contracts and acquisition documents are where the requirements become enforceable. Assessors look for clauses that require provider compliance with the organization's personnel security policies, define a notice window for staff transfers and departures, and grant the right to monitor compliance. Ask legal and procurement to confirm that existing agreements carry these clauses, and track which contracts predate the requirement so renewals close the gap.
Provider notice records with timestamps
When a provider reports that a person holding a credential, badge or privilege has transferred or left, the notice is evidence that the defined window was met. Keep the notice itself, the time it was received, the recipient, and the time the related access was changed. Gaps between notice and action are the findings assessors look for. Confirm that the notice channel is monitored outside one person's inbox, and that records are retained for the period your policy sets.
Deprovisioning logs from identity systems
Logs from the identity provider or directory show whether external accounts were disabled, group memberships removed and downstream applications updated. A SCIM-based provisioning connector, for example, can record creations, changes and deletions pushed to target applications. Check that logs record the source event, the actor or automation, and the target system. Test a sample of provider departures against these logs before the assessment, and keep the query you used so the sample can be reproduced.
Access certification results
Periodic access reviews show that the access held by external users is still needed and approved. Each campaign should record the reviewer, the decision to keep, change or revoke, and the deadline. Assessors check whether revocations were carried out and whether reviewers were independent of the access they approved. Keep the campaign definitions, reviewer assignments and completion reports, and confirm which external populations each campaign covers.
Periodic provider compliance reviews
PS-7 requires that provider compliance be monitored, so assessors expect a dated record of reviews against the requirements. A review should cover screening status, training acknowledgments, notice performance and findings from any access certification. Record each finding, the provider's response, the corrective action and its closure date. Between audits, schedule the reviews on the calendar, assign a reviewer for each provider, and retain the completed checklists alongside the contract file.
What meeting PS-7 costs in money and effort
This table breaks down the cost and effort components of meeting PS-7 for external providers, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none are supplied for this control, so use it to build a written scope and request a quote that prices each line separately.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives the cost |
|---|---|---|---|
| Contract and procurement review | Internal procurement, security and legal staff | One-time per contract, plus renewals | Number of providers, contract complexity and how many agreements already carry personnel security terms |
| Legal drafting of provider requirements | Internal or outside counsel | One-time, with periodic revision | Whether a standard clause set exists, and how many provider categories need different terms |
| Identity tooling or licenses | Software vendor if commercial, or none for self-hosted open source | Licenses recur if commercial; open-source software removes license spend but not labor | Number of systems the provider can reach and whether deprovisioning is automated or manual |
| Integration engineering | Internal platform team or an implementation partner under a fixed-scope agreement | One-time build, with recurring upkeep as systems change | Number of target applications, directory integrations and whether provisioning events flow automatically |
| Notice window and transfer workflows | Internal HR, provider managers and security operations | Recurring per transfer or termination event | How strict the defined notice window is, and whether providers notify through a single channel |
| Provider compliance monitoring | Internal control owners, with external reviewers if sampled | Recurring, usually tied to review cycles | Number of providers, frequency of reviews and whether access reviews are automated |
| External review or testing | Independent assessor or testing firm, if the organization engages one | Periodic, per review or engagement | Scope of provider access, sensitivity of systems and depth of testing requested |
| Auditor sampling and evidence requests | Independent auditor, paid by the organization | Recurring per assessment cycle | Number of providers sampled, quality of records and how quickly evidence can be produced |
Who owns PS-7: your team, a partner and the auditor
Your organization owns PS-7. The control asks you to establish personnel security requirements for external providers, including roles and responsibilities, to require provider compliance with your personnel security policies, to receive notice when provider staff with credentials, badges or privileges transfer or leave, and to monitor provider compliance. Those decisions sit with your security, legal, procurement and system owner functions, and no partner can make them for you.
- Requirements and roles: Define which provider roles need personnel security conditions, which screening or training they must meet, and who in your organization is accountable for each provider.
- Contract terms: Put the requirements, compliance duties and notification deadlines into contracts, statements of work and acquisition documents so they are enforceable.
- Notice channels: Name the internal personnel who receive transfer and termination notices from providers, and set the time window in writing.
- Monitoring decisions: Decide how often provider compliance is reviewed, what evidence you request and what happens when a provider falls short.
- Accountability: Keep the list of external accounts, their sponsors and their access, and approve changes to it.
Before relying on any partner, confirm that your own contract, notice and monitoring procedures exist and are signed off, because assessors examine those documents first.
An implementation partner prepares the systems and evidence that make PS-7 testable. In a self-hosted environment this usually means connecting identity sources to the systems external staff use, automating account lifecycle actions and collecting records that show what happened. The partner does not decide policy, sign provider contracts or certify that your controls operate.
- Identity integration: Configure directories and provisioning so that external accounts, groups and privileges can be traced to a sponsor and a provider. Open-source options such as authentik's SCIM provider, which deprovisions users from target applications when they lose access, can support this work once confirmed for your environment.
- Directory design: Set up centralized accounts and delegated administration in directories such as FreeIPA so provider access is visible in one place.
- Certification campaigns: Configure access review campaigns, for example in midPoint, so designated reviewers can keep, change or revoke provider access on a schedule you set.
- Evidence packs: Export provisioning logs, review records, notice correspondence and configuration exports into a package the assessor can examine.
- Documentation: Write the runbooks and system descriptions that explain how the tooling supports each requirement.
Before engaging a partner, ask for a written scope listing each system, deliverable and evidence item, because that list defines what they are responsible for.
An independent auditor or assessor tests whether PS-7 is implemented and operating. Under NIST's assessment approach in SP 800-53A, the assessor examines documents, interviews people and tests processes. DeployOpen does not issue audit reports, attestations or certifications. Only the independent assessor, or the body that issues the authorization or certificate your contract requires, can make that determination.
- Examine: Review procedures for external personnel security, the list of personnel security requirements and the acquisition documents that carry them.
- Interview: Speak with external providers and with internal staff who manage accounts, to confirm the process matches the documents.
- Test: Sample provider onboarding, transfer and termination events, and check that notices and access changes happened within the defined timeframes.
- Independence: Choose an assessor that did not design the controls it tests, so the conclusions carry weight with your customers and regulators.
- Scope limits: Agree in advance which systems, providers and periods the assessor will cover.
Before hiring an assessor, confirm which report or certificate your contract or regulator actually requires and whether the assessor is accepted by that party.
Where PS-7 programs usually fall short
PS-7 is rarely missing from paper. It fails in the handoffs between the organization and its external providers: what the contract says, how fast a provider must report a departure, who receives that notice, and whether anyone checks compliance afterward. The cards below cover the gaps assessors most often find and the fix for each.
Requirements missing from contracts
The personnel security requirements for contractors often live in an internal policy that the provider never signed. PS-7 expects requirements, including roles and responsibilities, to be established and documented, and expects providers to comply with the organization's personnel security policies. Check that the statement of work or master services agreement names the screening, training and access rules that apply to provider staff, and that acquisition documents point to them. Ask the provider to confirm in writing which policies bind its people.
No defined notice window
PS-7 requires providers to notify defined personnel within a defined time when staff holding credentials, badges or privileges transfer or leave. Many programs state that notice should be prompt but never set a number, so an assessor cannot test it. Set a specific window for each class of access, such as privileged accounts versus general application users, and write it into the contract. Confirm that the window is measured from the staff change, not from when the provider finally sends the message.
Notices with no owner
Provider notices of departures often arrive as an email to a shared mailbox or to whoever answered the original request. Nobody is accountable for revoking the access, so accounts stay active after the notice is read. Name a single internal owner and a backup for each provider, route notices to a ticket queue with a timestamp, and record the date the access was removed. Assessors look for that record when they interview account managers.
Provider accounts outside the identity source
When provider staff hold local accounts in applications, deprovisioning depends on someone remembering to delete them. An identity provider that is the single source of truth lets the organization disable a provider account in one step and push the change to connected applications. With authentik, the SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and runs a full sync every hour. Confirm which applications are excluded from that sync and why.
No periodic compliance monitoring
Signing a contract does not show that a provider still follows the screening and notice rules a year later. PS-7 requires provider compliance to be monitored, and assessors test whether the organization actually does it. Schedule reviews of provider rosters against the directory, sample recent offboardings for timely notice, and record exceptions in a plan of action. midPoint access certification campaigns can route provider access items to designated reviewers who decide within a set timeframe whether to keep, change or revoke them.
Questions buyers ask about PS-7
How much effort does PS-7 take to implement?
The effort depends on how many external providers hold credentials, badges or privileges in your environment and how many contracts already carry personnel security terms. PS-7 has five parts: documented requirements, provider compliance with your personnel security policies, notice of staff transfers and departures within a defined time, and monitoring of provider compliance. Most of the work is in the first and last parts, because they require someone to inventory providers, decide which requirements apply to each, and keep evidence that monitoring happens. Ask any consultant to break their quote into inventory, requirements drafting, contract updates, notification workflow and monitoring setup, so you can see where the hours go.
Can we meet PS-7 in-house without an outside partner?
Yes, if you have people who can write personnel security requirements, read your contracts and run a monitoring routine. The organization owns its controls, so an in-house team can do all of it. An outside implementation partner can help by preparing the identity workflows, documenting requirements in a form assessors can follow and building the evidence trail, but it does not replace your ownership or your assessor. Only an independent assessor can issue an assessment result. Decide early which parts your staff will own, such as provider notifications and quarterly reviews, and which parts you want help with, such as directory integration.
What do contract and HR teams need to do for PS-7?
Contract teams need to add personnel security terms to external provider agreements, including the security requirements providers must meet, a duty to comply with your personnel security policies and a duty to notify defined personnel when credentialed staff transfer or leave. HR or the staffing owner needs a reliable way to learn about provider staff changes. Procurement should record which providers are in scope so the list stays current. Ask legal to confirm that the notice period you define is enforceable in each contract, and ask your assessor which contract language they expect to see. Existing agreements may need an amendment, which can take longer than the technical work.
How long does PS-7 take to implement?
The duration depends on scope: how many providers you have, how many contracts need amendment, whether a notification process already exists and how many systems your providers can reach. NIST does not set an implementation timeline for PS-7, and no duration is set here. Ask any partner for a timeline tied to a written scope, and ask them to list the dependencies that could extend it, such as contract amendments, provider responses and directory integration. Monitoring is recurring, so plan for a steady workload after the first implementation.
Do open-source tools satisfy PS-7 by themselves?
No tool satisfies PS-7 on its own, because the control depends on documented requirements, contract terms, notification practice and monitoring that people carry out. Open-source tools can produce part of the evidence. For example, authentik's SCIM provider pushes user and group changes and deprovisions users from target applications when they lose access, and midPoint access certification campaigns have designated reviewers decide within a set timeframe whether to keep, change or revoke access. FreeIPA can hold provider accounts in a central directory with delegated administration. Confirm each tool's current capabilities in your own environment before you rely on it.
What will an auditor ask for to test PS-7?
Assessors follow the SP 800-53A procedure for PS-7, which examines documented procedures, the list of personnel security requirements and acquisition documents, interviews external providers and account management staff, and tests the processes used to manage and monitor external personnel. Expect to be asked for the requirements document with roles and responsibilities, the provider list, signed contract clauses, examples of provider notifications about transfers or departures, records of compliance monitoring and evidence of corrective action when a provider falls short. Ask your assessor to confirm the exact evidence list before you collect it.
How DeployOpen scopes and prepares PS-7 evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the access and offboarding records for external providers can be produced from systems you control. We prepare the systems, documentation and evidence for PS-7, while your organization owns the policy, the provider agreements and the decisions about who is accountable.
How we scope
- We confirm which external providers hold accounts, credentials, badges or privileges in your environment before work starts.
- The written scope names the PS-7 requirements, roles and notification windows that your organization defines and approves.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins. Ongoing support is available as a retainer.
How we build
- We configure identity sources so provider accounts can be created, changed and removed from a single authoritative record.
- We set up automated deprovisioning to target applications so access ends when a provider's staff leave or transfer.
- We configure access certification campaigns so designated reviewers confirm or revoke provider access on a schedule you set.
How we hand over
- We document how provider access is requested, approved, reviewed and removed, mapped to the PS-7 assessment objects.
- We deliver sample evidence exports, such as account change logs, campaign results and deprovisioning records, for your assessors to examine.
- We walk your staff through the runbooks so your organization can operate the controls and produce evidence without us.
How we support
- We test the provider access workflows and record gaps in a plan of action that your organization owns and prioritizes.
- We update configurations and documentation when provider contracts, applications or identity sources change.
- Independent auditors and assessors examine your controls and issue their own reports. DeployOpen prepares the systems and evidence only.
