# SA-04 Acquisition Process

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

Statement: Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection (one or more): standardized contract language; [Assignment: organization-defined contract language]] in the acquisition contract for the system, system component, or system service: a. Security and privacy functional requirements; b. Strength of mechanism requirements; c. Security and privacy assurance requirements; d. Controls needed to satisfy the security and privacy requirements. e. Security and privacy documentation requirements; f. Requirements for protecting security and privacy documentation; g. Description of the system development environment and environment in which the system is intended to operate; h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and i. Acceptance criteria.
Guidance: Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in SA-2. The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1] describes the process of requirements engineering as part of the system development life cycle. Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle. Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement. Organizations can determine other requirements that support security and operations, to include responsibilities for the organization and developer, and notification and timing requirements for support, maintenance and updates.

## Enhancements (11)
- SA-04(01) Functional Properties of Controls. Baselines: moderate, high
- SA-04(02) Design and Implementation Information for Controls. Baselines: moderate, high
- SA-04(03) Development Methods, Techniques, and Practices
- SA-04(05) System, Component, and Service Configurations. Baselines: high
- SA-04(06) Use of Information Assurance Products
- SA-04(07) NIAP-approved Protection Profiles
- SA-04(08) Continuous Monitoring Plan for Controls
- SA-04(09) Functions, Ports, Protocols, and Services in Use. Baselines: moderate, high
- SA-04(10) Use of Approved PIV Products. Baselines: low, moderate, high
- SA-04(11) System of Records
- SA-04(12) Data Ownership
Withdrawn by NIST: SA-04(04) (now in CM-08(09)).
Each enhancement's statement: /api/v1/controls/SA-04?fields=enhancements

## Patterns that use it (16)
- Critical (1): SP-042 Third Party Risk Management
- Important (8): SP-011 Cloud Computing Pattern; SP-012 Secure Software Development Lifecycle; SP-027 Secure LLM Usage; SP-037 Privileged User Management; SP-040 Post-Quantum Cryptography and Quantum Readiness; SP-047 Secure Agentic AI Frameworks; SP-048 Offensive AI and Deepfake Defence (draft); SP-049 AI in Security Operations (draft)
- Standard (7): SP-001 Client Module; SP-002 Server Module; SP-028 Secure DevOps Pipeline Pattern; SP-046 External Attack Surface Management; SP-051 Tokenised Asset Security Architecture (draft); SP-052 Decentralised Identity & Verifiable Credentials (draft); SP-053 Zero-Knowledge Proof Architecture (draft)

