All 93 controls · Technological controls
Control 8.31
Separation of development, test and production environments
What ISO/IEC 27002:2022 control 8.31 asks for, in our own words, with the five published attribute values, the evidence an auditor asks for and the gaps commonly found. ISO/IEC 27028 is the guidance that explains how to use these values.
What the control asks
Development, test and production environments are to be kept apart and secured. Purpose: keep work done in development and testing from harming production systems or production data. Guidance: determine and implement the degree of separation needed to avoid production problems, considering: separating development and production systems adequately and running them in different domains, such as separate virtual or physical environments; defining, documenting and applying rules and authorization for promoting software from development to production; testing changes in a test or staging environment before applying them to production (8.29); not testing in production except in defined, approved circumstances; keeping compilers, editors and other development or utility tools out of reach of production systems when not needed; showing clear environment labels in menus to reduce mistakes; and not copying sensitive information into development and test environments unless they have equivalent controls. Development and test environments themselves should be protected by patching and updating all development, integration and test tools (builders, integrators, compilers, configuration systems, libraries), securely configuring systems and software, controlling access, monitoring changes to the environments and the code in them, monitoring them securely, and backing them up. Nobody should be able to alter development and production alike unless someone has reviewed and approved it first, achieved through separate access rights or monitored rules; in exceptional cases, fine-grained logs and live monitoring should catch and respond to unauthorized changes. Other information: developer and tester access to production risks unwanted changes, failures, running untested code, disclosure and integrity or availability problems; a known, stable test environment is needed, supported by well-designed roles, segregation of duties and monitoring; shared environments cause accidental changes; sometimes the boundaries are deliberately blurred through pilot rollouts, internal live use or twin production environments for zero-downtime deployment; processes for using production data in testing (8.33) are needed; the same guidance can apply to training environments.
Purpose in the standard’s terms, in our words: Keeps development and testing work from harming production systems and data.
Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Application security, System and network security; Protection.
The five attribute values
These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.
| Control type | Preventive |
|---|---|
| Information security properties | ConfidentialityIntegrityAvailability |
| Cybersecurity concepts | Protect |
| Operational capabilities | Application securitySystem and network security |
| Security domains | Protection |
Evidence an auditor asks for
The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.
- Architecture showing development, test and production in separate domains, accounts or subscriptions
- Documented promotion rules and authorization records for moving software into production
- Access rights showing that no individual can change both development and production without review, or monitoring that detects it
- Evidence that development tools are absent from production and environment labels are displayed
- Security configuration, patching, access control, monitoring and backup evidence for development and test environments
- Approvals for any testing performed in production under defined circumstances
Where audits commonly find gaps
- Developers hold standing administrative access to production
- Test environments contain unmasked copies of production data with weak access controls
- Development and test tools are unpatched because they are seen as low risk
- Production and test consoles look identical, leading to changes in the wrong environment
What ISO/IEC 27028 changes for this control
It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (12.1.4, 14.2.6) is kept in the register so an older audit file can still be traced.
The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.
Controls that share its values
Source for this page
- ISO/IEC 27002:2022, the control catalogue and Table A.1. The reference record of the 93 controls, their five attribute values, purpose, evidence and gaps. The published standard is at https://www.iso.org/standard/75652.html.
- ISO/IEC 27028, official record. Stage 60.00 under publication, edition 1, committee, abstract and the dated lifecycle. Retrieved 20 October 2026.
Retrieved 2026-10-20. The requirement above is our statement of the clause in our own words; the official text is linked so you can check it.
The attribute kit, USD 799 one off. The 109-row register with all five values, the evidence list, a dated plan and the extension worksheet, as PDF, CSV and XLSX.