A.8.32 Change management: requirements and evidence

What A.8.32 change management requires and why audits fail it

If you must show that changes to your systems are controlled, A.8.32 requires that changes to information processing facilities and information systems go through change management procedures, and that the organization keeps records proving it. The control asks for a repeatable path for each change: a request, an impact assessment, an authorization, testing where it matters, a rollback plan and a record that ties them together. The risk it addresses is familiar to any operations team. An unauthorized or untested change to a firewall rule, a database schema or a production configuration can cause an outage, or quietly weaken a security control that nobody notices until an incident. The 2022 edition merges four controls from the 2013 edition, A.12.1.2 Change management, A.14.2.2 System change control procedures, A.14.2.3 Technical review of applications after operating platform changes and A.14.2.4 Restrictions on changes to software packages, so an assessor will expect one procedure that covers infrastructure, applications and vendor packages alike.

Audits usually fail this control for reasons that have little to do with the procedure on paper. The first is that changes happen outside the ticket system: an engineer edits a cloud security group in the console, a administrator patches a server over SSH, or a vendor updates a package during a maintenance window. The second is emergency changes, which are often made correctly under pressure but documented afterward, if at all. The third is mismatched records, where the ticket says one thing, the pull request says another, and the deployment log shows a third. Before you prepare for an assessment, confirm with your auditor which sources of change evidence they will sample, and reconcile a recent month of production changes against tickets, merge requests and deployment logs. Any change you cannot trace end to end is the finding you will receive.

The practical decisions sit with the organization, not with any tool or consultant. Decide which changes are standard, normal or emergency, who may approve each type, and what testing is proportionate to the risk. Decide how the change record links to the configuration and code history, since A.8.9 Configuration management and A.8.31 Separation of development, test and production environments depend on the same evidence. An implementation partner can help configure the ticketing and repository controls that enforce these decisions, but only the organization can own the rule that an unapproved change is a reportable exception, and only an independent certification body can judge whether the system works as described.

Which changes and systems fall under change management scope

A.8.32 applies to whatever the organization defines as a change within its ISMS scope, so the first decision is the boundary itself. The cards below cover the scoping choices that most change the procedure, the records an assessor will ask for, and the evidence volume each choice creates.

Production infrastructure changes

Changes to servers, hypervisors, network devices, storage, and cloud resources that carry live information are the core of A.8.32. Decide whether infrastructure-as-code merges count as the change record or whether each apply needs its own ticket. Check that every production change links to an authorization, a rollback step, and a post-change verification. Evidence volume grows with the number of hosts and how often automation runs.

Application code and releases

Code releases that reach production are changes even when they pass through a pipeline. Confirm which merges require a recorded approval, and whether a pipeline pass plus a second reviewer is enough. Protected branches in GitLab can block direct pushes and disable force pushes, which gives you enforceable records of who approved what. Evidence volume tracks release frequency, so high-velocity teams need automated, queryable records.

Configuration and security settings

Changes to firewall rules, access policies, encryption settings, and logging configuration can weaken controls without touching application code. Define a threshold for what is a security-relevant configuration change and log those changes with the same rigor as releases. Related controls A.8.9 and A.8.19 overlap here, so agree on one owner for each record. Evidence volume is often underestimated because settings change through consoles, scripts, and vendor portals.

Third-party and SaaS platforms

Where the organization administers a SaaS platform or hosted service, its tenant settings, integrations, and admin role changes are its changes to manage, even though the vendor operates the underlying system. Write down which platform changes need a ticket and which are routine vendor updates. Confirm what the vendor provides in its own change notices and what you must record yourself. Evidence volume depends on how many tenants and integrations you administer.

Emergency changes

Emergency changes made to restore service during an incident still need a record, but authorization and testing may happen after the fact. Define who can declare an emergency, the time limit for retrospective approval, and the review that follows. Assessors look for emergency changes that never got reviewed, since these are a common gap. Evidence volume spikes during incidents, so keep the template short enough to complete under pressure.

Changes made by suppliers

Changes that a supplier or outsourced operator makes to systems you depend on fall under A.8.32 when they affect your information processing. Put notification duties, change windows, and access to supplier change records in the contract. Ask for the supplier's change log and approvals, and check that they reach your records before go-live. Evidence volume depends on what the supplier shares and how quickly, so confirm this during contract review.

How an assessor tests change management

This table compares the testing approach an assessor typically uses for A.8.32, the evidence they request for each approach, and the findings that appear most often. Read each row as a question the assessor will ask of your change records, and check whether your own process can answer it with dated, retrievable records. The auditor, not DeployOpen, decides whether your change management meets the control.

