Auditing ISO 27001 Annex A 8.31 Separation of Development, Test, and Production Environments is the technical verification of logical and physical isolation between lifecycle stages. The Primary Implementation Requirement is strict network segregation and IAM role exclusivity, providing the Business Benefit of protecting production integrity and preventing unauthorised data exposure.
ISO 27001 Annex A 8.31 Separation of Development, Test, and Production Environments Audit Checklist
This technical verification tool is designed for lead auditors to establish the logical and physical isolation of critical environments. Use this checklist to validate compliance with ISO 27001 Annex A 8.31.
1. Environment Segregation Policy Formalisation Verified
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. Logical Network Isolation Confirmed
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. Administrative Account Segregation Validated
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.
4. Production Data Absence in Non-Production Zones Confirmed
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. Independent Deployment Path Integrity Verified
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. Developer Access to Production 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. Cross-Environment Resource Segregation Confirmed
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. Test Environment Hardening Alignment Validated
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. Audit Logging of Environment Transitions Verified
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. Periodic Segregation Efficacy Reviews 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.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Policy Enforcement | Tool checks if “SDLC Policy” is uploaded. | Verify Technical Boundaries. A PDF is intent; the auditor must see the VPC peering configurations that block traffic. |
| Identity Isolation | Platform identifies that “MFA is enabled.” | Verify Role Exclusivity. Check if the ‘Dev Admin’ group has ‘Owner’ rights in the production subscription. |
| Data Segregation | Tool accepts an answer saying “No production data used.” | Audit Disk Samples. Check the ‘Test’ database for legitimate customer names or email addresses that shouldn’t be there. |
| Deployment Gates | SaaS tool records “GitHub Actions is used.” | Verify Bypass Prevention. Can a developer with ‘Owner’ rights force-push code to the production branch? |
| Resource Isolation | Tool identifies “S3 Bucket: Active.” | Check Cross-Account Access. Lazy engineers often use production buckets for Dev testing to avoid “permission headaches.” |
| Emergency Access | Tool confirms “Emergency Access Policy” exists. | Review Usage Logs. If “Emergency” access is used daily, it is standard access masquerading as a controlled exception. |
| Environment Parity | Platform identifies “Testing environment exists.” | Verify Firewall Rules. If Dev is “Allow All” but Prod is “Deny All,” your security testing in Dev is a technical fiction. |
About the author
