Skip to main content

Your Governance Framework Is Protecting You From Progress (A $5.4 Billion Case Study)

· 16 min read
Jeevan D C
Governance Theatre

Somewhere in your organisation right now, an engineer wants to use a tool. It's open source. It's battle-tested. Half the Fortune 500 runs it in production. But first, they need to fill out a vendor assessment form, get InfoSec sign-off, wait for procurement to confirm there's a contract in place, and then — maybe, in four to six months — they'll get a "yes" or a "no" from a committee that's optimised for risk avoidance, not risk management.

This isn't an argument against governance. Governance matters — especially in regulated industries. This is an argument that the way most enterprises do governance today is broken: optimised for the appearance of control rather than the reality of it. The question isn't whether to govern. It's whether your governance framework is actually reducing risk — or just reducing speed.

Meanwhile, the startup down the road shipped the feature last Tuesday.

But hey, at least you've got a contract. You can sue them if things go wrong. Right?

The Contract Will Protect Us​

Let's start with the big one — the security blanket that justifies half of enterprise governance: "We need a contract so we have legal recourse."

Let's test that theory with the largest IT outage in history.

July 19, 2024. CrowdStrike pushes a faulty update. 8.5 million Windows machines crash globally. Every Fortune 500 airline goes down. 75% of top healthcare organisations affected. Estimated damages to Fortune 500 companies alone: $5.4 billion.

I know because I was there. Friday night, flight cancelled, standing in a terminal watching departure boards go dark one by one — with a conference talk to give Saturday morning. The approved vendor's approved update took down the approved airline's approved systems. Nobody asked me if I'd approved that.

CrowdStrike was the approved vendor. Every one of those enterprises had a contract. They'd been through procurement. They'd passed InfoSec review. They had SLAs, liability clauses, the works.

So how much have those enterprises recovered?

Zero dollars. As of today — not a cent.

Delta Air Lines — 7,000 cancelled flights, 1.3 million stranded passengers, $500M+ in claimed losses — is still in court. CrowdStrike is "confident" their liability is capped at single-digit millions thanks to the limitation of liability clause in the contract. The same contract that was supposed to protect Delta.

The shareholder lawsuit? Dismissed. The passenger class action? Dismissed. CrowdStrike's stock? Fully recovered within five months. Customer retention rate? 97%.

The contract didn't protect anyone. It protected CrowdStrike.

CrowdStrike: $5.4B damages, $0 recovered
warning

CrowdStrike's "apology" to affected partners? [10UberEatsgiftcards](https://dataconomy.com/2024/07/25/crowdstrike−gift−card−apology−uber−eats/).Fora10 Uber Eats gift cards](https://dataconomy.com/2024/07/25/crowdstrike-gift-card-apology-uber-eats/). For a 5.4 billion outage. That's not compensation — that's a meme.

"But Cloud Vendors Have SLAs"​

Sure they do. Let's read the fine print.

AWS's Customer Agreement, Section 9.1:

"NEITHER AWS NOR YOU... WILL HAVE LIABILITY TO THE OTHER... FOR (A) INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES, (B) THE VALUE OF YOUR CONTENT, (C) LOSS OF PROFITS, REVENUES, CUSTOMERS, OPPORTUNITIES, OR GOODWILL, OR (D) UNAVAILABILITY OF THE SERVICES"

Read that again. They explicitly exclude liability for the service being unavailable. The thing you're paying them for. If it breaks, they're not liable for the fact that it broke.

What you do get: service credits. Not cash — credits against future usage of the service that just failed you. Typically 10-30% of your monthly bill for the affected service.

So if you spend 100K/monthonAWSandsuffera4−houroutagethatcoststhebusiness100K/month on AWS and suffer a 4-hour outage that costs the business 2M in lost revenue, the SLA credit might be $10K. That's 0.5% of the actual loss. Industry analyses consistently show SLA credits cover a fraction of actual outage costs — the math simply doesn't work in the customer's favour.

The contract doesn't transfer risk. It transfers paperwork.

The Approved Vendor List: A History of Spectacular Failures​

The approved vendor list exists to ensure you only use "safe," vetted software. Let's look at how that's worked out.

SolarWinds (2020) — On the approved vendor list of 18,000 organisations including the US Treasury, Department of Homeland Security, and most of the Fortune 500. Russian intelligence inserted malicious code into trusted software updates — the exact mechanism enterprises rely on. Even FireEye, a cybersecurity company, was compromised through their own approved vendor.

