IT Change Management: Tracking What Changed and Why

The most common cause of an IT outage is a change. Not a hardware failure, not a cyberattack. A change that went wrong, a change that interacted with something unexpected, a change that was made without knowing what depended on it.

This is well-established enough that "something changed" is the first diagnostic question in most troubleshooting frameworks. Before chasing symptoms, you ask: what changed recently?

If you can't answer that question in two minutes, you have a change management problem.

What change management documentation is

Change management documentation is a record of what was changed, when, by whom, and why.

It's not an approval process. It's not a committee. It doesn't have to be bureaucratic. At its minimum, it's a log of changes with enough context to answer the "what changed" question during an incident.

Formal change management processes (CABs, change windows, approval workflows) exist and make sense in enterprise environments. For smaller environments and teams, the useful minimum is much simpler: a change log that gets updated when things are changed, and a habit of checking it when things break.

What to log

For each change, capture:

What was changed. Specific enough to be useful. "Firewall changes" is not specific. "Added inbound rule on port 8443 to allow traffic from vendor IP 203.0.113.44 to server 10.0.1.50" is.

When it was changed. Date and time. This lets you correlate changes with incidents. "Something broke at 2pm. What changed in the two hours before 2pm?" is a question the log should be able to answer.

Who made the change. For accountability and for follow-up. If something breaks and you need to understand what was done, knowing who to ask is faster than reading through logs.

Why it was changed. The justification. A ticket number, a request from a specific person, a security finding, a vendor recommendation. The "why" tells you whether the change should be rolled back or preserved if it causes a problem.

What the expected result was. What was this change supposed to accomplish? Knowing the intent helps diagnose when the change had an unintended effect.

What to watch. If there are specific things to monitor after this change to confirm it worked as expected or to catch problems early, note them.

The rollback question

Every change should have an answer to: if this doesn't work, how do we undo it?

For some changes, rollback is trivial. Revert the config file. Re-enable the disabled service. For others, rollback requires a backup, a specific sequence of steps, or accepting that the rollback has its own risks.

The time to think through rollback is before the change, not after something breaks. Write the rollback procedure in the change record before you make the change.

If you can't clearly answer how to roll back a change, that's a signal to think more carefully before making it.

Unauthorized changes

In any environment with more than one person and more than one way to make changes, unauthorized changes happen. Vendor technicians make configuration changes without telling you. Users install software. Someone "just restarts" a service that needed to stay running.

You can't prevent all of this. You can build systems that detect it.

Monitoring for configuration drift (comparing current state against a baseline) catches unauthorized changes automatically. Reviewing system logs periodically catches what monitoring misses.

When you find an unauthorized change, document it as if it were a planned change: what changed, when (approximately), who (if known), and any consequences. Treat it as a change that needs a root cause.

"We found an unknown change and investigated it" is better than "we don't know why things are different." It's also better than reverting the change and discovering it was load-bearing.

The correlation benefit

A change log earns its value during incidents.

When something breaks, you check the change log first. If there's a change in the window before the incident, that's your first hypothesis. If the change is well-documented, you know exactly what was done and can evaluate whether it could cause the symptoms you're seeing.

This shortcut can cut incident resolution time dramatically. A problem that would take two hours to diagnose from scratch takes twenty minutes when you can start with "the firewall rule added this morning is the most likely cause."

Without the log, every incident starts from zero. With it, you start with a hypothesis.

Making it a habit

The only change management process that works is one that people actually use. A complicated system with approval workflows and mandatory fields gets bypassed. A simple log that takes two minutes to update gets used.

The minimum viable change log is a shared document with a table. Date, time, what, who, why. That's it. A ticket comment in your PSA system works too. The format doesn't matter. The habit does.

One enforcement mechanism that works: make the change log part of ticket closure. A ticket that involved a change doesn't close until the change is logged. This is the same discipline that works for documentation generally, applied specifically to changes.

The overhead is two minutes per change. The payoff is hours saved during the next incident.