Skip to contentCYBERINFO
|

Control 8.31 : Separation of Development, Test and Production Environments

Summary

Development, testing and production environments should be separated and secured to reduce the risks of unauthorized access or changes to the production environment and to prevent the use of production data in non-production environments.

Applicability

In-Scope: Mandatory for maintaining system stability and data confidentiality. It ensures that experimental code or unvetted changes cannot accidentally impact live business operations or expose real customer data.

Out-of-Scope: Only partially reducible in very small, low-risk organizations where development and production occur on the same platform, though logical segregation (e.g., separate directories or databases) remains a requirement.

Implementation Guidance

Microsoft 365 / Entra ID

  • Environment Segregation: Use separate Azure Subscriptions or Resource Groups for Development, UAT (Testing), and Production to ensure strict identity and billing boundaries.

  • Access Control: Implement Entra ID Conditional Access policies that restrict production environment access to a specific subset of senior engineers using Privileged Identity Management (PIM).

  • Deployment Automation: Utilize Azure DevOps or GitHub Actions to automate the movement of code between environments, ensuring that no manual changes are made directly to the production state.

Evidence Checklist

  • Environment Architecture Diagram: A technical map showing the logical or physical separation between Dev, Test, and Prod.

  • Access Permission Logs: Evidence showing that developers do not have Write or Owner access to the production environment.

  • Data Handling Records: Proof that data masking or synthetic data is used in the test environment instead of production PII.

Practical Audit Advice

Here are some questions the auditor might ask:

  • How do you prevent a developer from accidentally deploying an untested script directly to the production server?

  • What process is in place to ensure that production database backups are never restored into the development or testing environment?

  • Can you demonstrate the technical gate that requires a formal sign-off before code is promoted from the testing environment to production?

  • How is the production environment protected from vulnerabilities that may exist in the less-secure development environment?