Quick-reference card
| Field | Value |
|---|---|
| Control ID | SA-21 |
| Control Name | Developer Screening |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | System and Services Acquisition |
| Baselines | HIGH |
| Relevance | Third Party |
| Risk Severity | MEDIUM |
What this control requires
SA-21 requires organizations to verify that external developers hold valid access authorizations and satisfy defined personnel screening criteria before they build or modify systems within the System and Services Acquisition control family. Most organizations treat developer vetting as a procurement checkbox, but this control demands ongoing validation that every individual contributing code or configuration to your environment has been screened to a level consistent with the sensitivity of the system they touch.
In practice, you need to maintain a current roster of all authorized developers, confirm that each person’s clearance or background check aligns with your personnel screening requirements, and apply additional screening criteria that match the risk profile of the work. This screening goes beyond individual developers. It extends to evaluating company ownership structures and business relationships that could compromise the quality or reliability of what’s being built.
The control exists because systems used in critical national or economic security functions can’t afford an unknown actor in the development pipeline. If you’re outsourcing development or procuring third-party components, you’re placing trust in people your organization may never meet in person. SA-21 forces you to formalize that trust through documented, repeatable screening rather than relying on contractual assumptions alone.
Why it matters
Failure to screen external developers introduces a governance gap that auditors will flag during any NIST SP 800-53 assessment. Without documented evidence that developers meet your access authorization and screening requirements, you risk certification withdrawal, adverse audit findings, and regulatory penalties. For organizations operating under federal mandates, a missing SA-21 implementation can stall an authorization to operate (ATO) entirely.
The risk compounds when you consider how many organizations rely on distributed development teams, offshore contractors, and third-party integrators. Each unscreened developer represents a potential insertion point for malicious code, intellectual property theft, or supply chain compromise. Unlike a vulnerability you can patch, a compromised developer has persistent, privileged access to your codebase and infrastructure.
Regulatory scrutiny in this area is growing. Agencies and auditors increasingly expect organizations to demonstrate not just that screening policies exist, but that they’re actively enforced and periodically reviewed. A policy document sitting in a shared drive doesn’t satisfy SA-21 if you can’t produce a verified list of screened developers on demand.
What attackers exploit
- Unvetted contractors or subcontractors who gain commit access to production repositories without background checks
- Opaque vendor ownership structures that mask connections to adversarial entities or sanctioned organizations
- Gaps between initial hiring screens and ongoing re-verification, allowing developers whose clearance has lapsed to retain access
- Lack of a centralized developer authorization list, making it impossible to confirm who currently has development privileges
- Vendor self-attestation accepted at face value without independent verification of screening claims
How to implement
For your vendors
The core challenge with SA-21 in a third-party context is that you can’t directly screen another organization’s developers, yet you remain accountable for ensuring those developers meet your security requirements. Your leverage comes from contractual obligations, evidence requests, and ongoing verification.
What to ask in a security questionnaire
Start by asking vendors to describe their developer screening program in detail. Key questions include the following.
- What background check and personnel screening criteria do you apply to developers who will access our systems or data?
- Do you maintain a current list of all individuals authorized to perform development work on systems delivered to customers?
- How do you handle screening for subcontractors or offshore development teams involved in your deliverables?
- What is your process for re-screening developers when their role changes or their clearance status is updated?
- How do you evaluate ownership structures and business relationships for entities involved in your development supply chain?
What evidence to request
Ask vendors to provide documentation that demonstrates active compliance rather than just policy intent. You should request their personnel security policy and procedures addressing developer screening, along with a sanitized list of authorized developers with screening status confirmed. Require copies of acquisition contracts or service level agreements that include personnel screening requirements. Request evidence of position risk designations for development roles. Finally, collect access agreement documentation showing developers acknowledged security obligations.
Red flags
Watch for vendors who can’t produce a current developer authorization list, resist providing details about subcontractor screening, or lack formal screening procedures altogether. A vendor that claims “all employees undergo background checks” without specifying criteria tied to system sensitivity likely hasn’t implemented SA-21 meaningfully. Ownership opacity is another warning sign. If a vendor can’t clearly describe their corporate structure or disclose relationships with entities that could influence development quality, you should escalate the review.
How to verify beyond self-attestation
Don’t rely solely on questionnaire responses. Request evidence of recent screening activities, such as redacted background check completion records or third-party screening service reports. Cross-reference the vendor’s developer list against your own access logs to confirm only authorized individuals have touched your systems. Include SA-21 compliance requirements in your acquisition contracts and service level agreements, and conduct periodic audits to confirm ongoing adherence. Where feasible, require vendors to notify you within a defined timeframe when a developer’s screening status changes or when new individuals join the development team.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Personnel screening policy | Personnel security policy defining screening criteria, background check requirements, and re-verification cadence for external developers |
| Developer authorization roster | Maintained list of all individuals authorized to perform development activities, including screening status and authorization level |
| Acquisition and contract documentation | Acquisition contracts and service level agreements specifying developer screening obligations, clearance requirements, and notification procedures |
| Position risk designations | Documentation mapping development roles to risk levels with corresponding screening criteria for each designation |
| Access agreement records | Signed access agreements confirming developers acknowledged security responsibilities and acceptable use requirements |
| Supply chain risk assessment | Supply chain risk management plan documenting evaluation of vendor ownership structures and business relationships affecting development quality |
| Screening verification evidence | Third-party background check completion reports, clearance verification records, and citizenship or nationality documentation |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 6.1 Screening | Partial |
Related controls
- PS-02 — Position Risk Designation: defines risk categories for positions, which determine the screening level SA-21 requires for external developers.
- PS-03 — Personnel Screening: establishes the internal screening baseline that SA-21 extends to external developer personnel.
- PS-06 — Access Agreements: requires signed agreements from individuals accessing organizational systems, complementing SA-21’s developer authorization verification.
- PS-07 — External Personnel Security: governs security requirements for external service providers, overlapping with SA-21’s focus on third-party developer trustworthiness.
- SA-04 — Acquisition Process: integrates security requirements into procurement, providing the contractual mechanism for enforcing SA-21 screening obligations.
- SR-06 — Supplier Assessments and Reviews: covers broader supplier evaluation activities that include verifying developer screening compliance as part of supply chain risk management.
Frequently asked questions
What is NIST SP 800-53 SA-21?
SA-21 is a NIST SP 800-53 control that requires organizations to verify external developers hold appropriate access authorizations and meet defined personnel screening criteria before contributing to system development. It applies specifically to developers outside your organization, including contractors, vendors, and subcontracted development teams. The control also requires evaluation of developer organizations’ ownership structures and business relationships that could affect system quality or reliability.
What happens if SA-21 is not implemented?
Without SA-21, your organization can’t demonstrate that external developers accessing critical systems have been properly vetted, which creates a direct audit finding during NIST SP 800-53 assessments. Auditors will look for a current developer authorization list, documented screening criteria tied to system sensitivity, and evidence that screening requirements flow into acquisition contracts. Failure to produce this evidence can delay or block an authorization to operate and may trigger regulatory findings from oversight bodies.
How do you audit SA-21?
Auditing SA-21 starts with reviewing the organization’s personnel screening policy to confirm it defines criteria for external developer vetting. Assessors then request the developer authorization roster to verify that every individual performing development work has been screened to the required level. They also examine acquisition documentation and service level agreements to confirm that screening obligations are contractually binding. Finally, auditors look for evidence of periodic re-verification and procedures for updating the roster when developers join, leave, or change roles.
Does SA-21 apply to contractors and subcontractors?
SA-21 applies to all external developers who build, modify, or maintain systems, system components, or system services on your behalf, including contractors and their subcontractors. The control’s supplemental guidance explicitly addresses the need to evaluate not just individual developers but also the organizations employing them, including corporate ownership and business relationships that could influence development integrity. If your vendor outsources development work to a subcontractor, your screening requirements should flow through the entire chain.