SA-21 Developer screening: requirements and evidence

What SA-21 developer screening asks for and why it is hard to prove

If your system is categorized at the high impact level, or a contract requires SA-21, you must show that the people who develop the system or its components hold the access authorizations their assigned duties need and meet the additional personnel screening criteria you define. SP 800-53B places SA-21 only in the high baseline, and in Release 5.2.0 it carries 3 organization-defined parameters, so the control is only as specific as the values your organization sets for the developer population, the systems or components in scope and the screening criteria. Its one control enhancement is withdrawn, so you do not need to plan around enhancement-level requirements.

The control addresses supply chain risk that ordinary employee screening can miss. Developers of a system can insert weaknesses, backdoors or misconfigurations, and the people who have write access to code, build pipelines and configuration are part of that attack surface, whether they are employees, contractors or staff of an external integrator. The parameters you define determine which roles count, so a platform engineer with deployment rights and a contractor who maintains a custom module may both fall inside scope even if neither writes application code full time.

The difficulty is proof, not intent. Evidence sits in three places that rarely share a system of record: HR and background screening records, acquisition contracts that state the access and screening requirements, and engineering systems that show who held repository, pipeline or production access and when. SP 800-53A Release 5.2.0 asks an assessor to examine acquisition contracts, the list of required access authorizations, the screening criteria and related documentation, and system design documentation. Before you start, confirm with HR, procurement and engineering who owns each record, how long screening results are retained, and whether your identity provider can export a current list of developers with their granted roles, so that the assessor can trace each person from screening to access.

Which developers and systems SA-21 reaches in your environment

SA-21 applies only where an organization decides which systems, components and services count as sensitive and who builds them. Each scoping decision below changes who must be screened, which criteria apply and which related controls must agree with the result.

Defining sensitive systems and components

SA-21 is tied to defined systems, components or services, so the first decision is which ones the organization names. Start from the security categorization of each system and list the components whose compromise would affect confidentiality, integrity or availability. Record the list in the system security plan so an assessor can trace each developer back to a named system. An undefined or vague list leaves the control untestable, and an assessor will ask how the boundary was drawn.

Internal staff and employee developers

Employees who write, configure or modify a defined system fall within the developer population. For each group, confirm which access authorizations their assigned duties require, such as repository write access, build pipeline rights or production deployment privileges. Map those authorizations to roles so the list of appropriate access authorizations can be produced on request. Staff who only consume a system without changing it usually sit outside this population, but the boundary should be written down.

Contractors, offshore teams and third-party developers

Contractors and outsourced development teams are often the largest share of people who touch sensitive code, so their coverage must be explicit in acquisition contracts. Confirm whether the contract requires the same screening criteria as employees, who performs the screening, and whether the supplier must evidence it. Offshore teams raise the question of where screening records are held and which criteria can be applied across jurisdictions. Ask counsel to review these points before the contract is signed.

Organization-defined parameters set the criteria

SA-21 has organization-defined parameters that set which access authorizations and which screening criteria apply. The organization fills in these values, so they decide how much screening each developer role receives. Document each value with its rationale, tie it to the role and system it covers, and approve it through the governance process that owns the control. An assessor compares the documented values with what the organization actually does.

Related PS controls and personnel records

The screening itself lives in the personnel security family. PS-2 and PS-3 define position risk and screening, PS-6 covers access agreements, and PS-7 covers external personnel. Each one must cover the same developer population as SA-21, or the records will not line up at assessment. Confirm that position risk designations for developer roles match the systems they build, and that external personnel are captured in the same records.

Acquisition and supply chain controls

SA-4 and SR-6 are where SA-21 reaches suppliers. SA-4 requires security requirements in acquisition contracts, and SR-6 covers supplier assessments. Write the screening obligation into the contract, set the evidence the supplier must return, and state the right to review it. Where FedRAMP applies, SA-21 is also linked to its supply chain indicator for mitigating supply chain risk, so the supplier evidence should be reusable there.

How an assessor tests SA-21 under SP 800-53A

This table breaks down how an assessor works through SA-21 Developer screening under SP 800-53A, from the two determination statements to the examine, interview and test methods. Use it to see which documents an assessor will ask for and where undocumented screening criteria usually cause findings.

