# Acquisition Security Requirements

**Template version:** 1.0.0 · **Edition:** Ready to adopt · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/standards/acquisition-security-requirements/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

| Owner | Approved by | Version | Effective date |
| --- | --- | --- | --- |
| [Chief Information Security Officer] | [Fill in: name and title] | [Fill in: version] | [Fill in: date] |

## 1. Purpose and scope

This standard sets the minimum security and privacy requirements that [Organization name] includes in the acquisition contract for each system, system component or system service, and how each solicitation is reviewed for them. It applies to new contracts, renewals, task orders, modifications that change what is delivered, and purchases made by purchase card or by accepting a supplier's online terms. It covers hardware, software, cloud and other external services, and development done under contract. External services also get the [external service review](https://kston83.github.io/nist-guide/templates/forms/external-service-review/) before use (SA-9).

## 2. Roles

| Role | Responsibilities |
| --- | --- |
| [Chief Information Security Officer] | Owns this standard; approves the standard security language; reviews each solicitation for a system, component or service before it is issued; approves deviations |
| [Senior privacy official] | Approves the standard privacy language; reviews each solicitation for a system that processes personally identifiable information |
| [Fill in: procurement office, for example the contracting office] | Keeps the approved clauses in the contract library; routes each solicitation for review; does not issue or award without it |
| [System owner] | Adds the system-specific requirements in section 3; confirms deliverables meet the acceptance criteria before the organization accepts them |

## 3. Putting the requirements into each contract

- The [System owner] shall include the requirements in section 4, explicitly or by reference, using [Select one or more: standardized contract language; [Assignment: organization-defined contract language]. Typical: standardized contract language that the procurement office maintains and the Chief Information Security Officer and senior privacy official approve, with system-specific requirements added for each acquisition], in the acquisition contract for each system, system component or system service. (SA-4)
- The system-specific requirements shall name the controls from the system's baseline that the supplier implements, with the parameter values the supplier must meet, and the tests the organization will run before acceptance. (SA-4d, SA-4i)
- The [Chief Information Security Officer] shall review each solicitation for a system, system component or system service against the checklist in section 5 before it is issued. (SA-4)
- The [Senior privacy official] shall review each solicitation for a system that processes personally identifiable information before it is issued. (SA-4)
- A purchase card buy, a no-cost service or a supplier's online terms shall get the same review before use, scaled to what is bought. (SA-4)
- A renewal or modification shall be reviewed again when it changes what is delivered, the information involved or the supplier's responsibilities. (SA-4)

## 4. Standard requirements

Each item cites the part of SA-4 it meets. Where an item does not apply to what is bought, the solicitation says so.

### 4.1 Functional, strength and control requirements

- Each contract shall state the security and privacy functional requirements for the system, component or service. (SA-4a)
- Each contract shall state the strength of mechanism requirements, such as correctness, completeness, and resistance to tampering, bypass and direct attack. (SA-4b)
- Each contract shall state the controls the supplier implements, with any parameter values it must meet. (SA-4d)
- Each contract shall require the developer to describe the functional properties of the controls it implements, as seen at their interfaces. The description shall cover every control the contract allocates to the developer. (SA-4(1))

### 4.2 Assurance requirements and developer evidence

