The change was “low risk”, apparently

“It’s only a small change.”

You hear it all the time. It’ll be something like a small firewall rule, a quick DNS tweak, or a restart that “won’t affect anything.” Usually said late in the day, with just enough confidence to make you slightly uncomfortable.

And sometimes, to be fair, it is fine. Nothing breaks, nobody even notices the change that took 4-hours to implement, and you close the ticket. Everyone moves on. But sometimes that “small” change is tied to something important by a piece of string nobody knew was there. And that’s when you find out that small and low risk are not the same thing.

Where it starts to go wrong

Quick changes feel efficient. No record, no real impact check, no rollback plan beyond “we’ll undo it.” No heads-up to anyone else. In the moment, that can feel like good service. Fast, responsive, helpful. The problem is that you’re building risk you can’t see, aAnd that kind of risk tends to show up at the worst possible time.

This is the bit people miss, some changes are technically simple but operationally risky, but the effort involved isn’t the point.

The real question is: what depends on it?

Because even small changes can touch:

• production systems
• customer data
• integrations you forgot existed
• scheduled jobs that only run once a day
• access paths people rely on without thinking

If it behaves differently than expected, what actually happens?

Why small things cause big problems

It usually comes down to a few familiar issues.

Dependencies aren’t clear
Systems aren’t isolated, even if they look like they are. That “small” change often has knock-on effects somewhere else.

Ownership is fuzzy
If nobody clearly owns something, nobody can confidently say what changing it will do.

Rollback is assumed
“We’ll just reverse it” isn’t a plan.

Communication is late
People find out about the change when something stops working, not before.

None of these are unusual. That’s what makes them dangerous.

When change control is mostly vibes

You can usually tell when things aren’t quite right.

• “It shouldn’t affect anything”
• “We’ve done this before”
• “No need to tell anyone”
• “We’ll roll it back if it breaks”
• “It’s too small to log”

What “good enough” looks like

Not every change needs a meeting and a form that feels like applying for planning permission.

But some basic structure goes a long way:

• know what you’re changing and why
• have a rough idea who or what might be affected
• give people a heads-up if it matters
• think about how you’d undo it before you start
• leave a record so someone else can follow what happened

That’s it.