Test approach	Evidence requested	Common findings
Sample changes from the population of change records over the audit period	Complete change register or export for the period, showing the population size and how it was generated	Register is incomplete, changes are missing from the export, or records are edited after the fact
Trace sampled changes from request to closure	Request, impact assessment, approval, test results, implementation record and closure note for each sampled change	Steps are missing, dates are out of order, or the closure note does not match what was deployed
Check authorization before implementation	Approval recorded before the deployment timestamp, with approver identity and role	Approval is granted after deployment, approvers lack authority, or approval is given by the person who made the change
Check testing and rollback planning for each change	Test evidence in the target environment and a documented rollback step or justification where rollback is not feasible	Testing is referenced but not recorded, or rollback plans are generic and never tied to a specific change
Check that emergency changes were reviewed afterwards	Emergency change tickets with the reason, approval given at the time, and a post-implementation review	Reviews are missing, happen months later, or emergency routing is used for routine work
Check that the process covers software, configuration and infrastructure	Evidence of changes to application code, configuration files, cloud resources and network devices passing through the same workflow	Infrastructure or configuration changes bypass the ticketing process and are made directly through consoles or scripts

How to implement change management step by step

This sequence turns A.8.32 from a policy statement into a working change process, where each change to systems or information processing facilities is classified, authorized, tested, reversible and recorded before an assessor asks to see it.

Define change types and approval authority
Start by sorting changes into types such as standard, normal and emergency, and state which roles may approve each type. Standard changes are pre-approved, low-risk and repeatable; normal changes need review by a named authority; emergency changes follow a shorter path defined in advance. The owner of the process, usually the IT or platform lead, signs off the type definitions, and the step is done when every type has a written description and an approver. Ask your auditor which change categories they expect to see in your records.
Set up a request and tracking workflow
Choose one system of record for change requests and require every change to pass through it, whether it is a configuration edit, a software release or a network rule. Each request should capture the requester, the affected systems, the reason and the planned window. Open-source service management tools such as GLPI, which includes ITIL-aligned change handling, can hold this record if you confirm they fit your environment. The step is complete when a sample of recent changes can be traced from request to closure in that one tool.
Write impact and risk criteria
Define the questions every request must answer before approval: which information, users and services are affected, whether security controls or logging are touched, how reversible the change is, and what happens if it fails. Translate the answers into a simple risk rating that determines who approves and how much testing is required. Record the criteria in the change procedure and confirm that the rating is filled in on each request. The output is a documented rubric that a reviewer can apply consistently.
Define authorization and separation of duties
Set rules so that the person who builds a change is not the only person who approves it, particularly for production systems and security settings. Configure who can approve each change type, and record the approval with a name and time. Where tooling allows, enforce approval in the system itself rather than relying on a comment in a ticket. The step is done when you can show that approvals for a sample of production changes came from someone other than the implementer.
Require test and rollback plans for standard changes
Even pre-approved standard changes should carry a short test description and a rollback method before they run. For normal changes, the test evidence and a tested rollback path are required before authorization. Specify the expected result, who verifies it and the condition under which the change is reverted. Store these plans with the change record. The output is a template that makes testing and rollback visible for every change, not only the large ones.
Set emergency change rules with retrospective review
Emergency changes will happen, so define in advance who can authorize them, the minimum information to capture at the time, and the deadline for a retrospective review by the change authority. The review confirms whether the change was justified, tested as far as time allowed and recorded correctly. Track emergency changes separately so that a rising count is visible to management. The step is complete when each emergency change has a documented retrospective decision.
Connect version control and deployment pipelines to the record
Link source repositories and deployment pipelines to the change record so that code and configuration moves to production only with an approved change reference. GitLab Community Edition supports protected branches that restrict who can push or merge and keep force pushes disabled unless explicitly allowed, which gives a technical check that matches the procedure. Confirm the exact protections you need in your own environment. The output is a traceable path from approved change to commit to deployment.
Run a first internal review of closed changes before the audit
Before the certification body arrives, sample closed changes across all types and check that each has a request, a risk rating, an approver independent of the implementer, test and rollback evidence, and a closure note. Record the findings, correct the gaps in the process or the records, and track any repeated failures as improvement actions. This review is the organization's own check, and it does not replace the independent audit. The step is done when the sample shows consistent records and the findings are logged.

Which change records satisfy an auditor

An auditor testing A.8.32 looks for a change procedure that people follow and records that prove it. The six artifacts below connect: the procedure defines what must be recorded, the register lists every change, and the approval, test, rollback and review records show each change was controlled from request to closure.

