# System and Services Acquisition Policy

**Template version:** 1.0.0 · **Baseline:** Privacy · **Edition:** Annotated (with guidance) · **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/policies/sa/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** The sections before and after Policy statements meet SA-1, which asks for a policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination and compliance, plus procedures, dissemination, a designated official and a review cycle. Assessors check each element, so keep every section even when it is short. Each statement cites the SA-1 item it meets. If you adopt several family policies, the same sections repeat in each; that is expected, and it lets each policy stand alone.

## Purpose

This policy states what [Organization name] requires for System and Services Acquisition, and who is accountable for meeting those requirements. (SA-1a.1(a))

## Scope

This policy applies at the [Select one or more: organization-level; mission/business process-level; system-level. Typical: organization-level] to every system that [Organization name] owns or operates, or that is operated on its behalf, and to every person with access to those systems, including employees, contractors and partners. (SA-1a.1(a))

## Roles and responsibilities

- The [Chief Information Security Officer] is accountable for this policy and shall approve exceptions to it. (SA-1a.1(a))
- The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall manage the development, documentation and dissemination of this policy and its procedures. (SA-1b)
- Each [System owner] shall implement this policy for their system and document how in the system security plan. (SA-1a.1(a))
- Each person within scope shall follow this policy and report suspected violations to the [Chief Information Security Officer]. (SA-1a.1(a))

## Management commitment

The [Senior leader] approves this policy and shall provide the resources needed to implement it. (SA-1a.1(a))

## Coordination

The [Chief Information Security Officer] shall coordinate this policy with the legal, privacy, human resources and procurement functions, and with the owners of related policies, before each approval. (SA-1a.1(a))

## Compliance

- This policy shall be consistent with the laws, executive orders, directives, regulations, policies, standards and guidelines that apply to [Organization name], including [Fill in: laws, regulations and standards that apply to the organization]. (SA-1a.1(b))
- The [Chief Information Security Officer] shall review compliance with this policy through the organization's assessment and continuous monitoring activities. (SA-1a.1(a))
- An exception to this policy shall be requested in writing, approved by the [Chief Information Security Officer], time-limited and recorded with its compensating measures. (SA-1a.1(a))
- Violations of this policy shall be handled through the organization's sanctions process. (SA-1a.1(a))

## Procedures

The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall ensure that documented procedures exist to implement this policy and its associated controls. (SA-1a.2)

## Dissemination

- The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall disseminate this policy to [Fill in: personnel or roles to whom the system and services acquisition policy is to be disseminated. Typical: everyone within its scope, through the policy library]. (SA-1a)
- The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall disseminate the procedures that implement this policy to [Fill in: personnel or roles to whom the system and services acquisition procedures are to be disseminated. Typical: the people who carry them out, and the system owners]. (SA-1a)

## Policy statements

> **Guidance:** Each statement below comes from the clause for one control or enhancement in the chosen baseline. The reference at the end of each statement names the control item it meets.

### Allocation of resources (SA-2)

> **Guidance:** SA-2 makes security and privacy part of the business case for each system, not a cost found later. NIST's SA-2 discussion includes funding for acquisition, sustainment and supply chain risk across the whole life cycle. Evidence is the requirements in the planning documents and a separate security and privacy line in the budget request; the organization-wide side of this is PM-3.

- The [System owner] shall determine the high-level information security and privacy requirements for the system or system service during mission and business process planning, before an acquisition or development begins. (SA-2a)
- The [System owner] shall determine and document the resources required to protect the system or system service, including acquisition, sustainment and supply chain risk management costs across the system development life cycle, as part of the organization's capital planning and investment control process. (SA-2b)
- The [Senior leader] shall allocate the documented resources through the capital planning and investment control process, and record the reason for any shortfall. (SA-2b)
- The [Chief Information Security Officer] and the [Senior privacy official] shall ensure a discrete line item for information security and a discrete line item for privacy are established in the organization's programming and budgeting documentation for the system. (SA-2c)