Assessment element	What the assessor checks	Evidence that usually satisfies it
Determination statement 1	Whether the organization has defined the appropriate access authorizations that developers of the in-scope system need for their assigned duties	A written list of required access authorizations mapped to developer roles, approved by the control owner
Determination statement 2	Whether the organization has defined additional personnel screening criteria for those developers and the criteria are applied	Screening criteria document, plus records showing screening was completed for developers before access
Examine: acquisition contracts	Whether contracts for developer services require the provider to meet the access authorization and screening requirements	Contract clauses or statements of work that name the authorizations and screening obligations
Examine: access authorization list	Whether the list matches the system's actual developer population and is current	The authorization list with version history and sign-off dates
Examine: screening criteria and documentation	Whether the criteria are defined, documented and tied to the organization's personnel screening process	Screening policy, criteria document and completed screening records for sampled developers
Examine: system design documentation	Whether the design documents identify the systems, components or services that trigger SA-21	Architecture or system boundary documents that list in-scope components and their developers
Interview	Asks system owners, HR or security personnel, and contracting staff how screening is requested, verified and enforced for developers	Consistent answers that match the written criteria and the records sampled
Test	Samples developers and checks that authorizations and screening were in place before access was granted	Sampled records showing screening dates that precede access grants
Common finding: undefined criteria	The organization requires screening but never states what additional screening means	Criteria document added and approved, then retested
Common finding: silent contracts	Contracts with developer service providers say nothing about developer screening	Contract amendment or updated statement of work with the required clauses

Implementing SA-21 in sequence

This sequence turns the SA-21 requirement into a documented, enforceable set of developer access rules, screening criteria and contract clauses, with each step producing an artifact an assessor can examine. It is written for organizations that run a high baseline system and need the developer population for that system to be controlled.

Define the sensitive systems and components
Start by listing the systems, components and services in scope for SA-21, using the system categorization and boundary documents already maintained for the authorization. The security owner and the system owner agree on which developers, internal or external, build or change these items. The output is a scoped inventory of sensitive systems and components tied to named development teams and vendors. The step is complete when every item in the boundary has either a named developer population or a documented reason it is out of scope.
Set the organization-defined parameters
SA-21 leaves several values to the organization, so the security team, with the system owner, sets them in writing. These values define which access authorizations apply and which screening criteria are required. The output is a parameter record that states each value, the reason for it, and the approver. Confirm the exact parameters against the current SP 800-53 Rev. 5 catalog and any agency or FedRAMP rules that apply to your system, since those sources define the fields you must fill.
List required access authorizations for each duty
For each development role, such as code committer, build engineer, release manager or production support engineer, list the access authorizations that role needs to perform its assigned official duties. Limit each entry to the access the duty requires, and record the system, repository, environment or data it covers. The output is a role-to-authorization matrix that the access owner signs off. The step is complete when every developer role in scope maps to a documented authorization set and no role has access without a stated duty.
Define additional screening criteria with HR and legal
Work with human resources and legal counsel to define the additional personnel screening criteria that go beyond standard hiring checks, and confirm which of them can lawfully apply in each jurisdiction and to each employment type, including contractors. Record the criteria, the roles they apply to, the screening provider, the refresh triggers, and how results are handled and retained. The output is a screening standard and a list of roles it covers. Legal review should be recorded, since the screening scope is constrained by employment law and by the contract with each developer employer.
Write the requirements into acquisition contracts
For external developers, add the access authorization and screening requirements to the acquisition contracts or statements of work, and tie them to the acceptance criteria. The contract should state who performs screening, what evidence the provider delivers, how the organization can verify it, and how changes in personnel are reported before access is granted. The output is signed contract language and a contract clause register that procurement can show. Procurement and the contracting officer or equivalent should confirm the clauses are enforceable before the work begins.
Map developer access to authorizations
Reconcile each developer identity with the authorization matrix and the screening record. Identity and access administrators grant access only where the developer's role, screening status and duty match the matrix, and they remove access when a duty ends. The output is an access map that lists each developer, role, authorizations held, screening status and the date of the last review. The step is complete when a sample of accounts can be traced from the identity system back to the matrix and to a screening result that is on file.
Keep the evidence current and ready for assessment
Set a recurring review of the parameter record, authorization matrix, screening standard, contract clauses and access map, and log each review with its approver. Assessors test SA-21 by examining the acquisition contracts, the access authorization list, the screening criteria and the system design documentation, so these artifacts should be stored together and kept consistent with each other. The output is an evidence package that an independent assessor can sample. Confirm the review cadence with your authorizing official or the assessment plan, because the organization sets it.

Evidence that passes an SA-21 review

