Implementing ISO 27001 Annex A 8.31 requires the rigid separation of development, testing, and production environments to maintain system integrity. This control mandates network-level segmentation and strict access restrictions to ensure code is verified before deployment. The critical business benefit is effectively preventing unauthorized changes and confidential data leakage.
Table of contents
- ISO 27001 Separation of development, test and production environments Implementation Checklist
- 1. Enforce Network-Level Segmentation
- 2. Implement Strict Role-Based Access Control (RBAC)
- 3. Mandate CI/CD Deployment Pipelines
- 4. Segregate Configuration Secrets
- 5. Sanitise Test Data
- 6. Differentiate Environments Visually
- 7. Restrict Compilers and Dev Tools in Prod
- 8. Implement “Break-Glass” Procedures
- 9. Lock Down Deployment Endpoints
- 10. Separate Backups and Archives
- ISO 27001 Annex A 8.31 SaaS / GRC Platform Implementation Failure Checklist
ISO 27001 Separation of development, test and production environments Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.31. This control necessitates a rigid logical and physical separation between development, test, and production environments to prevent unauthorised changes and data leakage.
1. Enforce Network-Level Segmentation
Control Requirement: Production environments must be isolated on the network level from development and test environments.
Required Implementation Step: Configure distinct VLANs or VPCs (Virtual Private Clouds) for Prod, Stage, and Dev. Implement ‘Deny All’ firewall rules between the Development network and the Production database ports; developers must not have a direct network route to production data stores.
Minimum Requirement: A `ping` from a development server to a production database server must timeout.
2. Implement Strict Role-Based Access Control (RBAC)
Control Requirement: Access rights must be restricted based on the environment’s classification.
Required Implementation Step: Audit your Identity Provider (IdP) groups. Remove ‘Write’ and ‘Execute’ permissions for the ‘Developers’ group in the Production environment; developers should only have access to view logs or metrics, not to modify infrastructure or data.
Minimum Requirement: Developers have Read-Only access to Production; only DevOps/SRE or CI/CD service accounts have Write access.
3. Mandate CI/CD Deployment Pipelines
Control Requirement: Changes to production must not be made manually by individuals.
Required Implementation Step: Disable SSH/RDP access for code deployment. Configure a CI/CD pipeline (e.g., Jenkins, GitLab CI, GitHub Actions) that is the only authorised mechanism to promote code from Staging to Production, ensuring an audit trail of every release.
Minimum Requirement: Direct editing of code on production servers is technically blocked.
4. Segregate Configuration Secrets
Control Requirement: Authentication credentials must be unique to each environment.
Required Implementation Step: Generate distinct API keys, database passwords, and encryption keys for Dev, Test, and Prod. Store these in a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) and inject them at runtime; never hardcode production secrets in the source code repository.
Minimum Requirement: A developer using the ‘Dev’ database password cannot authenticate against the ‘Prod’ database.
5. Sanitise Test Data
Control Requirement: Production data must not be used in development or test environments without protection.
Required Implementation Step: Write automated ETL scripts that mask, scramble, or anonymise Personally Identifiable Information (PII) when replicating data from Production to Staging. Alternatively, use synthetic data generators for lower environments.
Minimum Requirement: Real customer names and credit card numbers do not exist in the Test database.
6. Differentiate Environments Visually
Control Requirement: Staff must be able to immediately identify which environment they are working in to prevent errors.
Required Implementation Step: Configure terminal prompts, dashboard banners, and browser favicons to use distinct colour codes (e.g., Red for Production, Green for Dev). Force these visual cues via group policy or interface configuration settings.
Minimum Requirement: The Production console clearly displays a “PRODUCTION” warning banner.
7. Restrict Compilers and Dev Tools in Prod
Control Requirement: Development tools should not be present in the operational environment to reduce the attack surface.
Required Implementation Step: Strip compilers (gcc, make), debuggers, and unneeded editors from production server images or container builds. Production servers should contain only the compiled binary or runtime necessary to execute the application.
Minimum Requirement: Running `gcc` on a production server returns “command not found”.
8. Implement “Break-Glass” Procedures
Control Requirement: Emergency access to production must be controlled, monitored, and temporary.
Required Implementation Step: Create a specific emergency admin account that is disabled by default. Accessing it should trigger an immediate alert to the security team and require a documented incident ticket; access must be revoked immediately after the incident is resolved.
Minimum Requirement: No standing “Admin” accounts exist; elevation requires a logged approval workflow.
9. Lock Down Deployment Endpoints
Control Requirement: Testing activities must not impact production availability.
Required Implementation Step: Ensure that load testing and penetration testing tools are configured to target the Staging environment endpoints only. Block the IP addresses of load testing agents at the production firewall.
Minimum Requirement: Stress tests run against the Staging URL, never the Live URL.
10. Separate Backups and Archives
Control Requirement: Backups of production systems must be isolated to prevent accidental overwrites by development processes.
Required Implementation Step: Configure backup storage buckets (e.g., S3) with strict IAM policies that prevent the Development environment from reading or writing to Production backup repositories. Ensure retention policies differ appropriate to the environment.
Minimum Requirement: A ‘Restore to Dev’ command cannot accidentally target and overwrite a Production backup file.
ISO 27001 Annex A 8.31 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Network Segregation | SaaS tool checks if a policy document exists named “Network_Architecture.pdf”. | Prod and Dev servers reside on the same flat 192.168.x.x subnet, allowing malware to jump laterally instantly. |
| Access Control | SaaS tool verifies that “Access Control Policy” is signed by the CTO. | Developers share a generic `root` password for the production server, pinned in a Slack channel. |
| Data Sanitisation | SaaS tool asks “Do you protect test data?” (Yes/No). | Developers manually export full production database dumps (GDPR breach) to their unencrypted laptops for debugging. |
| Code Deployment | SaaS tool confirms a “Change Management” procedure is uploaded. | The lead developer edits PHP files directly on the live server using `nano` because “it’s faster”. |
| Secret Management | SaaS tool checks for an “Encryption Policy”. | AWS Access Keys with full admin privileges are hardcoded and committed into the public GitHub repository. |
| Environment Separation | SaaS tool looks for an asset register listing “Prod” and “Test”. | The “Test” environment is actually just a sub-folder on the Production server, sharing the same resources and vulnerabilities. |
| Tooling Restrictions | SaaS tool requires a “System Hardening Standard”. | Compilers and debugging tools are left installed on Prod, allowing attackers to compile exploits locally. |
ISO 27001 Certainty™: The Ultimate ISO 27001 Certification System & Toolkit
About the author
