A8.31 Separation of development, test and production environments

Separating development, testing, and production environments is a key principle of secure software and system management. When environments are not isolated, there is an increased risk of unauthorized changes, accidental data exposure, and the introduction of untested or insecure code into live systems.

ISO 27001 A8.31 Separation of development, test and production environments requires organizations to establish clear boundaries between development, test, and production to protect the integrity of operational systems and data. This control minimizes risk by enforcing access restrictions, preventing cross-contamination, and allowing secure deployment workflows.

Implementation Guide #

Step 1: Create Dedicated Environments

• Establish separate infrastructures (physical or virtual) for development, testing, and production.
• Ensure that each environment serves a distinct purpose and is not shared.
  → Tool Recommendation: Use VMware, AWS, Azure, or GCP to create isolated environments through virtual machines or containers.

Step 2: Restrict Access Based on Roles

• Enforce role-based access control (RBAC) to ensure users only have access to the environment relevant to their job function.
• Developers should not have direct access to production systems.

→ Tool Recommendation:

• Azure Active Directory, Okta, or AWS IAM for access management
• CyberArk or BeyondTrust for privileged access management

Step 3: Isolate Data Between Environments

• Use anonymized or synthetic data in development and testing to avoid exposing real customer or business information.

→ Tool Recommendation:

• Delphix, Informatica, or Tonic.ai for data masking and generation
• Avoid using production databases in non-production environments

Step 4: Implement Secure Deployment Pipelines

• Automate the movement of code between environments with approval gates and testing validations.
• Enforce strict control over what code or configuration moves into production.

→ Tool Recommendation:

• Jenkins, GitLab CI/CD, Azure DevOps, or CircleCI for deployment pipelines
• Terraform or Ansible for infrastructure-as-code with environment-specific configurations

Step 5: Monitor and Log Access and Activity

• Log all access to and activity within each environment, especially production.
• Alert on unauthorized access attempts or unusual patterns.

→ Tool Recommendation:

• Splunk, ELK Stack, or Wazuh for logging and monitoring
• Use SIEM solutions to correlate and analyze environment-specific events

Step 6: Enforce Change Management Controls

• Ensure all changes to production are authorized, tested, and documented.
• Separate teams or processes should be responsible for deploying to production versus development.

→ Tool Recommendation:

• ServiceNow, Jira Service Management, or Freshservice for change control workflows

Templates #

• Environment Separation Policy
• Access Control Matrix for Dev/Test/Prod
• Change Management Approval Form
• Environment Deployment Checklist
• Data Masking Compliance Record

Example #

A fintech company was running test scripts directly on a production database, which risked corrupting live data. After a security audit, they implemented isolated environments using AWS EC2 instances and separated access with AWS IAM roles. They masked production data before using it in test environments and set up a CI/CD pipeline via GitLab that enforced peer review and approval before deployments. As a result, operational risks were significantly reduced, and all deployments became traceable and secure.

How to Comply #

To comply with ISO 27001 A.8.31, organizations should:

• Establish clear boundaries and separation between development, test, and production systems.
• Use data masking or synthetic data in non-production environments.
• Control access with role-based permissions and monitor activities.
• Implement automated, secure deployment pipelines.
• Document and enforce change management procedures.

How to Pass an Audit #

Key Documents to Prepare:

• Environment Separation Policy and Architecture Diagram
• Access Control Logs for Each Environment
• Deployment and Change Logs
• Test Data Handling Procedures
• CI/CD and Access Control Configuration Records

What the Auditor Will Check:

• Are environments technically and logically separated?
• Are access rights appropriately segmented by environment?
• Is production data prevented from being used in development or test?
• Are change and deployment processes properly managed and documented?

Top 3 Mistakes People Make #

• Allowing developers or testers access to production systems or data
• Using real customer data in testing environments
• Not enforcing proper change control when pushing code to production

ISO 27001 Environment Separation FAQ #

Q1: Can we use the same server for all three environments if segmented by containers or VMs?
Technically yes, but only if strict segmentation, access control, and monitoring are enforced to prevent cross-contamination.

Q2: Is it okay to copy production data for testing?
Only if the data is properly anonymized or masked. Never use sensitive production data in lower environments without adequate protection.

Q3: What’s the risk of merging dev and test environments?
Blurring these boundaries increases the risk of untested or insecure code being promoted to production and makes root-cause analysis harder during incidents.

ISO 27001 Controls and Attribute Values #

Proper separation of environments ensures system integrity, safeguards data, and supports secure software development and operations.