Change procedure and change types

The written procedure defines what counts as a change, which change types exist (standard, normal, emergency), who may approve each type and what evidence each requires. Auditors check that the procedure matches how work is actually done, so a standard change pre-approved for routine patching should be described as such. Confirm the procedure names the systems in scope, including cloud configuration and information processing facilities, and is version-controlled with an owner and review date.

Change register for a period

The change register is an export of tickets or change records covering a defined period, with a unique ID, request date, type, risk rating, requester, implementer and status for each entry. Auditors sample from this list and also test the reverse direction, so completeness matters as much as the individual records. A GLPI or Zammad export filtered by date range, saved with its query parameters, lets you show the population was not edited after the fact.

Approval records with approver identity

Each change needs an approval recorded before implementation, made by someone authorized under the procedure, with the approver's identity and timestamp. The key check is timing: approval must precede deployment, so a ticket approved after the change went live is a finding. Confirm approvers cannot approve their own changes, and that emergency approvals are recorded after the fact with a documented reason and a retrospective sign-off.

Test evidence per change

For each change, the record should show what was tested, where (a non-production environment separated from production under A.8.31), the result and who verified it. Pipeline logs from GitLab merge requests or CI jobs, including Semgrep scan results where code changes are involved, can serve as test evidence when they link to the change ID. Auditors look for changes with no test evidence and for tests run against a different build than the one deployed.

Rollback plans per change

A rollback plan states how the change is reversed if it fails, which backup or previous version is restored and how long the reversal is expected to take. Auditors check that high-risk changes carry a plan before approval and that rollbacks actually performed are recorded as their own events. Protected branches in GitLab Community Edition, which block direct pushes and disable force pushes by default, help show that the code path to production is controlled and reversible.

Post-implementation and emergency reviews

A post-implementation review confirms the change achieved its goal, caused no unexpected incidents and was closed correctly, while an emergency change review checks that urgent work was justified and documented later. Auditors test whether reviews happen and whether failed or rolled-back changes triggered follow-up. Reconcile the monthly change list against deployment logs and the review backlog so that gaps are found by your team before the auditor finds them.

What meeting A.8.32 costs in money and effort

This table compares the main cost components of running change management for A.8.32, who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. Read it as a checklist for a written quote: most of the effort sits in process design and evidence upkeep, not in the software licence. Open-source tools can remove license spend, but configuration, hosting and staff time remain.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses for the change workflow	Mostly recurring if commercial; one-time setup if self-hosted open source	Number of users, approval workflows needed, integrations, and whether hosting is in your own environment	Choose tools you already run, such as a ticketing system or code platform, and confirm which features the tool includes in its free edition
Engineering time to wire pipelines to change records	One-time, with ongoing maintenance	Number of pipelines and environments, how many systems must link changes to tickets, and how often pipelines change	Link changes through a single, standard identifier and reuse one pipeline template across systems
Process design and approver time	One-time design, recurring approver time	Number of change types, emergency change rules, approver seniority and how many reviews each change needs	Define standard (pre-approved) change types and risk tiers so routine changes need less approval effort
Evidence upkeep and monthly reconciliation	Recurring	Volume of changes, gaps between tickets, code merges and deployments, and how often records are checked	Automate matching of change records to deployments and reconcile on a fixed schedule rather than at audit time
External review or pre-audit testing	Recurring or periodic, if bought	Scope of the review, whether the reviewer tests samples of changes, and whether an implementation partner or consultant is involved	Agree a fixed scope in writing and ask for the sample list and deliverables before work starts
Auditor sampling effort	Recurring at each audit cycle	Number of changes the auditor selects, how complete your records are, and how quickly staff can produce evidence	Keep one retrievable record per change, with request, approval, test result and rollback plan in one place

Which open-source tools support change records and code controls

Change management under A.8.32 depends on two kinds of evidence: the record of each request, approval and outcome, and the technical gate that stops unauthorized code from reaching production. The four tools below cover one part each, and none of them makes a change process compliant on its own.

GLPI Assistance change module

GLPI's Assistance module follows ITIL practices for tickets, problems and changes, with plannings, statistics, recurrent tickets and a Kanban view. For A.8.32, the change record is the evidence: request, impact assessment, approver, scheduled window, test result and closure. Check whether your configuration enforces mandatory fields and approval steps before a change can close, and confirm the feature set against current vendor documentation. The organization still owns the policy that defines which changes need review.

Zammad for user change requests

