Skip to main content

TDA-14: Developer Configuration Management

TDA 9 — Critical Protect

Mechanisms exist to require system developers and integrators to perform configuration management during system design, development, implementation and operation.

Control Question: Does the organization require system developers and integrators to perform configuration management during system design, development, implementation and operation?

General (24)
Framework Mapping Values
CIS CSC 8.1 16.11
CIS CSC 8.1 IG2 16.11
CIS CSC 8.1 IG3 16.11
GovRAMP Moderate SA-10
GovRAMP High SA-10
ISO 27002 2022 8.30 8.32
ISO 27017 2015 14.2.4
MITRE ATT&CK 10 T1078, T1078.001, T1078.003, T1078.004, T1195.003, T1213.003, T1495, T1505, T1505.001, T1505.002, T1505.004, T1542, T1542.001, T1542.003, T1542.004, T1542.005, T1547.011, T1553, T1553.006, T1564.009, T1574.002, T1601, T1601.001, T1601.002
NIST 800-53 R4 SA-10
NIST 800-53 R4 (moderate) SA-10
NIST 800-53 R4 (high) SA-10
NIST 800-53 R5 (source) SA-10
NIST 800-53B R5 (moderate) (source) SA-10
NIST 800-53B R5 (high) (source) SA-10
NIST 800-82 R3 MODERATE OT Overlay SA-10
NIST 800-82 R3 HIGH OT Overlay SA-10
NIST 800-161 R1 SA-10
NIST 800-161 R1 Level 2 SA-10
NIST 800-161 R1 Level 3 SA-10
NIST 800-171 R2 (source) NFO-SA-10
NIST CSF 2.0 (source) ID.RA-09
SCF CORE ESP Level 1 Foundational TDA-14
SCF CORE ESP Level 2 Critical Infrastructure TDA-14
SCF CORE ESP Level 3 Advanced Threats TDA-14
US (14)
Framework Mapping Values
US CERT RMM 1.2 TM:SG4.SP2 TM:SG4.SP3 VAR:SG2.SP2 VAR:SG2.SP3 VAR:SG3.SP1
US CMS MARS-E 2.0 SA-10
US DHS ZTCF DEV-04
US FedRAMP R4 SA-10
US FedRAMP R4 (moderate) SA-10
US FedRAMP R4 (high) SA-10
US FedRAMP R5 (source) SA-10
US FedRAMP R5 (moderate) (source) SA-10
US FedRAMP R5 (high) (source) SA-10
US IRS 1075 SA-10
US - CA CCPA 2025 7123(c)(14)
US - MA 201 CMR 17.00 17.03(2)(d)(B)(i)
US - TX DIR Control Standards 2.0 SA-10
US - TX TX-RAMP Level 2 SA-10
EMEA (1)
Framework Mapping Values
EMEA Germany C5 2020 DEV-02
APAC (2)
Framework Mapping Values
APAC Japan ISMAP 14.2.4
APAC Singapore MAS TRM 2021 6.1.5

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to require system developers and integrators to perform configuration management during system design, development, implementation and operation.

Level 1 — Performed Informally

C|P-CMM1 is N/A, since a structured process is required to require system developers and integrators to perform configuration management during system design, development, implementation and operation.

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.

  • 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

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 and integrators to perform configuration management during system design, development, implementation and operation.

Assessment Objectives

  1. TDA-14_A01 the developer of system, systems component or system service is required to have appropriate access authorizations as determined by assigned official duties.
  2. TDA-14_A02 configuration items under configuration management are defined.
  3. TDA-14_A03 personnel to whom security flaws and flaw resolutions within the system, component or service are reported is/are defined.
  4. TDA-14_A04 the developer of the system, system component or system service is required to perform configuration management during system, component or service per organization-defined criteria.
  5. TDA-14_A05 the developer of the system, system component or system service is required to document the integrity of changes to configuration items.
  6. TDA-14_A06 the developer of the system, system component or system service is required to manage the integrity of changes to configuration items.
  7. TDA-14_A07 the developer of the system, system component or system service is required to control the integrity of changes to configuration items.
  8. TDA-14_A08 the developer of the system, system component or system service is required to implement only organization-approved changes to the system, component or service.
  9. TDA-14_A09 the developer of the system, system component or system service is required to document approved changes to the system, component or service.
  10. TDA-14_A10 the developer of the system, system component or system service is required to document the potential security impacts of approved changes.
  11. TDA-14_A11 the developer of the system, system component or system service is required to document the potential privacy impacts of approved changes.
  12. TDA-14_A12 the developer of the system, system component or system service is required to track security flaws within the system, component or service.
  13. TDA-14_A13 the developer of the system, system component or system service is required to track security flaw resolutions within the system, component or service.
  14. TDA-14_A14 the developer of the system, system component or system service is required to report findings to personnel.
  15. TDA-14_A15 an alternate configuration management process has been provided using organizational personnel in the absence of a dedicated developer configuration management team.
  16. TDA-14_A16 the frequency with which to reassess individual positions and access to sensitive / regulated data is defined.
  17. TDA-14_A17 individuals that require enhanced personnel screening are identified.
  18. TDA-14_A18 positions that require access to sensitive / regulated data are identified.
  19. TDA-14_A19 organization-defined enhanced personnel screening is conducted for individuals.
  20. TDA-14_A20 individual positions and access to sensitive / regulated data is reassessed per an organization-defined frequency.
  21. TDA-14_A21 individuals with access to sensitive / regulated data are identified.
  22. TDA-14_A22 adverse information about individuals with access to sensitive / regulated data is defined.
  23. TDA-14_A23 organizational systems to which individuals have access are identified.
  24. TDA-14_A24 mechanisms are in place to protect organizational systems if adverse information develops or is obtained about individuals with access to sensitive / regulated data.

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-04 Design and Development Plan (DDP)

Documented evidence of an engineering method to control the design process and govern the lifecycle of the product/service.

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

Technology Recommendations

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.