Skip to main content

TDA-09: Cybersecurity & Data Protection Testing Throughout Development

TDA 9 — Critical Protect

Mechanisms exist to require system developers/integrators consult with cybersecurity and data protection personnel to: (1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability; (2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and (3) Document the results of the security testing/evaluation and flaw remediation processes.

Control Question: Does the organization require system developers/integrators consult with cybersecurity and data protection personnel to: (1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability; (2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and (3) Document the results of the security testing/evaluation and flaw remediation processes?

General (45)
Framework Mapping Values
AICPA TSC 2017:2022 (used for SOC 2) (source) CC4.1-POF1
CIS CSC 8.1 16.2 16.3 16.12
CIS CSC 8.1 IG2 16.2 16.3
CIS CSC 8.1 IG3 16.2 16.3 16.12
CSA CCM 4 AIS-05 TVM-03
CSA IoT SCF 2 SDV-07 SET-04 SET-05 SET-06
GovRAMP Core SA-11
GovRAMP Low+ SA-11
GovRAMP Moderate SA-11
GovRAMP High SA-11
ISO/SAE 21434 2021 RQ-10-10.a RQ-10-10.b RQ-10-10.c RQ-10-10.d RQ-10-11 RQ-10-12 RQ-10-13 RQ-11-01.a RQ-11-01.b RQ-11-01.c RQ-11-01.d RQ-11-02
ISO 27002 2022 8.25 8.29 8.30
ISO 27017 2015 14.2.7 14.2.8 14.2.9
MITRE ATT&CK 10 T1078, T1078.001, T1078.003, T1078.004, T1134.005, T1195.003, T1213.003, T1495, T1505, T1505.001, T1505.002, T1505.004, T1528, T1542, T1542.001, T1542.003, T1542.004, T1542.005, T1547.011, T1552, T1552.001, T1552.002, T1552.004, T1552.006, T1553, T1553.006, T1558.004, T1574.002, T1601, T1601.001, T1601.002, T1612
MPA Content Security Program 5.1 TS-1.12
NIST Privacy Framework 1.0 CT.DM-P9 CT.DM-P10
NIST 800-53 R4 SA-11
NIST 800-53 R4 (moderate) SA-11
NIST 800-53 R4 (high) SA-11
NIST 800-53 R5 (source) SA-11 SA-11(5) SA-11(6) SA-11(7)
NIST 800-53B R5 (privacy) (source) SA-11
NIST 800-53B R5 (moderate) (source) SA-11
NIST 800-53B R5 (high) (source) SA-11
NIST 800-53 R5 (NOC) (source) SA-11(5) SA-11(6) SA-11(7)
NIST 800-82 R3 MODERATE OT Overlay SA-11
NIST 800-82 R3 HIGH OT Overlay SA-11
NIST 800-161 R1 SA-11
NIST 800-161 R1 Level 1 SA-11
NIST 800-161 R1 Level 2 SA-11
NIST 800-161 R1 Level 3 SA-11
NIST 800-171 R2 (source) NFO-SA-11
NIST 800-171 R3 (source) 03.12.01 03.12.03 03.14.01.a
NIST 800-218 PO.4 PO.4.1 PW.5.1 PW.6 PW.7 PW.7.1 PW.8.1 PW.8.2 RV.1 RV.2 RV.2.1 RV.2.2 RV.3.1 RV.3.2 RV.3.3
NIST CSF 2.0 (source) ID.IM-01 ID.IM-02 ID.RA-01 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.3 6.2.3.1 6.2.4 6.5.6
PCI DSS 4.0.1 SAQ A-EP (source) 6.2.4
PCI DSS 4.0.1 SAQ C (source) 6.2.3.1 6.2.4
PCI DSS 4.0.1 SAQ D Merchant (source) 6.2.3 6.2.3.1 6.2.4 6.5.6
PCI DSS 4.0.1 SAQ D Service Provider (source) 6.2.3 6.2.3.1 6.2.4 6.5.6
UL 2900-1 2017 5.1 6.10 12.1 12.2 12.3 12.4 13.1 13.2 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10 15.11
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) TDA-09
SCF CORE ESP Level 1 Foundational TDA-09
SCF CORE ESP Level 2 Critical Infrastructure TDA-09
SCF CORE ESP Level 3 Advanced Threats TDA-09
US (20)
Framework Mapping Values
US C2M2 2.1 RISK-2.J.MIL3 ARCHITECTURE-4.H.MIL3
US CERT RMM 1.2 EXD:SG3.SP4 RTSE:SG1.SP4 RTSE:SG1.SP5 VAR:SG2.SP2 VAR:SG2.SP3 VAR:SG3.SP1 VAR:SG4.SP1
US CMS MARS-E 2.0 SA-11
US DoD Zero Trust Execution Roadmap 3.2.3 3.3 3.3.4
US DHS CISA SSDAF 2 4 4.a
US DHS ZTCF DEV-03 DEV-04
US EO 14028 4e(iii) 4e(iv) 4e(iv)
US FedRAMP R4 SA-11
US FedRAMP R4 (moderate) SA-11
US FedRAMP R4 (high) SA-11
US FedRAMP R5 (source) SA-11
US FedRAMP R5 (moderate) (source) SA-11
US FedRAMP R5 (high) (source) SA-11
US IRS 1075 SA-11 SA-11(5) SA-11(6)
US NISPOM 2020 8-302
US - CA CCPA 2025 7123(c)(14)
US - MA 201 CMR 17.00 17.03(2)(d)(B)(i)
US - NY DFS 23 NYCRR500 2023 Amd 2 500.8(a)
US - TX DIR Control Standards 2.0 SA-11
US - TX TX-RAMP Level 2 SA-11
EMEA (10)
Framework Mapping Values
EMEA EU EBA GL/2019/04 3.6.2(69) 3.6.2(70) 3.6.2(71)
EMEA EU NIS2 Annex 6.2.2(d) 6.5.1
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-02
EMEA Israel CDMO 1.0 11.9 17.3 17.4 17.12 17.15
EMEA Saudi Arabia CSCC-1 2019 1-3-1-1 1-3-2-1
EMEA Saudi Arabia ECC-1 2018 1-5-3-2 1-5-3-4 1-6-3-3
EMEA Saudi Arabia OTCC-1 2022 1-4-1-2
EMEA Saudi Arabia SACS-002 TPC-72
EMEA Spain CCN-STIC 825 8.6.2 [MP.SW.2]
APAC (4)
Framework Mapping Values
APAC Australia ISM June 2024 ISM-0402 ISM-1754
APAC India SEBI CSCRF PR.IP.S6
APAC Japan ISMAP 14.2.7 14.2.8 14.2.9
APAC Singapore MAS TRM 2021 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6 6.1.1 6.1.2 6.1.3 6.1.4 6.1.6 6.1.7
Americas (3)
Framework Mapping Values
Americas Canada CSAG 4.8 4.9
Americas Canada OSFI B-13 3.2.9
Americas Canada ITSP-10-171 03.12.01 03.12.03 03.14.01.A

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to require system developers/integrators consult with cybersecurity and data protection personnel to: (1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability; (2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and (3) Document the results of the security testing/evaluation and flaw remediation processes.

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.
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 protection-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.

  • 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 protection 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

Technology Development & Acquisition (TDA) efforts are metrics driven and provide sufficient management insight (based on a quantitative understanding of process capabilities) to predict optimal performance, ensure continued operations and identify areas for improvement. In addition to CMM Level 3 criteria, CMM Level 4 control maturity would reasonably expect all, or at least most, the following criteria to exist:

  • Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
  • Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
  • Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
  • Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
  • Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
  • Both business and technical stakeholders are involved in reviewing and approving proposed changes.
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 require system developers/integrators consult with cybersecurity and data protection personnel to: (1) Create and implement a Security Testing and Evaluation (ST&E) plan, or similar capability; (2) Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and (3) Document the results of the security testing/evaluation and flaw remediation processes.

Assessment Objectives

  1. TDA-09_A01 the developer of the system, system component or system service is required to demonstrate the use of a system development life cycle process that includes organization-defined system security engineering methods.
  2. TDA-09_A02 the developer of the system, system component or system service is required to perform attack surface reviews.
  3. TDA-09_A03 the breadth of testing and evaluation of required controls is defined.
  4. TDA-09_A04 the depth of testing and evaluation of required controls is defined.
  5. TDA-09_A05 frequency at which to conduct testing/evaluation is defined.
  6. TDA-09_A06 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to develop a plan for ongoing security assessments.
  7. TDA-09_A07 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing security assessments.
  8. TDA-09_A08 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to develop a plan for privacy assessments.
  9. TDA-09_A09 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing privacy assessments.
  10. TDA-09_A10 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to perform testing/evaluation frequency to conduct at depth and coverage.
  11. TDA-09_A11 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to produce evidence of the execution of the assessment plan.
  12. TDA-09_A12 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to produce the results of the testing and evaluation.
  13. TDA-09_A13 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to implement a verifiable flaw remediation process.
  14. TDA-09_A14 the developer of the system, system component or system service is required at all post-design stages of the system development life cycle to correct flaws identified during testing and evaluation.
  15. TDA-09_A15 the developer of the system, system component, or system service is required to verify that the scope of testing and evaluation provides complete coverage of the required controls per an organization-defined breadth.
  16. TDA-09_A16 the developer of the system, system component, or system service is required to verify that the scope of testing and evaluation provides complete coverage of the required controls per an organization-defined depth.

Evidence Requirements

E-TDA-03 Application Security Testing (AST)

Documented evidence of application security testing (e.g., DAST, SAST, fuzzing, etc.).

Technology Design & Acquisition
E-TDA-05 Failure Mode and Effect Analysis (FMEA)

Documented evidence of an engineering method designed to define, identify, and present solutions for system failures, problems, or errors.

Technology Design & Acquisition

Technology Recommendations

Micro/Small

  • Security Testing and Evaluation (ST&E)

Small

  • Security Testing and Evaluation (ST&E)

Medium

  • Security Testing and Evaluation (ST&E)

Large

  • Security Testing and Evaluation (ST&E)

Enterprise

  • Security Testing and Evaluation (ST&E)

The Secure Controls Framework (SCF) is maintained by SCF Council. Use of SCF content is subject to the SCF Terms & Conditions.

Manage this control in SCF Connect

Track implementation status, collect evidence, and map controls to your compliance frameworks automatically.