Skip to main content

TDA-08: Separation of Development, Testing and Operational Environments

TDA 10 — Critical Protect

Mechanisms exist to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).

Control Question: Does the organization manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS)?

General (24)
Framework Mapping Values
CIS CSC 8.1 16.8
CIS CSC 8.1 IG2 16.8
CIS CSC 8.1 IG3 16.8
CSA CCM 4 AIS-06 IVS-05
GovRAMP High CM-04(01)
ISO/SAE 21434 2021 RC-05-15
ISO 27002 2022 8.25 8.31
ISO 27017 2015 12.1.4
MPA Content Security Program 5.1 TS-1.0 TS-2.5
NIST Privacy Framework 1.0 PR.DS-P7
NIST 800-53 R4 CM-4(1)
NIST 800-53 R4 (high) CM-4(1)
NIST 800-53 R5 (source) CM-4(1)
NIST 800-53B R5 (high) (source) CM-4(1)
NIST 800-82 R3 HIGH OT Overlay CM-4(1)
NIST 800-161 R1 CM-4(1)
NIST 800-161 R1 Level 3 CM-4(1)
NIST 800-171 R2 (source) 3.4.5
NIST 800-218 PO.5 PO.5.1
PCI DSS 4.0.1 (source) 6.5.3 6.5.6
PCI DSS 4.0.1 SAQ D Merchant (source) 6.5.3 6.5.6
PCI DSS 4.0.1 SAQ D Service Provider (source) 6.5.3 6.5.6
Shared Assessments SIG 2025 I.1.1
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) TDA-08
US (13)
Framework Mapping Values
US CMMC 2.0 Level 2 (source) CM.L2-3.4.5
US CMMC 2.0 Level 3 (source) CM.L2-3.4.5
US CMS MARS-E 2.0 CM-4(1)
US DHS CISA SSDAF 1 1.a
US DHS ZTCF DEV-03 DEV-04
US EO 14028 4e(i) 4e(i)(A)
US FedRAMP R4 CM-4(1)
US FedRAMP R4 (high) CM-4(1)
US FedRAMP R5 (source) CM-4(1)
US FedRAMP R5 (high) (source) CM-4(1)
US FFIEC D3.PC.Am.B.10
US HIPAA HICP Small Practice 6.S.A
US - CA CCPA 2025 7123(c)(14)
EMEA (7)
APAC (6)
Framework Mapping Values
APAC Australia ISM June 2024 ISM-0400 ISM-1273 ISM-1274
APAC India SEBI CSCRF PR.DS.S5
APAC Japan ISMAP 12.1.4
APAC New Zealand HISF 2022 HHSP58 HML58 HSUP50
APAC New Zealand HISF Suppliers 2023 HSUP50
APAC Singapore MAS TRM 2021 5.7.3

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).

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 privacy-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
  • IT/cybersecurity architects manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).
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.
  • IT/cybersecurity architects manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).
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 manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).

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 manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production Technology Assets, Applications and/or Services (TAAS).

Assessment Objectives

  1. TDA-08_A01 changes to the system are analyzed in a separate test environment before implementation in an operational environment.
  2. TDA-08_A02 changes to the system are analyzed for cybersecurity / data privacy impacts due to flaws.
  3. TDA-08_A03 changes to the system are analyzed for cybersecurity / data privacy impacts due to weaknesses.
  4. TDA-08_A04 changes to the system are analyzed for cybersecurity / data privacy impacts due to incompatibility.
  5. TDA-08_A05 changes to the system are analyzed for cybersecurity / data privacy impacts due to intentional malice.

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.