SA-4: Acquisition Process

Quick-reference card

What this control requires

SA-04 mandates that organizations embed specific security and privacy requirements directly into every system and service acquisition contract. Without these contractual obligations, procured systems arrive without verified protections, and your security team inherits risk it didn’t choose.

The control covers nine categories of requirements that must appear in acquisition contracts, either explicitly or by reference. These categories include security and privacy functional requirements, strength-of-mechanism requirements (covering correctness, completeness, and tamper resistance), assurance requirements tied to development processes and assessment evidence, the specific controls needed to meet system requirements, documentation requirements across all stages of the system development life cycle (SDLC), protections for that documentation, a description of development and operating environments, allocation of responsibility for information security, privacy, and supply chain risk management, and acceptance criteria for deliverables.

In practice, these requirements flow from SA-02, which defines capital planning and investment control. The NIST SP 800-53 framework treats acquisition as a control surface because every externally developed or sourced component introduces dependencies your organization can’t verify after the fact. Defining requirements upfront shifts the burden of proof to the supplier, making security a procurement gate rather than a post-deployment discovery.

Why it matters

Acquisition contracts without embedded security requirements create a structural gap in your compliance posture. Auditors reviewing SA-04 aren’t looking for general intent; they’re checking whether each of the nine requirement categories appears in your contract language. A missing category is a finding, regardless of how secure the acquired system turns out to be.

The risk compounds because acquisition decisions lock in architectural and operational constraints for years. A system procured without strength-of-mechanism requirements, for example, may lack tamper resistance properties that can’t be retrofitted. Your organization absorbs that weakness into its authorization boundary with no contractual leverage to demand remediation.

From an audit perspective, SA-04 gaps tend to cascade. If your acquisition contracts don’t specify documentation requirements, you won’t have the evidence needed to satisfy related controls like SA-05 (System Documentation) or SA-11 (Developer Testing and Evaluation). The System and Services Acquisition family treats these controls as interdependent, and auditors evaluate them accordingly.

Supply chain compromise adds another dimension. Attackers increasingly target the acquisition pipeline because it offers access to systems before your monitoring infrastructure is in place. The following vectors are relevant to organizations without mature acquisition controls.

What attackers exploit:

• Weak or absent security requirements in contracts, allowing suppliers to deliver systems with known vulnerabilities and no obligation to remediate them
• Missing development environment descriptions, obscuring whether code was built in a controlled or compromised pipeline
• Lack of acceptance criteria, enabling systems to enter production without security validation or penetration testing
• Absent supply chain risk management allocation, leaving no party accountable for component provenance or integrity verification
• Insufficient documentation protections, allowing sensitive system architecture details to be exposed during or after the acquisition process

Organizations managing cyber supply chain risk need to address these vectors at the contract stage, not after deployment.

How to implement

The most common failure mode for SA-04 isn’t a lack of security awareness during procurement. It’s the gap between what security teams know should be in a contract and what ends up in the final signed agreement.

For your organization

Start by building standardized contract language templates that address each of the nine SA-04 requirement categories. These templates should be modular so procurement teams can adapt them to different acquisition types (commercial off-the-shelf software, custom development, cloud services, managed services) without omitting required categories.

Map your contract language to the requirements derived from SA-02 (capital planning and investment control). Each acquisition should trace back to a documented set of security and privacy requirements established during the planning phase. If that traceability doesn’t exist, your SA-04 compliance relies on ad hoc decisions by procurement staff who may not understand the security implications.

Develop a contract review checklist that your information security team uses before any acquisition agreement is finalized. The checklist should confirm that the contract includes functional requirements (what the system must do securely), strength-of-mechanism requirements (how robust those mechanisms must be), assurance requirements (what evidence the vendor must provide), applicable controls, documentation deliverables, documentation protections, development environment descriptions, responsibility allocation for information security, privacy, and supply chain risk, and acceptance criteria.

Common mistakes include treating acceptance criteria as a formality rather than defining specific security tests the system must pass. Another frequent gap is omitting development environment descriptions, which leaves your organization unable to assess whether the supplier’s build pipeline meets your integrity standards.

Maintain a configuration management plan that tracks which security requirements were specified in each acquisition contract and whether delivered systems satisfy those requirements. This plan serves as the audit trail connecting your procurement decisions to your system authorization packages.

Consider integrating your acquisition process with your organization’s supply chain risk management plan. The allocation of supply chain risk management responsibility in contracts should align with the risk tiers you’ve established for different supplier categories, and your vendor tiering framework provides the structure for making those distinctions.

For your vendors

When assessing whether your vendors meet SA-04 requirements, focus on the contract language they use with their own suppliers. A vendor’s acquisition process directly affects the security of components that flow into your environment.

