Safeguard
Compliance•

NIST 800-53 SA-21 Developer Screening: What to Show an Auditor

SA-21 covers vetting the outside developers who build your systems. Learn what screening evidence a customer or auditor can reasonably expect.

Safeguard Security Team
3 min read

SA-21, Developer Screening, asks the organization to require that the developers of named systems, components or services hold the appropriate access authorizations for their assigned roles and satisfy additional personnel screening criteria the organization sets. The enhancement SA-21.1 is titled Validation of Screening.

800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference for contractors, agencies and outsourced engineering teams.

What it means in practice

The guidance says this control is directed at external developers. Screening your own employees falls under PS-3. The federal wording mentions clearances, background checks, citizenship and nationality, because the original audience builds systems that matter to national or economic security. It also says trustworthiness can include a review of company ownership and the company's relationships with entities that may affect quality and reliability.

A commercial company will translate this into something narrower. Who is writing code that touches production or customer data? Were they screened to the same standard as an employee in that role? Do they have only the access their job needs?

The level of trust should be consistent with the people who access the system after deployment. If the vendor engineer can read customer data, screening should look like screening for your own staff who can.

Evidence to collect

  • The screening criteria you set for external developers, written down.
  • Contract language requiring those criteria and giving you the right to verify.
  • Confirmation from the vendor that screening was completed, ideally per person.
  • An access list showing which vendor staff have accounts and at what level.
  • Any ownership or relationship review you performed on the vendor.

Common gaps

Relying on the vendor's general statement that all staff are vetted, with no way to check who was on your project.

Giving contractors accounts before screening finishes.

Never removing vendor accounts when a contract ends or a person rotates off. PS-4 and PS-7 cover that side, so check them alongside.

How to implement it

  1. Decide the criteria by role. A contractor with production access needs more than one with read access to a test environment.
  2. Put the criteria in the contract and require confirmation before access.
  3. Ask for a named list and record it.
  4. Review the list each quarter against actual accounts.
  5. Where you rely on the vendor's screening, practice SA-21.1 and validate a sample.

What an auditor may ask

  • What screening applies to a contractor with production access?
  • Can you show completion for the people actually on your accounts today?
  • How quickly is access removed when a contract ends?

Pair the answers with your PS-3, PS-4 and PS-7 records so the story holds together.

Quick check

Does SA-21 cover your own employees?

No. The guidance points to PS-3 for internal developer screening. SA-21 is directed at external developers.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.