## Clauses by framework (78 frameworks)
- iso_27001_2022: 8.1, A.5.8, A.5.19, A.5.20, A.5.23, A.5.31, A.8.26, A.8.29, A.8.30. OSA's own, not in NIST's crosswalk: A.5.19, A.5.31, A.8.26
- iso_27002_2022: 5.8, 5.19, 5.20, 5.23, 5.31, 8.6, 8.26, 8.29, 8.30
- cobit_2019: APO09, APO10, BAI02, BAI03, MEA03
- pci_dss_v4: 12.8
- nist_csf_2: DE.CM-06, GV.OC-03, GV.SC-02, GV.SC-04, GV.SC-05, GV.SC-06, GV.SC-07, GV.SC-08, GV.SC-09, GV.SC-10, ID.AM-08, ID.IM-03, ID.RA-09, ID.RA-10. OSA's own, not in NIST's crosswalk: GV.OC-03, GV.SC-02, GV.SC-04, ID.RA-10
- cis_controls_v8: CIS 15, CIS 15.2, CIS 15.4, CIS 16
- soc2_tsc: CC1.4-POF2, CC1.4-POF3, CC2.3-POF12, CC3.3, CC3.4, CC5.2, CC9.1, CC9.2, CC9.2-POF1, PI1.2, PI1.3
- iso_42001_2023: A.6.2.2, A.10.3
- nis2: Art. 21(2)(d), Art. 21(2)(e), Art. 24
- apra_cps_234: Para 29-33
- mas_trm: 5, 16
- pra_op_resilience: SS2/21-3.1, SS2/21-5.1, SS2/21-6.1
- bsi_grundschutz: ORP.5
- anssi: Hygiene.42, SecNumCloud.15.1, SecNumCloud.16.1
- osfi_b13: B-13.2.3, B-13.4.1
- finma_circular: IV.F(100), V(101), V(102), V(103)
- gdpr: Art.28(1), Art.28(3), Art.28(3)(a)
- dora: Art.28(1)(a), Art.30(2), Art.30(3)
- bio2: 5.8, 5.19, 5.20, 5.23, 5.31, 8.6, 8.26, 8.29, 8.30
- rbi_csf: Annex1.6, Annex1.11, ITGRCA.10
- fisc: FISC.O6, FISC.O10, FISC.T6, FISC.T9
- lgpd_bcb: BCB.Art.11, BCB.Art.11-Supp, BCB.Art.12, BCB.Art.16
- hkma_tme1: TME1.3.1, TME1.3.4, TME1.12.1, TME1.12.2
- mlps_2: 8.1.9.3, 8.1.9.4, 8.3, 8.5
- dnb_good_practice: DNB.3.2, DNB.14.1, DNB.14.2
- cra: CRA.I.1, CRA.I.2b, CRA.I.2e, CRA.I.2j, CRA.II.1, CRA.Info.8f
- cbb_tm: TM-7, TM-15
- cbuae: CR-6, CR-12
- nca_ecc: 1-6, 1-7, 2-14, 4-1
- qatar_nia: SD
- sama_csf: 1.4, 3.2, 4.1, 4.2
- uae_ia: T10
- bog_cisd: CISD-IX, CISD-SDLC, CISD-XII, CISD-XVI
- bom_ctrm: 3.1, 3.9, 3.11
- cbe_csf: CTO-4, CTO-11, OVM-1
- cbn_csf: Part2.4, Part5.1, Part5.2
- popia: s21
- sa_js2: JS2-8.7, JS2-SA
- bcbs_239: Principle 4
- bot_cyber: Ch2.5, Ch5.1, Ch6.2
- cpmi_pfmi: PFMI.P17, PFMI.P22
- eba_ict: 3.2.3, 3.6.1, 3.6.2
- ecb_croe: CROE.2.2.3
- ffiec_is: II.C.2, II.C.14, II.C.17, II.C.20
- hipaa_sr: §164.308(b)(1), §164.308(b)(3), §164.314(a)(1), §164.314(a)(2)
- iosco_cyber: PROT-6, PROT-7
- nydfs_500: 500.8, 500.11
- sebi_cscrf: GV.SC, PR.AS
- nerc_cip: CIP-013-2
- nrc_73_54: RG5.71-C-SR
- ferc_cip: Order 829
- doe_c2m2: THIRD
- api_1164: Sec 12
- awia: AWWA Sec 7
- iaea_nss: Sec 6
- pci_pts: G, H
- fips_140: FIPS 140-3 §7.2, FIPS 140-3 §7.11
- cbest: CBEST.8
- tiber_eu: TIBER.PROV
- pci_hsm: 2
- common_criteria: CC Part 1 — PP, CC Part 1 — ST, CC Part 3 — SAR, CCRA
- isae_3402: Clause 7
- fca_sysc_13: SYSC 13.9.1, SYSC 13.9.2, SYSC 13.9.3
- fda_cyber: 524B-1, SBOM-1
- hitrust_csf: 05.b, 06.a, 09.b, 10.a
- iso_27799: 14.1, 15.1, 18.1
- lloyds_ms: BP2.1, MS8.8, MS13.1
- naic_ds: 4D
- nhs_dspt: NDG-10.1, NDG-10.2, NDG-10.3
- pra_ss1_23: P1.3
- solvency_ii: Art.49(1), Art.49(2), DR.272, EIOPA-Cloud-GL3
- csa_ccm_v4: CCC-05, DSP-13, IPY-01, IPY-02, IPY-03, IPY-04, IVS-07, STA-03, STA-09, STA-10, UEM-03
- csa_aicm: CCC-05, DSP-13, I&S-07, IPY-01, IPY-02, IPY-03, IPY-04, MDS-12, STA-03, STA-09, STA-10, STA-15, UEM-03
- mica: Art.66(1), Art.66(3)
- basel_sco60: SCO60.4, SCO60.54
- bssc: GSP-07, KMS-03, TIS-03, TIS-06
- sec_custody_digital: SEC-CD-10
- dpdpa: Act.8(2), Rules.6(1)(f)
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-04
- Clauses only: /api/v1/controls/SA-04?fields=mappings
- Page for people: /controls/sa-04/
- 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.