SA-15 Development Process, Standards, and Tools

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	Organization	11 (1 in a baseline)

Related controls: MA-6, SA-3, SA-4, SA-8, SA-10, SA-11, SR-3, SR-4, SR-5, SR-6, SR-9

Control statement

• a. Require the developer of the system, system component, or system service to follow a documented development process that:
  • 1. Explicitly addresses security and privacy requirements;
  • 2. Identifies the standards and tools used in the development process;
  • 3. Documents the specific tool options and tool configurations used in the development process; and
  • 4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and
• b. Review the development process, standards, tools, tool options, and tool configurations [Assignment: organization-defined frequency] to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: [Assignment: organization-defined security and privacy requirements].

NIST discussion

Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.

Control enhancements

SA-15(1) Quality Metrics

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to:

• (a) Define quality metrics at the beginning of the development process; and
• (b) Provide evidence of meeting the quality metrics [Selection (one or more): [Assignment: organization-defined frequency] ; [Assignment: organization-defined program review] ; upon delivery].

Discussion and assessment objectives for SA-15(1)

Organizations use quality metrics to establish acceptable levels of system quality. Metrics can include quality gates, which are collections of completion criteria or sufficiency standards that represent the satisfactory execution of specific phases of the system development project. For example, a quality gate may require the elimination of all compiler warnings or a determination that such warnings have no impact on the effectiveness of required security or privacy capabilities. During the execution phases of development projects, quality gates provide clear, unambiguous indications of progress. Other metrics apply to the entire development project. Metrics can include defining the severity thresholds of vulnerabilities in accordance with organizational risk tolerance, such as requiring no known vulnerabilities in the delivered system with a Common Vulnerability Scoring System (CVSS) severity of medium or high.

Determine if:

• SA-15(01)(a) the developer of the system, system component, or system service is required to define quality metrics at the beginning of the development process;
• SA-15(01)(b) the developer of the system, system component, or system service is required to provide evidence of meeting the quality metrics [Selection (one or more): [Assignment: organization-defined frequency] ; [Assignment: organization-defined program review] ; upon delivery].

Examine: System and services acquisition policy; procedures addressing development process, standards, and tools; procedures addressing the integration of security requirements into the acquisition process; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; list of quality metrics; documentation evidence of meeting quality metrics; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer.

SA-15(2) Security and Privacy Tracking Tools

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to select and employ security and privacy tracking tools for use during the development process.

Discussion and assessment objectives for SA-15(2)

System development teams select and deploy security and privacy tracking tools, including vulnerability or work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with development processes.

Determine if:

• SA-15(02)[01] the developer of the system, system component, or system service is required to select and employ security tracking tools for use during the development process;
• SA-15(02)[02] the developer of the system, system component, or system service is required to select and employ privacy tracking tools for use during the development process.

Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing development process, standards, and tools; procedures addressing the integration of security and privacy requirements into the acquisition process; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; documentation of the selection of security and privacy tracking tools; evidence of employing security and privacy tracking tools; system security plan; privacy plan; privacy impact assessment; privacy risk assessment documentation; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with privacy responsibilities.

SA-15(3) Criticality Analysis

Baselines: Moderate, High

Require the developer of the system, system component, or system service to perform a criticality analysis:

• (a) At the following decision points in the system development life cycle: [Assignment: organization-defined decision points] ; and
• (b) At the following level of rigor: [Assignment: organization-defined breadth and depth of criticality analysis].

Discussion and assessment objectives for SA-15(3)

Criticality analysis performed by the developer provides input to the criticality analysis performed by organizations. Developer input is essential to organizational criticality analysis because organizations may not have access to detailed design documentation for system components that are developed as commercial off-the-shelf products. Such design documentation includes functional specifications, high-level designs, low-level designs, source code, and hardware schematics. Criticality analysis is important for organizational systems that are designated as high value assets. High value assets can be moderate- or high-impact systems due to heightened adversarial interest or potential adverse effects on the federal enterprise. Developer input is especially important when organizations conduct supply chain criticality analyses.

Determine if:

• SA-15(03)(a) the developer of the system, system component, or system service is required to perform a criticality analysis at [Assignment: organization-defined decision points] in the system development life cycle;
• SA-15(03)(b)
  • SA-15(03)(b)[01] the developer of the system, system component, or system service is required to perform a criticality analysis at the following rigor level: [Assignment: organization-defined breadth];
  • SA-15(03)(b)[02] the developer of the system, system component, or system service is required to perform a criticality analysis at the following rigor level: [Assignment: organization-defined depth] .

