# System and Services Acquisition Policy

**Template version:** 1.0.0 · **Baseline:** Moderate · **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. -->

### Functional properties of controls (SA-4(1))

> **Guidance:** Functional properties are what a control does as seen at its interfaces: the security or privacy functions a user, administrator or other component can call on, not how the control works inside. NIST's SA-4(1) discussion excludes internal functions and data structures. The description lets the system owner check that each control the contract requires is actually delivered, and gives assessors something to test against.

- The [System owner] shall require the developer of the system, system component or system service, in the acquisition contract, to provide a description of the functional properties of the controls to be implemented. (SA-4(1))
- The [System owner] shall accept the description only when it covers every control the contract allocates to the developer. (SA-4(1))

### Design and implementation information for controls (SA-4(2))

> **Guidance:** NIST's SA-4(2) discussion describes the levels: high-level design is expressed in subsystems and the interfaces between them, low-level design in modules, and source code or hardware schematics are the implementation itself. Most commercial products provide interface and high-level design information only; ask for more where the system's risk warrants it, and say so in the solicitation. The discussion adds that the information can include the manufacturer, version, serial number, verification hash, software libraries used, and the date and source of purchase or download.

- The [System owner] shall require the developer of the system, system component or system service, in the acquisition contract, 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))
- The [System owner] shall protect the design and implementation information according to the system's security category, as the contract's documentation protection requirements set (SA-4f). (SA-4(2))

### Functions, ports, protocols and services in use (SA-4(9))

> **Guidance:** Knowing the functions, ports, protocols and services a product needs before it is bought lets the organization refuse risky ones early, instead of retrofitting controls later, as NIST's SA-4(9) discussion notes. The developer's list becomes the starting point for least functionality (CM-7) and for boundary protection rules (SC-7). For external services the matching requirement is SA-9(2).

- The [System owner] shall require the developer of the system, system component or system service to identify, early in the system development life cycle, the functions, ports, protocols and services intended for organizational use. (SA-4(9))
- The [System owner] shall review the list against the organization's prohibited and restricted functions, ports, protocols and services (CM-7) before the design or product is accepted, and record it in the system security plan. (SA-4(9))

### Use of approved PIV products (SA-4(10))

> **Guidance:** Personal Identity Verification (PIV) is the U.S. federal smart card credential, and the FIPS 201 Approved Products List names the products tested against its standard. An organization outside the federal government meets this enhancement where it implements PIV or PIV-interoperable capability; if the system implements none, record the enhancement as not applicable in the system security plan with that reason, as for IA-2(12).

- Where the system implements Personal Identity Verification (PIV) capability, the [System owner] shall employ only information technology products on the FIPS 201-approved products list for that capability. (SA-4(10))
- The [System owner] shall record the approved products list entry for each PIV product in the system's component inventory, and replace a product that is moved to the removed products list. (SA-4(10))

#### Federal systems

[FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final), Personal Identity Verification (PIV) of Federal Employees and Contractors (January 2022), states in its preamble (item 7) that FIPS 201 compliance of PIV components and subsystems is provided through products and services from the General Services Administration's approved products and services list, and in Appendix A.5 that products evaluated and approved under GSA's FIPS 201 Evaluation Program are placed on the [FIPS 201 Approved Products List](https://www.idmanagement.gov/fips201/) to promote the procurement of conformant products by agencies. As of September 2026.

- The [System owner] shall acquire PIV card products, readers and physical access control system products for the system only from the FIPS 201 Approved Products List that GSA maintains. (SA-4(10))

<!-- TODO(verify): FAR 4.1302(a) as codified on acquisition.gov (FAC 2026-01, effective March 13, 2026) reads "In order to comply with FIPS PUB 201, agencies must purchase only approved personal identity verification products and services." Confirm whether the Revolutionary FAR Overhaul deviation text for Part 4 keeps this before citing it here. -->

### System documentation (SA-5)

> **Guidance:** Administrator and user documentation is how the people who run and use a system learn to operate its security and privacy functions correctly. NIST's SA-5 discussion names system owners, system security officers and system administrators as the people who need it, and says the organization may need to recreate documentation it cannot obtain when that documentation is essential to operating the controls. Protect documentation that describes vulnerabilities more strictly than the rest.

- The [System owner] shall obtain or develop administrator documentation for the system, system component or system service that describes its secure configuration, installation and operation. (SA-5a.1)
- The administrator documentation shall describe the effective use and maintenance of the security and privacy functions and mechanisms. (SA-5a.2)
- The administrator documentation shall describe known vulnerabilities regarding the configuration and use of administrative or privileged functions. (SA-5a.3)
- The [System owner] shall obtain or develop user documentation that describes the user-accessible security and privacy functions and mechanisms, and how to use them effectively. (SA-5b.1)
- The user documentation shall describe methods of user interaction that let individuals use the system, component or service more securely and protect individual privacy. (SA-5b.2)
- The user documentation shall describe users' responsibilities for maintaining the security of the system, component or service and the privacy of individuals. (SA-5b.3)
- When documentation is unavailable or does not exist, the [System owner] shall document the attempts made to obtain it and [Fill in: actions to take when system, system component, or system service documentation is either unavailable or nonexistent. Typical: ask the manufacturer or supplier again and search its published material; where the documentation is essential to operating a control, write it in-house; and record any remaining gap as a risk in the risk register]. (SA-5c)
- The [System owner] shall distribute the documentation to [Fill in: personnel or roles to distribute system documentation to. Typical: the system owner, the system security officer and the system administrators]. (SA-5d)
- The [System owner] shall protect the documentation according to the system's security category, restricting documentation that describes vulnerabilities to those who need it. (SA-5)

#### 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.i(6), requires agencies to protect administrator, user and system documentation related to the design, development, testing, operation, maintenance and security of the hardware, firmware and software components of information systems. As of September 2026.

- The [System owner] shall protect the administrator, user and system documentation for the system's hardware, firmware and software components, as OMB Circular A-130, Appendix I, section 4.i(6), requires. (SA-5)

### Security and privacy engineering principles (SA-8)

> **Guidance:** NIST's SA-8 discussion lists examples of engineering principles: layered protections, security and privacy requirements built into the life cycle, clear physical and logical boundaries, developers trained to build secure software, and threat modeling. 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), describes 30 design principles in Appendix E, and says they are a basis for reasoning about a design, not rules to be complied with. For privacy, NIST IR 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems ([January 2017](https://csrc.nist.gov/pubs/ir/8062/final), current as of September 2026), sets out three privacy engineering objectives.

- The [System owner] shall apply the following systems security and privacy engineering principles in the specification, design, development, implementation and modification of the system and system components: [Fill in: systems security and privacy engineering principles. Typical: for security, the principles for trustworthy secure design in NIST SP 800-160 Vol. 1 Rev. 1, Appendix E, that the system's security architecture selects; for privacy, the objectives of predictability, manageability and disassociability from NIST IR 8062, and minimization (SA-8(33))]. (SA-8)
- The [System owner] shall record in the security and privacy architectures (PL-8) the principles applied to the system, and the reason for any principle not applied. (SA-8)
- For an existing system, the [System owner] shall apply the principles to upgrades and modifications to the extent feasible, given the current state of its hardware, software and firmware. (SA-8)

### 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)

### Identification of functions, ports, protocols and services (SA-9(2))

> **Guidance:** A provider's list of the functions, ports, protocols and services its service needs lets the organization weigh the trade-offs of blocking or restricting them, as NIST's SA-9(2) discussion notes. Use the list to set the boundary protection rules for the connection (SC-7) and to spot anything the service needs that the organization prohibits (CM-7).

- The [System owner] shall require providers of [Fill in: external system services that require the identification of functions, ports, protocols, and other services. Typical: all external system services that connect to the system] to identify the functions, ports, protocols and other services required for the use of those services. (SA-9(2))
- The [System owner] shall record each provider's list with the service in the system security plan, and update it when the provider changes the service. (SA-9(2))

### Developer configuration management (SA-10)

> **Guidance:** SA-10 applies configuration management to the developer, whether an outside supplier or an in-house team. NIST's SA-10 discussion treats the quality of the developer's configuration management as direct evidence that the controls work, and lists the configuration items to protect: design specifications, source code and hardware schematics, the running object code, comparison tools, and test fixtures and documentation. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; version 1.2 is a December 2025 draft; as of September 2026), cites SA-10 for practice PS.1, protecting all forms of code from unauthorized access and tampering.

- The [System owner] shall require the developer of the system, system component or system service to perform configuration management during [Select one or more: design; development; implementation; operation; disposal. Typical: design, development, implementation and operation]. (SA-10a)
- The [System owner] shall require the developer 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-10b)
- The [System owner] shall require the developer to implement only organization-approved changes to the system, component or service. (SA-10c)
- The [System owner] shall require the developer to document approved changes and their potential security and privacy impacts. (SA-10d)
- The [System owner] shall require the developer to track security flaws and flaw resolution within the system, component or service, and report 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-10e)
- The [System owner] shall ensure developer changes to an operational system go through the system's configuration change control (CM-3). (SA-10c)

### 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)

### Development process, standards and tools (SA-15)

