Development Process, Standards, and Tools SA-15
System and Services Acquisition · Moderate baseline ✗ Not implemented
Status — program-wide
What references this control
No risks name this control in their Framework field yet.
No policies reference it yet.
Link a risk or policy to this control
Attaching adds SA-15 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.
Source: NIST SP 800-53 Rev.5, System and Services Acquisition family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.
Control guide — plain-English, per NIST SP 800-53
SA-15 (Development Process, Standards, and Tools) asks the builder to follow a documented development process — one that explicitly addresses security and privacy, names the standards and tools used, records the tool settings, and controls changes to the process itself. You then review that process on a schedule to confirm it still meets your security needs. In plain terms: build things the same documented, secure way each time, using known-good tools. It is a Moderate-baseline control.
What good looks like
- Write down how the server is built and changed — the ordered steps that address security, such as hardening, secrets handling, and review.
- Name the standards and tools you build with, and pin their versions — the shell, the config manager, the linters, the scanners.
- Record the tool settings — the linter config, the scanner profile — so a build is repeatable, not improvised.
- Control changes to the process and tools the same way you control code — under version control, with a reason.
- Review the process on a schedule to confirm the standards and tools still meet your security requirements.
Framework mapping
- NIST CSF 2.0 — PR.PS-06 — Secure software development practices are integrated and monitored throughout the software development life cycle
- CIS Controls v8 — Control 16 — Application Software Security
How to move it toward Implemented
- Write a one-page build standard: the ordered steps, the tools and their versions, and the security requirement each step meets.
- Pin tool configs in the repository — commit the
.shellcheckrc, the scanner profile, and atool-versionsnote — so settings are recorded, not remembered. - Put the build standard itself under version control and set a review date (for example, every six months) to re-check it against your requirements.
- Attach the build standard and its review note as hardening evidence on the asset, naming
SA-15in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.