SA-17, Developer Security and Privacy Architecture and Design, asks the organization to require the developer of a system, component or service to produce a design specification and a security and privacy architecture. That architecture must do three things: stay consistent with the organization's own security architecture, describe accurately and completely the required security functionality and how controls are allocated among physical and logical components, and show how individual functions and mechanisms work together as a unified approach to protection.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, most useful when you outsource builds.
What it means in practice
The guidance draws a line that matters. SA-17 is aimed at external developers, although it can apply to in-house work. PL-8 is the control that tells your own people to build a security architecture. The difference is sharpest when you outsource development and must show the result fits your architecture.
So the question is simple: when a contractor delivers a system, can they show you a design that says where authentication happens, where data is encrypted, which component enforces which control, and how those pieces connect?
The enhancements range from formal to practical: SA-17.1 Formal Policy Model, SA-17.2 Security-relevant Components, SA-17.3 Formal Correspondence, SA-17.4 Informal Correspondence, SA-17.5 Conceptually Simple Design, SA-17.6 Structure for Testing, SA-17.7 Structure for Least Privilege and SA-17.8 Orchestration. Most commercial teams will never need formal models. Conceptually simple design and structure for least privilege are the ones that pay back.
Evidence to collect
- The design specification and architecture document from the developer, with a version and date.
- A diagram or table that allocates each required control to a component.
- Your review notes showing the design was checked against your own architecture.
- Change records showing the architecture was updated when the system changed.
- The contract clause that required the deliverable.
Common gaps
Diagrams that show boxes and arrows but not controls. An auditor wants to know which box enforces authentication, not only that a box exists.
Architecture documents written once at kickoff and never updated. After a year of releases the document describes a system that no longer exists.
No review on your side. If nobody compared the vendor design with your standards, the consistency requirement is unmet.
How to implement it
- Define a short template for the architecture deliverable: components, trust boundaries, data flows, and a control allocation table.
- Put the template and a review date in the statement of work.
- Review the first draft against your own security architecture and record the comments.
- Require an update when the system changes in a way that touches security.
- Store the final version beside the contract and the test evidence.
What an auditor may ask
- Where is authentication enforced, and which document says so?
- When was the architecture last updated, and what triggered the update?
- Who on your side reviewed the vendor design?
- How do you know the delivered system matches the design?
Have a dated answer to each before the audit starts.
Quick check
How does SA-17 differ from PL-8?
SA-17 is directed at external developers and your ability to demand a design from them. PL-8 directs your internal developers to produce an architecture integrated with the enterprise architecture.
Do you need formal policy models?
Only if you choose SA-17.1. Mappings to other frameworks vary, so check the mapping your auditor uses.