Zammad is a web-based helpdesk that brings email, chat, telephone and social media messages into one ticket system. It matters for A.8.32 only where change requests reach you from customers or users, since it keeps the originating request and the reply trail in one place. It does not model change approval or rollback planning by default, so teams usually pair it with a change process tool. Confirm its ticket workflow and retention settings against current vendor documentation.

GitLab protected branches

GitLab Community Edition protected branches let you restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Together these settings show that production code changes pass through reviewed merge requests and that the approval trail is retained. Confirm that protection covers the production branch in every repository, and check how approvals are enforced in your edition before you rely on the setting as evidence.

Semgrep scans in CI/CD

Semgrep Community Edition scans code in many languages, including Go, Java, JavaScript, Python and Terraform, using community or custom rules. Running it in a CI/CD pipeline gives each change a recorded scan result before it merges, which supports the testing and review steps of A.8.32. Its findings are only useful if someone triages them and the pipeline blocks merges on high-severity results. Confirm language coverage and rule options against current documentation for your stack.

Who owns change management and who can help

Your organization owns change management. The change policy, the approval authority, every authorization decision, the emergency change reviews and the change records must come from people inside the organization who are accountable for the systems involved. An assessor will ask who approved a change, whether that person had the authority to approve it, and whether the approval came before implementation. Those answers cannot be delegated to a partner or a tool.

Change policy owner: Defines which changes need review, who may approve each category and what counts as a standard, normal or emergency change.
Approvers: Named individuals or roles who authorize changes, with documented authority and a record of their decisions.
Emergency change reviewers: Review urgent changes after the fact, confirm the reason for bypassing normal approval and decide whether follow-up testing is needed.
Records owner: Keeps the change register complete, including requests, impact assessments, test results and rollback plans.
Process owners for each system: Assess impact and confirm that testing and rollback plans fit the systems they run.

Before engaging anyone outside the organization, confirm internally who holds each role and whether those people can show a sample of past changes with complete records.

Where change management usually falls short

Most A.8.32 findings are not missing procedures. They are gaps where a change bypasses the procedure, closes before it is verified, or leaves no record. Each card names one gap, how to close it, and the evidence an assessor will ask to see.

Direct changes outside the workflow

Engineers log in to production servers, edit configuration files or click through cloud consoles without raising a change. Close the gap by restricting production write access to the deployment pipeline and a small set of break-glass accounts, then reconciling configuration state against approved records. Evidence: access listings showing who can change production, and a sample of production changes matched to approved change IDs. Confirm with your own environment which consoles and tools still allow direct edits.

Emergency changes with no retrospective record

Urgent fixes during an incident often go in with a verbal approval and no ticket, so the record is written weeks later or never. Define an emergency change path with named approvers, a time limit for the ticket to be raised, and a mandatory post-implementation review. Evidence: emergency change tickets created within the defined window, with approver names and a review outcome for each.

Tickets closed after deployment

A change ticket is often marked complete when the deploy command runs, not when the result is verified. Require that the ticket records the test evidence, the verification step and the actual implementation time before closure, and that closure is blocked while any of these fields are empty. Evidence: closed tickets showing test results, a verification entry and a timestamp that falls after the deployment record.

No rollback plan for standard changes

Teams treat routine changes as low risk and skip the rollback step, which is when a small patch causes an outage with no tested way back. Require a rollback step in every change template, even for standard changes, and test it at least once for each recurring change type. Evidence: rollback steps attached to change records, and records of rollback tests or actual rollbacks with their outcomes.

Approvals given by the implementer

When the person who builds a change also approves it, the approval step checks nothing. Separate the requester, implementer and approver roles in the ticketing system and in the repository, so that merge rights and change approval rights are not held by the same person for the same change. Evidence: role assignments showing separation, and approval records naming someone other than the implementer. Confirm how your platform enforces this rather than relying on policy alone.

Gaps in configuration and cloud changes

Change control often covers application releases but not infrastructure changes, firewall rules, cloud IAM policies or configuration files. Bring infrastructure as code, cloud configuration and security settings into the same change process, and log changes that bypass the pipeline. Evidence: version history of infrastructure code with reviewed merge requests, and configuration drift reports that show no unrecorded changes. Ask your auditor which change types they expect in scope.

How much work does A.8.32 change management take to prove?

How much effort does it take to prove A.8.32 change management?

The effort depends less on the control itself than on how many changes the organization makes and how many of them already leave a trace. A team that deploys a few changes a month through one pipeline with pull requests and tickets has most of the evidence already. A team that changes production by hand, through several tools and without consistent tickets must first agree on a procedure, then retrofit records for the changes already made. The main cost drivers are the number of change types, the number of systems in scope, how many approval paths exist, and how far current practice is from a written procedure. No supplied figure sets the hours involved, so ask any partner or auditor to break the estimate into procedure design, tooling setup, staff training and sampling readiness, and to state which parts recur each year.

