APP-010 Environment Separation
Description
Development, test, and production environments are logically or physically separated. Production data must not be used in development or test environments without documented approval and appropriate de-identification. Access controls and deployment rights differ between environments. Promotion between environments follows a defined approval process.
Rationale
Mixing environments creates pathways for accidental data exposure, untested code reaching production, and developers gaining unintended production access. Separation is a fundamental engineering and compliance requirement.
Framework Mappings (5)
| AIS-06 | Secure Application Deployment | partial |
| CCC-06 | Change Management Baseline | partial |
| 8.31 | Separation of development, test and production environments | full |
| 8.33 | Test information | partial |
| CM-5 | Access Restrictions for Change | partial |
Evidence (2)
Infrastructure or network configuration showing that production, staging, and development environments are deployed in logically or physically separate accounts, VPCs, or namespaces with distinct access controls.
Example: AWS account structure or GCP project listing showing separate accounts/projects for prod, staging, and dev; or Kubernetes namespace configuration with RBAC policies showing distinct permission sets per environment. Include IAM role assignments showing developers do not have write access to production.
Test: Review the cloud infrastructure account/project structure and IAM policies. Verify: (1) production runs in a dedicated account, project, or equivalent isolation boundary separate from development and test, (2) developer IAM roles with write access to dev/test do not have equivalent write access to production resources, (3) network policies or security groups prevent dev/test resources from initiating connections to production systems.
Policy or procedure defining environment separation requirements, including prohibition on use of production data in lower environments without documented de-identification.
Example: Environment Management Policy or Data Handling Procedure document containing explicit clauses prohibiting production data in dev/test without de-identification approval, and defining the approval process and de-identification method required.
Test: Request the environment management or data handling policy. Verify: (1) the document explicitly prohibits production data in dev/test environments, (2) an exception/approval process is defined for cases where production-like data is required, (3) any approved exceptions have a corresponding de-identification record and approval ticket, (4) policy was reviewed within the last 12 months.
Questions (2)
Are development, test, and production environments logically or physically separated, with distinct access controls and deployment rights for each environment?
Separation must be structural (e.g. separate cloud accounts, VPCs, Kubernetes namespaces) — not solely procedural. Developers with write access to dev/test must not hold equivalent production write access.
Is production data permitted in development or test environments?
Use of production data in non-production environments without de-identification is a data protection risk and a finding in most audit frameworks. Any approved exceptions must have a de-identification record.