You delegated authority years ago.
That part felt responsible. Necessary, even.
You hired capable people. You empowered them. You trusted them to make technical decisions so you could focus on running the business—serving clients, patients, cases, projects, and regulators.
That arrangement worked. For a long time.
Until August 2007 forced a reckoning.
The incident that triggered it wasn’t dramatic. No outage. No breach. No headline-worthy failure.
It was a question.
It came from outside your IT department and landed squarely on your desk.
“Who approved this?”
The question referred to a system configuration that had existed for years. It had never caused a problem. It had never been challenged. It had quietly done its job.
And now, suddenly, it mattered.
If you lead a financial firm, you’ve seen this moment during an examination. If you’re in healthcare, it happens when auditors start mapping access paths instead of policies. Legal firms experience it when privilege is questioned not in theory but in practice. Engineering firms feel it when design controls are reviewed against contractual obligations.
The uncomfortable truth is this: authority can be delegated. Accountability cannot.
When the question came, the answer couldn’t be “IT handled that.”
Because the follow-up question was immediate and unforgiving.
“And who in leadership accepted the risk?”
Silence is rarely acceptable in those moments.
In August 2007, Microsoft’s platforms had matured to the point where they no longer obscured responsibility. Access logs were precise. Configuration histories were traceable. Decisions left fingerprints.
That transparency changed expectations.
Leadership could no longer plausibly claim distance from operational risk. Not because they were expected to know every technical detail—but because they were expected to know which risks had been consciously accepted.
This distinction matters deeply in regulated and high-trust industries.
Regulators don’t expect executives to configure servers.
They do expect executives to govern risk.
Clients don’t expect partners or physicians to manage systems.
They do expect leadership to ensure confidentiality, availability, and integrity.
August exposed a gap that many organizations share: authority was distributed, but accountability was assumed to evaporate somewhere below the executive level.
It doesn’t.
The conversations that followed were uncomfortable—but necessary.
“What decisions require leadership sign-off?”
“What risks are operational, and which are organizational?”
“What happens when something fails that no one remembers approving?”
Those are governance questions, not IT questions.
By the end of August, something subtle but important had shifted.
Leadership didn’t take control away from IT.
They took responsibility back.
Risk acceptance became explicit. Exceptions required documented approval. Operational decisions with material impact were surfaced instead of buried.
Not to slow the business.
To protect it.
Because once accountability is questioned publicly, internal confidence stops mattering.
And August made it clear: leadership is accountable even when authority has been delegated wisely.