Separation of development, test and production environments

Plain-language summary

Keeping development, test and live production environments apart and secured, so untested changes, test tools and developers' access do not reach the systems and data the business runs on — whether that means a full development pipeline or simply an ERP test company and a staging website.

What the clause is really asking

Changes built and tried directly on live systems are a leading cause of outages and data corruption, and development environments are usually less protected than production. This control asks you to separate development, test and production to the degree your risk needs and to secure each one. Typical measures: separate systems, tenants or at least separate databases; different credentials so a test login cannot touch production; changes promoted to production only through a controlled release (8.32); no compilers, editors or development tools on production systems unless needed; no testing on production; production data copied to test only with approval and protection (8.33); and clear labelling so people know which environment they are in. The plant equivalent is an engineer editing live PLC logic on a running line; where OT is in scope, offline testing or simulation first applies the same thinking. The common misunderstanding is that test environments are only for software houses — any organisation that changes or upgrades a business system needs somewhere to try the change first.

What auditors look for

Auditors ask which environments exist for your key systems and how they are separated. They pick the ERP or website and ask where the last change was built and tested before going live. They check whether developers or consultants have access to production, with which accounts, and whether test and production share credentials. They look for development tools installed on production servers. They ask whether test environments contain copies of live personal information and who approved the copy. The hard question: show me a change that went from test to production, and show me it was not edited directly in production.

Typical evidence

Environment inventory for key systems showing development, test and production; access lists per environment; release or promotion records through change management; configuration showing separate credentials and tenants; approvals for copying production data to test; labelling or banner settings distinguishing environments; check showing no development tools on production servers.

How to comply — recommendations

For each business-critical system, list the environments it has and create at least a test environment where changes and upgrades are tried first: an ERP test company, a staging site for the website, a separate low-code environment. Give each environment its own credentials and restrict production access to the people who run it; consultants work in test. Promote changes only through change management with a recorded approval. Label environments clearly — a different colour theme or banner stops people editing the wrong one. Do not copy live personal information into test without approval and masking. For PLC and HMI changes, require a backup of the running program and offline testing before download to a machine.

Common nonconformities

No test environment, with changes made directly in production; developers or consultants with unrestricted production access; same credentials across test and production; production data copied to test without approval or protection; development tools left on production servers; environments not labelled, leading to changes in the wrong system; promotion to production not controlled.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.