Examine: Supply chain risk management plan; system and services acquisition policy; procedures addressing development process, standards, and tools; procedures addressing criticality analysis requirements for the system, system component, or system service; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; criticality analysis documentation; business impact analysis documentation; software development life cycle documentation; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel responsible for performing criticality analysis; system developer; organizational personnel with supply chain risk management responsibilities.

Test: Organizational processes for performing criticality analysis; mechanisms supporting and/or implementing criticality analysis.

SA-15(5) Attack Surface Reduction

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to reduce attack surfaces to [Assignment: organization-defined thresholds].

Discussion and assessment objectives for SA-15(5)

Attack surface reduction is closely aligned with threat and vulnerability analyses and system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within systems, system components, and system services. Attack surface reduction includes implementing the concept of layered defenses, applying the principles of least privilege and least functionality, applying secure software development practices, deprecating unsafe functions, reducing entry points available to unauthorized users, reducing the amount of code that executes, and eliminating application programming interfaces (APIs) that are vulnerable to attacks.

Determine if the developer of the system, system component, or system service is required to reduce attack surfaces to [Assignment: organization-defined thresholds].

Examine: System and services acquisition policy; procedures addressing development process, standards, and tools; procedures addressing attack surface reduction; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system or system service; system design documentation; network diagram; system configuration settings and associated documentation establishing/enforcing organization-defined thresholds for reducing attack surfaces; list of restricted ports, protocols, functions, and services; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; organizational personnel responsible for attack surface reduction thresholds; system developer.

Test: Organizational processes for defining attack surface reduction thresholds.

SA-15(6) Continuous Improvement

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to implement an explicit process to continuously improve the development process.

Discussion and assessment objectives for SA-15(6)

Developers of systems, system components, and system services consider the effectiveness and efficiency of their development processes for meeting quality objectives and addressing the security and privacy capabilities in current threat environments.

Determine if the developer of the system, system component, or system service is required to implement an explicit process to continuously improve the development process.

Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing development process, standards, and tools; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; quality goals and metrics for improving the system development process; security assessments; quality control reviews of system development process; plans of action and milestones for improving the system development process; system security plan; privacy plan; privacy impact assessment; privacy risk assessment documentation; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer.

SA-15(7) Automated Vulnerability Analysis

Baselines: Not in a baseline

Require the developer of the system, system component, or system service [Assignment: organization-defined frequency] to:

• (a) Perform an automated vulnerability analysis using [Assignment: organization-defined tools];
• (b) Determine the exploitation potential for discovered vulnerabilities;
• (c) Determine potential risk mitigations for delivered vulnerabilities; and
• (d) Deliver the outputs of the tools and results of the analysis to [Assignment: organization-defined personnel or roles].

Discussion and assessment objectives for SA-15(7)

Automated tools can be more effective at analyzing exploitable weaknesses or deficiencies in large and complex systems, prioritizing vulnerabilities by severity, and providing recommendations for risk mitigations.

Determine if:

• SA-15(07)(a) the developer of the system, system component, or system service is required to perform automated vulnerability analysis [Assignment: organization-defined frequency] using [Assignment: organization-defined tools];
• SA-15(07)(b) the developer of the system, system component, or system service is required to determine the exploitation potential for discovered vulnerabilities [Assignment: organization-defined frequency];
• SA-15(07)(c) the developer of the system, system component, or system service is required to determine potential risk mitigations [Assignment: organization-defined frequency] for delivered vulnerabilities;
• SA-15(07)(d) the developer of the system, system component, or system service is required to deliver the outputs of the tools and results of the analysis [Assignment: organization-defined frequency] to [Assignment: organization-defined personnel or roles].

Examine: System and services acquisition policy; procedures addressing development process, standards, and tools; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; vulnerability analysis tools and associated documentation; risk assessment reports; vulnerability analysis results; vulnerability mitigation reports; risk mitigation strategy documentation; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel performing automated vulnerability analysis on the system.

Test: Organizational processes for vulnerability analysis of systems, system components, or system services under development; mechanisms supporting and/or implementing vulnerability analysis of systems, system components, or system services under development.

SA-15(8) Reuse of Threat and Vulnerability Information

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process.

Discussion and assessment objectives for SA-15(8)

Analysis of vulnerabilities found in similar software applications can inform potential design and implementation issues for systems under development. Similar systems or system components may exist within developer organizations. Vulnerability information is available from a variety of public and private sector sources, including the NIST National Vulnerability Database.

Determine if:

• SA-15(08)[01] the developer of the system, system component, or system service is required to use threat modeling from similar systems, components, or services to inform the current development process;
• SA-15(08)[02] the developer of the system, system component, or system service is required to use vulnerability analyses from similar systems, components, or services to inform the current development process.

