PS-3 Personnel screening: requirements and evidence

What PS-3 personnel screening requires before anyone gets system access

PS-3 requires the organization to screen individuals before it authorizes them to access a system, and to rescreen them under defined conditions and, where rescreening applies, at a defined frequency. If an audit, a contract or an authorization package cites PS-3, the assessor will look for two things: a documented screening step that happens before access is granted, and a rule that says when a person is screened again. The control does not prescribe the screening itself. The organization decides what checks apply, which positions need them and what triggers a rescreen, and it must write those decisions down. Those choices are tied to the risk designation of each position under PS-2, so the criteria for a systems administrator and for a help desk agent will often differ.

The risk PS-3 addresses is simple to describe and hard to run: someone with an unsuitable background or changed circumstances gains access to information or systems they should not have. The control is difficult in practice for two reasons. First, screening records are often scattered across HR, a background check vendor and hiring managers, so an assessor asking for the screening record of a specific account holder gets several partial answers. Second, screening is usually owned by HR and has no link to the identity system, so an account can be provisioned before the screening result exists. Closing that gap means agreeing a single owner, a required screening status before an account is created and a shared list of rescreen triggers that HR and the access owners both see.

The baselines matter for scope. SP 800-53B allocates PS-3 to the low, moderate and high baselines, and it is not part of the privacy baseline, so a system categorized only for privacy purposes does not inherit it. The catalog defines four enhancements for PS-3, covering classified information, formal indoctrination, special protective measures and citizenship, but none of them is allocated to an SP 800-53B baseline, so they apply only where the organization or a specific authorization adds them. Confirm with your authorizing official or contracting officer which baseline the system is held to and whether any enhancement has been added by tailoring or by an overlay.

Which people, positions and systems PS-3 applies to

PS-3 is not one screening check applied to everyone. The scope comes from three inputs: the risk designation of each position, the type of worker filling it, and the impact level of the systems they can reach. The cards below cover those decisions and the related controls that feed them, so the screening work follows the scope rather than the org chart.

Positions set by PS-2 designations

PS-3 screening criteria depend on the risk designation that PS-2 assigns to each organizational position. Start by confirming that every position has a designation, that the designations are current, and that roles with privileged access are not left at a default level. A position that holds administrator rights to a moderate-impact system should not inherit the screening of a general staff role. Ask who owns the designation list and when it was last reviewed.

Employees versus contractors and service staff

Employees are usually screened through the organization's own hiring process, but contractors, managed service staff and vendor engineers often reach the same systems through a different chain. Under PS-7, the external provider must meet the organization's screening requirements, and the organization must monitor that compliance. Check whether the contract requires the provider to screen its staff, and whether the organization receives notice when a worker transfers or leaves.

Privileged and non-privileged users

Privileged users, such as system administrators, security staff and database owners, carry the greatest access risk and usually need the most thorough screening and rescreening. Non-privileged users may need a lighter standard, but the boundary has to be defined in writing. Map privileged roles through AC-2 account management so that each privileged account traces back to a designated position. Accounts with no clear owner are a common gap to check first.

Systems at low, moderate or high impact

SP 800-53B allocates PS-3 to the low, moderate and high baselines, so the screening requirement applies at every impact level. What changes is the depth of the surrounding controls and how many positions fall in scope. Confirm the impact categorization of each system, because a position's designation should reflect the most sensitive system it can reach. The privacy baseline does not include PS-3.

Maintenance and remote support personnel

Personnel who perform maintenance, including vendors who service hardware or remote staff who log in for support, are a scoping question that is easy to miss. MA-5 addresses maintenance personnel and requires the organization to control who performs maintenance and to check their authorization. Build a list of maintenance accounts and third-party support paths, then confirm that each one is either screened or covered by an external provider requirement.

Physical access and sensitive facilities

Staff who enter data centers, server rooms or facilities holding system components may need screening even when their logical access is limited. PE-2 covers physical access authorizations, and its list of authorized individuals should match the positions that PS-3 has screened. Check for badge holders, cleaning contractors and visitors who are authorized for areas where systems are exposed.

Program-wide and acquired services

PM-12 sets insider threat program expectations across the organization, and SA-21 addresses developer screening for systems and components that the organization acquires or builds. Both feed PS-3 scope because they name roles outside the standard employee population. Confirm whether developers of acquired software and members of an insider threat program are already on the designation list, and avoid screening the same people twice under different records.

How PS-3 connects to position risk designation and account provisioning

PS-3 is the point where a screening decision becomes an access decision, and it only works if the chain before it is intact. PS-2 sets the risk designation for each position and the screening criteria that go with it. PS-3 then requires that the person filling that position is screened against those criteria before they are authorized to access the system, and rescreened under the conditions and frequency the organization has defined. If PS-2 is vague, PS-3 has nothing consistent to test against, so a reviewer will usually start by reading the position list and the designations attached to each role before looking at any individual file.

The next link is the account. AC-2 governs how accounts are requested, approved, created, modified and removed, and IA-4 governs how identifiers are assigned and managed. Together they determine which system identity a screened person actually holds. A screening record is only useful if it can be traced to a specific account identifier, the approval that created that account, and the role or position that approval was based on. Assessors follow that thread in both directions: from a sample of accounts back to a completed screening, and from a sampled screening back to the account it authorized. A screening that cannot be tied to an account leaves a gap, and an account with no screening record shows the control did not operate. Confirm with your HR and identity teams whether your identity provider or directory can hold a screening status attribute, and whether that field is populated before provisioning completes.

Access agreements under PS-6 belong in the same workflow. Where the organization requires signed agreements before access, the signature date should be recorded against the same account request as the screening outcome, so both preconditions are visible together at the point of grant. Ask your team to show one sample person end to end: the position and its designation, the screening completion, the signed agreement, the approved account request, and the first login. If any link must be reconstructed from email or memory, expect findings from the assessor, even where each individual control exists on paper. The NIST SP 800-53 Rev. 5 catalog lists these related controls together, which is a useful reminder that PS-3 is tested as part of a chain, not in isolation.

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

This table maps the three SP 800-53A determination statements for PS-3 to the examine, interview and test methods an assessor uses, along with the objects each method reviews. Read each row as one piece of the assessment, then check the evidence your organization can produce for it before the assessor asks.

Assessment method	What the assessor examines or does	Evidence that passes	Where it usually fails
Examine	Personnel security policy, procedures addressing personnel screening and records of screened personnel	Current policy and procedure documents with defined screening conditions and rescreening frequency, plus screening records linked to each individual and role	Procedures that omit rescreening triggers, or screening records that do not show the date relative to account creation
Interview	Organizational personnel with personnel security responsibilities, such as HR, hiring managers and system owners	Consistent answers on who is screened, when screening happens and what triggers rescreening, matching the written procedure	Staff who describe screening as a hiring step only and cannot explain rescreening or how position risk designations apply
Test	Organizational processes for personnel screening, run against a sample of recent hires and role changes	Walkthrough showing screening completed before system access was granted, with the assessor able to trace one sample from request to provisioning	Screening completed after access was granted, or access provisioned by a path that bypasses the screening check
Records check (common finding)	Whether defined rescreening conditions were applied to people who changed roles or gained higher-risk access	Rescreening entries with dates and reasons for each triggered case	Missing rescreening evidence, or rescreening conditions that were never defined by the organization
Identifier lookup	Where the assessor locates the control in the NIST reference tool	Assessment notes that cite PS-03 in CPRT and PS-3 in the organization's own documents, so both labels resolve to the same requirement	Mismatched identifiers between the policy, the SSP and the assessment workpapers

Implementing PS-3 in sequence

This sequence turns PS-3 from a policy statement into a working control: screening criteria tied to risk designations, rescreening rules the organization sets for itself, access gated on a screening record, and retained evidence that an assessor can sample. Each step closes with an output the organization owns and can show.

