{"data":{"id":"SA-04","name":"Acquisition Process","family":"SA","family_name":"System and Services Acquisition","withdrawn":false,"description":"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:\na. Security and privacy functional requirements;\nb. Strength of mechanism requirements;\nc. Security and privacy assurance requirements;\nd. Controls needed to satisfy the security and privacy requirements.\ne. Security and privacy documentation requirements;\nf. Requirements for protecting security and privacy documentation;\ng. Description of the system development environment and environment in which the system is intended to operate;\nh. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and\ni. Acceptance criteria.","supplemental_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.\n\nControls 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.\n\nSecurity 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.\n\nOrganizations 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":[{"id":"SA-04(01)","name":"Functional Properties of Controls","statement":"Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.","baselines":["moderate","high"]},{"id":"SA-04(02)","name":"Design and Implementation Information for Controls","statement":"Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design and implementation information]] at [Assignment: organization-defined level of detail].","baselines":["moderate","high"]},{"id":"SA-04(03)","name":"Development Methods, Techniques, and Practices","statement":"Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:\na. [Assignment: organization-defined systems engineering methods];\nb. [Assignment: organization-defined [Selection (one or more): systems security; privacy] engineering methods]; and\nc. [Assignment: organization-defined software development methods; testing, evaluation, assessment, verification, and validation methods; and quality control processes].","baselines":[]},{"id":"SA-04(04)","name":"Assignment of Components to Systems","withdrawn":true,"incorporated_into":["CM-08(09)"]},{"id":"SA-04(05)","name":"System, Component, and Service Configurations","statement":"Require the developer of the system, system component, or system service to:\na. Deliver the system, component, or service with [Assignment: organization-defined security configurations] implemented; and\nb. Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.","baselines":["high"]},{"id":"SA-04(06)","name":"Use of Information Assurance Products","statement":"a. Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and\nb. Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.","baselines":[]},{"id":"SA-04(07)","name":"NIAP-approved Protection Profiles","statement":"a. Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and\nb. Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved.","baselines":[]},{"id":"SA-04(08)","name":"Continuous Monitoring Plan for Controls","statement":"Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.","baselines":[]},{"id":"SA-04(09)","name":"Functions, Ports, Protocols, and Services in Use","statement":"Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.","baselines":["moderate","high"]},{"id":"SA-04(10)","name":"Use of Approved PIV Products","statement":"Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.","baselines":["low","moderate","high"]},{"id":"SA-04(11)","name":"System of Records","statement":"Include [Assignment: organization-defined Privacy Act requirements] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.","baselines":[]},{"id":"SA-04(12)","name":"Data Ownership","statement":"a. Include organizational data ownership requirements in the acquisition contract; and\nb. Require all data to be removed from the contractor’s system and returned to the organization within [Assignment: organization-defined time frame].","baselines":[]}],"baseline_low":true,"baseline_moderate":true,"baseline_high":true,"nist_800_53":{"rev5":{"id":"SA-04","name":"Acquisition Process","description":"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:\na. Security and privacy functional requirements;\nb. Strength of mechanism requirements;\nc. Security and privacy assurance requirements;\nd. Controls needed to satisfy the security and privacy requirements.\ne. Security and privacy documentation requirements;\nf. Requirements for protecting security and privacy documentation;\ng. Description of the system development environment and environment in which the system is intended to operate;\nh. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and\ni. Acceptance criteria.","discussion":"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.\n\nControls 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.\n\nSecurity 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.\n\nOrganizations 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.","related_controls":["CM-06","CM-08","PS-07","SA-03","SA-05","SA-08","SA-11","SA-15","SA-16","SA-17","SA-21","SR-03","SR-05"],"baseline_low":true,"baseline_moderate":true,"baseline_high":true,"baseline_privacy":true,"new_in_rev5":false,"changes_from_rev4":"Control text adds privacy,  controls needed to satisfy security and privacy requirements, and allocation of responsibility New parameter to specify contract language Discussion expanded to explain benefits Incorporates requirements elements of withdrawn App J control AR-03"}},"compliance_mappings":{"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"],"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"],"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"],"finos_ccc":[],"iso_42001_2023":["A.6.2.2","A.10.3"],"iec_62443":[],"asd_e8":[],"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"],"swift_cscf":[],"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"],"tsa_psd":[],"ieee_1686":[],"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_21_cfr_11":[],"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"],"owasp_masvs_v2":[],"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"],"ccss_v9":[],"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)"]},"attack_techniques":[{"id":"T1078","name":"Valid Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security requirements in acquisition contracts mandate that procured systems implement strong authentication, account management, and access controls, reducing the risk of valid account exploitation."},{"id":"T1078.001","name":"Default Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Acquisition security specifications require vendors to eliminate default accounts and credentials before delivery, preventing adversary initial access through factory-set authentication bypass."},{"id":"T1078.003","name":"Local Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security requirements in procurement contracts mandate that local accounts on acquired systems use strong, unique credentials and implement proper access controls to prevent unauthorized local access."},{"id":"T1078.004","name":"Cloud Accounts","tactics":["defense-evasion","initial-access","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Acquisition specifications require cloud service providers to implement robust IAM controls, MFA support, and secure credential management for cloud accounts in procured services."},{"id":"T1134.005","name":"SID-History Injection","tactics":["defense-evasion","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Security requirements in system acquisitions mandate proper SID-History filtering and trust configuration in procured Active Directory implementations, preventing cross-domain privilege escalation."},{"id":"T1574.002","name":"DLL Side-Loading","tactics":["defense-evasion","persistence","privilege-escalation"],"mapping_type":"mitigates","mapping_rationale":"Acquisition security requirements mandate that procured applications implement proper DLL loading practices with manifest-based binding, preventing DLL side-loading vulnerabilities in purchased software."}],"metadata":{"last_reviewed":"2026-10-03","review_notes":"2026-10-03: iso_27001_2022 8.1, A.5.23 added from NIST's SP 800-53 Rev 5 to ISO/IEC 27001:2022 crosswalk (OLIR entry 155), which OSA's mapping now takes as its base. 2026-10-03: nist_csf_2 DE.CM-06, GV.SC-07, GV.SC-08, GV.SC-09, ID.AM-08, ID.IM-03 added from NIST's CSF 2.0 to SP 800-53 Rev 5.2.0 crosswalk (OLIR entry 186), which OSA's mapping now takes as its base.","mapping_status":"complete"},"function":"preventative","used_by_patterns":["SP-001","SP-002","SP-011","SP-012","SP-027","SP-028","SP-037","SP-040","SP-041","SP-042","SP-046","SP-047","SP-048","SP-049","SP-051","SP-052","SP-053"]}}