Annex A.8.32 requires a formal, documented process for any change to information processing facilities or systems, including risk assessment, defined authorization, pre-deployment testing, a rollback plan, and a written record of the change. The action to take now: pull up your Statement of Applicability, confirm A.8.32 is marked applicable, and check whether your change policy actually describes this process or just gestures at it.
TL;DR:
- A documented change process must cover risk assessment, approval, testing, rollback, and record-keeping for any system updates affecting information processing facilities.
- Change policies need explicit scope, objectives, roles, categories, and escalation paths, with procedures detailing request, impact assessment, approval, testing, and review stages.
- Segregation of duties requires independent approval and verification, with evidence tied to specific timestamps, ensuring accountability through detailed change tickets.
- Emergency changes are permitted with rapid approval and post-implementation review, but must include a tested rollback plan and documented authorization within 48 hours.
- Regular metrics like documentation completeness, rollback frequency, and change times should be monitored to ensure the process stays effective and proportionate over time.
Table of Contents
- What Annex A.8.32 Covers and Why Auditors Care
- Core Elements Every Compliant Change Policy Must Include
- Running a Change from Request to Post-Implementation Review
- Who Approves What: Roles, the CAB, and Segregation of Duties
- Handling Emergency Changes Without Losing Control
- Building an Audit Pack Auditors Will Actually Accept
- Measuring Whether Your Change Process Actually Works
- Operational Tools That Speed Up A.8.32 Compliance
- Where Change Management Efforts Usually Go Wrong
- Sources
What Annex A.8.32 Covers and Why Auditors Care
Annex A.8.32 applies to changes affecting information processing facilities and systems: software releases, infrastructure updates, network reconfigurations, new integrations, cloud environment changes, and even significant process changes that touch how information gets handled. It does not apply narrowly to code deployments. Auditors read it broadly, and so should you.
The control sits inside a wider structure. ISO/IEC 27001 ties A.8.32 back to Clause 6 planning, which requires you to evaluate risk before you act, not after something breaks. It also connects directly to A.8.31, the control governing separation of development, test, and production environments. You cannot satisfy A.8.32’s testing requirement without somewhere isolated to test, which is exactly why auditors often check both controls in the same interview.
The security logic is straightforward; applying network change management discipline helps prevent unauthorized changes that can break confidentiality, integrity, or availability. An unreviewed change to a firewall rule, a database schema, or an access control list can quietly break confidentiality, integrity, or availability, the three properties your entire ISMS exists to protect. A single unauthorized change, deployed without testing, has caused outages and data exposure at organizations that otherwise had strong technical controls everywhere else. Change management is the seatbelt for every other control you’ve built.
What auditors expect to see, at minimum:
- A documented policy statement that names change management as a control and defines its scope
- A procedure describing the actual workflow, not just principles
- Evidence that changes were assessed for risk before approval
- Proof that someone other than the implementer approved the change
- Records showing testing occurred somewhere other than production
Auditors do not expect perfection. They expect consistency between what your documents say and what your tickets show happened.
Core Elements Every Compliant Change Policy Must Include
A policy that only says “changes must be approved” will not survive a certification audit. Auditors want to see the mechanics, and the NQA implementation guide is explicit that impact assessment, documented approvals, non-production testing, rollback plans, and post-change review all need to appear somewhere in writing.
Start with the policy itself. It needs five things:
- Scope statement defining exactly which systems, environments, and change types fall under the policy.
- Objectives explaining why the control exists (risk reduction, availability protection, audit compliance).
- Roles and responsibilities, naming who requests, assesses, approves, implements, and verifies.
- Change categories, typically standard, normal, and emergency, each with proportionate review requirements.
- Escalation path for disputes or high-risk changes that need broader sign-off.
The procedure is where the real audit evidence gets generated. A workable procedure moves through six stages: request, impact assessment, approval, testing, implementation, and post-change review. Konfirmity’s walkthrough of the control lists nine elements auditors look for across these stages, including a documented emergency path and a requirement to update related documentation once the change lands.
Segregation of duties deserves its own line in the procedure, not just a mention. The person who requests a change should not be the same person who approves it, and in higher-risk cases, the implementer shouldn’t be the verifier either. Small teams can satisfy this with peer review rather than a formal board, but the separation has to be visible in the record, not just assumed.
Every change needs to leave behind a specific evidence trail:
- The original request with business justification
- A completed risk/impact assessment
- A named approver and a timestamp
- Test results or a link to test evidence
- A rollback plan, even for changes that never needed it
- A closure note confirming the change matched the plan
Pro Tip: Build your change ticket template with these six fields as mandatory, not optional. Auditors sample tickets at random, and a ticket missing even one field looks like a gap in the whole process, not a one-off oversight.
ComplianceDocs’ guidance on writing change policies makes a point worth repeating: proportionality is the design principle, not an afterthought. Standard, low-risk changes (a routine patch, a config tweak you’ve made fifty times) can run through pre-approved templates. High-risk changes need full change advisory board review and an explicit rollback plan before anyone touches production.
Running a Change from Request to Post-Implementation Review
The gap between having a policy and having a working process usually shows up in the details of the ticket itself. A request form needs specific fields, not a free-text box: change title, requesting system or asset, business justification, proposed date, category (standard, normal, or emergency), and the name of the person requesting it. Vague requests produce vague risk assessments, and vague risk assessments are the first thing an auditor flags.
Risk and impact assessment doesn’t need a complicated model. A simple 3x3 matrix, scoring likelihood against impact on a low, medium, high scale, is usually enough to satisfy auditors while staying fast enough that people actually use it. The output matters more than the method: does the assessment name what could break, who would notice, and how long recovery would take? A change touching customer authentication gets a different review depth than a change to an internal reporting dashboard, and your matrix should reflect that difference automatically.
Testing is where a lot of organizations quietly cut corners, and it’s the step auditors probe hardest. Copla’s breakdown of the control frames non-production testing as non-negotiable for anything short of a true emergency, because it’s the only way to catch a breaking change before it reaches real users and real data. Practically, that means:
- Attaching test case results, screenshots, or logs to the change ticket
- Recording which environment the test ran in and confirming it wasn’t production
- Noting any failed test and how it was resolved before approval
Roughly nine distinct elements show up across practitioner walkthroughs of a compliant change procedure, from impact assessment through documentation updates and continuity review, and testing sits near the center of that list every time it’s cited.
Implementation planning needs a scheduled window, a named implementer, and explicit rollback criteria written down before the change starts, not improvised after something goes wrong. Rollback criteria should answer one question in plain language: what specific signal tells us to reverse this change immediately?
Post-implementation review closes the loop. Within a defined window (24 to 72 hours works for most organizations) someone who wasn’t the implementer checks that the change did what it was supposed to do, caused no unexpected side effects, and left documentation current. Closure only happens once that review is signed off.
Who Approves What: Roles, the CAB, and Segregation of Duties
Five roles cover almost every change management setup, regardless of company size:
- Requester: identifies the need and submits the request
- Owner: the person or team accountable for the affected system
- Approver: reviews risk and authorizes the change, and must not be the implementer
- Implementer: executes the change according to the approved plan
- Verifier: confirms the change worked and documentation is current
A full change advisory board makes sense once you’re running enough concurrent changes that informal coordination breaks down, or once your risk categories start including changes with organization-wide impact. Below that threshold, a board is overhead you don’t need.
For high-risk or normal changes, route approval through whoever owns the affected system plus one independent reviewer. For standard, low-risk changes, a pre-approved template with a single sign-off is proportionate and defensible; the ComplianceDocs framework treats this tiering as the correct way to keep controls from strangling delivery speed.
Small teams without a formal board can still satisfy the intent of segregation of duties. Peer review before merge, pull request approval workflows in your version control system, or a simple second sign-off from a teammate all demonstrate that someone independent reviewed the change. What matters to an auditor is evidence of separation, not the size of the committee.
Whatever mechanism you choose, timestamp every approval and store it somewhere immutable. A verbal “go ahead” in a hallway conversation is not evidence. A logged approval in your ticketing system, tied to a specific person and a specific minute, is.
Handling Emergency Changes Without Losing Control
Emergency changes exist because production breaks at inconvenient times, and waiting for a full approval cycle sometimes causes more damage than the fix itself. ISO 27001 doesn’t ban expedited changes; it requires that they still leave an accountable trail.
- Define, in the policy, exactly what qualifies as an emergency (active outage, active security incident, or imminent data loss are common thresholds).
- Allow implementation with abbreviated approval, often verbal sign-off from one authorized person, but require formal documentation within a fixed window afterward (24 to 48 hours is typical).
- Route every emergency change through the same post-implementation review as a standard change, no exceptions.
Rollback planning is what separates a controlled emergency change from a gamble. Before implementing anything urgent, know what you’re rolling back to: a system snapshot, a database backup, or a saved prior configuration file. If you can’t answer “how do we undo this in five minutes” before you start, you’re not ready to start.
Pro Tip: Test your rollback procedure during a scheduled maintenance window at least once a year, not just when you need it. A rollback plan nobody has ever executed is a rollback plan you don’t actually have.
Schedule a retrospective for every emergency change within a short period after resolution. The retrospective should ask one question the ticket itself can’t answer: could this have been prevented, or classified as standard next time?
Building an Audit Pack Auditors Will Actually Accept
When an auditor samples your change records, they’re checking for a consistent thread from request to closure. The artifacts they’ll ask for, in roughly the order they’ll ask for them:
- The change ticket itself, with justification and category
- The documented risk/impact assessment
- The named approver and timestamp
- Test evidence, whether logs, screenshots, or a signed test report
- The rollback plan, present even for changes that never needed it
- The post-implementation review and closure sign-off
A detail that separates a passable audit from a smooth one: link each significant change back to the specific Statement of Applicability entries it affects. Konfirmity’s guidance on this points out that mapping changes to SoA entries lets an auditor see exactly which Annex A controls a change touched and why your organization judged them applicable in the first place. That single habit turns a change ticket from an isolated record into proof your ISMS actually functions as a system.
Retain change records for at least the length of your certification cycle, typically three years, and longer if a regulatory framework you’re also subject to demands more. Package evidence by change category rather than chronologically. An auditor who wants to see how you handle emergency changes shouldn’t have to dig through six months of routine patches to find three examples.
Reviewing what audit evidence auditors expect more broadly is worth doing before your first surveillance audit, since change records are only one evidence category among several you’ll need organized the same way.
Measuring Whether Your Change Process Actually Works
A change management control that generates paperwork but no insight isn’t doing its job. Track a small set of metrics and review them on a fixed schedule, ideally alongside your regular management review.
| Metric | What it tells you | Suggested review cadence |
|---|---|---|
| Percentage of changes with complete documentation | Whether your process is actually being followed | Monthly |
| Failed or rolled-back change rate | Whether risk assessment is catching real problems before deployment | Monthly |
| Average time from request to approval | Whether proportionate review is working or bottlenecking delivery | Quarterly |
| Emergency changes as a share of total changes | Whether your standard process needs to absorb more change types | Quarterly |
| Post-implementation reviews completed on time | Whether closure discipline is holding | Monthly |
Set thresholds that trigger action, not just observation. If failed changes climb above a level you’ve defined as acceptable, that’s a signal your risk assessment step needs recalibrating, not a footnote for the next audit. If emergency changes keep growing as a share of the total, your “standard” category is probably too narrow and needs expanding.
Use these numbers to adjust your classification rules over time. A change type that’s been executed cleanly forty times in a row is a candidate for reclassification from normal to standard, freeing up review capacity for changes that genuinely need scrutiny.
Operational Tools That Speed Up A.8.32 Compliance
Building this process from a blank page takes real hours you probably don’t have budgeted. ISMS Calculator’s readiness assessment estimates the effort a change management control will actually take based on your company size, industry, and current security maturity, which turns “we should probably formalize this” into a scoped project with a timeline.
A maturity assessment covering all 14 ISO domains can help show exactly where change management ranks against other gaps rather than guessing. Customizable Gantt timelines then let you sequence policy drafting, template rollout, and CAB formation against a certification deadline instead of tackling everything at once. Saved and comparable estimates provide something concrete to hand an auditor or a budget committee as proof of proportionate planning rather than improvising.
If you’re still confirming whether change management belongs in scope at all, the free 2-minute readiness check is the fastest way to find out.
Where Change Management Efforts Usually Go Wrong
The most common failure isn’t a missing policy, it’s a policy nobody follows because it was written for an audit rather than for the team using it. Over-documentation kills adoption faster than under-documentation ever does.
Rollback plans get skipped most often, not because teams don’t value them, but because nobody assigned owning them. Fix that with a risk-based template that makes rollback a required field, not an afterthought, and push approval routing into your ticketing tool so timestamps happen automatically instead of relying on memory. Schedule post-change reviews on the calendar the moment a change is approved, not after something goes wrong.
— Martin
Ready to scope the real cost and timeline for building this control into your ISMS? ISMS Calculator’s readiness assessment gives you a tailored estimate based on your company’s size, industry, and current maturity, backed by industry benchmarks so you know whether your plan is proportionate before you present it to leadership. Compare saved estimates side by side, export a PDF for your steering committee, and move from “we need a change policy” to a scheduled project with a Gantt timeline in one sitting.
Sources
- ISO/IEC 27001 Information security, cybersecurity and privacy protection — ISO
- NQA — ISO 27001 implementation guide (change management guidance excerpt)
- ISO 27001 Change Management: A Walkthrough with Templates | Konfirmity
- ISO 27001 and change management: Policies, procedures, and templates explained | Copla