System and Services Acquisition Policy

System and Services Acquisition Policy template: Ready-to-adopt System and Services Acquisition policy template for NIST SP 800-53 Rev. 5, with a statement group for each control and a variant per baseline (Low, Moderate, High, Privacy).

Type	Program stage	Status	Template version	NIST basis
Policy	Operate	Draft	1.0.0	SP 800-53 release 5.2.0

What it is

The System and Services Acquisition policy states what the organization requires for system and services acquisition and who is accountable for it. It meets SA-1 through the sections every family policy shares, and adds one statement group per control. Each baseline variant includes only the controls in that baseline, taken from the NIST SP 800-53B profiles.

Adopt the ready-to-adopt edition: fill every highlighted field, delete any “Federal systems” section that does not apply, and have the accountable official approve it. The annotated edition adds guidance on why each section exists and what assessors look for.

Controls satisfied

“Yes” marks the baseline variants that include the control’s statements. SA-1 is met by the common sections.

Control	Title	Low	Moderate	High	Privacy
SA-1	Policy and Procedures	Yes	Yes	Yes	Yes
SA-2	Allocation of Resources	Yes	Yes	Yes	Yes
SA-3	System Development Life Cycle	Yes	Yes	Yes	Yes
SA-4	Acquisition Process	Yes	Yes	Yes	Yes
SA-4(1)	Functional Properties of Controls		Yes	Yes
SA-4(2)	Design and Implementation Information for Controls		Yes	Yes
SA-4(5)	System, Component, and Service Configurations			Yes
SA-4(9)	Functions, Ports, Protocols, and Services in Use		Yes	Yes
SA-4(10)	Use of Approved PIV Products	Yes	Yes	Yes
SA-5	System Documentation	Yes	Yes	Yes
SA-8	Security and Privacy Engineering Principles	Yes	Yes	Yes
SA-8(33)	Minimization				Yes
SA-9	External System Services	Yes	Yes	Yes	Yes
SA-9(2)	Identification of Functions, Ports, Protocols, and Services		Yes	Yes
SA-10	Developer Configuration Management		Yes	Yes
SA-11	Developer Testing and Evaluation		Yes	Yes	Yes
SA-15	Development Process, Standards, and Tools		Yes	Yes
SA-15(3)	Criticality Analysis		Yes	Yes
SA-16	Developer-provided Training			Yes
SA-17	Developer Security and Privacy Architecture and Design			Yes
SA-21	Developer Screening			Yes
SA-22	Unsupported System Components	Yes	Yes	Yes

Decisions to make first

The policy has 41 organization-defined parameters across all variants; each appears as a highlighted field with its typical value where one is given. Settle these first:

Decision	Controls	Typical	Who decides
Which system development life cycle do systems follow, and where in it are the security and privacy activities and approvals?	SA-3, SA-8, SA-15	One organization-wide life cycle with five phases (initiation, development or acquisition, implementation and assessment, operations and maintenance, and disposal), each with named security and privacy activities and a gate the system owner cannot pass without the security and privacy reviews.	Chief Information Officer, with the Chief Information Security Officer and the senior privacy official
Who maintains the standard security and privacy contract language, and who checks that each acquisition uses it?	SA-4, SA-4(1), SA-4(2), SA-4(9), SA-4(10)	The procurement office keeps standard clauses that the Chief Information Security Officer and the senior privacy official approve; the system owner adds system-specific requirements, and the security team reviews each solicitation for a system, component or service before it is issued.	Chief Information Security Officer, with the procurement office
Who reviews an external service before the organization uses it, and how is the provider’s compliance checked afterwards?	SA-9, SA-9(2)	The security team reviews each new external service and its shared responsibility matrix before contract award; the system owner reviews the provider’s independent attestation reports each year and the provider’s status reports as they arrive.	Chief Information Security Officer
What must developers of custom systems and components deliver as evidence, and who reviews it?	SA-10, SA-11, SA-15, SA-15(3)	Configuration management records, the developer’s test plan and results (including static analysis, component analysis and dynamic testing), the flaw tracking record and the development tool list, reviewed by the system owner and the security team before each release is accepted.	System owner, with the Chief Information Security Officer
What happens to a component when its vendor stops supporting it, and who can approve keeping it?	SA-22	The component is replaced before its end-of-support date; where that is not possible, the authorizing official may approve continued use for a set period, with extended support from an external provider, isolation and extra monitoring, recorded in the plan of action and milestones.	Authorizing official

Record your values in the System and Services Acquisition decision worksheet, which lists every parameter with its typical value.

Downloads

Variant	Ready to adopt	Annotated
Low	Word · Markdown	Word · Markdown
Moderate	Word · Markdown	Word · Markdown
High	Word · Markdown	Word · Markdown
Privacy	Word · Markdown	Word · Markdown

Everything for this family in one file: SA pack (.zip), with every variant and edition of the policy and the decision worksheets.

Preview (Moderate baseline, annotated)

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

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

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, 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, 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, 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 (CA-3) covers the connection; this clause covers the provider. The 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, 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, 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, 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, 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, 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, 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 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, 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, 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, Federal agency responsibilities) and OMB Circular A-130, 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))