CrowdStrike (2024) — The approved security vendor. $5.4 billion in damages. Already covered.

Log4Shell (2021) — 93% of enterprise cloud environments were vulnerable. CVSS severity: 10.0 (maximum). The US Department of Homeland Security estimated finding and fixing every instance would take a decade. Total lawsuits against Apache, the maintainer? Zero. Because the Apache Software Foundation runs on [3millionayear](https://sanesecurityguy.com/articles/log4shell−giants−standing−on−the−shoulders−of−dwarves/)—roughly3 million a year](https://sanesecurityguy.com/articles/log4shell-giants-standing-on-the-shoulders-of-dwarves/) — roughly 8,600 per project. And Log4j wasn't on your approved vendor list directly — it was inside the commercial software that was.

IncidentApproved Vendor?DamagesRecovered
SolarWindsOn 18,000 approved listsBillions (classified + commercial)Negligible
CrowdStrikeApproved security vendor$5.4B+ (Fortune 500 alone)$0
Log4ShellInside approved softwareTens of billions$0

The approved vendor list didn't prevent any of these. That's not an argument for abolishing vendor vetting — it's an argument that vendor vetting alone is insufficient. These incidents succeeded despite the process, not because of it. The list catches real risks every day. But it creates a dangerous illusion when it becomes the primary line of defence rather than one layer in a deeper stack.

"Do I Still Need Approval to Build a Slack App?"​

Let's zoom in on something that'll make your eye twitch.

An engineer wants to build an internal Slack bot. It reads messages in one channel and posts a summary in another. It touches no customer data. It has no external network access. It runs on the company's own infrastructure.

The approval process (conservatively estimated — your mileage may vary, but probably won't):

  1. Vendor assessment form (even though there's no vendor — you're building it)
  2. InfoSec review (a few weeks, if you're lucky)
  3. Architecture review board (next available slot: TBD)
  4. Data classification exercise (it's Slack messages between engineers, but sure)
  5. Procurement sign-off (for a tool that costs $0)
  6. Privacy impact assessment (it's an internal bot, but policy says...)

Total elapsed time: long enough that the engineer has either built it in secret or stopped caring. For a Slack bot. That took an afternoon to build.

Now multiply that by every internal tool, every automation, every experiment. Every time someone has an idea that could save the team hours a week, they run the same gauntlet. Most of them don't bother. They either build it quietly and don't tell anyone (hello, shadow IT), or they just... stop having ideas.

Vendor onboarding at large companies takes up to 6 months. 52% of companies say third-party assessments take 31-60 days. And the average enterprise wastes $18 million annually on unused software licenses — software that was approved but nobody uses because by the time it arrived, the team had moved on.

The process doesn't prevent risk. It prevents progress.

2-4 months to approve a $0 tool

Code Isn't the IP Anymore​

Here's the existential one. For decades, the governance narrative has been: "The code is the competitive advantage. Leaking it is catastrophic."

But what happens when AI writes most of it?

If anyone with the same agent and the same prompt can regenerate functionally equivalent code, the code itself is a commodity. The actual IP is the problem definition, the architecture decisions, the domain knowledge, the data, and the evaluation criteria that guide the agents. Not the for-loops.

Open source already proved this. Linux, Kubernetes, React — all public. The companies using them still have competitive advantages. The code was never the moat. The system was.

And yet, governance frameworks still treat source code like it's the crown jewels. They lock down repos, restrict tooling, and add friction to every commit.

💡

Protecting an asset whose relative value is declining while underinvesting in the assets (data, brand, system design) that increasingly matter more.

In economics, this is a classic misallocation of scarce resources. Governance budgets — time, attention, political capital — are finite. Every hour spent locking down code repos is an hour not spent building data governance, eval frameworks, or output validation.

Even domain knowledge — once the ultimate moat — is being disrupted as AI context windows grow large enough to absorb and reason over entire codebases.

What Regulation Actually Says (vs. What People Think It Says)​

What people think: "Regulators require us to use approved, contracted enterprise vendors."

What regulators actually say:

RegulatorActual PositionMandates Specific Vendors?
EU AI ActRisk-based classification, proportionate obligationsNo — prescribes outcomes: transparency, fairness, logging
FINRA"Technology neutral" — existing rules applyNo — explicitly says don't "rely on vendors as a shield"
SECMateriality-informed disclosureNo — cares about accurate representation and governance
US Treasury230 control objectives across 6 domainsNo — asks "what evidence demonstrates effectiveness?"
FCA (UK)"Adaptive and positive approach" via existing frameworksNo — no new AI-specific rules
MAS (Singapore)Principles-based, pro-innovationNo — risk-based human oversight, outcomes-focused

Every single major regulator takes a technology-neutral, outcomes-based approach. They care about controls, audit trails, and accountability — not which vendor's logo is on the invoice.

FINRA said it explicitly: firms must "update their written supervisory procedures to address the use of AI rather than relying on vendors as a shield." The regulator is literally telling you that the contract isn't the governance.

The Real Governance Stack​

So if contracts, approved vendor lists, and code lockdowns aren't the answer — what is?

🛡️ Actual Governance — Controls outcomes:

  • Agent sandboxing — what can it access?
  • Audit trails — who prompted what, what was generated?
  • Output validation — automated tests, SAST, policy gates
  • Eval frameworks — is the output correct and safe?
  • Data residency — where do prompts and outputs flow?
  • Red teaming — actively trying to break it
  • Model version pinning — the model you tested is the model you run
  • Human-in-the-loop — risk-based, not blanket
  • Cost governance — who's accountable for API spend?

The question isn't "is this tool on the approved list?" It's "do we have the infrastructure to use any tool safely?"

If the answer is no, banning tools is a band-aid. If the answer is yes, the vendor's size doesn't matter — the controls do.

The Startup Ecosystem Is Already Enterprise-Grade​

The reflexive response: "We can't use startup tools. They might disappear. They're not enterprise-ready."

The data says otherwise:

These aren't scrappy side projects. They're the tools that the world's largest companies are already running in production — while the procurement team is still evaluating the vendor assessment form.

The hybrid model makes sense: big vendors for infrastructure and data (AWS, GCP, Azure — compliance, residency, stability), startup/OSS ecosystem for tooling and orchestration (speed of innovation, composability, low switching cost). The risk profiles are categorically different. Treating them the same is a category error.

The Cost of Not Moving​

Here's what doesn't show up on a risk register:

  • 95% of enterprise AI pilots fail to deliver measurable P&L impact (MIT, July 2025). The report attributes this to a "learning gap" — the inability to integrate AI into existing workflows, poor resource allocation, and brittle processes. Governance theatre makes this worse: instead of building the organisational muscle to adopt AI effectively, enterprises burn their change budget on procurement cycles and vendor assessments that don't address the actual failure modes.
  • Two-thirds of companies are stuck in pilot phase (McKinsey). The ones that aren't are pulling ahead fast.
  • Top AI performers are 2x as likely to quit their jobs (Upwork Research Institute). The best engineers leave because they can't use modern tools. We're left with people comfortable with the status quo.
  • Gartner predicts 75% of large enterprises will adopt dedicated AI governance platforms by 2026. Not "ban AI tools" — govern them.

The risk of adopting is visible. The risk of not adopting is invisible.

Nobody gets fired for maintaining the status quo. People get fired for approving a tool that causes an incident. The incentive structure rewards inaction — the same payoff problem that makes cross-team collaboration break down at scale.

You avoided the risk of a new tool causing an incident. Instead, you got the risk of irrelevance. One is recoverable. The other isn't.

The One Thing​

We don't ban cars because they can crash. We build seatbelts, airbags, speed limits, licensing, and insurance.

Enterprises that ban AI tools are banning cars. Enterprises that build governance frameworks are building roads.

The approved vendor list didn't stop SolarWinds. The contract didn't stop CrowdStrike. The SLA won't make you whole when the cloud goes down. And the procurement process won't protect you from the startup that ships in a week what takes you a quarter.

Stop asking "is this tool safe enough to use?"

Start asking "do we have the governance infrastructure to use any tool safely?"

Build the seatbelts. Then drive.

Build the seatbelts. Then drive.

References: CrowdStrike outage analysis, AWS Customer Agreement, EU AI Act, FINRA Regulatory Notice 24-09, US Treasury FS AI RMF, MAS Project MindForge, MIT GenAI Divide Report, Gartner Market Guide for AI Governance Platforms. The SolarWinds, Log4Shell, and CrowdStrike case studies draw from multiple sources linked throughout.