How to Write a Change Management Policy (for ISO 27001 & SOC 2)

A change management policy keeps changes to your systems controlled so they do not quietly break security or availability. Here is what it must cover, how it maps to ISO 27001 and SOC 2, and how auditors expect you to evidence it.

Why a Change Management Policy Exists

Many security incidents and outages are not caused by attackers at all. They are caused by a well-meaning change that nobody assessed, tested, or recorded: a firewall rule edited at 5pm, a database migration with no backout, a deploy that quietly turned off logging. A change management policy exists to stop that. Its purpose is to control how changes are made to your systems, infrastructure, and software so that a change intended to improve the service does not undermine its security or availability instead.

The core idea is proportionate review before production. Every meaningful change gets requested, assessed for risk, tested where possible, approved by someone other than the person who built it, and recorded — with a way to undo it if it goes wrong. The depth of that review scales with risk: a routine patch needs far less ceremony than a firewall change or an irreversible data migration.

This matters for two audiences at once. Internally, it prevents self-inflicted downtime and security regressions. Externally, it produces the audit trail that an ISO 27001 certification body or a SOC 2 examiner will ask to see, because both frameworks treat controlled change as a fundamental discipline rather than an optional nicety.

What the Policy Must Cover: Request, Risk, and Testing

Start with the change request and documentation. Every non-trivial change should produce a record — a ticket or change entry — that captures who requested it, the business or technical reason, the systems and data affected, the proposed window, and an outcome once it is done. If a change cannot be traced from request to deployment in your records, an auditor will treat it as uncontrolled, no matter how careful the engineer actually was.

Next, require a risk and impact assessment before approval. The change owner should classify each change and flag the higher-risk ones: anything touching internet-facing systems, personal or confidential data, security controls (firewall rules, authentication, logging, backups), or anything that cannot be cleanly rolled back. High-risk changes earn more scrutiny and more senior approval; low-risk routine changes can follow a pre-approved path so the process does not become a bottleneck.

The policy must also require testing in a non-production environment wherever one exists, with the test evidence attached to the change record. Validating a change in dev or staging before it reaches production is exactly why you keep development, test, and production environments separate in the first place. Where no test environment exists, say so honestly in the record and define an in-production verification step that confirms success immediately after the change.

What the Policy Must Cover: Approval, Rollback, and Review

Authorization and approval come next, and they must be recorded in writing before implementation begins — verbal-only approval is not evidence. This is where segregation of duties matters: the person who builds or proposes a change should not be the sole person who approves and deploys it. In a tiny team one person may wear several hats, but the policy should still require that an implementer is never the only approver of their own change, even if the second pair of eyes is a peer reviewing a pull request rather than a formal change board.

Every normal and emergency change needs a rollback (backout) plan recorded before it goes live: the method (restore from backup, snapshot revert, redeploy the previous release), the expected time to roll back, and the criteria that trigger it. For high-risk changes, confirm a current, restorable backup exists first. A change you cannot undo is a change you should treat as high risk by default.

Finally, the policy must handle emergency changes and post-implementation review. Emergencies trade advance paperwork for speed but never for accountability: get at least verbal approval, make the minimum change needed, then complete the record and hold a retrospective shortly after. Failed and emergency changes in particular should get a post-implementation review to find the cause and decide on corrective action.

Mapping to ISO 27001 and SOC 2

Under ISO/IEC 27001:2022, the headline control is Annex A.8.32, Change Management, which requires that changes to information processing facilities and systems are subject to change management procedures. Your policy is the direct evidence that A.8.32 is implemented, and it should reference the related procedures it depends on — risk assessment, backups, secure development, and incident response.

The non-production testing requirement connects to Annex A.8.31, Separation of Development, Test and Production Environments. A.8.31 is about keeping those environments apart so changes can be validated safely before release; it is not the segregation-of-duties control, which is a separate concept in ISO 27001. Keep the two ideas distinct in your documentation: A.8.31 separates environments, while separation of duties separates people's roles in a single change.

For SOC 2, the relevant point is Common Criteria CC8.1, the sole criterion in the CC8 series, which addresses how the organization manages changes to infrastructure, data, software, and procedures. CC8.1 expects you to authorize, design, test, approve, document, and implement changes in a controlled way — so the same policy covering request, risk assessment, testing, approval with segregation of duties, rollback, and review serves CC8.1 directly. Crucially, satisfying these criteria comes from operating the control, not from owning the document: ISO certification is issued by an accredited body and a SOC 2 report by a licensed CPA firm, each only after examining how your change process actually runs.

Common Pitfalls and How to Evidence the Control