Confirm PS-2 risk designations and screening criteria
Start from the position risk designations the organization assigned under PS-2. The HR or personnel security lead and the system owner confirm which positions carry each designation and which screening criteria apply to each designation, such as the checks performed and who approves them. Confirm that every position with system access maps to a designation. The output is a signed designation register with screening criteria attached to each level, so an assessor can trace a person's screening back to the position they hold.
Define rescreening conditions and frequencies in policy
PS-3 requires the organization to define when rescreening happens and, where it applies, how often. Personnel security and legal or HR counsel write these conditions into the organization's own personnel security policy and procedures rather than relying on a default. Each condition should name the trigger, the positions it covers and the screening steps repeated. The output is an approved policy section with defined conditions and frequencies, which the assessor will examine against the PS-3 determination statements.
Gate account provisioning on a screening record
Connect the identity process to the screening process so that no account is provisioned before screening completes. The identity administrator and the personnel security lead agree on the handoff: the provisioning ticket or workflow refers to a screening completion record, and the request is rejected if that record is missing or expired. Test the gate with a sample of new requests, including one that lacks a record. The output is a documented provisioning workflow and test results showing the gate blocks access before screening is complete.
Set rescreening triggers for role changes and cycles
Configure the events that start rescreening. Role changes into a higher designation, transfers into sensitive positions and the periodic cycle the organization defined should each generate a task for the personnel security team. Where an HR system or identity platform can emit these events, connect them to the screening queue so triggers are not missed. Confirm with HR which events they report and how quickly. The output is a trigger map listing each event, its source system and the rescreening task it creates, plus a sample of triggered tasks.
Set up records retention for screening evidence
Decide where screening records live, who can read them, how long they are kept and how they are protected. Records should show the position, designation, criteria applied, date of completion, the person who approved the result and any rescreening dates. Legal or HR counsel should confirm retention periods against applicable law, since NIST does not set them. The output is a retention schedule and access rule for screening records, with a restricted repository in which assessors can find the records without exposing unnecessary personal data.
Run a sampling review before the assessment
Before an assessor arrives, the organization tests its own program on a sample of people with system access. Pick individuals across designation levels and recent role changes, then check that each has a screening record that meets the position's criteria, that rescreening occurred when a trigger fired and that the provisioning date follows the screening date. Record exceptions and track them in the plan of action and milestones. The output is a dated sampling report with exceptions and corrective actions, which shows the assessor that the control operates, not only that it is documented.

Screening evidence that passes an assessment

An assessor testing PS-3 will ask for proof that screening happened, that it happened before access was granted, and that it repeats on schedule. The cards below cover the artifacts that answer those questions, and the upkeep that keeps them accurate between assessments. Your organization owns these records; DeployOpen can help design and assemble them, but only the independent assessor reaches a conclusion on them.

Screening policy and procedures

The written policy states which positions require screening, who performs it, and what the organization does with results. The procedures describe the steps HR and security follow for each screening type, including who approves exceptions. Assessors examine both documents against the PS-3 determination statements, so each procedure should name an owner and a review date. Confirm with your policy owner that the document lines up with the position risk designations under PS-2, since screening criteria flow directly from those designations.

Screening criteria matrix by risk designation

A matrix maps each risk designation to the screening checks required for positions at that level, such as identity verification, criminal history, or credit review where the role justifies it. Assessors use it to test whether the organization screened people according to their role rather than applying one check to everyone. Keep the matrix versioned and link each row to the position descriptions it covers. Ask counsel which checks are lawful in each jurisdiction where you hire.

Screening records linked to user IDs

A completed screening record shows who was screened, the date, the check performed, the outcome and the adjudicator. Linking each record to the directory or identity provider account proves the person screened is the person who holds access. Store results in a system with restricted read access, since these records contain sensitive personal information. Reconcile the record set against active accounts at each review so that no active account lacks a matching screening entry.

Provisioning gate record

A provisioning gate record shows that screening was completed before access was granted. Assessors look for the timestamp of the screening outcome earlier than the timestamp of the account creation or role assignment. In practice this means the provisioning workflow checks for an approved screening record before it creates the account. Export the workflow log for a sample of new hires and contractors to demonstrate that the gate operated, and document any path that bypassed it.

Rescreening schedules and completed rescreens

The organization defines the conditions that trigger rescreening and, where it applies, the frequency. The schedule lists each person or role due for rescreening, and the completed rescreen records show the check was actually performed on time. Assessors compare the schedule to the records and look for gaps. Confirm the triggers and frequencies with your policy owner and make sure they match what the organization wrote in its procedures.

Exception approvals

