TDA-01: Technology Development & Acquisition
Mechanisms exist to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.
Control Question: Does the organization facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs?
General (55)
| Framework | Mapping Values |
|---|---|
| AICPA TSC 2017:2022 (used for SOC 2) (source) | CC2.3-POF10 CC5.2 CC5.2-POF4 PI1.2 PI1.3 |
| CIS CSC 8.1 | 15.7 16 |
| COBIT 2019 | APO03.02 APO03.03 APO04.01 BAI03.02 BAI03.03 BAI03.04 DSS03.01 DSS03.02 DSS03.03 DSS03.04 DSS03.05 |
| COSO 2017 | Principle 11 |
| CSA CCM 4 | AIS-01 AIS-04 |
| CSA IoT SCF 2 | SET-06 |
| GovRAMP Low | PL-01 SA-01 |
| GovRAMP Low+ | PL-01 SA-01 |
| GovRAMP Moderate | PL-01 SA-01 SA-04 |
| GovRAMP High | PL-01 SA-01 SA-04 |
| IMO Maritime Cyber Risk Management | 3.5.3.3 |
| ISO/SAE 21434 2021 | RC-05-13 RQ-06-10 RQ-06-15.a RQ-06-15.b RQ-06-15.c RQ-06-16.a RQ-06-16.b RQ-06-16.c RQ-06-16.d RQ-06-17.a RQ-06-17.b |
| ISO 27002 2022 | 8.25 8.30 |
| ISO 27017 2015 | 14.2.7 |
| ISO 42001 2023 | A.6.1 A.6.1 A.6.1.3 A.6.2.3 |
| MITRE ATT&CK 10 | T1078, T1078.001, T1078.003, T1078.004, T1134.005, T1574.002 |
| NAIC Insurance Data Security Model Law (MDL-668) | 4.D(2)(e) |
| NIST AI 100-1 (AI RMF) 1.0 | GOVERN 1.2 GOVERN 3.1 GOVERN 4.2 MANAGE 2.0 |
| NIST 800-53 R4 | PL-1 SA-1 SA-4 |
| NIST 800-53 R4 (low) | PL-1 SA-1 SA-4 |
| NIST 800-53 R4 (moderate) | PL-1 SA-1 SA-4 |
| NIST 800-53 R4 (high) | PL-1 SA-1 SA-4 |
| NIST 800-53 R5 (source) | PL-1 SA-1 SA-4 SA-23 |
| NIST 800-53B R5 (privacy) (source) | PL-1 SA-1 SA-4 |
| NIST 800-53B R5 (low) (source) | PL-1 SA-1 SA-4 |
| NIST 800-53B R5 (moderate) (source) | PL-1 SA-1 SA-4 |
| NIST 800-53B R5 (high) (source) | PL-1 SA-1 SA-4 |
| NIST 800-53 R5 (NOC) (source) | SA-23 |
| NIST 800-82 R3 LOW OT Overlay | PL-1 SA-1 SA-4 |
| NIST 800-82 R3 MODERATE OT Overlay | PL-1 SA-1 SA-4 |
| NIST 800-82 R3 HIGH OT Overlay | PL-1 SA-1 SA-4 |
| NIST 800-160 | 3.1 3.1.1 3.1.2 |
| NIST 800-161 R1 | PL-1 SA-1 SA-4 |
| NIST 800-161 R1 C-SCRM Baseline | PL-1 SA-1 |
| NIST 800-161 R1 Level 1 | SA-1 |
| NIST 800-161 R1 Level 2 | PL-1 SA-1 |
| NIST 800-161 R1 Level 3 | SA-1 |
| NIST 800-171 R2 (source) | NFO-SA-4 |
| NIST 800-171 R3 (source) | 03.12.01 03.12.03 03.14.01.a 03.16.01 03.17.02 |
| NIST 800-171A R3 (source) | A.03.16.01.ODP[01] A.03.17.02[04] A.03.17.02[05] A.03.17.02[06] |
| NIST 800-218 | PO.1 PO.3 PO.3.2 RV.3.4 |
| NIST CSF 2.0 (source) | ID.RA-09 PR.PS-06 |
| OWASP Top 10 2021 | A01:2021 A02:2021 A03:2021 A04:2021 A05:2021 A06:2021 A07:2021 A08:2021 A09:2021 A10:2021 |
| PCI DSS 4.0.1 (source) | 6.2 6.2.1 |
| PCI DSS 4.0.1 SAQ A-EP (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ C (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ D Merchant (source) | 6.2.1 |
| PCI DSS 4.0.1 SAQ D Service Provider (source) | 6.2.1 |
| SWIFT CSF 2023 | 2.8A |
| UL 2900-1 2017 | 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 |
| SCF CORE Mergers, Acquisitions & Divestitures (MA&D) | TDA-01 |
| SCF CORE ESP Level 1 Foundational | TDA-01 |
| SCF CORE ESP Level 2 Critical Infrastructure | TDA-01 |
| SCF CORE ESP Level 3 Advanced Threats | TDA-01 |
| SCF CORE AI Model Deployment | TDA-01 |
US (26)
| Framework | Mapping Values |
|---|---|
| US C2M2 2.1 | RISK-2.J.MIL3 ARCHITECTURE-4.A.MIL2 ARCHITECTURE-4.D.MIL3 |
| US CERT RMM 1.2 | EF:SG3.SP3 EF:SG4.SP1 |
| US CMS MARS-E 2.0 | PL-1 SA-1 |
| US DoD Zero Trust Execution Roadmap | 3.2 3.2.2 |
| US DHS CISA SSDAF | 1.d 4.b |
| US DHS ZTCF | DEV-03 |
| US EO 14028 | 4e(i)(D) 4e(iv) |
| US FedRAMP R4 | PL-1 SA-1 |
| US FedRAMP R4 (low) | PL-1 SA-1 |
| US FedRAMP R4 (moderate) | PL-1 SA-1 |
| US FedRAMP R4 (high) | PL-1 SA-1 |
| US FedRAMP R4 (LI-SaaS) | PL-1 SA-1 |
| US FedRAMP R5 (source) | PL-1 SA-1 |
| US FedRAMP R5 (low) (source) | PL-1 SA-1 |
| US FedRAMP R5 (moderate) (source) | PL-1 SA-1 |
| US FedRAMP R5 (high) (source) | PL-1 SA-1 |
| US FedRAMP R5 (LI-SaaS) (source) | PL-1 SA-1 |
| US GLBA CFR 314 2023 (source) | 314.4(c)(4) |
| US IRS 1075 | PL-1 SA-1 |
| US NNPI (unclass) | 16.2 |
| US - CA CCPA 2025 | 7123(c)(14) |
| US - NY DFS 23 NYCRR500 2023 Amd 2 | 500.3(i) 500.8(a) |
| US - NY SHIELD Act S5575B | 4(2)(b)(ii)(B)(1) |
| US - TX DIR Control Standards 2.0 | PL-1 SA-1 |
| US - TX TX-RAMP Level 1 | PL-1 SA-1 |
| US - TX TX-RAMP Level 2 | PL-1 SA-1 |
EMEA (18)
| Framework | Mapping Values |
|---|---|
| EMEA EU AI Act | 14.4 |
| EMEA EU EBA GL/2019/04 | 3.6.2(67) 3.6.2(74) |
| EMEA EU DORA | 13.7 |
| EMEA EU NIS2 | 21.2(e) 21.3 |
| EMEA EU NIS2 Annex | 5.1.1 6.2.1 6.2.2(c) 6.2.4 |
| EMEA Austria | Sec 14 Sec 15 |
| EMEA Belgium | 16 |
| EMEA Germany Banking Supervisory Requirements for IT (BAIT) | 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 |
| EMEA Germany C5 2020 | DEV-01 |
| EMEA Israel CDMO 1.0 | 17.1 17.9 |
| EMEA Qatar PDPPL | 11.4 11.5 11.6 |
| EMEA Saudi Arabia CSCC-1 2019 | 2-13 2-13-3-1 2-13-3-2 2-13-3-3 2-13-3-4 |
| EMEA Saudi Arabia ECC-1 2018 | 1-6-3 2-5-4 |
| EMEA Saudi Arabia OTCC-1 2022 | 1-1-2 |
| EMEA Saudi Arabia SAMA CSF 1.0 | 3.3.6 |
| EMEA Spain BOE-A-2022-7191 | 19.1 19.2 19.2(a) 19.2(b) 19.2(c) 19.3 |
| EMEA Spain 311/2022 | 19.1 19.2 19.2(a) 19.2(b) 19.2(c) 19.3 |
| EMEA Spain CCN-STIC 825 | 7.1.3 [OP.PL.3] 8.6.1 [MP.SW.1] |
APAC (6)
| Framework | Mapping Values |
|---|---|
| APAC Australia ISM June 2024 | ISM-0938 ISM-1780 |
| APAC China Cybersecurity Law | 22 46 48 |
| APAC Japan ISMAP | 14.2.7 |
| APAC New Zealand HISF 2022 | HHSP50 HML50 HSUP42 |
| APAC New Zealand HISF Suppliers 2023 | HSUP42 |
| APAC Singapore MAS TRM 2021 | 5.3.1 5.3.2 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.2.1 6.2.2 6.3.1 6.3.2 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8 6.5.1 6.5.2 6.5.3 |
Americas (3)
| Framework | Mapping Values |
|---|---|
| Americas Canada CSAG | 4.8 4.9 |
| Americas Canada OSFI B-13 | 2.4.3 |
| Americas Canada ITSP-10-171 | 03.12.01 03.12.03 03.14.01.A 03.16.01 03.17.02 |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.
Level 1 — Performed Informally
Technology Development & Acquisition (TDA) efforts are ad hoc and inconsistent. CMM Level 1 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- IT personnel use an informal process to govern technology development and acquisition.
- Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- IT personnel work with data/process owners to help ensure secure practices are implemented throughout the System Development Lifecycle (SDLC) for all high-value projects.
- Project management is decentralized and generally lacks formal project management managers or broader oversight.
Level 2 — Planned & Tracked
Technology Development & Acquisition (TDA) efforts are requirements-driven and governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
- IT/cybersecurity personnel identify cybersecurity and data protection controls to address applicable statutory, regulatory and contractual requirements for technology development and acquisition management.
- IT/cybersecurity personnel implement secure practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets, data and network(s).
- Secure development practices mostly conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- Procurement practices require third-party developers of systems, system components or services to follow secure engineering practices.
- A Project Management office (PMO), or project management function, enables the implementation of cybersecurity and data privacy-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
Level 3 — Well Defined
Technology Development & Acquisition (TDA) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist: o Provides governance oversight for the implementation of applicable statutory, regulatory and contractual cybersecurity and data protection controls to protect the confidentiality, integrity, availability and safety of the organization's applications, systems, services and data for technology development and acquisition. o Ensures the Information Assurance Program (IAP) evaluates applicable cybersecurity and data protection controls as part of “business as usual” pre-production testing. o Operates the Cybersecurity Supply Chain Risk Management (C-SCRM) program to identify and mitigate supply chain-related risks and threats.
- The Chief Information Security Officer (CISO), or similar function with technical competence to address cybersecurity concerns, analyzes the organization's business strategy to determine prioritized and authoritative guidance for technology development and acquisition practices.
- The CISO, or similar function, develops a security-focused Concept of Operations (CONOPS) that documents management, operational and technical measures to apply defense-in-depth techniques across the enterprise for technology development and acquisition.
- A steering committee is formally established to provide executive oversight of the cybersecurity and data privacy program, including technology development and acquisition.
- A Validated Architecture Design Review (VADR) evaluates design criteria for secure practices and conformance with requirements for applicable statutory, regulatory and contractual controls to determine if the system/application/service is designed, built and operated in a secure and resilient manner.
- Secure development practices conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- A procurement team, or similar function, ensures that third party development and/ or acquisitions meet, or exceed, the organization's business, cybersecurity and data privacy requirements to have secure and resilient systems, applications, services and processes.
- A Software Assurance Maturity Model (SAMM) governs a secure development lifecycle for the development of systems, applications and services.
- Administrative processes exist and technologies are configured to implement secure configuration settings by default to reduce the likelihood of software being deployed with weak security settings, putting the asset at a greater risk of compromise.
- An IT Asset Management (ITAM) function, or similar function, categorizes devices according to the data the asset stores, transmits and/ or processes and applies the appropriate technology controls to protect the asset and data.
- A formal Change Management (CM) program help to ensure that no unauthorized changes are made, all changes are documented, services are not disrupted and resources are used efficiently.
- A Governance, Risk & Compliance (GRC) function, or similar function;
- A Project Management Office (PMO), or project management function, enables IAP pre-production testing of cybersecurity and data protection controls as part of the organization's established project management processes.
Level 4 — Quantitatively Controlled
See C|P-CMM3. There are no defined C|P-CMM4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.
Level 5 — Continuously Improving
See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs.
Assessment Objectives
- TDA-01_A01 a system and services acquisition policy is developed and documented.
- TDA-01_A02 system and services acquisition procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls are developed and documented.
- TDA-01_A03 acquisition strategies, contract tools, and procurement methods are implemented to identify supply chain risks.
- TDA-01_A04 acquisition strategies, contract tools, and procurement methods are implemented to protect against supply chain risks.
- TDA-01_A05 acquisition strategies, contract tools, and procurement methods are implemented to mitigate supply chain risks.
- TDA-01_A06 personnel or roles to whom the system and services acquisition policy is to be disseminated is/are defined.
- TDA-01_A07 personnel or roles to whom the system and services acquisition procedures are to be disseminated is/are defined.
- TDA-01_A08 one or more of the following organization-defined criteria is/are selected: {organization-level. mission/business process-level. system-level}.
- TDA-01_A09 an official to manage the system and services acquisition policy and procedures is defined.
- TDA-01_A10 the frequency at which the current system and services acquisition policy is reviewed / updated is defined.
- TDA-01_A11 events that would require the current system and services acquisition policy to be reviewed / updated are defined.
- TDA-01_A12 the frequency at which the current system and services acquisition procedures are reviewed / updated is defined.
- TDA-01_A13 events that would require the system and services acquisition procedures to be reviewed / updated are defined.
- TDA-01_A14 the system and services acquisition policy is disseminated to organization-defined personnel or roles.
- TDA-01_A15 the system and services acquisition procedures are disseminated to organization-defined personnel or roles.
- TDA-01_A16 the organization's system and services acquisition policy addresses purpose.
- TDA-01_A17 the organization's system and services acquisition policy addresses scope.
- TDA-01_A18 the organization's system and services acquisition policy addresses roles.
- TDA-01_A19 the organization's system and services acquisition policy addresses responsibilities.
- TDA-01_A20 the organization's system and services acquisition policy addresses management commitment.
- TDA-01_A21 the organization's system and services acquisition policy addresses coordination among organizational entities.
- TDA-01_A22 the organization's system and services acquisition policy addresses compliance.
- TDA-01_A23 the organization's system and services acquisition policy is consistent with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines.
- TDA-01_A24 the organization-defined official is designated to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures.
- TDA-01_A25 the system and services acquisition policy is reviewed / updated organization-defined frequency.
- TDA-01_A26 the current system and services acquisition policy is reviewed / updated following organization-defined events.
- TDA-01_A27 the current system and services acquisition procedures are reviewed / updated organization-defined frequency.
- TDA-01_A28 the current system and services acquisition procedures are reviewed / updated following organization-defined events.
- TDA-01_A29 systems or system components supporting mission-essential services or functions are defined.
- TDA-01_A30 organization's is employed on organization-defined systems or system components supporting essential services or functions to increase the trustworthiness in those systems or components.
- TDA-01_A31 systems security engineering principles to be applied to the development or modification of the system and system components are defined.
- TDA-01_A32 Technology Development & Acquisition (TDA) operations are conducted according to documented policies, standards, procedures and/or other organizational directives.
- TDA-01_A33 adequate resources (e.g., people, processes, technologies, data and/or facilities) are provided to support Technology Development & Acquisition (TDA) operations.
- TDA-01_A34 responsibility and authority for the performance of Technology Development & Acquisition (TDA)-related activities are assigned to designated personnel.
- TDA-01_A35 personnel performing Technology Development & Acquisition (TDA)-related activities have the skills and knowledge needed to perform their assigned duties.
Evidence Requirements
- E-TDA-01 Secure Software Development Principles (SSDP)
-
Documented evidence of a Secure Software Development Principles (SSDP). This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - E-TDA-02 Secure Engineering & Data Privacy (SEDP)
-
Documented evidence of a Secure Engineering & Data Privacy (SEDP) program. This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - E-TDA-08 Secure Engineering Principles (SEP)
-
Documented evidence of defined secure engineering principles used to ensure Sensitivity, Integrity, Availability & Safety (CIAS) concerns are properly addressed in the design and implementation of systems, applications and services.
Technology Design & Acquisition - E-TDA-17 System Design Documentation
-
Documented evidence of system design documentation.
Technology Design & Acquisition
Technology Recommendations
Micro/Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
Small
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
Medium
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
- System Development Lifecycle (SDLC) governance / oversight
Large
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
- System Development Lifecycle (SDLC) governance / oversight
Enterprise
- Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
- Defined business processes
- Product / project management
- Defined technical requirements
- Defined business requirements
- System Development Lifecycle (SDLC) governance / oversight