Examine: System and services acquisition policy; supply chain risk management plan; procedures addressing development process, standards, and tools; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; threat modeling and vulnerability analyses from similar systems, system components, or system services; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with supply chain risk management responsibilities.

SA-15(10) Incident Response Plan

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to provide, implement, and test an incident response plan.

Discussion and assessment objectives for SA-15(10)

The incident response plan provided by developers may provide information not readily available to organizations and be incorporated into organizational incident response plans. Developer information may also be extremely helpful, such as when organizations respond to vulnerabilities in commercial off-the-shelf products.

Determine if:

• SA-15(10)[01] the developer of the system, system component, or system service is required to provide an incident response plan;
• SA-15(10)[02] the developer of the system, system component, or system service is required to implement an incident response plan;
• SA-15(10)[03] the developer of the system, system component, or system service is required to test an incident response plan.

Examine: System and services acquisition policy; procedures addressing incident response, standards, and tools; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system components or services; acquisition documentation; solicitation documentation; service level agreements; developer incident response plan; system security plan; privacy plan; supply chain risk management plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with supply chain risk management responsibilities.

SA-15(11) Archive System or Component

Baselines: Not in a baseline

Require the developer of the system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security and privacy review.

Discussion and assessment objectives for SA-15(11)

Archiving system or system components requires the developer to retain key development artifacts, including hardware specifications, source code, object code, and relevant documentation from the development process that can provide a readily available configuration baseline for system and component upgrades or modifications.

Determine if the developer of the system or system component is required to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security and privacy review.

Examine: System and services acquisition policy; procedures addressing development process, standards, and tools; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system or system component; evidence of archived system or component; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with privacy responsibilities.

SA-15(12) Minimize Personally Identifiable Information

Baselines: Not in a baseline

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.

Discussion and assessment objectives for SA-15(12)

Organizations can minimize the risk to an individual’s privacy by using techniques such as de-identification or synthetic data. Limiting the use of personally identifiable information in development and test environments helps reduce the level of privacy risk created by a system.

Determine if the developer of the system or system component is required to minimize the use of personally identifiable information in development and test environments.

Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing the development process; procedures addressing the minimization of personally identifiable information in testing, training, and research; personally identifiable information processing policy; procedures addressing the authority to test with personally identifiable information; standards and tools; solicitation documentation; service level agreements; acquisition contracts for the system or services; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer.

Test: Organizational processes for the minimization of personally identifiable information in development and test environments; mechanisms to facilitate the minimization of personally identifiable information in development and test environments.

SA-15(13) Logging Syntax

Baselines: Not in a baseline

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.

Discussion and assessment objectives for SA-15(13)

In support of better incident response and the ability to more quickly reconstruct security-related actions, identifying specific requirements for secure logging facilitates the ability to connect application-produced audit event logs with operational data. Event types are consistent with the event types defined in AU-02.

Determine if Determine if:

the developer of the system, system component, or system service uses [Assignment: organization-defined secure logging format(s)] to log [Assignment: organization-defined events types to log] at [Assignment: organization-defined level of detail to log].

Examine: System and services acquisition policy;; solicitation documentation;; acquisition documentation;; service level agreements;; acquisition contracts for the system, system component, or system service;; requirements for logging format, event types, and level of detail;; documentation evidence of requirements for logging format, event types, and level of detail;; system security plan; other relevant documents or records..

Interview: Organizational personnel with system and service acquisition responsibilities;; organizational personnel with information security responsibilities;; system developer.

Test: Developer logs for the system, system component, or system service..

Withdrawn enhancements: SA-15(4), SA-15(9).

Assessment objectives (SP 800-53A)

Objectives and methods for SA-15

Determine if:

• SA-15a.
  • SA-15a.01
    • SA-15a.01[01] the developer of the system, system component, or system service is required to follow a documented development process that explicitly addresses security requirements;
    • SA-15a.01[02] the developer of the system, system component, or system service is required to follow a documented development process that explicitly addresses privacy requirements;
  • SA-15a.02
    • SA-15a.02[01] the developer of the system, system component, or system service is required to follow a documented development process that identifies the standards used in the development process;
    • SA-15a.02[02] the developer of the system, system component, or system service is required to follow a documented development process that identifies the tools used in the development process;
  • SA-15a.03
    • SA-15a.03[01] the developer of the system, system component, or system service is required to follow a documented development process that documents the specific tool used in the development process;
    • SA-15a.03[02] the developer of the system, system component, or system service is required to follow a documented development process that documents the specific tool configurations used in the development process;
  • SA-15a.04 the developer of the system, system component, or system service is required to follow a documented development process that documents, manages, and ensures the integrity of changes to the process and/or tools used in development;