#### 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.b(1) to (3), requires agencies to identify and plan for the resources needed to implement information security and privacy programs; to ensure that security and privacy are addressed throughout the life cycle of each agency information system, with security and privacy activities and costs identified and included in IT investment capital plans and budgetary requests; and to plan and budget to upgrade, replace or retire any system for which protections commensurate with risk cannot be effectively implemented. Section 4.e(6) requires the Senior Agency Official for Privacy to review IT capital investment plans and budgetary requests so that privacy requirements, and their costs, are explicitly identified and included. As of September 2026.

- The [System owner] shall identify the system's security and privacy activities and costs in its IT investment capital plan and budgetary requests, as OMB Circular A-130, Appendix I, section 4.b(2), requires. (SA-2b)
- For a system that processes personally identifiable information, the [Senior privacy official] shall review the system's IT capital investment plan and budgetary requests to confirm that privacy requirements and their costs are explicitly identified and included, as OMB Circular A-130, Appendix I, section 4.e(6), requires. (SA-2c)

### System development life cycle (SA-3)

> **Guidance:** The system development life cycle (SDLC) is where the Risk Management Framework's tasks happen: NIST SP 800-37 Rev. 2 ([December 2018](https://csrc.nist.gov/pubs/sp/800/37/r2/final), current as of September 2026) ties each RMF task to an SDLC phase, using the phase names in the typical value. NIST's SA-3 discussion calls for qualified security and privacy staff in SDLC processes and role-based training for them (AT-3). SA-3 leaves the life cycle model to the organization, iterative or sequential; what an assessor checks is that each phase has defined security and privacy activities and someone accountable for them.