Exceptions cover cases where a person accesses the system before screening completes or where a check cannot be performed. Each exception should record the justification, the compensating measures such as supervised access, the approver with authority to accept the risk, and an expiry date. Assessors test whether exceptions are rare, approved and closed. Review open exceptions at each rescreening cycle, and confirm with counsel how exception records are retained alongside screening records.

PS-3 enhancements for classified information, indoctrination and citizenship

The PS-3 enhancements extend basic personnel screening to classified information, formal indoctrination, special protective measures and citizenship. Release 5.2.0 of SP 800-53 defines four active enhancements for PS-3, and none of them is allocated to a SP 800-53B baseline. In practice this means the base control, which applies at the low, moderate and high baselines, is the requirement most systems must meet, while the enhancements apply only where an agency, contract or program explicitly invokes them. A system that handles no classified material and no special access program may never need to implement any of them.

Because the enhancements are conditional, the first task is to find out which ones your authorizing body or contract actually calls for. Ask the authorizing official, the contracting officer or the program security office to name the enhancements in writing, and record the answer in the system security and privacy plan so the assessor tests the same scope you implemented. Do not work from a summary or a secondary blog post. Pull the exact wording of each enhancement from the official NIST CPRT catalog for PS-03 or from the OSCAL catalog, because paraphrased requirements tend to drift from what an assessor will test against.

Once the scope is confirmed, check whether your organization already has the records the enhancements would require, such as indoctrination or access briefing records, citizenship verification records and special protective measure approvals, and confirm who owns each process. Where these records do not exist, a fixed-scope readiness review can identify the gap before an assessment starts. Any hypothetical example is illustrative only: a contractor that is asked to add an enhancement mid-contract should expect the screening workflow, the HR system and the access provisioning process to change together, not just the policy document.

What meeting PS-3 costs in money and effort

This table lists the cost components of PS-3 screening, who gets paid for each, whether the cost is one-time or recurring, and what pushes it up or down. Use it to build a request for quote, since NIST does not estimate compliance costs and no supplied figure gives a price for any component.

Cost component	Who is paid or who does the work	One-time or recurring, and what drives it
Background check services	Screening vendors, paid per check, often through the organization's HR or procurement team	Recurring. Driven by the number of screened positions, rescreen frequency and whether checks cross borders
International and clearance-level checks	Specialist vendors or government sponsoring agencies, where the organization is charged per request	Recurring and higher per check. Driven by foreign residency, clearance levels and citizenship requirements in PS-3 enhancements
Criteria and rescreen trigger design	HR, security and legal staff, often with an outside consultant hired for a fixed scope	One-time for the initial design, with periodic updates. Driven by the number of risk designations defined under PS-2
Provisioning and identity integration	Platform or integration engineers, internal or from an implementation partner	One-time build, then recurring maintenance. Driven by how many systems read screening status before granting access
Records upkeep	HR and security staff who keep screening records, dates and rescreen due dates current	Recurring. Driven by headcount turnover and how much of the record process is automated
Assessor sampling and evidence preparation	Staff who pull screening records for the assessor, and the independent assessor who samples them	Recurring at each assessment cycle. Driven by sample size and whether records are retrievable on request
Open-source record and gating tools	Internal platform team; self-hosted software carries no license fee, but hosting and operations still need staff time	Mostly one-time setup, then recurring operations. Removes license spend, not background check spend
Quote requests	Ask each vendor and consultant for a written scope covering checks per year, countries, rescreen cycles and records format	Confirm each figure in writing before budgeting, because NIST does not publish PS-3 cost estimates

Who owns screening, who can help, and what the auditor checks

Your organization owns PS-3 in full. Screening is a personnel decision, so the policy, the criteria, the screening decisions and the records all belong to you. An assessor will ask for the people who hold these responsibilities and will expect them to explain how the process works in practice, not only what the document says.

Screening policy and criteria: Define which screening is required for each position, based on the risk designations you assign under PS-2, and document the conditions that trigger rescreening and its frequency.
Screening decisions: Human resources, legal and the hiring manager decide whether an individual is screened to an acceptable standard and whether they may be granted access.
Background check providers: You select and contract any screening vendor, confirm it meets your legal and labor obligations, and keep the results under your control.
Records: Keep records of screened personnel, including dates, the screening performed and the authorization decision, in a form an assessor can sample.
Enhancements: If classified information, formal indoctrination or special protective measures apply, your security office sets those requirements.

