Skip to main content

TDA-01.1: Product Management

TDA 10 — Critical Protect

Mechanisms exist to design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations.

Control Question: Does the organization design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations?

General (24)
Framework Mapping Values
AICPA TSC 2017:2022 (used for SOC 2) (source) PI1.1-POF1 PI1.1-POF2 PI1.1-POF3
CIS CSC 8.1 15.7
COBIT 2019 APO03.02 APO03.03 BAI05.01 BAI05.02 BAI05.03 BAI05.04 BAI05.05 BAI05.06 BAI05.07 BAI06.01 BAI06.02 BAI06.03 BAI06.04 BAI07.01 BAI07.02 BAI07.04 BAI07.05 BAI07.06 BAI07.07 BAI07.08 BAI08.01 BAI08.02 BAI08.03 BAI08.04 DSS03.01 DSS03.02 DSS03.03 DSS03.04 DSS03.05
CSA IoT SCF 2 SET-05
IEC TR 60601-4-5 2021 4.2 4.6.2 4.6.3
IEC 62443-4-2 2019 CR 3.10 (7.12)
ISO/SAE 21434 2021 RQ-05-12 RC-05-13 RC-05-15 RC-05-16 RQ-06-01 RQ-06-05.a RQ-06-05.b RQ-06-09 RQ-06-18 RQ-06-19 RQ-06-20 RQ-06-21.a RQ-06-21.b RQ-06-21.c RQ-10-01.a RQ-10-01.b RQ-10-01.c RQ-10-02 RQ-10-03 RQ-12-01 RQ-12-02.a RQ-12-02.b RQ-12-02.c RQ-12-02.d RQ-12-03 RQ-14-02
ISO 42001 2023 A.6.2 A.6.2.2 A.6.2.7 A.6.2.8
NIST AI 100-1 (AI RMF) 1.0 GOVERN 1.2 GOVERN 3.1 GOVERN 4.1 GOVERN 4.2 GOVERN 5.1 GOVERN 5.2 GOVERN 6.0 MANAGE 2.0 MANAGE 2.2 MAP 2.1
NIST AI 600-1 GV-6.2-005 MP-1.1-004 MP-3.4-003 MS-1.1-008
NIST 800-53 R5 (source) SA-23
NIST 800-53 R5 (NOC) (source) SA-23
NIST 800-171 R3 (source) 03.12.03
NIST 800-218 PO.1 PO.1.1 PO.1.2 PO.4.2 PW.1.2 PW.4 PW.4.2 PW.5 PW.5.1 PW.6.2 PW.8.1 RV.2.2 RV.3 RV.3.3 RV.3.4
NIST CSF 2.0 (source) GV.SC-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
UL 2900-1 2017 11.5 11.6 11.7 11.8
UN R155 7.2.2.1(a) 7.2.2.1(b) 7.2.2.1(c) 7.2.2.2(a) 7.2.2.2(b) 7.2.2.2(c) 7.2.2.2(d) 7.2.2.2(e) 7.2.2.2(f) 7.2.2.2(g) 7.2.2.2(h) 7.2.2.3 7.2.2.4(a) 7.2.2.4(b) 7.2.2.5 7.4.1 7.4.2 8.1 8.1.1 8.1.2 8.1.3
UN ECE WP.29 7.2.2.1(a) 7.2.2.1(b) 7.2.2.1(c) 7.2.2.2(a) 7.2.2.2(b) 7.2.2.2(c) 7.2.2.2(d) 7.2.2.2(e) 7.2.2.2(f) 7.2.2.2(g) 7.2.2.2(h) 7.2.2.3 7.2.2.4(a) 7.2.2.4(b) 7.2.2.5 7.4.1 7.4.2 8.1 8.1.1 8.1.2 8.1.3
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) TDA-01.1
SCF CORE ESP Level 1 Foundational TDA-01.1
SCF CORE ESP Level 2 Critical Infrastructure TDA-01.1
SCF CORE ESP Level 3 Advanced Threats TDA-01.1
SCF CORE AI Model Deployment TDA-01.1
US (6)
Framework Mapping Values
US C2M2 2.1 RISK-2.J.MIL3
US DHS CISA SSDAF 1.d 2
US DHS ZTCF DEV-03
US EO 14028 4e(i)(D) 4e(iii)
US - CA SB327 1798.91.04(a) 1798.91.04(a)(1) 1798.91.04(a)(2) 1798.91.04(a)(3) 1798.91.04(b) 1798.91.04(b)(1) 1798.91.04(b)(2)
US - CA CCPA 2025 7123(c)(14)
EMEA (10)
Framework Mapping Values
EMEA EU AI Act 14.3(b)
EMEA EU Cyber Resiliency Act 10.1 10.1 10.10 10.11 10.5 10.6 10.9 13.1 13.2 13.2(a) 13.2(b) 13.2(c) 13.3 13.4 13.5 13.6 14.1 14.2 14.2(a) 14.2(b) 14.3 14.4 5 5.1 5.2
EMEA EU Cyber Resiliency Act Annexes Annex 1.1(3)(j) Annex 1.2(2) Annex 2.1 Annex 2.2 Annex 2.3 Annex 2.4 Annex 2.5 Annex 2.6 Annex 2.7 Annex 2.8 Annex 2.9 Annex 2.9(a) Annex 2.9(b) Annex 2.9(c) Annex 2.9(d) Annex 6 Module A.3 Annex 6 Module A.4.1 Annex 6 Module C.2.1 Annex 6 Module C.3.1 Annex 6 Module H.2 Annex 6 Module H.3.2 Annex 6 Module H.3.4 Annex 6 Module H.5.1 Annex 6 Module H.5.2 Annex 6 Module H.6
EMEA EU EBA GL/2019/04 3.6.2(68)
EMEA EU DORA 13.7
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 Israel CDMO 1.0 17.9
EMEA Qatar PDPPL 11.4 11.5 11.6
EMEA Saudi Arabia CSCC-1 2019 2-13-1 2-13-2 2-13-3-1 2-13-3-2 2-13-3-3 2-13-3-4
EMEA Saudi Arabia OTCC-1 2022 1-1-2 4-1-1-1
APAC (6)
Framework Mapping Values
APAC Australia ISM June 2024 ISM-1796 ISM-1797 ISM-1798
APAC Japan ISMAP 8.1.2.7.PB
APAC New Zealand HISF 2022 HHSP50 HML50 HSUP42
APAC New Zealand HISF Suppliers 2023 HSUP42
APAC New Zealand NZISM 3.6 12.1.31.C.01 12.1.32.C.01 12.1.32.C.02 12.1.32.C.03 12.1.33.C.01 12.1.34.C.01 12.1.34.C.02 12.1.35.C.01 12.1.36.C.01 12.1.37.C.01 12.4.3.C.01 12.4.4.C.01 12.4.4.C.02 12.4.4.C.03 12.4.4.C.04 12.4.4.C.05 12.4.4.C.06 12.4.5.C.01 12.4.6.C.01 12.4.7.C.01
APAC Singapore MAS TRM 2021 5.8.1 5.8.2 7.6.1 7.6.2 14.4.1 14.4.2 14.4.3
Americas (2)
Framework Mapping Values
Americas Canada OSFI B-13 2.4.3
Americas Canada ITSP-10-171 03.12.03

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations.

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 formally 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 and compliant practices.
  • IT/cybersecurity personnel identify cybersecurity and data privacy 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 privacy 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 privacy 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 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 privacy 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 privacy 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 design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations.