SA-21 is tested by examining documents and records, so an assessor will look for a short set of artifacts that agree with each other. The cards below cover each artifact and how to keep it current between assessments, since stale lists and missing screening records are the usual reasons this control fails in practice.

Acquisition contract clauses for developer services

The contract with any external developer or development firm should state the access authorizations required for assigned duties and the additional screening the developer must meet. Assessors examine acquisition contracts for developer services to confirm these terms exist, so check that the clauses name the systems and components in scope rather than using generic language. Review the clauses when a statement of work changes or a subcontractor is added, because a new scope without a matching clause is a common gap.

Access authorization list for developers

The organization needs a current list of the access authorizations its developers hold for the system, tied to their assigned official duties. An assessor will compare this list against the system's accounts and repository permissions, so any developer with production or source access who is missing from the list is a finding. Keep the list generated from identity and repository systems where possible, and record who approved each authorization and when it was last confirmed.

Personnel screening criteria documents

Written screening criteria define which additional checks apply to developers of the defined systems and components, and why. These documents are what the assessor reads to judge whether the criteria are defined and appropriate, so they should name the roles covered and the checks required for each. Version the document, record approval by the responsible owner, and review it when the defined systems change or when the organization's personnel security policy is revised.

Screening records with dates and results

Screening records show that each developer on the list was checked against the defined criteria before access was granted. Each record should carry the person's role, the criteria applied, the date completed, the result and the approver, with personal details held under the organization's privacy rules. Assessors sample records, so a developer who has access but no matching record will be noticed quickly. Confirm with the screening provider how long records are retained and how they are retrieved.

System design documentation

System design documentation shows where developers sit in the architecture and which components they can change, which tells the assessor whether the screening scope is complete. Use the design to trace each privileged component back to the authorization list, including build pipelines, infrastructure-as-code repositories and secrets stores. Update the design when a new component or environment is added, since an undocumented component is a scope gap that the assessor can test.

Access reviews between audits

Periodic access reviews confirm that the authorization list still matches reality, including developers who have moved teams or left. Set a review cadence in the organization's own policy, compare repository and cloud permissions to the list, and record the reviewer, the date and every removal. Between formal assessments, the same review should also catch contractors whose screening has lapsed or whose engagement has ended, since those people often keep access longest.

How the developer screening chain connects to SA-4 and PS controls

SA-21 is only as strong as the controls it depends on. The developer screening requirement sits at the end of a chain. SA-4 (Acquisition process) decides which developers and development services a contract covers, and the PS family (Personnel Security) decides who those people are, what access they hold and how they are screened and re-screened. The Release 5.2.0 catalog lists six related controls for SA-21: PS-2, PS-3, PS-6, PS-7, SA-4 and SR-6. In practice, an assessor who tests SA-21 will start with the acquisition contract and the list of access authorizations, then trace each developer back to a screening record. If any link in that trace is missing, the SA-21 package fails even when every individual control looks complete on its own.

The gaps usually sit between teams, not inside them. HR typically owns position risk designations, screening and termination records (PS-2, PS-3, PS-7), while procurement and the contract owner own SA-4 terms that name developer screening requirements. SR-6 (Supplier assessments and reviews) asks whether the organization reviews suppliers' personnel practices and performance on an ongoing basis, so it lands with supply chain or vendor risk staff. Ask each team for its evidence in writing: the HR screening roster for developers, the contract clause that requires screening and the most recent supplier review. Then confirm that the names, roles and dates match across all three. Developers supplied through a staffing firm or an offshore partner are the most common place where these records diverge, because the people are paid through one party and granted access by another.

Agree on the owner of the SA-21 package before the assessment starts. Decide who maintains the list of developers with access to the defined system, who signs off the screening criteria and who collects the procurement evidence. Confirm with your assessor which SA-21 examine objects they expect to see, including acquisition contracts for developer services, the access authorization list, the screening criteria with supporting documentation and the system design documentation. Where a contractor performs the development, the screening evidence should be requested and stored under the contract, with a refresh trigger tied to personnel changes. DeployOpen can help map these records and prepare the evidence trail for a readiness review, but the organization owns the screening decisions and the independent assessor makes the final determination.

What meeting SA-21 costs in money and effort

This table breaks down who is paid for each part of meeting SA-21 developer screening, whether each cost is one-time or recurring, and what pushes it up. Use it to build a request for quote and to separate screening spend from the access and evidence work an implementation partner can prepare. No prices appear because none were supplied, so the right-hand column tells you what to ask for.

