How to Stop “Just Testing Something” from Taking Your Live Systems Down
ISO 27001 Control 8.31 is all about separating development, test and production environments so that experiments, bug fixes and new features don’t accidentally damage your live services or expose real data.
In practice, this control is asking:
“Can developers and testers safely do their work without putting production systems and production data at risk?”
When you get this right, you reduce the chance of:
- untested changes breaking live services
- test scripts or tools damaging production data
- developers having unnecessary access to real customer information
- configuration drift that nobody really understands
This guide turns ISO 27001 Control 8.31 into a practical set of steps you can actually implement and evidence.
What ISO 27001 Control 8.31 Actually Expects
In plain English, ISO 27001 Control 8.31 – Separation of development, test and production environments expects you to:
- Run development, test and production in clearly separated environments (logically and often physically).
- Control and monitor how changes move towards production, with approvals and checks.
- Protect production data from being casually copied into non-production.
- Limit who can access which environments – and make sure no single person can silently change everything.
- Apply sensible security controls (patching, hardening, logging, backups) to all environments, not just production.
An auditor will typically pick a system and ask:
- “Show me your dev, test and production environments.”
- “Who can access each, and how do changes move between them?”
- “What stops someone testing something directly in live?”
Your answers (and evidence) are what demonstrate this control.
Step 1 – Clearly Separate Your Environments
First, you need to make it impossible to “accidentally” work in the wrong place.
Good practice for separating development, test and production environments:
- Separate domains or accounts
- Different tenants/subscriptions/projects for dev, test and production where possible.
- At minimum, clear network and logical separation.
- Network segmentation
- Use firewalls, security groups or VLANs so dev/test cannot freely talk to production.
- Only allow the specific pathways you genuinely need (e.g. monitoring or deployment pipeline).
- Dedicated test / staging environment
- All releases go through a staging or test environment that closely mirrors production before going live.
- Security testing (Control 8.29) happens there, not on live systems.
- Minimal testing in production
- No “quick tests” in live as normal practice.
- Where controlled production testing is needed (e.g. canary, blue–green), it must follow defined procedures and have clear rollback plans.
The key is: you can point to each environment and show it is separate by design, not just by naming convention.
Step 2 – Protect Production Data from Leaking into Non-Production
One of the biggest risks is real data being used in development and testing.
To align with ISO 27001 Control 8.31:
- Restrict direct access to production data
- Only those who genuinely need it (e.g. support, operations) should have access.
- Developers and testers should use masked or synthetic data wherever possible.
- Control data copies and exports
- No casual cloning of production databases into dev/test because it’s “easier for debugging”.
- If copies genuinely are needed, apply masking/anonymisation and protect them with equivalent security controls.
- Define rules for test data
- Where test data may be sensitive (e.g. in UAT), treat that environment with elevated security.
- Link this to your test information protection approach (Control 8.33).
You want to be able to say: “We don’t routinely use live personal or confidential data in dev or test, and where we must, it’s controlled and protected to the same standard.”
Step 3 – Control Tools and Access in Each Environment
Control 8.31 is also about what can be done where, and by whom.
Practical measures:
- No development tools on production systems
- Compilers, IDEs, code editors and debugging tools should not be installed on production servers by default.
- If there’s a genuine exception, document and control it tightly.
- Environment-specific accounts and labels
- Clear banners and prompts indicating which environment a person is logged into (“PRODUCTION”, “STAGING”, etc.).
- Separate accounts or roles for dev/test vs production work.
- Least privilege access
- Developers can access dev, maybe test, but not production by default.
- Operations/DevOps staff have production access where required but not broad rights everywhere.
- Controlled change promotion
- No direct code edits in production.
- Changes must move through a defined pipeline: dev → test/stage → production with approvals.
This is where you show that production is special, not just another server someone can ssh into.
Step 4 – Secure and Maintain Dev and Test Environments Properly
It’s a mistake to think only production needs proper security.
Attackers love dev and test because they are often:
- less monitored
- less patched
- full of helpful debug information
- linked (however loosely) to live systems
To avoid that:
- Keep all environments patched and hardened
- Apply OS, platform and tool updates on a defined schedule, not “when we get time”.
- Use the same baseline security configurations as production where practical.
- Control access to dev/test
- Least privilege, with role-based access.
- MFA for privileged access, just as for production.
- Log and monitor activity
- Track changes to code, configuration and deployed artefacts.
- Send logs to central logging or SIEM if you have one – dev/test are still part of your attack surface.
- Back up dev and test environments
- Especially if they hold unique configuration, test harnesses or integration setups.
- Ensure backups are protected and tested.
- Use isolation technologies
- Containerisation and virtualisation to create clean, isolated environments.
- Tear down and recreate environments regularly using IaC to reduce configuration drift.
This shows that dev/test are treated as real environments with real security expectations, not throwaway sandpits.
Step 5 – Enforce Segregation of Duties Around Production Changes
ISO 27001 is big on segregation of duties; this control reinforces that for environments.
Key practices:
- No “solo power” over dev and prod
- The same person should not be able to develop code and deploy it to production without oversight.
- Use separate roles, approvals and pipeline permissions.
- Formal approvals for production deployment
- Pull/merge requests with peer review.
- CAB or change approval where appropriate, especially for high-impact systems.
- Audit trails and monitoring
- Log who approved, who deployed, and what changed.
- Review privileged access activities periodically.
- MFA for privileged access
- Multi-factor authentication for deployment tools, jump hosts and management consoles.
Segregation of duties doesn’t have to be heavy and bureaucratic; even in DevOps/Agile environments you can still ensure more than one set of eyes on anything going live.
Step 6 – Support Modern Deployment Models Safely (DevOps, Cloud, Feature Flags)
Separation of environments doesn’t mean you can’t be modern or flexible. It just means you do it in a controlled way.
Common patterns that fit with ISO 27001 Control 8.31:
- Blue–green deployments
- Two production-like environments; you switch traffic between them.
- Each still goes through proper testing and approval.
- Canary releases and rolling deployments
- Gradually roll out changes to a small percentage of users.
- Use monitoring and clear rollback plans if something goes wrong.
- Feature flags
- Deploy code safely but turn features on only for limited user groups.
- Allows controlled live testing without continual deployments.
- Pilot testing in live
- Small, controlled group of users with clear monitoring and readiness to roll back.
- Explicitly documented as an exception with agreed safeguards.
The common theme: even when you test in production, it’s planned, monitored and reversible, not an ad-hoc “let’s see what happens”.
Step 7 – Apply These Principles to Training and Other “Side” Environments
Training and demo environments can be quiet sources of risk if they’re overlooked.
To keep them under Control 8.31:
- Treat training environments as non-production
- Do not use raw production data.
- Mask or anonymise if you really need realistic datasets.
- Apply basic security controls
- Access controls, logging, patching, backups – proportionate to the risk.
- Clear rules about what can and cannot be demonstrated.
- Keep them separate from production
- No shared admin accounts or uncontrolled network connectivity.
Again, the point is consistent: no shadow copies of production with real data and weak controls.
Quick Implementation Checklist for ISO 27001 Control 8.31
Use this as a quick sense-check of your separation of development, test and production environments:
- ISO 27001 Control 8.31 is covered in your development, change and environment management procedures.
- Development, test and production environments are separated logically and/or physically (different domains, networks, tenants or projects).
- All changes go through a non-production environment (test/staging) before deployment to production.
- Production data is not routinely copied to dev/test; where it is, it is masked/anonymised and protected to equivalent standards.
- Development tools (compilers, IDEs, debuggers) are not installed on production systems by default.
- Access to each environment is restricted by role, with least privilege and MFA for privileged and production access.
- Dev/test environments are patched, hardened, logged and backed up in a structured way.
- There is segregation of duties so that no single individual can develop and push unreviewed changes directly into production.
- You have controlled approaches for live testing (blue–green, canary, feature flags) with monitoring and rollback.
- Training and other side environments follow the same principles and do not contain unprotected production data.
Bringing It All Together
ISO 27001 Control 8.31 – Separation of development, test and production environments – is essentially about containing risk:
- Keep experimentation and change in safe spaces (dev and test).
- Treat production – and production data – as special and protected.
- Make sure changes move into live in a controlled, visible and reversible way.
If you can show that your environments are genuinely separated, that access is appropriate, and that production changes follow a clear path through non-production first, you’ll be in a strong position for both the audit and real-world resilience.
Explore the ISO 27001 Control Group Purposes