Before an assessment, confirm that a named owner can walk an assessor from the position risk designation through to a granted account.

Where PS-3 programs usually fall short

PS-3 looks simple on paper: screen people before they get access and rescreen them under defined conditions. In practice, the gaps sit in the handoffs between HR, the security team, system administrators and external providers. The cards below cover the failure points an assessor is most likely to find, each with a closing action you can check in your own environment.

Screening after provisioning

Accounts are often created when a hiring manager submits a ticket, while screening finishes days or weeks later. PS-3 asks that screening come before authorization to access the system, so the gap is a sequence problem, not a missing check. Confirm that your provisioning workflow holds the account request until the screening result is recorded, and that exceptions have a named approver.

Screening records not tied to accounts

Many organizations screen people through HR but never connect that result to the identity that holds access. When an assessor samples an account, the team cannot show which screening result supports it. Check that each identity record in your directory carries a screening status or reference, and that someone can trace a privileged account back to its screening record in one step.

Undefined rescreening conditions

PS-3 requires rescreening under conditions the organization defines and at a frequency it sets. Many programs say only that rescreening occurs periodically, with no triggers such as a change to a sensitive role, a new clearance need or a reported concern. Write the conditions and frequencies into your personnel security procedure, then confirm that HR and IT both have a way to act on them.

Contractors left out of PS-7 coordination

Contract staff often receive system access through a provider's onboarding, and the buyer never sees their screening evidence. PS-7 covers external personnel, so the screening requirement and the provider's notice obligations for staff changes belong in the same agreement. Ask each provider for its screening process, the evidence it will supply, and how it will notify you when a contractor leaves the engagement.

Criteria that ignore PS-2 designations

PS-2 assigns a risk designation to each position, and PS-3 screening criteria should follow from it. Programs frequently apply one screening level to every employee, which either over-screens low-risk roles or under-screens privileged ones. Compare your screening matrix against the current position designations, and flag any privileged or administrative role that is screened at the same level as a general user role.

Records kept in unsecured spreadsheets

Screening results often live in a shared spreadsheet with broad read access, no version history and no retention rule. An assessor examining records of screened personnel will expect the records to be complete, protected and retrievable. Move screening evidence into a restricted system with access logging, record who can view it, and confirm that the retention period matches your HR and legal requirements.

Questions buyers ask about PS-3 screening

What does PS-3 screening cost and what drives the price?

No supplied fact gives a price for PS-3, and DeployOpen does not publish one, so the figure follows from a written scope. Most of the cost sits in the organization's own staff time and in the screening services it buys. The main cost components are: HR time to define screening criteria per position risk designation, fees paid to background check providers for each screened individual, legal review of consent and retention language, and implementation effort to record screening status in the systems that grant access. Costs recur when people are rescreened or when new roles are added, and they rise with the number of positions, the depth of checks and the number of jurisdictions involved. Ask any provider for a quote that separates one-time setup from per-check and recurring fees, and state which checks are included.

How long does PS-3 implementation take?

The supplied facts do not give a duration for PS-3 work, so confirm timing against your own environment rather than a published figure. Elapsed time depends on how many roles already have defined risk designations, whether screening criteria exist in writing, how many personnel and contractor populations need screening, and how quickly your HR and legal teams approve the screening language. Technical work to link screening status to account provisioning is usually smaller than the policy and process work. A fixed-scope engagement agrees deliverables and timelines in writing before work starts, so ask for that schedule with its dependencies listed.

What does PS-3 need from HR and IT?

PS-3 cannot be met by IT alone, because screening decisions depend on HR records and on position designations. HR typically owns the screening criteria, consent collection, the screening process for new hires and transfers, and the rules for rescreening. IT owns the link between a screening result and access: provisioning should not grant system access until screening is recorded as complete for the role. Both teams need a shared record of who was screened, when, against which criteria and when the next screening is due. Legal or privacy staff usually review consent wording and retention periods, since screening data is personal data.

Can our team implement PS-3 in-house?