Assessment Objectives

  1. TDA-01.1_A01 product management processes are designed and implemented to ensure products, including systems, software and services, are routinely updated to improve functionality and correct security deficiencies.
  2. TDA-01.1_A02 systems or system components supporting mission-essential services or functions are defined.
  3. TDA-01.1_A03 organization-defined criteria are employed on systems or system components supporting essential services or functions to increase the trustworthiness in those systems or components.

Evidence Requirements

E-CPL-06 Manufacturer Disclosure Statement for Medical Device Security (MDS2)

Documented Manufacturer Disclosure Statement for Medical Device Security (MDS2) that communicates information about medical device cybersecurity & data privacy characteristics to current device owners and potential buyers. [note MDS2 is specific to medical device manufacturers]

Compliance
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
E-TDA-06 Multi Patient Harm View (MPHV)

Documented evidence of a description of a Multi Patient Harm View (MPHV) that explains how the device / system defends against and/or responds to attacks with the potential to harm multiple patients. [note MPHV is specific to medical device manufacturers]

Technology Design & Acquisition
E-TDA-07 Ports, Protocols & Services (PPS)

Documented evidence of all ports, protocols and services in use by the system, application or service.

Technology Design & Acquisition
E-TDA-15 Updateability / Patchability View

Documented evidence of a description of the end-to-end process permitting software updates and patches to be deployed to the device/service.

Technology Design & Acquisition
E-TDA-17 System Design Documentation

Documented evidence of system design documentation.

Technology Design & Acquisition

Technology Recommendations

Micro/Small

  • Defined business processes
  • Product / project management
  • Defined technical requirements
  • Defined business requirements

Small

  • Defined business processes
  • Product / project management
  • Defined technical requirements
  • Defined business requirements

Medium

  • Defined business processes
  • Product / project management
  • Defined technical requirements
  • Defined business requirements
  • System Development Lifecycle (SDLC) governance / oversight

Large

  • Defined business processes
  • Product / project management
  • Defined technical requirements
  • Defined business requirements
  • System Development Lifecycle (SDLC) governance / oversight

Enterprise

  • Defined business processes
  • Product / project management
  • Defined technical requirements
  • Defined business requirements
  • System Development Lifecycle (SDLC) governance / oversight

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.