How long must the change process run before an audit?

The process must operate for the whole period the auditor samples, not just on the day of the audit. Auditors select a period of change records and test whether each sampled change followed the procedure: a request, an impact assessment, an authorization, testing, a rollback plan and a record of the outcome. A procedure written the week before the audit will show gaps in the sampled records, so the organization should run the procedure long enough to produce a representative set of changes before the audit window opens. Confirm the sampling period, the number of changes the auditor expects to test and the certification body's specific expectations in writing before setting a start date.

Can a small team run A.8.32 change management alone?

Yes, a small team can run the control alone if the procedure is proportionate to its change volume and the same people are not the only reviewers of their own work. The control asks for consistent handling of changes, not a large change advisory board. A two- or three-person team can use a single ticket type, a standard change category for routine work, and a peer review step recorded in the code host. The risk to watch is segregation: if one engineer requests, approves, deploys and closes every change, the records will not show independent authorization. Document how that gap is handled, such as a second approver for production changes, before the auditor asks.

What does the organization itself need to provide for this control?

The organization owns the control, so several inputs must come from inside it regardless of who helps. These usually include:

Named approvers for each class of change, with a stated backup when the approver is unavailable
Access to the source repositories, deployment pipelines and ticketing system so that records can be produced and sampled
Time for reviewers to assess impact and test results before a change is authorized
A decision on which changes are standard, normal and emergency, and who may approve each

Without these, the procedure exists on paper while the records show approvals made by default or after deployment.

Are self-hosted open-source tools enough to evidence A.8.32?

Open-source tools can produce most of the evidence, provided they are configured to enforce the procedure rather than merely record it. For example, GLPI's Assistance module can hold change tickets that follow ITIL-style practices, GitLab Community Edition's protected branches can block direct pushes to production branches and disable force pushes unless explicitly allowed, and Semgrep Community Edition can run in CI/CD to scan changes before merge. Tools do not write the procedure or make the risk decisions. Confirm with each vendor which features are in the edition you deploy, and check that the change records link the request, the approval, the test results and the deployment so an auditor can trace a sampled change end to end.

How should an organization choose between in-house work and partner help?

Choose in-house work when the team already runs its pipelines, has named owners for each system, and can dedicate time to designing and operating the procedure. Consider a partner when the scope is fixed and the team lacks time or experience with the tools. DeployOpen works on fixed scope agreed in writing before work starts, and it can plan, configure, document and support self-hosted platforms in the client's own infrastructure, including the change tooling and the evidence it produces. Ask any partner to state which deliverables are configuration, which are documentation, and which remain the organization's decisions. Pricing follows from the written scope, so request a quote that lists each deliverable.

What can an implementation partner not do for the auditor?

An implementation partner cannot decide whether the organization conforms, and it cannot issue an audit report or certificate. Only an independent auditor or a certification body accredited to issue certificates can do that. A partner can prepare the procedure, configure the systems, collect records and help staff answer questions. It should not select the sample, write the findings or sign off the evidence on the auditor's behalf. Keep the roles separate in the contract and in practice, and ask the certification body in advance how it expects change records to be provided.

How DeployOpen prepares change management evidence

DeployOpen plans, implements and documents the change management workflow that A.8.32 expects, inside your own infrastructure. Your organization keeps ownership of its controls, and an independent auditor or certification body decides whether the evidence meets the standard.

How we scope

We agree in writing which systems, change types and ticket workflows fall under A.8.32 before work starts.
The written scope names the platforms, environments and approval roles that the change procedure will cover.
Engagements are fixed-scope, and ongoing support is available as a retainer once the workflow is running.

How we build

We configure self-hosted ticketing for change requests, impact assessments, approvals and rollback plans.
We enforce protected branches and review gates in your source control so unreviewed changes cannot reach production.
We connect CI/CD testing and security scanning to the change record so each deployment links to its tests.

How we hand over

We deliver the written change procedure, role matrix and records templates that your team operates day to day.
We document how each change record links to its request, approval, test results and rollback evidence.
We walk your team through an evidence pack so an assessor can trace sample changes from request to closure.

How we support

We can maintain the change tooling, upgrades and backups under a retainer agreed in writing.
We can run periodic reviews of change records to find skipped approvals or missing rollback plans.
Your organization decides which findings to act on, and an independent auditor performs any formal assessment.