A.8.31 Technological
Separation of development, test and production environments
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (12)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- AC-3mostlyaligns with — Both controls enforce access restrictions that prevent a single individual from modifying both development and production environments without review or approval.
- CM-2mostlyaligns with — Both controls require distinct, controlled environments for development, testing, and production to prevent unauthorized or untested changes from reaching operational systems.
- CM-4mostlyaligns with — The ISO requirement to test changes in a separate staging environment before production deployment directly supports the NIST objective of analyzing the security impact of changes prior to implementation.
- AC-6partialaligns with — The ISO guidance to restrict compilers, editors, and utilities from production systems and to segregate access rights implements the principle of least privilege across environment boundaries.
- AU-2partialaligns with — The ISO mandate for detailed logging and real-time monitoring when a single person can access both development and production supports the generation of audit records for security-relevant events.
- CM-3partialaligns with — Documented rules and authorization for moving software from development to production align with the NIST requirement for formal configuration change control procedures.
Aligned NIST CSF 2.0 outcomes (10)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.AA-05mostlyaligns with — By requiring segregation of access rights and prohibiting a single person from modifying both development and production without review, the control implements policy-driven access permissions and authorizations across environments.
- PR.IR-01mostlyaligns with — The control enforces logical separation of development, test, and production environments to prevent unauthorized access and changes, directly supporting the CSF outcome of protecting networks and environments from unauthorized logical access.
- PR.PS-01mostlyaligns with — The control mandates secure configuration, patching, and change monitoring of development, test, and production systems, aligning with the CSF outcome of establishing and applying configuration management practices.
- ID.AM-08partialaligns with — By defining distinct life-cycle stages for systems and requiring controlled transitions between development, test, and production, the control supports managing assets throughout their life cycles.
- PR.PS-04partialaligns with — The control requires secure monitoring and detailed logging of changes in development and production environments, which contributes to generating log records for continuous monitoring.
Related OWASP ASVS 5.0 requirements (10)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V13.2.4mostlycovers — Requiring explicit rules and authorization for moving code between development and production implements the same objective as maintaining an allow-list of permitted external or cross-environment resources.
- V13.2.3partialaligns with — The ISO requirement that a single person must not unilaterally change both development and production environments directly supports the ASVS rule that service credentials must not be default or shared across environments.
- V13.4.2partialaligns with — Mandating that development and test tools are inaccessible from production systems aligns with the ASVS control that debug modes must be disabled in production to avoid unintended exposure.
- V15.2.3partialaligns with — The ISO directive to keep development and test environments separate from production mirrors the ASVS requirement that production must contain only the functionality needed for live operation.
- V8.3.1partialaligns with — Enforcing deployment rules and authorization at the boundary between development and production environments corresponds to the ASVS expectation that authorization decisions are enforced at a trusted service layer rather than by untrusted clients.
Related weaknesses / CWE (35)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CWE-1291mostlyprevents — Separation of development/test and production environments extends to cryptographic material, preventing shared signing keys.
- CWE-215mostlyprevents — Separation of environments reduces accidental exposure of debug builds to production.
- CWE-653mostlyprevents — Separation of development, test and production environments is a direct application of compartmentalization.
- CWE-669mostlyprevents — Environment separation limits unintended resource leakage between spheres.
- CWE-11partialmitigates — Separation of environments reduces the chance that debug builds reach production but does not address the configuration weakness itself.
- CWE-114partialmitigates — Environment separation reduces risk of cross-contamination but does not directly address untrusted code execution.
- CWE-1269partialmitigates — Separation of development, test and production environments prevents accidental promotion of non-release configurations.
- CWE-1295partialmitigates — Separation of environments reduces risk of debug exposure in production but does not address the weakness itself.
- CWE-200partialprevents — Prohibiting the copy of sensitive data into less-protected development and test environments lowers the likelihood that production secrets will be exposed through weaker controls in those environments.
- CWE-250partialmitigates — Segregating environments and limiting tool availability in production stops developers from retaining unnecessary elevated privileges once code moves into the live system.
- CWE-284partialmitigates — Requiring distinct domains, access rules, and approval gates between development and production environments directly blocks unauthorized actors from reaching production resources they should never touch.
- CWE-489partialprevents — Separation of environments reduces risk of debug code reaching production but does not directly address its removal.
- CWE-527partialmitigates — Segregating development, test and production environments reduces the chance that repositories are placed in publicly accessible locations.
- CWE-531partialmitigates — Separation of dev/test/prod environments limits exposure of test code containing secrets.
- CWE-540partialmitigates — Environment separation reduces risk of accidental exposure but does not address secrets already in code.
- CWE-553partialprevents — Environment separation limits the blast radius but does not stop the shell from existing in the production web root.
- CWE-732partialmitigates — Mandating secure configuration and access control for development and test systems reduces the chance that overly permissive file or resource permissions will be inherited by production.
- CWE-1100nonenone — Separation of development, test and production environments indirectly benefits from modular isolation but does not enforce it.
- CWE-1125noneprevents — Environment separation reduces risk from development artifacts but does not address production attack surface size.
- CWE-214nonenone — Separation of environments limits the blast radius if sensitive invocation data is exposed.
- CWE-285nonenone — Enforcing documented authorization for deployments and prohibiting a single person from altering both development and production code prevents privilege misuse that would otherwise allow improper actions on production data.
- CWE-344noneprevents — Separation of environments highlights the need for different configurations, indirectly mitigating the weakness.
- CWE-501nonenone — Environment separation reduces cross-contamination risk but does not address mixing inside a single data structure.
- CWE-524nonenone — Environment separation reduces risk of cache exposure across development/test/production.
- CWE-74nonenone — Environment separation limits the blast radius of injection exploits but does not prevent them.
- CWE-77nonenone — Environment separation limits the blast radius of an exploited command injection but does not prevent the flaw itself.
- CWE-778nonenone — Requiring detailed logging and real-time monitoring when segregation cannot be fully enforced supplies the visibility needed to detect unauthorized changes that would otherwise go unnoticed.
- CWE-913nonenone — Environment separation reduces exposure of dynamic code resources but does not address the underlying weakness.
- CWE-95nonenone — Separation of environments limits the blast radius if eval injection occurs in non-production.
Mitigated MITRE ATT&CK techniques (8)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- T1078partialmitigates — Segregating development, test, and production environments plus enforcing dual-control change rules limits an adversary's ability to leverage a single compromised account across the full software lifecycle to introduce or execute malicious code in production.
- T1195partialmitigates — Requiring review, approval, and testing before code moves from development to production makes it harder for an attacker to insert malicious components into the supply chain that will later run in the live environment.
- T1505partialmitigates — Strict separation and access controls between development and production make it harder for an attacker to plant or modify server-side components such as web shells without passing documented change-control processes.
- T1210nonemitigates — Keeping development and test systems in separate domains from production limits lateral movement via remote service exploitation, because a foothold gained in one environment does not automatically grant access to the others.
- T1543nonemitigates — Rules that prevent a single individual from altering both development and production, plus mandatory pre-deployment testing, reduce the likelihood that a malicious service or scheduled task can be introduced into the live environment.
- T1550nonemitigates — Strict separation of environments and access rights reduces the chance that stolen credentials or tokens from a development or test system can be directly reused to access or manipulate production systems.
- T1553nonemitigates — Preventing development tools and compilers from being present on production systems reduces opportunities for an adversary to abuse or subvert trust mechanisms that rely on those utilities being available in the target environment.
- T1554nonemitigates — Keeping development utilities and compilers out of production, combined with mandatory testing in isolated environments, limits an adversary’s ability to alter or replace production binaries without detection.
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.