The most common pitfall is a policy that no team follows. If your document mandates a change advisory board but your engineers ship through pull requests and CI/CD, the auditor will find the gap immediately. Write the policy around how you actually deploy — reviewed pull requests, pipeline gates, infrastructure-as-code — so the evidence matches the words. Other frequent failures: approvals captured only verbally or after the fact, rollback plans that are missing or untested, emergency changes that never get back-documented, and standard changes so loosely defined that risky work slips through as routine.

To evidence the control, give an examiner the artifacts they actually sample. Expect to show change records or tickets that trace request to deployment, written approval dated before implementation, test evidence attached to the record, a rollback plan recorded before the change, and post-implementation reviews for failed and emergency changes. A particularly strong control is a periodic review of the change log against system audit trails to confirm no unauthorized changes occurred, plus change records being sampled during internal audit.

The honest test is whether a stranger could reconstruct any production change from your records months later: what changed, why, who approved it, how it was tested, and how it could have been undone. If they can, the control is real. If the trail is missing, the control exists only on paper, and that is precisely what an audit is designed to expose.

Using a Toolkit as Your Starting Point

Writing this policy from a blank page is slower than it looks, because a good change management policy has to interlock with your risk assessment, backup, secure development, logging, and incident response documents — referencing them rather than contradicting them. That cross-referencing is where homegrown attempts usually drift.

This is where an editable template set helps. The ComplianceDocs ISO 27001 Complete Toolkit and SOC 2 Complete Toolkit each include a Change Management Procedure (mapped to A.8.32 and to CC8.1 respectively) already wired into the surrounding policies, with the approval matrix, risk classification, rollback requirements, emergency-change handling, and post-implementation review structured for you to tailor. You replace the placeholders with how your organization actually works, then keep it current.

Be clear about what that does and does not buy you. A toolkit is the documentation layer — it gives you a credible, audit-aware starting point and saves you the drafting, but it does not make you certified, attested, or compliant. Certification and a SOC 2 report come only from an accredited body or a licensed CPA firm after they examine the control operating in your environment. The document gets you ready faster; running the process is still the work that earns the result. Any time or cost savings here are illustrative estimates, not quotes, and actual figures vary by organization.

Frequently asked questions

What is the difference between a change management policy and a change management procedure?

A policy states the rules and intent: that all changes must be requested, risk-assessed, approved by someone other than the builder, tested, and recorded, with a rollback plan. A procedure is the step-by-step mechanics of how that happens in your tools — how a change ticket is raised, who approves which category, how emergency changes are documented afterward. Auditors generally want both: the policy shows commitment and accountability, while the procedure shows the control is operable day to day. Smaller organizations sometimes combine them into one document, which is fine as long as both the rules and the mechanics are present.

How does a change management policy map to ISO 27001 and SOC 2?

For ISO/IEC 27001:2022 it directly addresses Annex A.8.32 (Change Management), and its non-production testing requirement connects to A.8.31 (Separation of Development, Test and Production Environments). For SOC 2 it supports Common Criteria CC8.1, the single criterion covering how you manage changes to infrastructure, data, software, and procedures. One well-written policy can satisfy all three, because they ask for the same underlying discipline: controlled, reviewed, recorded change. Note that A.8.31 is about keeping environments separate, not about segregating people's duties, which is a distinct concept.

Does segregation of duties mean we need a separate person for every change?

It means the person who builds or proposes a change should not also be the sole approver and deployer of that same change. In larger teams this is straightforward. In a small team where one person wears several hats, you satisfy the spirit of the control by having a second person review and approve before deployment — for example, a peer approving a pull request rather than a formal change board. The policy should state explicitly that an implementer is never the only approver of their own change, and your records should show that second approval.

How do we evidence change management for an audit?

Auditors sample concrete artifacts, so produce them as you work rather than reconstructing later. Be ready to show change records or tickets that trace each change from request to deployment, written approval dated before implementation, test evidence attached to the record, a rollback plan recorded before the change, and post-implementation reviews for failed and emergency changes. A periodic review of the change log against system audit trails — confirming no unauthorized changes slipped through — is strong supporting evidence. The simple test is whether someone could fully reconstruct any past production change from your records alone.

Will a change management template make us ISO 27001 certified or SOC 2 compliant?

No. A template is the documentation layer: it gives you an editable, audit-aware policy and procedure mapped to A.8.32, A.8.31, and CC8.1, which saves drafting time and helps you cover the right elements. It cannot make you certified, attested, or compliant on its own. ISO 27001 certification is issued by an accredited body, and a SOC 2 report by a licensed CPA firm, each only after examining the control actually operating in your environment. The document speeds your readiness; running the process consistently and keeping the evidence is what earns the certification or report.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles