8.31 Separation of development, test and production environments
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.
Source: ISO/IEC 27002:2022, 8.31. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Security configuration, patching, access control, monitoring and backup evidence for development and test environments · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
- Documented promotion rules and authorization records for moving software into production · Cloud console / configuration management
- Evidence that development tools are absent from production and environment labels are displayed · Cloud console / configuration management
- Approvals for any testing performed in production under defined circumstances · Cloud console / configuration management
governing documentDocuments that govern the control
- Architecture showing development, test and production in separate domains, accounts or subscriptions · Policy repository / GRC workspace
- Access rights showing that no individual can change both development and production without review, or monitoring that detects it · Policy repository / GRC workspace
First move
Common gaps auditors find
- 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
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet