By: Michael Henry, CEO, Accelerynt
Every company in my career has had a change board, and they all did what they were supposed to do. Proposals came in, somebody asked about rollback, somebody else asked what the help desk would think, and the change either went out in the Thursday window or waited for the next meeting. Production was running, so the board must have been effective, right? It never claimed to see everything that changed in the environment, and for most of my career, the gap between approved changes and everything that was changing was small enough to ignore.
Lately, however, that gap has been growing. Software now makes changes on its own, and administrator changes to configuration via an admin portal are getting more complex and less structured. In April, a startup reported that a coding agent, working through a routine task, wiped its production database in nine seconds and took the backups with it, because the backups lived on the same volume. The hosting provider confirmed a rogue customer agent had hit an old endpoint. Nobody approved that change because nobody was asked.
The wise people who think hardest about this have answers, and the common denominator is a pipeline. DORA’s research says shift left: replace the board with peer review and automated checks during development, which is where they found elite teams deploying more than a thousand times a year while the low performers waited for a meeting. The asynchronous school keeps the review and loses the meeting: name a service owner, let them approve in the workflow. The risk-tiering school routes small changes past the board automatically. The policy-as-code school goes furthest and enforces at commit time, on the argument that if review happens after deployment, the control is already behind the change.
All these schools of thought are right about pipelines and right about agents. Anything with delete rights, anything that can take down a tenant, anything a script can finish in nine seconds needs a gate in front of it, and the gate needs a pipeline to live in.
Where the solution runs thin is the admin console. You can put a Microsoft 365 or Azure tenant under configuration as code. A few shops do that. Most do not, and even the ones that do still leave administrators with portal rights, so the exclusion can still get added by hand at 4:50 on a Friday. Many things an administrator does in a portal don’t file a ticket, so a named location loses an IP range or a detection rule gets switched off during an upgrade, and the minutes say nothing. There is no commit to check because the change never entered a flow that had checks. Reach’s 2026 survey shows the end results: 97 percent of enterprises had a misconfiguration-related incident in the past year, and remediation runs more than eight days.
It’s time for the change board to have a second job: declare the configuration baseline for critical services, observe the tenant, and put the diff on the agenda. Every change since the last meeting gets one of three answers: keep; revert; promote (which means this class of change gets gated next time).
We already use this mechanism in other areas. When an emergency change goes in ahead of approval, ITIL has the change board review it afterward and decide whether it stands. Agency law has done the same thing for longer than IT has existed: when someone acts without authority, the principal ratifies or repudiates.
Configuration change detection is a solved problem. Configuration-as-code tools and the posture-management market will tell you when the tenant drifts. What needs to happen is putting the drift in front of the people who own the risk, with a decision and a name attached. That is what the change board was built for and it’s time for them to take ownership.
A proposal invites a no, and saying no to a proposal is free. A change that already happened has an owner, and the owner must defend keeping it against evidence of what it did. The friction argument that stalls a proposal doesn’t have anything to attach to in a diff review because the friction, if there was any, is already in the record.
Two conditions to think about. First, the window between the change and the meeting is exposure, so anything in the high-blast-radius set should get alerted the hour it happens. Second, the diff needs to be easy. It needs a declared baseline and a way to compare the tenant against it. Most organizations have neither, which is why the diff either takes minutes to produce or dies after the second meeting. That is a tooling problem, and it is solvable. The judgment problem is drawing the line between what gets gated and what gets ratified. Review the diffs by blast radius: create future gates for what cannot be undone and ratify or reject the rest.
Change control has been guarding a door with a process behind it. The other door never had a process, and it is now the one creating the most risk.