Separation of development, test and production environments

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Environment separation protects production. The guidance asks for the boundary, the data, the access and the test.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep architecture showing development, test and production in separate domains, accounts or subscriptions and one live sample together.

Evidence an assessor asks for

• Environment separationArchitecture showing development, test and production in separate domains, accounts or subscriptions
• Environment separationDocumented promotion rules and authorization records for moving software into production
• Environment separationAccess rights showing that no individual can change both development and production without review, or monitoring that detects it
• Environment separationEvidence that development tools are absent from production and environment labels are displayed
• Environment separationSecurity configuration, patching, access control, monitoring and backup evidence for development and test environments
• Environment separationApprovals for any testing performed in production under defined circumstances

The question an assessor will ask

An assessor will ask for architecture showing development, test and production in separate domains, accounts or subscriptions, then trace it to the system it protects. For A.8.31 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: developers hold standing administrative access to production.