Nine years of break-fix taught me how controls fail in real life

There's a special kind of education you get from supporting fifty-plus client environments at an MSP. You see the same controls implemented fifty different ways, and you learn quickly which ones survive contact with reality.

The policy binder vs. the server room

Almost every client had a written password policy. A meaningful fraction of them also had the Wi-Fi password on a sticky note in the break room. The policy wasn't wrong — the control just didn't account for how people actually work. That's the gap auditors live in: not between good policy and bad policy, but between policy and practice.

Controls rot

The firewall rule that was perfectly justified in 2021 is a mystery in 2026, and nobody wants to be the one to delete it. "Temporary" exceptions become permanent. The backup that "runs every night" hasn't completed successfully in three weeks, but the email alerts go to someone who left in March. Controls don't usually fail all at once — they decay, quietly, one unreviewed exception at a time.

What this means for audit work

Here's what nine years of break-fix gave me that a textbook can't: I know what control failure looks like from the inside. I've seen the sticky note. I've found the dead backup job. I've been the guy who inherited the mystery firewall rule.

An auditor who has only read about controls tests whether the control exists. An auditor who's watched them rot tests whether the control works — and knows exactly where to look when it doesn't. That's the auditor I want to be.