The ultimate audit guide to ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments
Table of contents
- 1. Verify the Environment Segregation Policy
- 2. Review Logical Network Isolation
- 3. Ensure Administrative Account Segregation
- 4. Make sure there is no Production Data in Non-Production
- 5. Review Independent Deployment Path Integrity
- 6. Check that Developer Access to Production is Restricted
- 7. Ensure Cross-Environment Resource Segregation
- 8. Validate that Test Environment Hardening Aligns with Production
- 9. Check for Audit Logging of Environment Transitions
- 10. Evidence Segregation Reviews are Recorded
1. Verify the Environment Segregation Policy
Verification Criteria: A documented policy exists defining the mandatory separation between development, testing, and production environments, including specific trust boundaries.
Required Evidence: Approved “Access Control Policy” or “Secure Development Policy” citing environment isolation requirements.
Pass/Fail Test: If the organisation cannot produce a formalised standard defining the separation of these environments, mark as Non-Compliant.
2. Review Logical Network Isolation
Verification Criteria: Technical network controls (e.g., VLANs, Subnets, or VPCs) are active to prevent unauthorised traffic flow between development and production zones.
Required Evidence: Firewall rule base exports or Cloud Network Security Group (NSG) logs showing restricted ingress/egress between environments.
Pass/Fail Test: If a developer machine in the ‘Dev’ subnet can ping or access the ‘Production’ database directly via the internal network, mark as Non-Compliant.
3. Ensure Administrative Account Segregation
Verification Criteria: Identity and Access Management (IAM) configurations ensure that administrative accounts for development environments have no permissions in production.
Required Evidence: IAM role reports or Active Directory group memberships showing distinct, non-overlapping accounts for ‘Dev’ and ‘Prod’ admins.
Pass/Fail Test: If a single administrative credential grants ‘Write’ or ‘Owner’ access to both development and production clusters, mark as Non-Compliant.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Make sure there is no Production Data in Non-Production
Verification Criteria: Personal Identifiable Information (PII) or sensitive production data is not present in development or test environments without masking or anonymisation.
Required Evidence: Data masking logs or database snapshots from the ‘Test’ environment demonstrating the use of synthetic or obfuscated data.
Pass/Fail Test: If unmasked production PII is found residing on a development server or a local developer workstation, mark as Non-Compliant.
5. Review Independent Deployment Path Integrity
Verification Criteria: The software deployment process (CI/CD) utilizes independent, automated paths that prevent code from bypassing the ‘Test’ phase before reaching ‘Production’.
Required Evidence: Pipeline configuration files (e.g., Jenkinsfile, GitLab CI YAML) showing mandatory sequential stages and gated approvals.
Pass/Fail Test: If a developer can manually push code directly to production without passing through a verified staging/test environment gate, mark as Non-Compliant.
6. Check that Developer Access to Production is Restricted
Verification Criteria: Developers are technically restricted from accessing production environments, except for specific, time-limited emergency support cases.
Required Evidence: Access logs for the production environment and “Just-in-Time” (JIT) access records from a PAM tool.
Pass/Fail Test: If developers have permanent ‘Read/Write’ access to production servers for “troubleshooting” purposes, mark as Non-Compliant.
7. Ensure Cross-Environment Resource Segregation
Verification Criteria: Technical resources such as storage buckets, API keys, and service accounts are environment-specific and never shared between ‘Dev’ and ‘Prod’.
Required Evidence: Resource inventory showing distinct naming conventions and unique UUIDs for assets in different environments.
Pass/Fail Test: If a development application uses a production API key or shares a production S3 bucket for file storage, mark as Non-Compliant.
8. Validate that Test Environment Hardening Aligns with Production
Verification Criteria: The test environment is hardened to a level that mirrors the production environment to ensure that security tests are representative of reality.
Required Evidence: Configuration audit reports or Infrastructure-as-Code (IaC) templates showing parity in security settings between environments.
Pass/Fail Test: If the test environment has security controls (e.g., firewalls or MFA) disabled to “facilitate testing,” mark as Non-Compliant.
9. Check for Audit Logging of Environment Transitions
Verification Criteria: All transitions of code and data between environments are logged in an immutable central repository with associated change IDs.
Required Evidence: SIEM logs or VCS audit trails showing the movement of code from ‘Stage’ to ‘Production’ with timestamped authorisations.
Pass/Fail Test: If code is promoted to production without a corresponding log entry identifying the individual who authorised the transition, mark as Non-Compliant.
10. Evidence Segregation Reviews are Recorded
Verification Criteria: Management or security teams perform regular technical reviews to ensure environment isolation remains intact and has not suffered from configuration drift.
Required Evidence: Quarterly “Zone Integrity Reports” or Internal Audit logs specifically testing for cross-environment leakage.
Pass/Fail Test: If the organisation has not conducted a technical review of its environment isolation boundaries in the last 12 months, mark as Non-Compliant.
About the author