Yes, many organizations do, provided they have an HR owner for screening, a documented set of criteria tied to position risk designations and an identity or provisioning process that can hold a screening status. The work is mostly procedural, so the main risk is inconsistency rather than technical difficulty. An outside implementation partner can help with the technical gating, such as blocking account creation until a screening flag is set, and with evidence collection. Only an independent assessor can test the control and issue an assessment result. Decide which parts you will keep internal and write that split into the scope before you compare providers.

Can screening data be stored on a self-hosted platform?

Screening records can be kept within your own infrastructure, which matters because screening results are sensitive personal data. A self-hosted identity or HR system can hold the screening status, the date of the last check, the criteria applied and the rescreening due date, with access restricted to the people who need it. Confirm with your legal and privacy team where background check reports may be stored, since many providers keep their own copies and retention rules vary by jurisdiction. Your own cloud account, data center or air-gapped network can host the records, and DeployOpen works inside those environments. Check each platform's audit logging and access controls against your requirements before you rely on it.

What will an assessor sample when testing PS-3?

Under SP 800-53A, an assessor examines the personnel security policy and the procedures for screening, examines records of screened personnel, interviews the people who run screening, and tests whether the screening process works as written. In practice the sample usually covers recent hires, transfers into sensitive roles and contractors with system access. For each person sampled, expect to show the risk designation of the position, the screening criteria applied, the date of the screening and proof that screening was completed before access was granted. Keep records complete and current so the sample can be pulled quickly. Only the assessor decides whether the control is satisfied.

How does PS-3 relate to PS-2 and PS-7?

PS-2 sets the foundation: each position receives a risk designation and the screening criteria that go with it. PS-3 then applies those criteria to the people who fill the positions, before access is granted and again under defined conditions. PS-7 covers external personnel, such as contractors and service bureaus, and requires the provider to meet your personnel security requirements, so PS-3 screening for those staff is usually written into the provider agreement. If PS-2 designations are missing or vague, PS-3 screening has no clear basis, so resolve PS-2 first. Map all three controls to the same roster so an assessor can follow one person from designation to screening to access.

What should we ask a provider before we sign for PS-3 work?

Ask for a written scope that lists the positions and populations covered, the screening steps in each, and which parts are performed by your staff. Request a deliverables list that includes the screening procedure, the records format, the provisioning gate and the rescreening schedule. Ask how the provider will leave you with evidence an assessor can examine, and which items remain your responsibility. Confirm what the provider does not do: DeployOpen prepares systems and evidence but does not issue audit reports or certifications, and independent assessors perform that role. Ask who will maintain the work after handover and what the support arrangement costs.

How DeployOpen prepares PS-3 evidence in your environment

DeployOpen's role in PS-3 is to build the technical and documentary machinery around screening, not to perform the screening itself. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it can configure provisioning gates in those platforms so that an account is not activated until your screening record for that individual is marked as complete. It can also design the evidence records that show this happened: a screening register keyed to each user identifier, timestamps for the screening decision and the rescreening due date, and a log of who approved the access. DeployOpen does not run background checks, does not decide whether a candidate is suitable for a role, and does not issue assessment reports or attestations. Those decisions stay with your HR, legal and security owners, and the assessment is carried out by your independent assessor.

Before any build starts, confirm with your HR and legal teams which screening conditions and rescreening frequencies your organization has defined for each position risk designation, because PS-3 expects those values to be set by the organization and the platform gates can only enforce what you have written down. Ask your assessor which examine and interview evidence they expect for the three determination statements in SP 800-53A, including the screening policy, the procedures and the records of screened personnel. Ask your screening provider how it returns results to you, so that the register can capture a result and a date without storing unnecessary personal data. These questions shape the scope.

DeployOpen works on a fixed-scope basis. The systems, the gate logic, the register fields, the evidence to be produced and the handover deliverables are agreed in writing before work begins, and a quote follows from that written scope. Ongoing support, upgrades and periodic testing of the gates can be covered by a retainer if you want them maintained after handover. Expect the quote to depend on how many systems are in scope, how many identity sources feed your provisioning, and whether the screening register must integrate with an existing HR system. Ask for those assumptions to be listed in the statement of work so you can see what changes the price.

PS-3 Personnel screening