A lot of outages I review start the same way. A system worked on Friday. On Monday it fails, runs slowly, or sends data to the wrong place. The team checks for a hardware failure or an attack, and the early checks come back clean.
Then someone remembers a change. A firewall rule was adjusted late Thursday. A software update was installed to fix a small bug. A vendor changed a setting during routine support work. The change was real, it was approved in a hallway conversation, and nobody wrote it down.
Why a written change record matters
A change record gives the team a starting point when something breaks. It lists what changed, who made the change, when it happened, who approved it, and how to reverse it.
Without that record, troubleshooting starts from memory. Staff try to recall who touched the system and what the old setting was. That work takes time, and it gets harder when the person who made the change is out sick, on vacation, or works for a vendor.
For a mid-market company, the cost shows up in hours. Staff wait to work, customers wait for answers, and IT staff test unrelated systems because they have no reliable list of recent changes to check first.
The changes that cause the most trouble
Routine changes cause most of the problems I see, because they look low risk at the time.
Examples include a password policy change that locks out a service account, a DNS change that points email to the wrong server, a storage change that fills a drive overnight, and a permissions change that blocks a department from its files. A vendor update can belong on this list too. If a line of business application updates overnight and a report format changes, the team needs to know the update happened before they spend a morning rebuilding reports.
Major projects usually get planning and documentation. Small fixes often get a quick action and no record. The size of the change and the size of the impact are different things.
A simple process that fits a small team
You need a process staff will actually use on a busy day. Keep it short.
1. Log the change before the work starts.
Use a shared list or ticket system. Record the date, the system, a plain description of the change, the person making it, and the approver. One or two sentences are enough for a routine item.
2. State the rollback step.
Write down how the change will be reversed if it fails. Save the prior configuration, note the previous setting, or keep the installer for the prior version. A rollback note written in advance saves time during an outage.
3. Note the check that will confirm it worked.
Name one test: staff can sign in, email flows, the report runs, the backup completes. Record the result, not just the plan.
4. Review changes once a week.
Spend 15 minutes reviewing the list. Look for changes with no approver, no test result, and no rollback note. Look for patterns too, such as repeated changes to the same system in a short period.
What to ask your IT provider
If an MSP or vendor can change your systems, ask how those changes are logged and where you can read the log. Ask who can approve a change to the firewall, to user access, and to your main business applications. Ask how emergency changes get recorded after the fact, because emergencies happen and the record still needs to exist the next morning.
Add one item to your regular IT review: show me the changes made in the last 30 days, with approvals and test results. A provider with a working process can produce that list quickly. Gaps in the list are useful information. They show where work is happening outside the process you agreed to.
Start with the next change
Pick a start date this week. From that date, every change to a production system gets a line in the log, including vendor work and small fixes. Keep the first version simple so the habit forms. Review the log after your next incident or outage, and check whether the first hour of troubleshooting got shorter.
A change log will not prevent every outage. It will give your team facts to work from when one happens, and it will reduce the number of outages caused by work nobody knew had taken place.
Not sure where your IT really stands? Start with a Clarity Audit: a focused assessment of your backups, security, vendors, and AI readiness. It's the first step in every engagement I take on.
About the author: Chris McGlasson is a fractional CIO and the founder of ClearStack Advisory, where he helps mid-market companies build AI governance, IT strategy, and technology roadmaps without the overhead of a full-time CIO. He previously built and sold LANPRO Systems, an IT services firm serving 350+ enterprise clients.