Developer Security and Privacy Architecture and Design SA-17

System and Services Acquisition · High 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-17 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-17 (Developer Security and Privacy Architecture and Design) asks the builder to produce a real design document — a security and privacy architecture — that lines up with the organization's overall architecture, describes exactly which security functions are needed and where each control lives, and explains how those controls work together to protect the system. It is a High-baseline control, aimed at systems built from the ground up. In short: design the security on paper first, and show the pieces fit.

What good looks like

There is a written design of the server's security, not just settings that accreted over time.
The design is consistent with your broader architecture — it reuses the same identity, logging, and network patterns as the rest of your environment.
It describes each security function and where its control lives — which components enforce authentication, which handle logging, which segment the network.
It explains how the controls work together — how authentication, authorization, and monitoring combine into one defense, not five disconnected settings.
Data flows and trust boundaries are drawn, so you can see where sensitive data crosses a line and what protects it there.

Framework mapping

NIST CSF 2.0 — PR.PS-06 — Secure software development practices are integrated and monitored throughout the software development life cycle

How to move it toward Implemented

Draw a one-page architecture diagram — the server's components, its network boundaries, and where each control (authentication, firewall, logging, encryption) sits.
Write a short design note mapping each security requirement to the component that enforces it, and showing how they reinforce each other.
Check the design is consistent with your other systems — same identity source, same log destination, same hardening baseline — and record any gaps.
Attach the architecture diagram and design note as hardening evidence on the asset, naming SA-17 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.