ISO/IEC 27001:2022 Annex A 8.31 – Separation of development, test and production environments focuses on keeping development, testing, and live production environments appropriately separated.
The objective is to reduce the risk that development activities, testing, unauthorized changes, test data, or developer access could negatively affect live production systems or customer information.
For startups and SaaS companies, this control is particularly important because a single cloud environment is often used during the early stages of development. As the company grows, weak separation between environments can become a significant security and audit risk.
What Is ISO 27001 Annex A 8.31?
Annex A 8.31 requires organizations to establish appropriate separation between:
- Development environment – where developers build and modify applications, code, infrastructure, and configurations.
- Test environment – where software and changes are validated before release.
- Production environment – where the live application, customer services, business operations, and production data reside.
The separation should be appropriate to the organization’s risks and business requirements.
Separation does not necessarily mean that every environment must use completely different physical infrastructure.
For modern cloud and DevOps environments, logical separation can be achieved using mechanisms such as:
- Separate cloud accounts or subscriptions
- Separate projects
- Separate networks or VPCs
- Separate databases
- Separate credentials
- Separate identities and roles
- Separate secrets
- Access controls
- CI/CD deployment pipelines
- Environment-specific configurations
- Network segmentation
- Approval and change controls
The key objective is to prevent uncontrolled activity in development or testing from affecting production.
Why Is Separation of Environments Important?
Without adequate separation, an organization may face risks such as:
1. Accidental production changes
A developer could unintentionally modify or delete a production resource.
2. Unauthorized access to production data
Developers may have access to customer information simply because the same database or credentials are used across environments.
3. Vulnerable code reaching production
Unfinished or experimental code may be deployed directly into the live environment.
4. Test activities affecting customers
Security testing, load testing, database testing, or configuration testing could disrupt live services.
5. Credential compromise
If development credentials are compromised and those credentials also work in production, an attacker may gain access to critical systems.
6. Data leakage
Production customer data may be copied into development or test environments without appropriate protection.
7. Difficult incident investigation
When developers can directly modify production systems, it becomes harder to establish who made a change and why.
8. Increased attack impact
Compromise of a development environment should not automatically provide an attacker with unrestricted access to production.
Development vs Test vs Production
| Environment | Primary Purpose | Typical Users | Data |
|---|---|---|---|
| Development | Build and modify software | Developers | Synthetic/sample data preferred |
| Test | Validate functionality and security | Developers, QA, security teams | Test/synthetic/masked data |
| Production | Deliver live services | Operations, authorized administrators | Real business/customer data |
The exact environment structure will vary depending on the organization’s technology and risk profile.
What Does ISO 27001 Annex A 8.31 Require?
The practical objective is to ensure that development, testing, and production activities are sufficiently separated to reduce security and operational risks.
An organization should consider:
- Separate environments
- Separate access permissions
- Separate credentials and secrets
- Controlled movement of software between environments
- Protection of production systems from development activity
- Protection of production data
- Controlled production access
- Monitoring and logging
- Environment-specific configurations
- Appropriate change and deployment controls
Activities Required to Implement A.8.31
A practical implementation normally includes the following activities.
| Activity | What the Organization Should Do |
|---|---|
| Environment identification | Document development, test/staging and production environments |
| Architecture separation | Establish appropriate technical separation |
| Identity separation | Control who can access each environment |
| Credential separation | Do not reuse production credentials in development |
| Secrets management | Use environment-specific secrets |
| Network separation | Restrict unnecessary communication between environments |
| Data protection | Avoid uncontrolled use of production data in non-production |
| Deployment control | Move code through controlled deployment processes |
| Production access | Restrict and monitor privileged production access |
| Logging | Record important administrative and deployment activities |
| Change management | Ensure production changes follow approved processes |
| Monitoring | Monitor production for unauthorized or unexpected activity |
How to Implement ISO 27001 A.8.31
Step 1 – Identify Your Environments
Document all environments used by the organization.
For example:
Development
↓
Testing / QA
↓
Staging
↓
Production
For some organizations, staging may function as the final test environment.
Document:
- Environment name
- Purpose
- Infrastructure
- Applications
- Databases
- Users
- Administrators
- Network connections
- Data types
- Deployment mechanism
Step 2 – Define Access Requirements
Access should be based on business and security requirements.
For example:
| Role | Development | Test | Production |
|---|---|---|---|
| Developer | Yes | Yes | Restricted |
| QA | Limited | Yes | No/Restricted |
| DevOps | Yes | Yes | Yes |
| Security Team | As required | Yes | Yes |
| Business User | No | As required | Yes |
| External Vendor | Controlled | Controlled | Exceptional |
The exact permissions should depend on the organization’s risk assessment.
Step 3 – Use Separate Credentials
One of the most common mistakes is using the same credentials across environments.
For example:
Poor practice
DEV → production database password
TEST → production API key
DEV → production cloud administrator account
A better approach is:
DEV → Development credentials
TEST → Test credentials
PROD → Production credentials
Production credentials should be tightly restricted.
Where possible, use centralized secrets-management solutions rather than storing passwords or API keys directly in source code.
Step 4 – Separate Production Secrets
Production secrets should not be copied into development repositories, developer laptops, or test environments.
Examples include:
- Database passwords
- API keys
- Cloud credentials
- Encryption keys
- OAuth secrets
- Signing keys
- Service account credentials
- Third-party integration credentials
Environment-specific configuration should be maintained securely.
Step 5 – Control Network Connectivity
The organization should evaluate communication between environments.
For example:
Internet
|
v
Production
|
X
Development
Development systems should not automatically have unrestricted access to production databases or administrative interfaces.
Where communication is necessary, it should be explicitly authorized and controlled.
Step 6 – Restrict Production Access
Production should have stronger access controls than development.
Consider:
- MFA
- Least privilege
- Privileged access management
- Individual accounts
- Just-in-time access
- Approval for sensitive administrative actions
- Session logging
- Administrative logging
- Periodic access reviews
Avoid shared administrator accounts whenever practical.
Step 7 – Control Software Promotion
Software should move through controlled stages.
A typical workflow is:
Developer
↓
Code Repository
↓
Automated Security Checks
↓
Development
↓
Testing
↓
Security / QA Validation
↓
Approval
↓
Production Deployment
This helps prevent developers from bypassing testing and security controls.
Step 8 – Protect Production Data
Production data should not automatically be copied into development or testing.
Where testing requires realistic information, consider:
- Synthetic data
- Masking
- Anonymization
- Pseudonymization
- Data minimization
If production data must be used for testing, the organization should document the justification and apply appropriate security controls.
Step 9 – Monitor Production Changes
Important production activities should be logged and monitored.
Examples include:
- Administrative access
- Configuration changes
- Database changes
- Deployment activities
- Privilege changes
- Infrastructure changes
- Security configuration changes
Logs should support investigation and accountability.
Step 10 – Review the Environment Architecture
Environment separation should be reviewed when there are significant changes.
Examples:
- New application
- Cloud migration
- New production platform
- New development team
- New outsourced developer
- Major architecture change
- New customer requirement
- New regulatory requirement
- Security incident
Example – SaaS Startup
Consider a SaaS startup developing a customer management platform.
The startup initially uses:
One Cloud Account
|
└── Application
Developers have administrator access to everything.
This creates significant risk.
The startup later establishes:
Cloud Organization
│
├── Development
│ ├── Application
│ ├── Database
│ └── Test Data
│
├── Test / Staging
│ ├── Application
│ └── Test Data
│
└── Production
├── Application
├── Production Database
└── Customer Data
Additional controls are implemented:
- Separate credentials
- MFA
- Production access restricted
- CI/CD deployment
- Branch protection
- Code review
- Security testing
- Production logging
- Environment-specific secrets
- Synthetic test data
This provides a much stronger implementation of A.8.31.
What Should Trigger a Review?
Organizations should review environment separation when significant changes occur.
Typical triggers
| Trigger | Required Consideration |
|---|---|
| New application | Define development/test/production environments |
| New cloud provider | Review environment architecture |
| Cloud migration | Reassess separation |
| New developer/team | Review access |
| New outsourcing partner | Review external access |
| New production database | Review access and connectivity |
| Major application release | Confirm deployment controls |
| Security incident | Reassess environment boundaries |
| Production compromise | Review privilege and network separation |
| New regulation | Review data handling |
| Customer security requirement | Review environment controls |
| New DevOps architecture | Review CI/CD and production access |
Startup Quick Summary
For a startup, A.8.31 does not necessarily mean building three completely independent physical infrastructures.
A practical cloud implementation can be:
Development
→ Developers build and experiment.
Test/Staging
→ Changes are validated.
Production
→ Only approved and tested changes are deployed.
The important point is that access, credentials, data, and deployment processes should be appropriately separated.
Minimum Implementation for a Startup
A startup can begin with the following minimum controls:
1. Separate environments
At minimum:
Development
Test/Staging
Production
2. Separate credentials
Do not reuse production credentials in development.
3. Restrict production access
Only authorized personnel should have production administrative access.
4. Use MFA
Especially for cloud, production, administrative, and privileged accounts.
5. Use CI/CD
Deploy approved code through a controlled deployment process where practical.
6. Protect production data
Avoid using real customer data in development and testing unless properly justified and protected.
7. Separate secrets
Use environment-specific secrets.
8. Log production activity
Maintain sufficient logs to identify important administrative and deployment actions.
9. Document the architecture
Maintain a simple environment architecture diagram.
10. Review access periodically
Remove unnecessary production access.
Simple Rule for A.8.31
Developers should build in development, validate in test, and deploy to production through controlled processes—not make uncontrolled changes directly in production.
Example Environment Separation Register
Organizations can maintain a simple register like this:
| Environment | Purpose | Location | Data Type | Users | Access Level | Owner |
|---|---|---|---|---|---|---|
| Development | Software development | AWS | Synthetic | Developers | High | Engineering |
| Test | QA/security testing | AWS | Masked/Test | QA + Security | Controlled | QA |
| Staging | Pre-production validation | AWS | Synthetic/Masked | Engineering + QA | Controlled | DevOps |
| Production | Live service | AWS | Customer Data | Authorized Staff | Restricted | Operations |
Environment Access Matrix
A separate access matrix can also be maintained.
| Role | DEV | TEST | STAGING | PROD |
|---|---|---|---|---|
| Developer | Full | Controlled | Controlled | Restricted |
| QA | Limited | Full | Full | No |
| DevOps | Full | Full | Full | Privileged |
| Security | As Required | Full | Full | Controlled |
| External Vendor | Controlled | Controlled | Controlled | Exceptional |
The matrix should reflect the organization’s actual roles and risk assessment.
ISO 27001 A.8.31 Audit Evidence
An auditor may look for evidence such as:
Environment documentation
- Network architecture
- Cloud architecture
- Environment diagrams
- Asset inventory
- Environment register
Access control
- User access lists
- IAM configurations
- Role assignments
- MFA configuration
- Privileged access records
- Access review records
Deployment
- CI/CD configuration
- Deployment logs
- Pull requests
- Code approvals
- Release records
- Change tickets
Data protection
- Test data procedures
- Data masking evidence
- Synthetic data records
- Data transfer approvals
Security
- Network rules
- Firewall rules
- Security group configurations
- Secrets-management configuration
- Monitoring records
- Production logs
Change management
- Change requests
- Approval records
- Emergency change records
- Release approvals
ISO 27001 A.8.31 Audit Checklist
| # | Audit Question | Evidence |
|---|---|---|
| 1 | Are development, test and production environments identified? | Environment register |
| 2 | Is there appropriate separation between environments? | Architecture diagram |
| 3 | Are production credentials separated from development credentials? | IAM/secrets configuration |
| 4 | Is production access restricted? | Access matrix |
| 5 | Is MFA enabled for privileged access? | IAM evidence |
| 6 | Are production changes controlled? | Change records |
| 7 | Are software releases tested before production deployment? | Test/release evidence |
| 8 | Is production data protected from unnecessary use in testing? | Test data procedure |
| 9 | Are environment-specific secrets used? | Secrets-management evidence |
| 10 | Are production administrative activities logged? | Logs |
| 11 | Are development-to-production pathways controlled? | CI/CD/network evidence |
| 12 | Are access rights periodically reviewed? | Access review |
| 13 | Are significant environment changes reviewed? | Change/review records |
| 14 | Is direct production modification restricted? | IAM/configuration evidence |
Common Mistakes
Mistake 1 – Everyone has production access
Giving every developer administrator access to production increases the potential impact of compromised accounts and accidental changes.
Mistake 2 – Same credentials everywhere
Using one database password or cloud administrator account across environments defeats much of the purpose of environment separation.
Mistake 3 – Production data copied into development
Real customer information should not be casually copied into development or test environments.
Mistake 4 – Direct changes to production
Developers manually modifying production without appropriate authorization, testing, logging, and change control creates audit and operational risk.
Mistake 5 – No documented architecture
The company may have technically separated environments but cannot demonstrate how they are separated.
Mistake 6 – Environment separation exists only on paper
A policy saying “development and production are separated” is not sufficient if developers can actually access production without appropriate controls.
Policy vs Process vs Technical Control
| Area | Example |
|---|---|
| Policy | Development and production environments must be appropriately separated |
| Procedure | Define how environments are created, accessed and changed |
| Technical Control | Separate cloud accounts/projects, IAM roles, networks and credentials |
| Process Control | Code review, testing and deployment approval |
| Monitoring | Production access and deployment logging |
| Evidence | Architecture diagrams, IAM records, deployment logs |
ISO 27001 implementation should combine documentation with actual technical and operational controls.
Relationship With Other ISO 27001 Controls
A.8.31 works together with several other controls.
| Control | Relationship |
|---|---|
| A.8.25 Secure Development Life Cycle | Establishes security throughout development |
| A.8.26 Application Security Requirements | Defines application security requirements |
| A.8.27 Secure System Architecture and Engineering Principles | Establishes secure architecture principles |
| A.8.28 Secure Coding | Controls secure coding practices |
| A.8.29 Security Testing in Development and Acceptance | Ensures security testing |
| A.8.30 Outsourced Development | Addresses externally developed software |
| A.8.32 Change Management | Controls changes to production |
| A.8.33 Test Information | Protects information used during testing |
| A.8.2 Privileged Access Rights | Controls privileged production access |
| A.8.4 Access to Source Code | Protects source code |
| A.8.9 Configuration Management | Maintains controlled configurations |
| A.8.15 Logging | Provides records of important activities |
A.8.31 vs A.8.29 vs A.8.32
These controls are related but address different risks.
| Control | Main Focus |
|---|---|
| A.8.29 | Security testing |
| A.8.31 | Separation of environments |
| A.8.32 | Change management |
A simple way to remember them:
A.8.29 → Test it securely
A.8.31 → Keep environments appropriately separated
A.8.32 → Control changes
Together, these controls help establish a controlled path from development to production.
Useful Resources
Organizations implementing A.8.31 may benefit from maintaining the following documents:
- Draft Development, Test & Production Environment Security Policy —
[Insert Document Link] - Environment Separation Procedure —
[Insert Document Link] - Environment Access Control Matrix —
[Insert Document Link] - Production Access Review Checklist —
[Insert Document Link] - Secure Deployment Checklist —
[Insert Document Link] - Test Data Protection Procedure —
[Insert Document Link] - Development-to-Production Deployment Checklist —
[Insert Document Link] - Cloud Environment Architecture Template —
[Insert Document Link]
Practical Implementation Model
A simple implementation model for a startup is:
SOURCE CODE
|
v
DEVELOPMENT
|
Code Review +
Security Checks
|
v
TEST/QA
|
Security + Functional
Validation
|
Approval
|
v
PRODUCTION
|
Restricted Access +
Monitoring + Logs
The objective is to create a controlled path rather than allowing unrestricted movement between environments.
Final Takeaway
ISO 27001 Annex A 8.31 is fundamentally about reducing the security and operational risks created when development, testing, and live production activities are mixed together.
For startups, implementation can be relatively simple:
Separate environments → Separate credentials → Restricted production access → Controlled deployment → Protected test data → Monitoring and logging.
You do not necessarily need expensive infrastructure to implement this control effectively. What matters is that the separation is appropriate to your risk, consistently implemented, and supported by evidence.
A strong implementation of A.8.31 helps prevent a development mistake, compromised developer account, or testing activity from directly becoming a production security incident.