Quick-reference card
| Field | Value |
|---|---|
| Control ID | SA-15 |
| Control name | Development Process, Standards, and Tools |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | System and Services Acquisition |
| Baselines | MODERATE HIGH |
| Relevance | Organization (Third Party) |
| Risk severity | Medium |
What this control requires
SA-15 requires organizations to ensure their developers follow a documented development process that addresses security and privacy, tracks tooling decisions, and controls changes. The control applies whether that developer is an internal team or an outsourced provider building systems on your behalf.
In practice, this control means you can’t accept a vendor’s claim that they “follow best practices” without evidence. You need to see their documented development process, know which tools and configurations they use, and confirm they track changes to both the process and the tooling. Organizations must also review these elements on a defined schedule to verify they still satisfy your security and privacy requirements.
The review component is what separates SA-15 from a one-time checkbox. Development environments evolve constantly, with new tools, updated configurations, and shifting standards. Without periodic reviews, a process that met your requirements at contract signing may drift into non-compliance within months. SA-15 ensures that oversight keeps pace with the System and Services Acquisition family’s broader goal of embedding security into every phase of system procurement and development.
Why it matters
Most organizations can name the tools their developers use but can’t produce documentation proving those tools are configured securely or that changes to them are tracked. That gap between assumed and demonstrated control over the development process is exactly where compliance risk concentrates under SA-15. The control sits within the System and Services Acquisition family because insecure development practices represent an acquisition risk, not just an engineering problem.
Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. When auditors evaluate SA-15, they look for a documented chain connecting your security requirements to the specific tool configurations and process steps that satisfy those requirements. Missing links in that chain create findings that can delay or block authority to operate (ATO) decisions.
The risk compounds in outsourced development scenarios, where you inherit the security posture of your vendor’s development environment without direct visibility. If a third-party developer lacks configuration control over their build tools or can’t demonstrate integrity of changes to their development process, your system inherits that exposure.
Beyond audit consequences, weak development process controls create real operational risk. Untracked changes to build configurations, unvetted development tools, and undocumented process modifications all expand the attack surface of the systems those developers produce. Organizations that skip maturity model reviews or treat development process documentation as static lose the ability to detect drift before it becomes an exploitable weakness.
What attackers exploit
- Unmanaged or untracked changes to build tools and CI/CD pipeline configurations, allowing injection of malicious code during the build process
- Development environments where tool options and configurations aren’t documented, making it harder to detect unauthorized modifications
- Gaps between documented development standards and actual practice, which create blind spots in security testing
- Lack of configuration control over development tools, enabling supply chain attacks through compromised dependencies or plugins
- Absence of periodic development process reviews, leaving outdated or insecure tooling in place long after vulnerabilities are discovered
How to implement
For your vendors
The most common failure mode in third-party SA-15 compliance is accepting a vendor’s generic “we follow secure development practices” statement without requesting the specific documentation this control demands. Vendor self-attestation alone doesn’t satisfy SA-15’s requirement for documented, reviewable, and integrity-controlled development processes.
What to ask in a security questionnaire:
- Do you maintain a documented development process that explicitly addresses security and privacy requirements?
- What development standards do you follow, and where are they documented?
- Can you provide a list of development tools, their specific configurations, and the rationale for each configuration choice?
- How do you track and authorize changes to your development process and tooling?
- What is the frequency and scope of your development process reviews?
- Do you use maturity models to evaluate the effectiveness of your development processes?
What evidence to request:
- The documented development process itself, including sections addressing security and privacy requirements
- A development tool inventory listing tool names, versions, and configuration guides
- Configuration management records showing tracked changes to tools and processes
- Records of periodic development process reviews, including the criteria used and findings
- Service level agreements or contract clauses requiring adherence to specified development standards
Red flags to watch for:
- The vendor can name their tools but can’t produce configuration documentation for them
- No evidence of change control for the development process itself
- Development process reviews are ad hoc rather than scheduled at a defined frequency
- Security and privacy requirements aren’t traceable to specific process steps or tool configurations
- The vendor treats this control as a one-time documentation exercise rather than an ongoing integrity requirement
How to verify beyond self-attestation:
Request configuration management records alongside the vendor’s development process documentation. A vendor risk management platform can centralize this evidence collection and flag when a vendor’s documentation doesn’t align with what their security posture reveals externally. Cross-reference the vendor’s stated development tools against their actual attack surface to identify undisclosed or shadow development infrastructure. Review their change control records for completeness, looking specifically for whether changes to tools and configurations are approved before implementation and whether those approvals reference the security requirements from NIST SP 800-53.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Development process documentation | Documented secure development lifecycle (SDLC) policy specifying security and privacy requirements, assigned roles, and review cadence |
| Tool inventory and configuration guides | Spreadsheet or configuration management database listing all development tools with version numbers, approved configurations, and justification for each setting |
| Change control records | Change management log documenting all modifications to development tools, configurations, and processes with approval signatures and dates |
| Standards and procedures | Development standards document identifying coding standards, security testing protocols, and tool usage guidelines |
| Process review records | Completed review reports evaluating development processes against security and privacy requirements, including maturity model assessments |
| Acquisition and contract documentation | Solicitation documents, acquisition contracts, and service level agreements specifying required development practices and tool standards |
| Configuration integrity evidence | Configuration control records demonstrating that tool settings match approved baselines and unauthorized changes trigger alerts |
| System security and privacy plans | System security plan and privacy plan sections addressing SA-15 implementation, including roles, responsibilities, and review frequency |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.8 Information security in project management | Partial |
| ISO 27001:2022 | 8.25 Secure development life cycle | Partial |
| ISO 27001:2022 | 8.30 Outsourced development | Partial |
Related controls
- MA-06 — Timely Maintenance: Ensures maintenance activities that affect development environments are performed within defined timeframes, protecting the integrity of the tools and configurations SA-15 requires you to document.
- SA-03 — System Development Life Cycle: Defines the overarching lifecycle framework within which SA-15’s documented development processes operate.
- SA-04 — Acquisition Process: Establishes the contractual basis for requiring vendors to follow the development standards and tool configurations SA-15 mandates.
- SA-08 — Security and Privacy Engineering Principles: Provides the security engineering principles that SA-15’s documented development process must incorporate into tool selection and configuration decisions.
- SA-10 — Developer Configuration Management: Focuses specifically on the configuration management practices that support SA-15’s requirement to track and control changes to development tools and processes.
- SA-11 — Developer Testing and Evaluation: Addresses the testing activities that validate whether the development process, standards, and tools documented under SA-15 produce systems meeting security requirements.
- SR-03 — Supply Chain Controls and Processes: Extends SA-15’s development process oversight into the broader supply chain, ensuring that component provenance and integrity are maintained.
- SR-04 — Provenance: Tracks the origin of system components and development tools, supporting SA-15’s goal of maintaining integrity across the development process.
- SR-05 — Acquisition Strategies, Tools, and Methods: Governs how organizations select and procure the development tools that SA-15 requires them to document and configure securely.
- SR-06 — Supplier Assessments and Reviews: Provides the assessment framework for evaluating whether suppliers meet the development process and tooling requirements established under SA-15.
Frequently asked questions
What is NIST SP 800-53 SA-15?
SA-15 requires organizations to ensure their system developers follow a documented development process that addresses security and privacy requirements, identifies standards and tools, documents specific tool options and tool configurations, and maintains the integrity of changes to those processes. The control applies to both in-house and outsourced development. It also mandates periodic reviews of the development process, standards, tools, and configurations to confirm they continue meeting defined security and privacy requirements.
What happens if SA-15 is not implemented?
Without SA-15, organizations lose visibility into whether their developers’ tool configurations and process changes introduce security gaps. Auditors will flag the absence of documented development process reviews, configuration control records, and tool integrity evidence as control failures. These findings can delay or prevent authority to operate decisions and may result in certification conditions or withdrawal during compliance assessments.
How do you audit SA-15?
Auditors verify SA-15 by examining the documented development process for explicit coverage of security and privacy requirements, then tracing those requirements to specific tool options, tool configurations, and development standards. They review configuration control records to confirm that changes to the process and tooling are tracked, authorized, and managed. Auditors also check for completed maturity model reviews and evidence that periodic reviews of development process, standards, tools, and configurations have occurred at the organization-defined frequency.
How does SA-15 relate to supply chain risk management?
SA-15 addresses a critical upstream control point in supply chain risk by requiring documented, integrity-controlled development processes before systems or components enter your environment. When vendors can’t demonstrate configuration control over their development tools or produce evidence of process reviews, you have no assurance that the software they deliver hasn’t been tampered with during development. Specifically, SA-15’s requirement to track changes to tools and processes provides a verifiable chain of custody for the development environment itself. Related controls SR-03, SR-04, and SR-05 extend this oversight into component provenance, acquisition methods, and broader supply chain processes.