Cost component	Who is paid	One-time or recurring	What drives it and what to request
Defining screening criteria	Internal HR and legal staff, or outside counsel	One-time, revisited on policy change	Number of role types and jurisdictions. Ask the provider to state which criteria are defined by you and which are proposed by them.
Background check and screening vendor fees	Screening vendor, billed per check	Recurring for new and rescreened developers	Developer headcount, checks per person and local record-access limits. Request per-check pricing, included checks and rescreening rules in writing.
Contract revisions for developer obligations	Legal and procurement staff, and the supplier	One-time per contract, plus renewals	Count of developer-providing contracts and subcontracts. Ask whether the template already covers SA-21 flow-down to subcontracted developers.
Access authorization administration	Internal identity and access team, or implementation partner	Recurring with joiner, mover and leaver activity	Developer turnover and number of privileged development environments. Request the identity platform changes needed and who maintains access lists.
Evidence collection and upkeep	Internal compliance staff or implementation partner	Recurring, at each assessment cycle	Number of systems in scope and frequency of assessments. Ask for the evidence list, retention period and who signs off on each artifact.
Assessor sampling and testing	Independent assessor or auditor	Recurring, per assessment	Number of developers sampled and records requested. Ask the assessor how many screening files they will sample and which SP 800-53A objects they will examine.
Open-source access and evidence tooling	Hosting and support, not software licenses	Recurring hosting, one-time setup	Self-hosted tools remove license spend for access and evidence tooling only. Screening services remain a separate paid vendor cost, so confirm that in the quote.

Who owns SA-21, who can help, and where the auditor stops

Your organization owns SA-21 in full. Only you can decide which systems, components or services fall under the control, which developers need access authorizations for their assigned duties, and which additional screening criteria apply before someone builds a high-impact component. Those decisions belong to the people accountable for the system, usually the system owner working with HR, legal and the security office. The control is defined through organization-defined parameters, so the values you set become the standard an assessor will hold you to.

Scope decisions: Name the systems, components and services that trigger the control, and record why each was included or excluded.
Screening criteria: Set the additional personnel screening required for developers, and document how it relates to your existing personnel security program.
Access authorizations: Define which access each developer role needs for assigned official duties and approve it.
Exceptions and risk acceptance: Decide who may approve a developer who does not meet the criteria, and record the decision.
Contract language: Make sure acquisition contracts for developer services carry the screening obligations, because your assessor will look for them.

Before engaging anyone, confirm with your authorizing official or compliance owner which parameter values and screening criteria already apply to your system.

Common SA-21 gaps and how to close them

Most SA-21 findings come from the same few places: parameters left blank, screening rules that live only in someone's head, and contractor developers who never appear in HR records. The cards below cover the gaps assessors most often find and the closing action for each.

Undefined organization-defined parameters

SA-21 has organization-defined parameters that set which systems, components or services are covered and what screening criteria apply. If these are left blank or vague, the control cannot be tested because the assessor has nothing to measure against. Confirm the parameter values in the system security plan, name the developed systems and components they cover, and have the authorizing official approve them before assessment.

Screening criteria not written down

Many teams screen developers informally, relying on managers to vouch for people. An assessor looking for personnel screening criteria and associated documentation will find nothing to examine. Write the additional screening criteria as a standard, tie them to the access levels they unlock, and keep the signed criteria with the system design records.

Contracts without developer clauses

Acquisition contracts for developer services often omit screening obligations, so contractors are never required to meet the criteria the organization set. Add clauses that require screening to the defined standard, specify who performs it, and require notice when a developer leaves the project. Check that the contract references the same parameters as the system plan.

Contractor developers outside HR records

Contract developers often have repository and pipeline access but no entry in the HR or personnel system, so their screening status is invisible to the control owner. Keep a roster of every developer with access to the defined systems, including contractors and offshore staff, and reconcile it against source control and CI/CD accounts each quarter.

Access not tied to documented authorizations

SA-21 requires developers to hold access authorizations appropriate to their assigned duties, yet repository, build and production-adjacent rights are often granted by default. Map each role to the authorizations it needs, grant access only against that mapping, and export the access list from your identity provider as evidence. Confirm the mapping matches the list the assessor will examine.

No periodic review

Screening done at hire and never revisited leaves the control stale as roles change and people move between projects. Set a review cycle in the procedure, record each review with its date and outcome, and trigger an extra review when a developer changes role or gains new privileges. Retain the review records so the assessor can see the control operating over time.

SA-21 questions buyers ask before hiring help

Does SA-21 apply outside the high baseline?

