Skip to main content

TDA-20: 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.

Renumbered: Formerly TDA-14 in SCF 2025.4.

Code reused: In SCF 2025.4 and earlier, TDA-20 was Access to Program Source Code. That control is now TDA-16.1.

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

General (22)
Framework Mapping Values
CIS CSC 8.1 16.11
CIS CSC 8.1 IG2 16.11
CIS CSC 8.1 IG3 16.11
GovRAMP SA-10
GovRAMP Moderate SA-10
GovRAMP High SA-10
ISO 27002 2022 8.30 8.32
ISO 27017 2015 12.1.2 14.2.4
ISO 27018 2025 8.30 8.32
MITRE ATT&CK 16 T1072 T1078 T1078.001 T1078.003 T1078.004 T1195.001 T1195.003 T1213.003 T1495 T1505 T1505.001 T1505.002 T1505.004 T1542 T1542.001 T1542.003 T1542.004 T1542.005 T1553 T1553.006 T1559.003 T1564.009 T1574.002 T1601 T1601.001 T1601.002 T1647
NIST 800-53 R4 SA-10
NIST 800-53 R5.2 SA-10
NIST 800-53B R5 (moderate) (source) SA-10
NIST 800-53B R5 (high) (source) SA-10
NIST 800-82 R3 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
US (8)
EMEA (2)
Framework Mapping Values
EMEA Germany C5 2026 DEV-02.02B.1 DEV-02.02B.2
EMEA Spain CCN-STIC 825 op.exp.5

Capability Maturity Model

Level 0 — Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 — Performed Informally

SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

Level 2 — Planned & Tracked

Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments.

Level 3 — Well Defined

Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to require system developers and integrators to perform configuration management during system design, development, implementation and operation.

Level 4 — Quantitatively Controlled

Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ 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. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 — Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.

Assessment Objectives

  1. TDA-20_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-20_A02 configuration items under configuration management are defined.
  3. TDA-20_A03 personnel to whom security flaws and flaw resolutions within the system, component or service are reported is/are defined.
  4. TDA-20_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-20_A05 the developer of the system, system component or system service is required to document the integrity of changes to configuration items.
  6. TDA-20_A06 the developer of the system, system component or system service is required to manage the integrity of changes to configuration items.
  7. TDA-20_A07 the developer of the system, system component or system service is required to control the integrity of changes to configuration items.
  8. TDA-20_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-20_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-20_A10 the developer of the system, system component or system service is required to document the potential security impacts of approved changes.
  11. TDA-20_A11 the developer of the system, system component or system service is required to document the potential privacy impacts of approved changes.
  12. TDA-20_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-20_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-20_A14 the developer of the system, system component or system service is required to report findings to personnel.
  15. TDA-20_A15 an alternate configuration management process has been provided using organizational personnel in the absence of a dedicated developer configuration management team.
  16. TDA-20_A16 the frequency with which to reassess individual positions and access to sensitive / regulated data is defined.
  17. TDA-20_A17 individuals that require enhanced personnel screening are identified.
  18. TDA-20_A18 positions that require access to sensitive / regulated data are identified.
  19. TDA-20_A19 organization-defined enhanced personnel screening is conducted for individuals.
  20. TDA-20_A20 individual positions and access to sensitive / regulated data is reassessed per an organization-defined frequency.
  21. TDA-20_A21 individuals with access to sensitive / regulated data are identified.
  22. TDA-20_A22 adverse information about individuals with access to sensitive / regulated data is defined.
  23. TDA-20_A23 organizational systems to which individuals have access are identified.
  24. TDA-20_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-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

Technology Recommendations

Micro/Small

  • Version control for code and configuration (e.g., Git)

Small

  • Version control with tagged releases
  • Configuration items documented

Medium

  • Developer configuration management (source control, build configuration, environment definitions as code)
  • Change tracking through the SDLC

Large

  • Configuration management plan for developed systems
  • Infrastructure as Code (IaC) under version control
  • Baseline management

Enterprise

  • Enterprise developer configuration management standards (e.g., aligned with NIST SP 800-128 and SSDF)
  • Automated baseline tracking and drift detection
  • Developer contract CM requirements

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.