• SA-15b.
  • SA-15b.[01] the developer of the system, system component, or system service is required to follow a documented development process in which the development process, standards, tools, tool options, and tool configurations are reviewed [Assignment: organization-defined frequency] to determine that the process, standards, tools, tool options, and tool configurations selected and employed satisfy [Assignment: organization-defined security requirements];
  • SA-15b.[02] the developer of the system, system component, or system service is required to follow a documented development process in which the development process, standards, tools, tool options, and tool configurations are reviewed [Assignment: organization-defined frequency] to determine that the process, standards, tools, tool options, and tool configurations selected and employed satisfy [Assignment: organization-defined privacy requirements].

Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing development process, standards, and tools; procedures addressing the integration of security and privacy requirements during the development process; solicitation documentation; acquisition documentation; critical component inventory documentation; service level agreements; acquisition contracts for the system, system component, or system service; system developer documentation listing tool options/configuration guides; configuration management policy; configuration management records; documentation of development process reviews using maturity models; change control records; configuration control records; documented reviews of the development process, standards, tools, and tool options/configurations; system security plan; privacy plan; privacy impact assessment; privacy risk assessment documentation; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer.

Policy statement

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

SA-15(3) Criticality analysis

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

From the System and Services Acquisition Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SA-15 asks you to require a documented development process that addresses security and privacy, names its standards and tools, records the tool options and configurations, and controls changes to the process and tools. Then review the process and tools on a set schedule against your security and privacy requirements. NIST’s SA-15 discussion says reviews can use maturity models, and that controlling changes to tools and processes supports supply chain risk management. A compromised build tool compromises everything it builds.

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. It is a common basis for the documented process and for the review in item b. A secure software development policy and SDLC standard based on the SSDF are planned for the site’s methods strand.

Common implementations. A secure development standard for in-house teams, covering coding standards, required reviews and security testing. A toolchain inventory listing the languages, frameworks, compilers, build and pipeline tools, and scanners, with their versions and security-relevant settings, kept in source control. Changes to pipeline templates and tool settings go through review like code changes. For an outside developer, the contract (SA-4) requires the same, and the developer shares its process description. An annual review, often a self-assessment against the SSDF practices, with gaps tracked in the plan of action and milestones.

Organization-defined parameters. Typical values, which your organization may set differently:

Parameter	Typical value
Review frequency (b)	At least annually, and before a new development tool or a major change to the development process is adopted
Security requirements the process must satisfy (b)	The security requirements in the acquisition contract (SA-4) and the organization’s secure software development practices
Privacy requirements the process must satisfy (b)	The privacy requirements recorded in the system’s privacy impact assessment
Decision points for criticality analysis (SA-15(3))	During design, before acquiring major components or services, and when the architecture changes significantly
Breadth of criticality analysis (SA-15(3))	The components and functions that support the system’s critical functions, including third-party and open-source components
Depth of criticality analysis (SA-15(3))	Down to the component and software module level for each critical function, naming the supplier of each critical component

In the System and Services Acquisition policy, the system owner requires the documented process, runs the review and tracks shortfalls to correction.

Evidence assessors ask for.

• The developer’s documented development process, and the standards and tools it names
• The tool options and configurations in use, such as the pipeline and scanner settings
• Change records for the process and the tools
• The results of the last review, with the shortfalls found and their plan of action and milestones items
• The developer’s criticality analysis, and how it fed the organization’s own (SA-15(3))

Inheritance. A shared development standard and toolchain may be common controls for in-house teams. For a commercial product, the supplier performs SA-15 and the organization relies on the contract and the supplier’s evidence. The system owns the review.

Common findings.

• A development process that exists only in people’s heads.
• No list of tools or their settings, so no one can tell when a scanner rule was switched off.
• Build tools and pipeline plugins updated without review.
• No review of the process, or reviews with no follow-up on the gaps found.

Enhancements in the Moderate baseline. SA-15(3) criticality analysis, also in High. The developer’s analysis feeds the organization’s own under RA-9, which often cannot see inside commercial products. NIST’s SA-15(3) discussion says developer input matters most for supply chain criticality analyses and for high value assets. The decision points match those in the RA-9 clause, so both analyses are updated together. SA-15(1), (2), (5) to (8) and (10) to (13) are in no baseline.

Federal systems (as of September 2026). 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. It 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. Base the requirements used in the SA-15 review on the agency’s assurance policy and a risk assessment of the system.

Artifacts

• Acquisition Security Requirements
• System and Services Acquisition Decision Worksheet
• System and Services Acquisition Policy