Request copies of your vendor’s system and services acquisition policy and procedures. These documents should describe how the vendor incorporates security and privacy requirements into contracts with their subcontractors and technology providers. If the vendor can’t produce these documents, that gap signals a systemic weakness in their supply chain governance.

Ask these assessment questions during your vendor risk assessment process:

• Does your acquisition policy require security and privacy functional requirements in all technology contracts?
• How do you define and verify strength-of-mechanism requirements for procured components?
• What acceptance criteria do you apply before deploying externally developed systems?
• How do you allocate responsibility for supply chain risk management in vendor agreements?
• Can you provide a sample contract addendum showing your standardized security requirements language?

Red flags during vendor assessment include contracts that reference “industry standard security” without specifying which standards, vendors who can’t produce a supply chain risk management plan, and acquisition procedures that don’t include a security review stage before contract signing.

Verification should go beyond document review. Request evidence that the vendor’s acquisition controls produce results, such as records of contracts where security requirements led to vendor remediation or rejection. A vendor risk management checklist helps structure this verification consistently across your third-party portfolio.

Evidence examples

Cross-framework mapping

Related controls

• CM-06 — Configuration Settings: Ensures that systems acquired under SA-04 are deployed with secure baseline configurations rather than vendor defaults.
• CM-08 — System Component Inventory: Tracks all components introduced through the acquisition process so each item is accounted for in the organization’s asset inventory.
• PS-07 — External Personnel Security: Governs security requirements for external personnel who may gain access to systems as part of an acquisition or service agreement.
• SA-03 — System Development Life Cycle: Defines the SDLC framework within which acquisition requirements from SA-04 are specified and validated.
• SA-05 — System Documentation: Ensures that documentation deliverables required by acquisition contracts are produced, maintained, and accessible to authorized personnel.
• SA-08 — Security and Privacy Engineering Principles: Provides the engineering standards that inform the security functional and strength-of-mechanism requirements embedded in acquisition contracts.
• SA-11 — Developer Testing and Evaluation: Requires vendors and developers to conduct security testing that validates whether acquired systems meet the assurance requirements specified in contracts.
• SA-15 — Development Process, Standards, and Tools: Governs the development environment and tooling standards that SA-04 contracts should describe and require.
• SA-16 — Developer-provided Training: Ensures that vendors provide training on securely operating and maintaining acquired systems, supporting the knowledge transfer required by acquisition contracts.
• SA-17 — Developer Security and Privacy Architecture and Design: Requires vendors to produce architecture and design documentation that demonstrates how acquired systems meet the security and privacy requirements specified in contracts.

Frequently asked questions

What is NIST SP 800-53 SA-04?

SA-04 is the NIST SP 800-53 control that requires organizations to include security, privacy, and supply chain risk management requirements in acquisition contracts for systems and services. It covers nine categories of contractual requirements, including security functional requirements, strength-of-mechanism requirements, assurance requirements, applicable controls, documentation deliverables, documentation protections, development environment descriptions, responsibility allocation, and acceptance criteria. The control applies across all baselines (LOW, MODERATE, HIGH, and PRIVACY) and addresses both first-party and third-party risk.

What happens if SA-04 is not implemented?

Without SA-04, your organization procures systems and services with no contractual obligation for vendors to meet specific security or privacy standards. Auditors will flag the absence of standardized acquisition contract language covering the nine requirement categories as a direct compliance finding. The downstream effect extends to related controls, because missing documentation requirements in contracts means you won’t have the system security plans, design documentation, or supply chain risk management plans needed for SA-05, SA-11, and other controls in the System and Services Acquisition family.

How do you audit SA-04?

Auditors verify SA-04 by examining acquisition contracts for explicit inclusion of each requirement category, either through standardized organizational contract language or by reference to applicable standards. The assessment checks whether contracts contain security functional requirements, privacy functional requirements, strength-of-mechanism requirements, security and privacy assurance requirements, applicable controls, documentation requirements with protections, development environment descriptions, responsibility allocation for information security, privacy, and supply chain risk management, and acceptance criteria. Auditors also review the system and services acquisition policy and procedures to confirm that the organization has a repeatable process for embedding these requirements into procurement workflows.

What contract language should you include for NIST SA-04?

Your acquisition contracts should include modular clauses addressing each of the nine SA-04 requirement categories, with language specific enough to be auditable. For strength-of-mechanism requirements, specify the correctness, completeness, and tamper resistance properties the system must demonstrate. For acceptance criteria, define the specific security tests and evaluation procedures the vendor must pass before system delivery is accepted. Reference your organization’s supply chain risk management plan to allocate responsibilities between your team and the supplier for ongoing risk monitoring and incident notification.