Separation of development, test and production environments
Plain English Translation
Organizations must logically and physically separate their development, testing, and production environments. This ensures that experimental changes, untested code, or developmental tools do not inadvertently impact live customer-facing systems or corrupt production data. Enforcing strict access controls and distinct networks between these environments prevents unapproved modifications and minimizes the blast radius of potential security incidents.
Technical Implementation
Use the tabs below to select your organization size.
Required Actions (startup)
- Use separate database instances and subnets for staging and production.
- Restrict developer write access to the production environment.
- Avoid using live customer data in local development environments.
Required Actions (scaleup)
- Deploy dev, test, and prod into distinct cloud accounts (e.g., AWS Organizations, Azure Subscriptions).
- Implement automated CI/CD pipelines to manage all code deployments to production.
- Ensure secrets and API keys are managed independently per environment.
Required Actions (enterprise)
- Enforce strict zero-trust network boundaries between all environments.
- Implement automated data masking or synthetic data generation for testing purposes.
- Require multi-factor authentication and Just-In-Time (JIT) access for any production troubleshooting.
ISO 27001 Clause A.8.31 is a technological control requiring organizations to separate and secure their development, testing, and production environments. Understanding what is separation of development test and production environments involves ensuring these stages are strictly isolated to prevent untested changes or overly broad developer access from impacting live, critical systems.
Organizations must separate these environments to protect live services from instability, accidental data corruption, and security vulnerabilities introduced during active development. Proper environment segregation ensures that buggy code or misconfigurations in a test environment do not cascade into production, maintaining overall system reliability and data integrity.
Production environments demand the strictest controls, requiring formal change management approvals, continuous security logging, and highly restricted access limited strictly to authorized operations personnel. In contrast, development environments typically allow broader access and rapid, unapproved changes to foster developer productivity, while testing environments balance the two for rigorous quality assurance.
Knowing how to use separate cloud accounts or subscriptions for dev test prod is the most robust and highly recommended method for cloud isolation. Organizations should utilize AWS Organizations, Azure Management Groups, or GCP Folders to place dev, test, and prod workloads into entirely separate accounts, ensuring absolute logical boundaries and preventing IAM permissions from inadvertently overlapping.
While using network segmentation for dev test and production environments via VPCs, VNETs, or namespaces provides a baseline of isolation, it is often insufficient on its own for rigorous compliance. Organizations must pair this network segmentation with distinct identity and access management (IAM) roles, separate databases, and independent secret management to fully meet ISO 27001 A.8.31 control requirements and examples.
Standard developers should not have standing write access to production data or infrastructure. Production environment access controls and approvals should restrict access to designated operations teams or automated deployment pipelines. Emergency break-glass access must be handled via Just-In-Time (JIT) provisioning, requiring formal ticketing, multi-factor authentication, and comprehensive, unalterable session logging.
Applying best practices for environment segregation in CI/CD pipelines involves creating strict, automated deployment gates. The CI/CD system should automatically block code from reaching production unless it has successfully passed automated security tests in the staging environment and received explicit, logged approval from an authorized release manager.
Common audit evidence for environment separation ISO 27001 includes network architecture diagrams illustrating distinct network zones, screenshots of separate cloud account structures, and IAM policies proving developers lack standing production write access. Auditors will also review CI/CD deployment logs to verify that unapproved code cannot bypass testing phases. Tools like WatchDog Security's Compliance Center can help organize these artifacts and link them directly to A.8.31 audit evidence requests.
Secrets and configuration management across environments must be completely decoupled so that a compromised test environment does not accidentally reveal live production credentials. Organizations should use dedicated secret managers for each environment, ensuring that production database passwords or critical API keys are never accessible to or readable by development systems.
Generally, using raw production data in testing is one of the most common mistakes when separating dev test and production environments and is highly discouraged. If organizations must use production data to ensure accurate testing, ISO 27001 expects strict safeguards, including rigorous data masking, anonymization, or tokenization to ensure sensitive information is completely obscured before entering lower-security environments.
A common challenge is keeping environment boundaries, access rules, and CI/CD gates consistently documented as systems evolve. Tools like WatchDog Security's Compliance Center can centralize control requirements, map evidence to A.8.31, and highlight gaps when key artifacts (e.g., architecture diagrams, IAM reviews, pipeline logs) are missing.
Environment segregation often erodes through permission creep and misconfigurations (e.g., overly broad IAM roles or shared network routes). Tools like WatchDog Security's Posture Management can help surface misconfigurations and risky access patterns across cloud environments so teams can remediate drift before it becomes an audit or security issue.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-17 | WatchDog Security GRC Team | Initial publication |