Automate ISO 27001 Change Evidence: 7-Step Workflow

Last Updated: October 21, 2026

Why Automating ISO 27001 Change Evidence Beats Spreadsheets

The core problem with spreadsheet-based evidence is timing. Evidence gathered after the fact is reconstruction, not record.

ISO 27001 change evidence is the documented proof that changes to your information systems were authorised, tested and reviewed in line with your control environment. Under ISO 27001:2022, change management sits primarily in Annex A control 8.32 (change management) and 8.9 (configuration management), with related requirements in clause 7.5 on documented information.

This guide from ChangeGate walks through a seven-step workflow for automating that evidence and maps change control to Annex A controls so auditors accept it the first time.

Watch Out The most common failure we see is teams that automate the approval step but leave evidence capture manual. The approval gets logged, but the test results, the deployment confirmation and the rollback plan sit in email threads. Auditors sample change records, not approval logs, and a record with a gap fails the sample.

Map Your ISO 27001 Change Control Procedure to Annex A Controls

Start with the mapping, not the tooling.

Here is a working mapping we use as a starting point:

The point is traceability, not completeness: every row tells the auditor which control the evidence supports, so a sampled change can be followed from request to deployment without another document.

A common mistake is mapping generically ("this satisfies change management") without linking specific evidence artefacts. Auditors want the control, the evidence and the link between them.

Pro Tip Build your mapping as a living document and store it alongside your Statement of Applicability. When a control owner changes, the mapping tells them exactly which evidence their control depends on. This is the single highest-use document in an ISO 27001 change evidence programme.

Build the Automation Workflow: Step by Step

The workflow below is tool-agnostic: implement it in a governance platform, your ITSM tool with custom fields, or a workflow engine bolted onto your change system.

Step 1: Define the Change Record Schema

Define the fields every change record must contain before connecting any tools: change ID, description, risk rating, affected systems, control owner, approver, test evidence reference, deployment timestamp and rollback plan reference.

Treat the schema as a contract: every integration writes into these fields, and any optional field will be missing in the audit sample. Make them mandatory at change closure, so a change cannot be marked complete until every required artefact is attached.

Step 2: Connect Your Change Request and Approval Tools

Wire your change request system to your approval workflow so approval is captured as a system event, not a forwarded email. The critical requirement is segregation of duties: the raiser must not be the approver.

Your workflow engine should query the identity provider for requester and approver identities and compare them before allowing approval. Reject self-approval at the API level, not just the UI, auditors test this by attempting to approve as the requester, and a soft warning fails.

Step 3: Automate Evidence Capture at Each Stage

At each stage, the workflow should write an evidence artefact automatically, risk assessment at request, approval record at sign-off, test results at verification, deployment log at release, each carrying the change ID so it traces back to the record.

This is where manual processes break down: evidence lives in five places with no common key. Automated capture writes everything to one repository keyed on the change ID.

Step 4: Handle Exceptions, Emergency Changes and Failed Deployments

Emergency changes are where audit findings cluster. Your workflow needs an explicit emergency path that still captures evidence, even retrospectively. Failed deployments need the same treatment: rollback, post-incident review and corrective action all attach to the original change record.

Do not let emergency changes bypass the schema: route them through a shortened approval with a mandatory post-hoc review. Auditors accept a documented emergency path, never an undocumented one.

Step 5: Set Review Cadence and Continuous Monitoring

Set a review cadence for the evidence itself, not just the changes. A monthly check that every change record in the period has complete evidence catches gaps before the audit does. Continuous monitoring means alerting when a change closes without its required artefacts.

A scheduled query against your evidence repository should flag any change record missing a required artefact, or where the approval timestamp is later than the deployment timestamp.

Step 6: Map Evidence to Controls Automatically

As each artefact is written, tag it with the Annex A control it supports. The mapping table becomes the rule set: test results to A.8.29, deployment logs to A.8.31, approval records to A.8.32 and A.5.3. This lets an auditor sample a control and see every change that exercised it, rather than sampling changes and hoping the controls are covered.

Step 7: Export for Audit

Build an export that produces, for any date range or control, a complete evidence pack: change records, linked artefacts, control mapping and reviewer sign-offs. Make it immutable once generated, with a hash and timestamp so the auditor can verify it has not been altered. Test the export before the audit, not during it.

Key Takeaway The workflow is not a tool. It is a set of rules about what evidence must exist, who owns it, and how it is linked. Tools implement the rules; they do not replace them.

ISO 27001 Audit Evidence Checklist for Change Records

Use this checklist to sample your own change records before the auditor does. A checklist alone is not enough: the auditor is not checking that a box is ticked but that the evidence behind it is sufficient, attributable, time-stamped and tamper-evident.

• Change request exists with a unique ID and a description of what changed

• Risk assessment recorded, with a rating and the reasoning behind it

• Approver identified and different from the requester

If your evidence repository can answer every line of this checklist from a single change ID, you are audit-ready. If it takes more than one search to answer any line, the workflow has a gap.

Book Demo →

What Makes Evidence Sufficient for an Auditor

Auditors apply four tests to every artefact. Sufficiency: does the evidence prove the control operated, or merely suggest it? A screenshot of an approval email is weaker than a system-generated approval record with approver identity and timestamp.

