ISO 27001 A.8.31: Separate development, test and production safely

What A.8.31 requires in practice

Annex A control A.8.31 expects development, testing and production environments to be separated and secured. Both words count. Separation means the environments are distinct, with controlled movement between them. Securing means each is protected in a way that suits its purpose.

Each environment has a role. Development supports creation and experiment. Testing needs a stable and representative setting. Production supports authorised live operation. Different names or addresses do not amount to separation if the same access can alter all of them. The organisation therefore looks at accounts, credentials, interfaces and shared resources.

The outputs are a defined purpose and protection level for each environment, rules for how software and configuration move between them and who approves, access that reflects the separation, and records that the arrangement works as designed. Applicability follows risk treatment and the Statement of Applicability, and physical architecture is the organisation's choice.

Define the boundary and what may cross it

Identify the purpose of each environment and the protection it needs. Development supports creation and experimentation; testing needs a sufficiently stable and representative setting; production supports authorised live operation. Define how software and configuration move between them and who can approve that movement.

Physical or logical separation can contribute, but the arrangement must address the actual exposure. Review access, credentials, interfaces and shared resources. A test system with credentials that can freely alter production can undermine the intended boundary even when its infrastructure is separately hosted.

Make production change an accountable decision

Establish suitable review and authorisation before code or settings become operational. A small team may allocate several responsibilities to the same person, but it still needs an arrangement that prevents unreviewed changes from becoming normal practice. Appropriate access restrictions, review and monitoring can support that accountability.

Connect deployment with change management and security testing. Ensure the tested version and approved configuration are the ones intended for release. Keep development tools away from operational systems when they have no justified need there.

Why environment separation matters to the business

Mixing development, testing and production invites accidents. A tester can overwrite live information, an experiment can interrupt a service or unfinished code can reach customers. Separation protects live services from unapproved change and keeps sensitive production information away from environments with looser protection. Customers benefit from steadier service and the business benefits from fewer incidents caused by its own staff. Clear boundaries also make investigations simpler, since it is evident where an issue began. At audit, a well-defined environment structure is a quick indicator that change and access are under control.

How to implement A.8.31

Begin with purpose and access, then bring in the movement of changes. This order works for small teams and large ones. Keep the arrangement proportionate to the size of the team and the sensitivity of production, because even small organisations can separate credentials and approvals. Involve whoever administers the platforms, since they understand the practical shortcuts that undermine boundaries, and make the agreed boundaries easy for developers to follow day to day.

1. Define the purpose and required protection for each environment you use.
2. Review who holds access to each and remove overlaps that are not needed.
3. Make sure credentials differ so that a development or test credential cannot alter production.
4. Check shared resources and interfaces for routes that cross the boundary.
5. Define how software and configuration move into the next environment and who approves each move.
6. Keep production information out of lower environments unless protected, in line with test information rules.
7. Log and review promotion into production.
8. Check the separation after major platform or team changes.

Evidence an auditor expects for A.8.31

An auditor checks that the boundaries are real and respected. Evidence may include: Where cloud platforms are used, account structure and permissions are often the most telling sources.

• a description of each environment and its protection needs
• access lists showing who can reach which environment
• records of approval for recent moves into production
• observation of credentials and settings, confirming a test account cannot act on production
• an interview with a developer explaining how a change reaches live operation

Samples across more than one team give a fuller picture.

Common nonconformities with A.8.31

Findings typically show separation that exists in naming but not in control. They usually arise because teams share convenient accounts and the naming looks tidy, so an auditor tests whether a credential from one environment can act in another and who approved the last promotion.

• Shared credentials or accounts that can change development, test and production alike.
• Developers with routine unrestricted access to live systems.
• Software promoted to production with no recorded approval.
• Production information copied to test systems without equivalent protection.
• Separation never rechecked after a platform change.

Illustrative software example: separate environments sharing credentials

Illustrative BPO example: testing a workflow against live records

A hypothetical BPO team changes an internal automation workflow. Its test run uses the production connection because that provides realistic information with little preparation. The workflow can update customer records, so an experiment could have an immediate operational effect.

The organisation creates an appropriate controlled test arrangement and selects information suitable for the purpose. It verifies the revised workflow before an authorised deployment and clearly identifies the operating environment to users. The decision preserves meaningful testing while reducing the chance that staff accidentally perform development work on live records.

Protect non-production environments too

Development and testing can contain valuable source code, sensitive configurations and information requiring protection. Maintain suitable access, updates, monitoring and recovery arrangements. Calling an environment temporary or non-production does not make it harmless, particularly when it connects to important repositories or build processes.

Coordinate with test information. Avoid copying sensitive operational information merely because it is convenient. Where a justified use is authorised, appropriate protection and lifecycle controls must follow it. Separation should not become a reason to provide weaker safeguards around an unnecessary copy.

Control exceptional testing and verify the arrangement

Some activities may require carefully defined testing in or near an operational environment. Such circumstances need explicit assessment and approval, with appropriate safeguards. They should not be used as a blanket exception that allows routine experimentation on live systems.

Useful evidence includes the environment design, access decisions, deployment rules, relevant approvals and representative test results. These are practical methods rather than prescribed document titles. A review can check whether a development account can perform an action in production that it should not be able to perform, using safe authorised methods.

Trace a completed release from its test environment through approval to the deployed state. Check temporary permissions and information copies after the work ends. Common failures include shared credentials, unreviewed direct changes and production-like data in weakly controlled test spaces. Use operational control to keep exceptions visible and address their causes.