- The [System owner] shall acquire, develop and manage the system using [Fill in: system development life cycle. Typical: the organization's documented system development life cycle, with security and privacy activities and a review gate in each phase: initiation, development or acquisition, implementation and assessment, operations and maintenance, and disposal] that incorporates information security and privacy considerations. (SA-3a)
- The [Chief Information Security Officer] and the [Senior privacy official] shall define and document the information security and privacy roles and responsibilities for each phase of the system development life cycle. (SA-3b)
- The [System owner] shall identify, in the system security plan, the individuals who hold information security and privacy roles and responsibilities for the system. (SA-3c)
- The [System owner] shall integrate the organization's information security and privacy risk management process into the system development life cycle, so that categorization, control selection, implementation, assessment, authorization and monitoring take place in the phases the risk management process assigns them to. (SA-3d)

#### 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.b(2), requires agencies to ensure that information security and privacy are addressed throughout the life cycle of each agency information system. As of September 2026.

- The [System owner] shall ensure information security and privacy are addressed in every phase of the system's life cycle, from planning and acquisition through operation, maintenance and disposal, as OMB Circular A-130, Appendix I, section 4.b(2), requires. (SA-3a)

### Acquisition process (SA-4)

> **Guidance:** SA-4 puts the security and privacy requirements into the contract, where a supplier is bound by them. NIST's SA-4 discussion derives the functional requirements from the high-level requirements set under SA-2, and points to NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems ([November 2022](https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final), current as of September 2026), for requirements engineering. Standard clauses keep contracts consistent; each acquisition still needs its own requirements, controls and acceptance criteria. Assessors sample recent contracts for a system and check each item a to i is present, in the text or by reference. The [acquisition security requirements](https://kston83.github.io/nist-guide/templates/standards/acquisition-security-requirements/) standard gives the standard contract requirements and the checklist for the solicitation review.

- The [System owner] shall include the following requirements, descriptions and criteria, 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 contract shall state the security and privacy functional requirements. (SA-4a)
- The contract shall state the strength of mechanism requirements, such as resistance to tampering, bypass and direct attack. (SA-4b)
- The contract shall state the security and privacy assurance requirements, including the development processes and the evidence from development and assessment that the supplier provides. (SA-4c)
- The contract shall state the controls needed to satisfy the security and privacy requirements, with any control parameter values the supplier must meet. (SA-4d)
- The contract shall state the security and privacy documentation requirements (SA-5). (SA-4e)
- The contract shall state the requirements for protecting security and privacy documentation. (SA-4f)
- The contract shall describe the system development environment and the environment in which the system is intended to operate. (SA-4g)
- The contract shall allocate responsibility for, or identify the parties responsible for, information security, privacy and supply chain risk management. (SA-4h)
- The contract shall state the acceptance criteria for the system, component or service. (SA-4i)
- The [Chief Information Security Officer] shall review each solicitation for a system, system component or system service for these requirements before it is issued, and the [Senior privacy official] shall review each one for a system that processes personally identifiable information. (SA-4)

> **Guidance:** NIST's SA-4 discussion also suggests other requirements that support security and operations: the responsibilities of the organization and the developer, and notice and timing for support, maintenance and updates. Add the time within which a supplier must report an incident or a vulnerability in its product, and how long it will provide security updates, since both drive IR-6 and SA-22.

#### 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 them to include 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. As of September 2026.

- The [System owner] shall ensure each contract or agreement involving Federal information incorporates 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 to require a secure software development attestation or a software bill of materials, following the agency's assurance policy under OMB M-26-05. (SA-4c)

<!-- TODO(verify): FAR contract requirements for IT security. The FAR as codified on acquisition.gov (FAC 2026-01, effective March 13, 2026) has 39.101(c), requiring agencies to include the appropriate information technology security policies and requirements, including use of common security configurations from NIST, in IT acquisitions, and the 52.239-1 clause at 39.106. Many agencies (for example GSA, Treasury, DOL and HUD) have issued Revolutionary FAR Overhaul class deviations for Part 39, and whether the deviation text keeps these requirements was not confirmed on 2026-09-29. Cite the FAR here once it is clear which text governs. -->

### Minimization (SA-8(33))

> **Guidance:** Minimization means processing only the personally identifiable information that is directly relevant and necessary to an authorized purpose, and keeping it only as long as that purpose needs, as NIST's SA-8(33) discussion puts it. SA-8(33) builds the principle into the design; SI-12(1) limits the elements a running system processes, and SI-12(2) limits personally identifiable information in testing, training and research. The minimization section of the [privacy impact assessment](https://kston83.github.io/nist-guide/templates/reports/privacy-impact-assessment/) is the usual record. SA-8(33) is in the Privacy baseline only.

- For a system that processes personally identifiable information, the [System owner] shall implement the privacy principle of minimization using [Fill in: processes that implement the privacy principle of minimization. Typical: the minimization review in the system's privacy impact assessment, which lists the data elements needed for each stated purpose and those left out, and the retention periods and disposal steps set under SI-12]. (SA-8(33))
- The [Senior privacy official] shall review the minimization decisions for each new system, and for each change that adds personally identifiable information or a new purpose, before the change is approved. (SA-8(33))

#### Federal systems

The Privacy Act requires each agency that maintains a system of records to "maintain in its records only such information about an individual as is relevant and necessary to accomplish a purpose of the agency required to be accomplished by statute or by executive order of the President" ([5 U.S.C. § 552a(e)(1)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title5-section552a&num=0&edition=prelim)). As of September 2026.

- For a system that contains a Privacy Act system of records, the [System owner] shall design the system to maintain only the information about individuals that is relevant and necessary to a purpose of the agency required by statute or executive order, as 5 U.S.C. § 552a(e)(1) requires. (SA-8(33))

### External system services (SA-9)

> **Guidance:** External system services are cloud platforms, software as a service, hosting, managed security and other services the system relies on but does not run. NIST's SA-9 discussion keeps the responsibility for their risk with the authorizing official, and has the organization document the basis of its trust in each provider so the relationship can be monitored. A shared responsibility matrix for each service, recorded in the system security plan as inherited, shared or system-owned controls, shows who does what. The [information exchange agreement](https://kston83.github.io/nist-guide/templates/forms/information-exchange-agreement/) (CA-3) covers the connection; this clause covers the provider. The [external service review](https://kston83.github.io/nist-guide/templates/forms/external-service-review/) records the review of each service before use and at each annual review, with a register of every external service.

- The [System owner] shall require that providers of external system services comply with the organization's security and privacy requirements and employ [Fill in: controls to be employed by external system service providers. Typical: the controls of the system's baseline that the provider is responsible for, per the shared responsibility matrix, with evidence from an independent attestation]. (SA-9a)
- The [System owner] shall record those requirements in the contract or service agreement before the service is used. (SA-9a)
- The [System owner] shall define and document the organization's oversight roles and responsibilities, and the user roles and responsibilities, for each external system service, including a shared responsibility matrix. (SA-9b)
- The [System owner] shall employ [Fill in: processes, methods, and techniques employed to monitor control compliance by external service providers. Typical: annual review of independent attestation reports, review of the provider's continuous monitoring or status reports, and contract service reviews] to monitor the provider's control compliance on an ongoing basis. (SA-9c)
- The [System owner] shall follow up each exception in a provider's attestation report, and each customer control the report expects the organization to operate, and record weaknesses that affect the system in its plan of action and milestones (CA-5). (SA-9c)

#### 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(2)(a) and (b), requires agencies to provide oversight of information systems used or operated by contractors or other entities on behalf of the Federal Government, including documented oversight policies and procedures and ensuring that the security and privacy controls of those systems and services are effectively implemented and comply with NIST standards and guidelines and agency requirements. 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), agencies must obtain and maintain a FedRAMP authorization for cloud products and services that create, collect, process, store or maintain federal information on the agency's behalf, unless the memo places them out of scope. As of September 2026.

- The [System owner] shall ensure each cloud product or service within the scope of OMB M-24-15 has a FedRAMP authorization before it processes federal information, and that the agency issues its own authorization to use it. (SA-9a)
- The [System owner] shall document the agency's oversight of each system a contractor or other entity operates on its behalf, and verify that its controls are effectively implemented, as OMB Circular A-130, Appendix I, section 4.j(2), requires. (SA-9c)

### Developer testing and evaluation (SA-11)

> **Guidance:** Developer testing finds flaws before the system reaches the assessor or the adversary. NIST's SA-11 discussion names the approaches: manual code review, security architecture review, penetration testing, and static, dynamic and binary analysis, with instrumentation and fuzzing. It defines depth as the rigor and detail of testing and coverage as the number and type of artifacts tested, and has contracts set acceptance criteria for the plans, the flaw remediation process and the evidence. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; as of September 2026), cites SA-11 for practices PW.7, reviewing and analyzing human-readable code, and PW.8, testing executable code.

- The [System owner] shall require the developer of the system, system component or system service, at all post-design stages of the system development life cycle, to develop and implement a plan for ongoing security and privacy control assessments. (SA-11a)
- The [System owner] 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)
- The [System owner] shall require the developer to produce evidence of the execution of the assessment plan and of the results of the testing and evaluation. (SA-11c)
- The [System owner] shall require the developer to implement a verifiable flaw remediation process. (SA-11d)
- The [System owner] shall require the developer to correct flaws identified during testing and evaluation, and shall not accept a release with an unresolved flaw unless the risk is accepted (RA-7). (SA-11e)
- For a system that processes personally identifiable information, the [System owner] shall ensure the developer's tests use test data prepared under SI-12(2), not live personally identifiable information, unless the [Senior privacy official] approves otherwise. (SA-11b)

## Review and update

- The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall review and update this policy [Fill in: the frequency at which the current system and services acquisition policy is reviewed and updated. Typical: annually] and following [Fill in: events that would require the current system and services acquisition policy to be reviewed and updated. Typical: assessment or audit findings, security incidents or breaches, and changes in applicable laws, executive orders, directives, regulations, policies, standards or guidelines]. (SA-1c.1)
- The [Fill in: an official to manage the system and services acquisition policy and procedures. Typical: Chief Information Security Officer] shall review and update the procedures that implement this policy [Fill in: the frequency at which the current system and services acquisition procedures are reviewed and updated. Typical: annually] and following [Fill in: events that would require the system and services acquisition procedures to be reviewed and updated. Typical: the same events as the policy, and changes to the systems, tools or services the procedures describe]. (SA-1c.2)

### Federal systems

For federal information systems, this policy also carries out the agency's information security responsibilities under the Federal Information Security Modernization Act of 2014 ([44 U.S.C. § 3554](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim), Federal agency responsibilities) and [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, Responsibilities for Protecting and Managing Federal Information Resources.

- Where the agency's organization-wide policy sets a value for a parameter in this policy, each system shall use that value or a stricter one. (SA-1a.1(b))