SA-4 acquisition: what security terms to put in a software contract

NIST 800-53 control SA-4, Acquisition Process, lists what to include in a contract for a system, component or service: functional and assurance requirements, needed controls, documentation requirements, a description of the development and operating environment, who is responsible for security, privacy and supply chain risk, and acceptance criteria. It is a useful checklist for both buyers and suppliers.

The nine items

The Rev. 5 text asks the contract to include, explicitly or by reference:

1. security and privacy functional requirements
2. strength of mechanism requirements
3. security and privacy assurance requirements
4. controls needed to satisfy those requirements
5. security and privacy documentation requirements
6. requirements for protecting that documentation
7. a description of the development environment and the environment the system will operate in
8. allocation of responsibility for information security, privacy and supply chain risk management
9. acceptance criteria

The discussion explains strength of mechanism as degree of correctness, completeness, resistance to tampering or bypass and resistance to direct attack. Assurance requirements cover development processes and the evidence from development and assessment that gives grounds for confidence. SA-4 is in the low, moderate and high baselines.

Turning it into contract language

• Functional requirements. What to write down: Authentication, logging and encryption features required
• Assurance. What to write down: Testing, review and secure development practices the supplier follows
• Documentation. What to write down: What the supplier must hand over, such as an SBOM and test summaries
• Environment. What to write down: Where the software is built and where it runs
• Responsibility. What to write down: A named split of who patches, who monitors, who reports incidents
• Acceptance. What to write down: The tests or evidence that must pass before you accept delivery

Ask for evidence, not adjectives

"Secure by design" is not a requirement. A requirement is checkable: an SBOM per release, a stated vulnerability response time, a signed artifact, a list of subcontractors. Our post on RFP questions about secure development covers questions that produce usable answers.

If you are the supplier

Expect these asks and prepare standard answers once. Keep a short package with your development practices, your testing evidence and a responsibility split. Answer truthfully about what is done and what is planned.

Flow-down

If your contract flows security terms to your own suppliers, carry the same nine items down. A gap in the chain is a gap in your assurance. For defense contracts see DFARS 7012 flowdown.

Acceptance is where it bites

Define in advance what happens if the evidence is missing at delivery. Without a stated consequence, acceptance becomes a formality.

Quick check

Safeguard's SBOM and dependency scanning and compliance and evidence automation help a supplier produce the documentation these clauses request. A free scan is at gold.safeguard.sh/scan.

Sources

• NIST SP 800-53 Rev. 5 catalog and baseline profiles, SA-4 (OSCAL content)
• NIST SP 800-53 Rev. 5 page

Last reviewed: 19 October 2026.