Many organisations pass the first two tests and fail the last two: emails and spreadsheets are attributable but not time-stamped or tamper-evident, while system logs are time-stamped but often not linked to the change record.

How Auditors Sample Change Records

Auditors do not review every change; they sample. Typically they pick a period, such as the last six months, and sample changes across risk ratings and types, including at least one emergency and one failed change, then trace each from request to outcome, checking the evidence trail is complete and the controls in your Statement of Applicability were actually applied.

Your weakest change record sets the bar for the sample: if one is missing a test result, the auditor will expand the sample and may raise a nonconformity. The review cadence in Step 5 exists to catch those weak records first.

Evidence Quality Criteria You Can Automate

Encode the auditor's four tests as automated rules in your evidence repository: require every artefact to carry a system-generated timestamp, actor identity from the identity provider, change ID and cryptographic hash; reject artefacts lacking any field; flag changes where approval postdates deployment or that close without a rollback plan reference. This turns evidence quality from manual review into a continuous control.

Watch Out The most common audit finding in change management is not a missing policy. It is a change record where the evidence exists but cannot be linked to the change, or where the approval cannot be proven to have happened before deployment. Automate the linkage and the timestamp comparison, and you remove the finding.

Control-by-Control Evidence Requirements

For each Annex A control your change process touches, define the minimum evidence set: A.8.32 needs the change request, risk assessment, approval record and deployment log; A.8.9 the before/after configuration snapshot; A.8.29 the test result and sign-off; A.5.3 proof the approver is not the requester.

If your evidence repository can answer every checklist line from a single change ID and prove the four quality tests for each artefact, you are audit-ready.

ISO 27001 Change Management Examples: What Good Evidence Looks Like

Good evidence is specific, timestamped and linked. Here is what that looks like in practice.

Example two: an emergency change. A critical vulnerability forces an out-of-hours patch.

Example three: a failed deployment. A change is deployed and rolled back within the hour.

What all three share is traceability. The evidence trail is complete from request to outcome, and every artefact carries the same change ID.

What to Look For in ISO 27001 Compliance Software

ISO 27001 compliance software should reduce the manual work of evidence collection, not add bureaucracy.

Look for four capabilities:

• Change-specific evidence capture. The tool should write evidence artefacts automatically at each stage of the change lifecycle, keyed on the change ID. Generic document management is not enough.

• Segregation of duties enforcement. The tool should block self-approval as a hard rule, not a soft warning.

• An evidence repository with traceability. Every artefact should be linked to its change record and its Annex A control, so an auditor can follow the trail without asking you.

ChangeGate is built around exactly this pattern: it unifies business, operational and IT change in one governed lifecycle, generates audit-ready evidence automatically, and enforces accountability so no change is approved by the person who raised it.

Pricing depends on the size of your organisation and the scope of your change estate, so we recommend booking a demo to get a quote rather than working from a list price.

Conclusion

The challenge is not collecting evidence but collecting it at the moment the change happens, in a form an auditor will accept, without adding work to the people making the changes. Spreadsheets cannot do that; a governed workflow can.

ChangeGate gives you a unified lifecycle for business, operational and IT change, automatic audit-ready evidence generation, and centralised governance that enforces segregation of duties across every business unit.

Frequently Asked Questions

What evidence is needed for ISO 27001 change management?

An auditor typically wants to see the change request with its stated purpose, a risk assessment or impact analysis, approval by someone other than the requester (segregation of duties), evidence of testing, deployment records, and post-implementation review. Each record should link to the relevant Annex A controls, such as 8.32 for change management and 8.9 for configuration management. The evidence must show the change was authorised before it happened, not reconstructed afterwards.

How can change management evidence be automated for ISO 27001?

Automation starts by connecting your change request tool, approval workflow and deployment pipeline to a central evidence repository. Each time a change moves through a stage, the system captures the timestamp, the approver, the test result and the deployment record automatically. This removes manual evidence gathering from spreadsheets and screenshots. The key is defining a consistent change record schema first, so every automated capture lands in the right place and can be traced back during an audit.

Can change management software help prepare for an ISO 27001 audit?

Yes, provided the software generates evidence as a by-product of the workflow rather than requiring separate manual entry. Look for tools that export an audit trail, link change records to Annex A controls, and support a Statement of Applicability that stays current. Software that only stores documents without connecting approvals to implementation evidence will still leave you assembling records by hand when the certification audit arrives.

How often should change records be reviewed for ISO 27001?

Review change records at least quarterly as part of your internal audit cycle, and immediately after any failed change, emergency change or nonconformity. A monthly spot-check of a sample of changes helps catch missing approvals or incomplete test evidence before an auditor does. The review should confirm that each record has a complete audit trail, that segregation of duties was maintained, and that corrective actions were logged where a change did not go to plan.

If your change evidence still lives in spreadsheets and email chains, the next audit will find the gaps before you do. ChangeGate brings change governance, risk management and evidence capture into one place, with audit-ready evidence generated automatically for ISO 27001, SOC 2 and TISAX. Get started with ChangeGate and walk into your next certification audit with a traceable record behind every change.

Book Demo