NIST 800-53 REV 5 • SYSTEM AND SERVICES ACQUISITION
SA-17 — Developer Security and Privacy Architecture and Design
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that: Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture; Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.
Supplemental Guidance
Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, [PL-8](#pl-8) is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and [PL-8](#pl-8) is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2](#87087451-2af5-43d4-88c1-d66ad850f614), [ISO 15408-3](#4452efc0-e79e-47b8-aa30-b54f3ef61c2f) , and [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.
Practitioner Notes
Require developers to produce and maintain a security architecture and design document that describes how the system implements security requirements. The architecture should be designed before code is written.
Example 1: Require a security architecture document for every new system that covers: trust boundaries, authentication and authorization design, encryption strategy, audit logging approach, network segmentation, and data flow diagrams showing where sensitive data is processed, stored, and transmitted.
Example 2: Use architecture review boards that include security expertise to evaluate designs before development begins. Review proposed architectures against NIST, OWASP, and organization-specific security standards. Document review findings and require resolution before development proceeds.