- Each contract shall state the security and privacy assurance requirements: the development processes the supplier follows, and the evidence from development and assessment it provides. (SA-4c)
- Each contract shall require the developer to provide design and implementation information for the controls that includes [Select one or more: security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design and implementation information]. Typical: security-relevant external system interfaces and high-level design, and for High systems also low-level design] at [Fill in: level of detail. Typical: enough detail to show, for each subsystem and interface, which controls it implements and how]. (SA-4(2))
- A contract for custom development shall require the developer to perform configuration management during [Select one or more: design; development; implementation; operation; disposal. Typical: design, development, implementation and operation], and to document, manage and control the integrity of changes to [Fill in: configuration items under configuration management. Typical: design specifications, source code, build scripts and pipeline configuration, infrastructure and configuration as code, test scripts and results, and each released executable]. (SA-10a, SA-10b)
- A contract for custom development shall require the developer to implement only organization-approved changes, document approved changes and their potential security and privacy impacts, and track security flaws and their resolution, reporting findings to [Fill in: personnel to whom security flaws and flaw resolutions within the system, component, or service are reported. Typical: the system owner and the Chief Information Security Officer]. (SA-10c, SA-10d, SA-10e)
- A contract for custom development shall require the developer to develop and implement a plan for ongoing security and privacy control assessments at all post-design stages of the life cycle. (SA-11a)
- A contract for custom development shall require the developer to perform [Select one or more: unit; integration; system; regression. Typical: unit, integration, system and regression] testing and evaluation [Fill in: frequency at which to conduct the selected unit, integration, system or regression testing/evaluation. Typical: with each build for automated tests, and before each release to production for system and regression testing] at [Fill in: depth and coverage of the selected unit, integration, system or regression testing/evaluation. Typical: static analysis of all custom code, analysis of third-party and open-source components for known vulnerabilities, dynamic testing of every externally reachable interface, and a test for each security and privacy requirement]. (SA-11b)
- A contract for custom development shall require the developer to produce evidence of the assessment plan's execution and the testing results, implement a verifiable flaw remediation process, and correct flaws found in testing. (SA-11c, SA-11d, SA-11e)
- A contract for custom development shall require the developer to follow a documented development process that addresses security and privacy requirements, identifies the standards and tools used, documents tool options and configurations, and controls changes to the process and tools. (SA-15a)
- A contract for custom development shall require the developer to support the organization's review of that process [Fill in: frequency at which to review the development process, standards, tools, tool options, and tool configurations. Typical: at least annually, and before a new development tool or a major change to the development process is adopted], against [Fill in: security and privacy requirements. Typical: the security requirements in the acquisition contract (SA-4) and the organization's secure software development practices, and the privacy requirements recorded in the system's privacy impact assessment]. (SA-15b)
- A contract for custom development shall require the developer to perform a criticality analysis at [Fill in: decision points in the system development life cycle. Typical: during design, before acquiring major components or services, and when the architecture changes significantly], covering [Fill in: breadth and depth of criticality analysis. Typical: the components and functions that support the system's critical functions, including third-party and open-source components, analyzed down to the component and software module level and naming the supplier of each critical component]. (SA-15(3))

### 4.3 Documentation and its protection

- Each contract shall require administrator documentation that describes secure configuration, installation and operation, the effective use and maintenance of the security and privacy functions, and known vulnerabilities in administrative or privileged functions. (SA-4e, SA-5a)
- Each contract shall require user documentation that describes the user-accessible security and privacy functions, how to use them securely, and users' responsibilities. (SA-4e, SA-5b)
- Each contract shall state how the supplier protects the documentation and the design and implementation information, according to the system's security category, including limits on who may see documentation that describes vulnerabilities. (SA-4f)

### 4.4 Environments, configurations and functions in use

- Each contract shall describe the system development environment and the environment in which the system, component or service is intended to operate. (SA-4g)
- Each contract shall require the developer to identify, early in the life cycle, the functions, ports, protocols and services intended for organizational use. (SA-4(9))

This paragraph applies to High systems.

- Each contract shall require the developer to deliver the system, component or service with [Fill in: security configurations for the system, component, or service. Typical: the secure configuration baselines named in the baseline configuration standard for that type of component, with default passwords changed and the functions, ports, protocols and services not needed disabled] implemented, and to use those configurations as the default for any later reinstallation or upgrade. (SA-4(5))

### 4.5 Responsibilities and supply chain

- Each contract shall allocate responsibility for information security, privacy and supply chain risk management between the organization and the supplier, or name the parties responsible. (SA-4h)
- Each contract shall require the supplier to flow the security and privacy requirements down to the subcontractors that take part in delivering the system, component or service. (SA-4h)
- Each contract shall require the supplier to identify the origin of critical components and to tell the organization of changes in the suppliers of those components. [Fill in: further supply chain terms from the supply chain risk management plan, or "none"] (SR-5)

### 4.6 Support, notification and updates

- Each contract shall require the supplier to notify the organization of a security incident or breach affecting the organization's information or the delivered product within [Fill in: time, for example 24 hours of discovery]. (SA-4)
- Each contract shall require the supplier to notify the organization of a vulnerability in the delivered product, with its fix or mitigation, within [Fill in: time, for example 30 days of the supplier learning of it, or sooner when it is being exploited]. (SA-4)
- Each contract shall state the period during which the supplier provides security updates, and require at least [Fill in: notice, for example 12 months] notice before support ends. (SA-4, SA-22)
- Each contract shall require the supplier to cooperate with the organization's assessments, and to provide the evidence the organization needs to monitor compliance. (SA-4c)

### 4.7 Acceptance criteria

- Each contract shall state the acceptance criteria for the system, component or service, including that the deliverables in sections 4.1 to 4.4 have been provided and that the organization's acceptance tests have passed. (SA-4i)
- The [System owner] shall not accept a deliverable that fails an acceptance criterion unless the risk is accepted under section 6. (SA-4i)

### 4.8 Personal Identity Verification products

- Where the system implements Personal Identity Verification (PIV) capability, each contract for that capability shall require products on the FIPS 201-approved products list. (SA-4(10))

### 4.9 Personnel security

These items apply to each contract under which the supplier's personnel will hold organizational credentials or badges, have system privileges, or have access to organizational information.

- Each such contract shall state the personnel security requirements for the supplier's personnel, including their security roles and responsibilities. (PS-7a, PS-7c)
- Each such contract shall require the supplier to comply with the organization's personnel security policies and procedures, and to flow these requirements down to subcontractors whose personnel will have such access. (PS-7b)
- Each such contract shall require the supplier to screen its personnel to the criteria the organization sets for the risk designation of the position they fill, before they are given access, and to give the organization evidence of the screening. (PS-7b, PS-3)
- Each such contract shall require the supplier's personnel to sign the organization's access agreements before they are given access, and to complete the training the organization requires for their role. (PS-7b, PS-6, AT-2, AT-3)
- Each such contract shall require the supplier to notify [Fill in: personnel or roles to be notified of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges or who have system privileges. Typical: the organization's contract manager for the provider, and the account managers of the systems the individual has access to] within [Fill in: time period within which third-party providers are required to notify organization-defined personnel or roles of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges or who have system privileges. Typical: 24 hours] of any transfer or termination of its personnel who hold organizational credentials or badges, or who have system privileges. (PS-7d)
- Each such contract shall require the supplier to provide a current roster of its personnel with such access [Fill in: for example monthly], and to cooperate with the organization's monitoring of its compliance with these requirements. (PS-7e)

#### Federal systems

[5 CFR 731.106](https://www.ecfr.gov/current/title-5/section-731.106)(a) (OPM; as amended June 30, 2026) requires a risk designation for every covered position, including one in which the occupant performs a service as a contractor employee; the investigation and continuous vetting requirements of 731.106(c) and (d) follow from that designation. [FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022), section 2.9.4, requires a PIV Card to be terminated when a contractor changes positions and no longer needs access to federal buildings or systems. As of October 2026.

- Each contract under which contractor employees fill covered positions shall require them to undergo the investigation and continuous vetting that the position's risk designation requires under 5 CFR 731.106. (PS-7b, PS-3)
- Each such contract shall require the supplier's notice under section 4.9 to include an employee who changes positions and no longer needs access to federal buildings or systems, so the agency can have the PIV Card terminated as FIPS 201-3 section 2.9.4 requires. (PS-7d, PS-4b)

## 5. Solicitation review checklist

The reviewer completes one checklist for each solicitation and keeps it with the contract file.

| Solicitation | System | Reviewer | Date | Processes personally identifiable information |
| --- | --- | --- | --- | --- |
| [Fill in: solicitation or purchase number] | [Fill in: system] | [Fill in: name] | [Fill in: date] | [Fill in: yes or no] |

| Item | Requirement | Present (yes, no or not applicable) | Where in the solicitation |
| --- | --- | --- | --- |
| SA-4a | Security and privacy functional requirements | [Fill in: answer] | [Fill in: section] |
| SA-4b | Strength of mechanism requirements | [Fill in: answer] | [Fill in: section] |
| SA-4c | Assurance requirements and developer evidence | [Fill in: answer] | [Fill in: section] |
| SA-4d | Controls the supplier implements, with parameter values | [Fill in: answer] | [Fill in: section] |
| SA-4e | Documentation requirements | [Fill in: answer] | [Fill in: section] |
| SA-4f | Protection of documentation | [Fill in: answer] | [Fill in: section] |
| SA-4g | Development and operating environments | [Fill in: answer] | [Fill in: section] |
| SA-4h | Responsibilities for security, privacy and supply chain risk; incident and vulnerability notice; support period | [Fill in: answer] | [Fill in: section] |
| SA-4i | Acceptance criteria | [Fill in: answer] | [Fill in: section] |
| SA-4(1), SA-4(2) | Functional properties of controls; design and implementation information | [Fill in: answer] | [Fill in: section] |
| SA-4(9) | Functions, ports, protocols and services identified | [Fill in: answer] | [Fill in: section] |
| SA-4(5) | Secure configurations delivered (High systems) | [Fill in: answer] | [Fill in: section] |
| SA-4(10) | Approved PIV products (systems with PIV capability) | [Fill in: answer] | [Fill in: section] |
| SA-10, SA-11, SA-15 | Developer configuration management, testing and development process (custom development) | [Fill in: answer] | [Fill in: section] |
| PS-7 | Personnel security requirements, screening, access agreements, training, transfer and termination notice, and roster (supplier personnel with credentials, badges, privileges or access to information) | [Fill in: answer] | [Fill in: section] |
| SA-9 | External service review completed (external services) | [Fill in: answer] | [Fill in: review ID] |

Result: [Fill in: approved to issue, approved with the changes listed, or returned]. Changes required: [Fill in: list, or "none"].

## 6. Deviations

- A solicitation that leaves out a requirement in section 4 that applies shall be issued only with the [Chief Information Security Officer]'s written approval, recording the reason and any compensating measures. (SA-4)
- A deviation that leaves a risk to the system shall be accepted by the official the risk management strategy authorizes to accept risk at its level, and tracked in the system's plan of action and milestones. (SA-4, RA-7)

### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.j(1), requires agencies to ensure that the terms and conditions of contracts and other agreements involving Federal information incorporate security and privacy requirements sufficient to meet Federal and agency-specific requirements for its protection; section 4.j(5) requires provisions for Federal Government notification and access, and for cooperation with agency personnel and Inspectors General. [OMB M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf), Adopting a Risk-based Approach to Software and Hardware Security (January 23, 2026), rescinds M-22-18 and M-23-16, so agencies are no longer required to collect the Secure Software Development Attestation Form. It requires agencies to develop software and hardware assurance policies and processes that match their risk determinations, and lets them use the attestation form, and contract terms requiring a current software bill of materials on request, where they choose to. [FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022) provides FIPS 201 compliance of PIV components through GSA's [FIPS 201 Approved Products List](https://www.idmanagement.gov/fips201/) (preamble item 7, Appendix A.5). Under [OMB M-24-15](https://www.fedramp.gov/2026/authority/m-24-15/), Modernizing the Federal Risk and Authorization Management Program (July 25, 2024), cloud products and services that create, collect, process, store or maintain Federal information on an agency's behalf need a FedRAMP authorization, unless the memo places them out of scope. As of September 2026.

- Each contract or agreement involving Federal information shall incorporate the security and privacy requirements that apply to that information, and provisions for Federal Government notification and access and for cooperation with agency personnel and the Inspector General, as OMB Circular A-130, Appendix I, sections 4.j(1) and 4.j(5), require. (SA-4)
- The [Chief Information Security Officer] shall decide, for each acquisition of software or hardware and based on a risk assessment, whether the contract requires a secure software development attestation or a software bill of materials, following the agency's assurance policy under OMB M-26-05. (SA-4c)
- Each solicitation for PIV card products, readers or physical access control system products shall require products from the FIPS 201 Approved Products List that GSA maintains. (SA-4(10))
- Each solicitation for a cloud product or service within the scope of OMB M-24-15 shall require the offering to hold a FedRAMP authorization, or to obtain one before it processes Federal information. (SA-4, SA-9a)

<!-- TODO(verify): FAR contract requirements for IT security (FAR 39.101(c), clause 52.239-1 at 39.106) and PIV products (FAR 4.1302(a)). The codified FAR (FAC 2026-01) and the Revolutionary FAR Overhaul class deviations for Parts 4 and 39 may differ; cite the FAR here once it is clear which text governs. Same open question as the SA-4 and SA-4(10) clauses (PROGRESS.md, Open questions). -->

## 7. Review

The [Chief Information Security Officer] reviews this standard [Fill in: for example annually], and whenever the system and services acquisition policy, acquisition rules or the organization's risk tolerance changes, or a supplier incident shows a gap in the standard language.

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [Fill in: version] | [Fill in: date] | [Fill in: summary of change] | [Fill in: name and title] |