> **Guidance:** SA-15 asks for a development process that is written down, addresses security and privacy, and keeps its own tools under control, since a compromised build tool compromises everything it builds. NIST's SA-15 discussion says reviews of the process can use maturity models, and that controlling changes to tools supports supply chain risk management. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; version 1.2 is a December 2025 draft; as of September 2026), cites SA-15 for its Prepare the Organization practices, including PO.1, defining security requirements for software development, and PO.3, implementing supporting toolchains. The organization's own secure development policy and standard, based on the SSDF, are Phase 4 templates.

- The [System owner] shall require the developer of the system, system component or system service to follow a documented development process that explicitly addresses security and privacy requirements. (SA-15a.1)
- The documented process shall identify the standards and tools used in the development process. (SA-15a.2)
- The documented process shall document the specific tool options and tool configurations used in the development process. (SA-15a.3)
- The documented process shall document, manage and ensure the integrity of changes to the process and the tools used in development. (SA-15a.4)
- The [System owner] shall review the development process, standards, tools, tool options and tool configurations [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] to determine whether they can satisfy [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)
- The [System owner] shall record each review's findings, and track any shortfall to correction in the plan of action and milestones. (SA-15b)

#### Federal systems

[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 OMB M-22-18 and M-23-16. It states that each agency should validate provider security using secure development principles and a comprehensive risk assessment, requires agencies to develop software and hardware assurance policies and processes that match their risk determinations and mission needs, and names NIST SP 800-218 as a reference. As of September 2026.

- The [Chief Information Security Officer] shall base the security requirements used under SA-15b on the agency's software and hardware assurance policy under OMB M-26-05, and on a risk assessment of the system. (SA-15b)

### Criticality analysis (SA-15(3))

> **Guidance:** The developer's criticality analysis feeds the organization's own (RA-9), which often cannot see inside commercial products. NIST's SA-15(3) discussion says developer input is especially important for supply chain criticality analyses and for systems designated as high value assets. The decision points here match those in the RA-9 clause, so both analyses are updated together.

- The [System owner] shall require the developer of the system, system component or system service 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]. (SA-15(3)(a))
- The [System owner] shall require the developer's criticality analysis to cover the following breadth and depth: [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)(b))
- The [System owner] shall use the developer's results in the organization's criticality analysis (RA-9). (SA-15(3))

### Unsupported system components (SA-22)

> **Guidance:** An unsupported component gets no security updates, so each new vulnerability in it stays open. NIST's SA-22 discussion allows exceptions only where no newer technology exists for a critical capability or the system is too isolated to replace, and suggests isolation, such as no connection to public or uncontrolled networks, to reduce the risk. Track each component's end-of-support date in the component inventory (CM-8), and treat an unsupported component as a flaw under the [patch and flaw remediation standard](https://kston83.github.io/nist-guide/templates/standards/patch-and-flaw-remediation-standard/) until it is replaced.

- The [System owner] shall replace system components when support for them is no longer available from the developer, vendor or manufacturer. (SA-22a)
- The [System owner] shall plan and budget each replacement before the component's announced end-of-support date. (SA-22a)
- Where a component cannot be replaced by its end-of-support date, the [System owner] shall provide the following options for alternative sources of continued support: [Select one or more: in-house support; [Assignment: organization-defined support from external providers]. Typical: support from an external provider under contract, such as extended vendor support or a third-party support provider; in-house support only for an isolated component whose replacement is scheduled]. (SA-22b)
- The authorizing official shall approve each continued use of an unsupported component, for a set period, with the compensating measures recorded and the replacement tracked in the plan of action and milestones. (SA-22b)

#### 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.i(8), requires agencies to prohibit the use of unsupported information systems and system components, and to give systems and components that cannot be appropriately protected a high priority for upgrade or replacement; section 5.p allows the same exceptions as NIST's SA-22 discussion, with in-house or contracted support for them. CISA [Binding Operational Directive 26-02](https://www.cisa.gov/news-events/directives/bod-26-02-mitigating-risk-end-support-edge-devices), Mitigating Risk From End-of-Support Edge Devices (February 5, 2026), covers edge devices: devices on the boundary of an agency's network that are reachable from the public internet. It requires agencies to update supported devices running end-of-support software immediately; to inventory devices on CISA's end-of-support edge device list within 3 months; to decommission listed devices and report to CISA within 12 months; to decommission every end-of-support edge device within 18 months; and, within 24 months, to keep a continuous discovery process and inventory and decommission each edge device by its end-of-support date. As of September 2026.

- The [System owner] shall not use an unsupported system component except under an exception that OMB Circular A-130, Appendix I, section 5.p, allows, approved by the authorizing official. (SA-22a)
- The [System owner] shall inventory the system's edge devices, replace or decommission each one that is end of support, and report each decommission to CISA, by the deadlines BOD 26-02 sets. (SA-22a)
- From the directive's 24-month deadline, the [System owner] shall decommission each edge device on or before its end-of-support date, as BOD 26-02 requires. (SA-22a)

## 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))