# SA-17 Developer Security and Privacy Architecture and Design

NIST SP 800-53 control. Family: SA System and Services Acquisition. Function: preventative. Baselines: high. Mapping licence: CC BY-SA 4.0.

Statement: Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that: a. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture; b. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and c. 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.
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 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 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], [ISO 15408-3], and [SP 800-160-1] 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.

## Enhancements (9)
- SA-17(01) Formal Policy Model
- SA-17(02) Security-relevant Components
- SA-17(03) Formal Correspondence
- SA-17(04) Informal Correspondence
- SA-17(05) Conceptually Simple Design
- SA-17(06) Structure for Testing
- SA-17(07) Structure for Least Privilege
- SA-17(08) Orchestration
- SA-17(09) Design Diversity
Each enhancement's statement: /api/v1/controls/SA-17?fields=enhancements

## Patterns that use it (2)
- Important (2): SP-040 Post-Quantum Cryptography and Quantum Readiness; SP-053 Zero-Knowledge Proof Architecture (draft)

## Clauses by framework (46 frameworks)
- iso_27001_2022: A.8.25, A.8.27, A.8.28. OSA's own, not in NIST's crosswalk: A.8.28
- iso_27002_2022: 8.25, 8.27
- cobit_2019: APO03, BAI03
- pci_dss_v4: 6.2
- nist_csf_2: ID.RA-09, PR.PS-06
- cis_controls_v8: CIS 16, CIS 16.10, CIS 16.14
- mas_trm: 5, 6
- bio2: 8.25, 8.27
- rbi_csf: Annex1.6
- fisc: FISC.O10, FISC.T1, FISC.T6
- hkma_tme1: TME1.3.2, TME1.7.3
- mlps_2: 8.1.2.3, 8.1.3.6, 8.1.4.6
- dnb_good_practice: DNB.2.1
- cra: CRA.I.1
- cbb_tm: TM-7
- cbuae: CR-6
- nca_ecc: 1-6
- qatar_nia: SD
- sama_csf: 1.4, 3.2
- uae_ia: T10
- bog_cisd: CISD-SDLC
- bom_ctrm: 3.1, 3.11
- cbe_csf: CTO-4
- cbn_csf: Part5.1
- sa_js2: JS2-SA
- bcbs_239: Principle 2, Principle 6
- bot_cyber: Ch2.5, Ch6.2
- eba_ict: 3.6.2
- ffiec_is: II.C.2, II.C.17
- iosco_cyber: PROT-6
- nydfs_500: 500.8
- sebi_cscrf: PR.AS
- tsa_psd: SD-2 Sec F
- doe_c2m2: ARCHITECTURE
- pci_pts: F
- fips_140: FIPS 140-3 §7.2
- common_criteria: CC Part 1 — ST, CC Part 3 — SAR
- isae_3402: Clause 9
- fda_21_cfr_11: §11.10(a)
- fda_cyber: SPDF-1, SPDF-3, TM-2
- hitrust_csf: 10.b, 10.d
- iso_27799: 14.2
- lloyds_ms: BP2.1
- pra_ss1_23: P3.1, P3.5
- solvency_ii: EIOPA-ICT-4.11
- basel_sco60: SCO60.51
OSA's mapping for iso_27001_2022 and nist_csf_2 takes NIST's published crosswalk as its base. A clause not marked as OSA's own is in that crosswalk.

## More
- This control as JSON, with guidance and ATT&CK techniques: /api/v1/controls/SA-17
- Clauses only: /api/v1/controls/SA-17?fields=mappings
- Page for people: /controls/sa-17/
- Found an error? Open an issue at https://github.com/opensecurityarchitecture/osa-data/issues with the id, what OSA says and what the source says.