No. SP 800-53B assigns SA-21 to the high security control baseline only, so a moderate or low system does not select it by default. Organizations outside the high baseline can still adopt it by tailoring, for example when a system supports a critical function or a contract requires it, and that choice should be recorded in the system security plan. Confirm which baseline your authorization or contract names before scoping work, because the baseline sets the starting list of controls. Also check whether an overlay or a FedRAMP requirement adds SA-21 to a system that would otherwise not carry it.

How much effort does SA-21 take to meet?

Effort depends less on the control text than on how many developers your system depends on and how many of them your organization does not directly employ. The control has two parts: access authorizations matched to official duties, and additional screening criteria that you define. Most of the work is inventory and documentation: listing who develops or changes the system, mapping their access to job duties, and writing down the screening criteria and how they are applied. Organizations with a small, stable, internal team usually have less to document than those using several contractor firms across many components.

How long does preparing for SA-21 take?

No researched duration is available for this control, so treat any timeline you receive as an estimate that needs verification. The main variables are whether screening processes already exist for developers, how quickly HR can confirm role requirements, and whether the assessor expects evidence from a prior cycle. Ask any implementation partner to tie the timeline to a written scope with named deliverables, and ask your assessor which evidence they will sample so you know what must exist before testing begins.

Can an in-house team meet SA-21 without outside help?

Yes, if your security, HR and engineering teams can agree on the screening criteria, document the access authorizations and collect evidence consistently. Outside help is most useful when the system spans several developer organizations, when the access model is complex, or when the team lacks someone to write the system design documentation the assessor will examine. An independent assessor is still needed to test the control. A partner can prepare the systems and evidence, but only the assessor issues the assessment result.

What does SA-21 need from HR and procurement?

SA-21 depends on HR and procurement records that many organizations keep outside security. HR must define which roles need which screening and confirm that screening happens before access is granted. Procurement must write the screening and access requirements into contracts with developer services providers, so that a subcontractor's staff are covered. Both teams should keep records that link a named developer to a screening result and an access authorization. Without these links, the security team cannot show the assessor that the criteria are applied in practice.

How does FedRAMP Class D change SA-21 scope?

FedRAMP's Rev5 baselines require SA-21 at Class D, which means cloud service providers pursuing FedRAMP authorization must implement the control in addition to the high baseline controls they already carry. Read the FedRAMP control reference and the consolidated rules that apply to your authorization level before scoping, because the required parameters and related controls can differ from a plain NIST baseline. FedRAMP also links SA-21 to its supply chain indicator, so the same screening evidence may be reviewed under more than one control.

What drives the cost of SA-21 compliance?

Cost follows the number of developers in scope, the number of developer organizations, how often roles change, and whether screening criteria must be built from scratch. One-time costs include defining criteria, documenting access authorizations and setting up the evidence trail. Recurring costs include screening new developers, reviewing access when roles change, and supporting the assessor each cycle. Ask any provider for a quote that separates these items, names who performs each one, and states which screening is paid for by your organization and which by the developer firm.

What does DeployOpen do for SA-21 readiness?

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it can prepare the systems, access configuration and evidence that SA-21 assessors examine. It does not define your personnel screening policy, perform background checks, or issue any assessment result. Engagements are fixed-scope, so the systems, documents and deliverables are agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen prepares SA-21 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the access authorization and screening records that SA-21 Developer screening asks the organization to hold. The organization owns its personnel decisions and its controls, and an independent assessor reaches its own conclusions about them.

How we scope

We agree in writing which systems, components and developer roles fall under SA-21 for your high baseline system.
We confirm the organization-defined screening criteria and access authorizations with your HR, security and contracting owners before work starts.
Engagements are fixed-scope, so scope, deliverables and timelines for SA-21 evidence are agreed in writing first.

How we build

We configure the developer access model in your environment so that access matches the authorizations you have defined.
We map each developer role to its required authorizations and record where contractor and external developers are covered.
We prepare design documentation and acquisition contract language that show how screening requirements flow to developers.

How we hand over

We deliver a written evidence package listing the contracts, authorization lists, screening criteria and design documents an assessor will examine.
We document how each artifact maps to the SA-21 determination statements in SP 800-53A, so reviewers can trace evidence quickly.
We walk your owners through the evidence and record open gaps, owners and dates in a plan of action and milestones.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so authorization lists stay current as developers change.
We can review developer access and screening records after significant changes to the system or its development team.
Confirm with your independent assessor which evidence formats and sampling they expect before the assessment begins.