Why your audit trail is only as strong as your change management

Ask any IT leader what happens when an audit request lands, and most will admit that rather than creating a report, it’s a scramble. It might look something like this: one person pulls logs from three different tools, someone else messages a colleague to ask why they approved a change four months ago, and a third person digs through old emails looking for a sign-off that actually happened in a meeting that nobody wrote down.

They’re not imagining the pain, either. In Thoropass’s 2026 State of Audit and Compliance report, based on a survey of 536 infosec leaders, 53% named collecting evidence across multiple tools as the most common bottleneck in the audit process. And 91% said they have to resubmit audit evidence at least sometimes due to miscommunication or shifting auditor expectations.

I read that number from both sides. SysAid is examined annually under SOC 2 Type II and certified to ISO 27001, 27017, and 27018, with annual surveillance audits, so the scramble I’m describing is one I’ve stood in, not one I’ve only heard about.

Passing an audit isn’t the same as having an audit trail

A change management audit trail is a linked record of every change request, authorization, testing, and deployment, captured as it happens, so an auditor can verify that the control worked without anyone having to reconstruct it.

If your team can eventually piece together who approved what and when, most audits get passed. Compliance has traditionally asked a fairly narrow question: was this change approved, and can you prove it after the fact? You don’t need a real-time record to answer that. You just need the pieces to exist somewhere, even if it takes two weeks and three tools to find them.

What makes it fragile is the shape of the test. An auditor examines whether a control operated effectively over the entire period, and the only artifacts they can examine are those you produce. Reconstructing it after the fact only proves the pieces still exist somewhere, not that the process worked while it mattered.

So teams get good at the scramble rather than at the process. And because the scramble usually works well enough to pass, nobody stops to ask what it would take to actually have the answer on hand.

What auditors actually ask for in a change management audit

It helps to be specific about the mechanic, because it’s less abstract than people expect. The auditor doesn’t ask whether you have a change management process. They take a sample of changes from the period, twenty-five, say, and for each one, they want the authorization, the evidence it was tested, and the rollback plan. Then they check whether the person who requested the change is the same person who approved it.

In my experience, approval almost always happened, just not visibly tied to that specific change. The record exists, but the thread between the request, the decision, and the deployment was never joined, which is exactly why “we can find it eventually” stops being good enough.

Weak change management shows up as outages, not just audit stress

It’s as much a change management problem as a compliance one, and it surfaces most acutely during audit season.

Uptime Institute’s 2025 outage analysis found that nearly 40% of organizations experienced a major outage due to human error in the past three years. Of those, 85% traced back to staff not following procedure, or to a procedure that didn’t hold up in the first place. And the share of human-error outages caused specifically by failure to follow procedure rose ten percentage points in 2025 compared with 2024. It’s the same gap that makes audits painful: a process that exists on paper but isn’t actually being followed or captured in the moment.

The record you can’t produce for an auditor and the process gap that causes an outage are usually the same thing, just discovered at different times.

What a defined emergency change path includes 

If you want to know how healthy a change process is, don’t look at the planned changes. Look at the ones that happen at 2 am.

Emergency changes are legitimate. Something is broken, the fix can’t wait for a Tuesday approval meeting, and someone makes a judgment call under pressure. What happens next is where it actually breaks: the retroactive approval that never gets recorded, the post-implementation review nobody schedules, the change that quietly enters production without ever hitting the register.

So a real process defines the emergency path before it’s needed. Who can invoke it, how quickly the approval has to be documented afterward, and what review closes it out. Auditors know this is where the gaps live, and it’s usually the first place they sample after the standard changes come back clean.

How AI is changing the change management audit

Here’s where this gets more urgent, not less. As AI takes on more of the work in change management, flagging risk, routing approvals, and sometimes initiating changes on its own, the questions being asked are changing, too.

The frameworks are already explicit about the mechanics. ISO 27001 asks whether changes to information-processing facilities are authorized, tested, and documented (A.8.32), and whether the person requesting a change is the same one approving it (A.5.3). SOC 2 tests the same ground under CC8.1. For EU financial entities and the providers they rely on, DORA places accountability for ICT risk with the management body itself.

What’s new is the AI layer, and it’s a different question. Where an agent flags the risk, routes the approval, or initiates the change, “who authorized this” stops being a name in a field. The EU AI Act’s human oversight requirements and ISO/IEC 42001 point to the same conclusion: a named person remains accountable, and the basis for the decision must be reconstructible afterward. A status field that says “approved” doesn’t survive that question. Neither does a Slack thread from four months ago that nobody can find.

It’s also the gap most teams already feel. In the same Thoropass survey, 69% said AI adoption in their organization is outpacing their ability to secure and govern it. Change management is where that shows up first, because it’s the first place an agent is trusted to act rather than advise.

Practically, that means three things I’d want in place before an agent touches a change. It acts under its own scoped identity, not a shared service account, so “who did this” has an answer. The inputs it saw at decision time are retained so that the decision can be replayed rather than guessed at. And high-risk changes keep a human gate. One more thing, easy to get wrong: agent-initiated changes belong in the same change register as human ones. A separate AI activity log is how you end up with two partial records and no complete one.

The honest trade-off

None of this is an argument for gating everything. I’ve seen the other failure mode too, and it’s worse: a process so heavy that people route around it, and changes start happening in places the register never sees. A control universally resented is one quietly bypassed.

The workable answer is to tier changes by risk. Low-risk, well-understood work runs as a pre-approved standard change with a light record. Normal changes are reviewed in proportion to their blast radius. Emergency changes get speed now, with documented approval immediately afterward. Same register, three speeds. That’s a process people follow, and it’s the only one that produces a real audit trail.

Build the record as you go, not after someone asks 

Your team shouldn’t have to choose between moving fast on changes and being ready to answer for them later. Every approval, every status update, every action should be logged the moment it happens, not pieced together when someone asks.

With one caveat, I’d put on my own argument. Automation captures what happened, when, and by whom. It does not capture why. If the timestamps are perfect and the reasoning field is empty, you have a flawless record that still fails the real question: on what basis was this approved? The system should make the record effortless. Someone still has to write the sentence explaining the judgment, and no tool will do that part for you.

When I’m the one asking my team what happened and why, I don’t want to have to search Slack for the answer. I want it already there. That’s the standard we hold ourselves to, and it’s the standard SysAid’s change management is built for: every step, from request through approval to deployment, captured as it happens, so the record is a by-product of the work rather than a project of its own.

Four things worth checking this week

If you want to know where you actually stand, these four answers will tell you faster than a policy review:

• Pick a change from six months ago. Can you produce the authorization, test evidence, and rollback plan in under an hour from a single place?
• What is your documented window for approving an emergency change after the fact, and does anyone enforce it?
• Can the same person request and approve a change? Try it and see whether the system stops you.
• Are agent-initiated changes in the same register as human ones, or in a log somebody would have to remember to look at?

If your change process still runs on tribal knowledge and Slack searches, SysAid’s change management builds the record as the work happens, so you’re never reconstructing it under pressure.