WikiFrameworksISO/IEC 27001:2022Separation of development, test and production environments

Separation of development, test and production environments

Updated: 2026-02-17

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.

Executive Takeaway

Separating environments prevents unverified code and developmental activities from causing outages or security breaches in live production systems.

ImpactHigh
ComplexityMedium

Why This Matters

  • Prevents accidental or malicious changes made during development from impacting the stability and security of live customer environments.
  • Reduces the risk of exposing sensitive production data to developers or third-party contractors by isolating it from lower environments.

What “Good” Looks Like

  • Development, testing, and production reside in entirely separate cloud accounts or strict Virtual Private Clouds (VPCs) with independent access controls, with evidence and periodic access reviews tracked in tools like WatchDog Security's Compliance Center.
  • Automated CI/CD pipelines enforce deployment gates, ensuring code cannot move from testing to production without formal approvals and security scans.

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.

ISO-27001 A.8.31

"Development, testing and production environments shall be separated and secured."

VersionDateAuthorDescription
1.0.02026-02-17WatchDog Security GRC TeamInitial publication