Control statement
Require that the developer of [Organization-defined: system, systems component, or system service]:
- a.Has appropriate access authorizations as determined by assigned [Organization-defined: official government duties] ; and
- b.Satisfies the following additional personnel screening criteria: [Organization-defined: additional personnel screening criteria].
Discussion
Developer screening is directed at external developers. Internal developer screening is addressed by [PS-3](#ps-3) . Because the system, system component, or system service may be used in critical activities essential to the national or economic security interests of the United States, organizations have a strong interest in ensuring that developers are trustworthy. The degree of trust required of developers may need to be consistent with that of the individuals who access the systems, system components, or system services once deployed. Authorization and personnel screening criteria include clearances, background checks, citizenship, and nationality. Developer trustworthiness may also include a review and analysis of company ownership and relationships that the company has with entities that may potentially affect the quality and reliability of the systems, components, or services being developed. Satisfying the required access authorizations and personnel screening criteria includes providing a list of all individuals who are authorized to perform development activities on the selected system, system component, or system service so that organizations can validate that the developer has satisfied the authorization and screening requirements.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Developer Screening as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure acquisition, engineering, development lifecycle, supplier expectations, and system integrity by design.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- security requirements in contracts and specifications
- architecture and design review records
- development lifecycle evidence
- supplier assessment and acceptance records
Common failure patterns
- security requirements added after procurement
- supplier claims accepted without evidence
- development exceptions become permanent
- security architecture not tied to testable requirements
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- SA-21a.the developer of [Organization-defined: system, systems component, or system service] is required to have appropriate access authorizations as determined by assigned [Organization-defined: official government duties];
- SA-21b.the developer of [Organization-defined: system, systems component, or system service] is required to satisfy [Organization-defined: additional personnel screening criteria].
Examine
- System and services acquisition policy
- personnel security policy and procedures
- procedures addressing personnel screening
- system design documentation
- acquisition documentation
- service level agreements
- acquisition contracts for developer services
- system configuration settings and associated documentation
- list of appropriate access authorizations required by the developers of the system
- personnel screening criteria and associated documentation
- system security plan
- supply chain risk management plan
- other relevant documents or records
Interview
- Organizational personnel with system and service acquisition responsibilities
- organizational personnel with information security responsibilities
- organizational personnel responsible for developer screening
Test
- Organizational processes for developer screening
- mechanisms supporting developer screening
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
SA-21(1) — Validation of Screening
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.