# The Board Didn't See It Coming. They Never Do.
The Southwest Airlines meltdown over Christmas 2022 didn't happen because hackers broke in. It happened because scheduling software built in the 1990s couldn't handle cascading failures when weather disrupted operations. The airline's board had approved growth, new routes, new aircraft — all the things that show up in an investor deck. The 30-year-old crew scheduling system that would eventually strand 2 million passengers? That was an IT department problem.
That story has become the template for a specific category of corporate catastrophe: the infrastructure failure that looks like a surprise to everyone except the engineers who had been flagging it for years.
A new commentary from DXC Technology president Chris Drumgoole makes this argument for board-level audiences, and while the piece is clearly promotional — DXC sells exactly the governance consulting it's advocating for — the underlying diagnosis is largely correct. Boards are structurally bad at seeing technology risk, and that structural problem is getting more dangerous as AI adoption and cloud concentration raise the stakes on every infrastructure decision.
## The Invisibility Problem Is Real, and It's Architectural
Drumgoole identifies what he calls the core paradox of infrastructure investment: the return only becomes visible when the investment isn't made. You don't see the five years of patching that prevented a breach. You do see the breach.
This isn't a new observation, but it keeps getting worse. The financial accounting frameworks boards use to evaluate investments are built around returns — revenue generated, costs reduced, market share gained. A project to pay down technical debt, modernize legacy authentication systems, or build geographic redundancy into cloud infrastructure produces none of those numbers. It produces absence: absence of outages, absence of breach pathways, absence of cascading failures.
Board members trained to read income statements and evaluate acquisitions aren't equipped to evaluate the risk posed by a BGP routing table with 15-year-old configurations, or a SCADA network that hasn't been segmented from corporate IT because the upgrade would require a two-week production shutdown.
The result is a predictable dynamic: technology risk accumulates at exactly the pace that finance-focused boards are comfortable with, which is to say, it accumulates indefinitely until it becomes a crisis.
## Normalization Is the Attack Vector
The most operationally useful point in Drumgoole's piece gets one paragraph: the risks causing the most disruption "weren't the ones executives were actively discussing. They were the ones that had become accepted as normal, that teams actively worked around every day."
That's a description of what disaster researchers call normalization of deviance — the gradual process by which a known problem gets reclassified from "risk requiring action" to "known condition we manage around." Every engineer who's written a monitoring alert that pages them at 3 AM three nights a week eventually stops treating it as a signal and starts treating it as background noise. Every team that builds a manual workaround for a broken system dependency eventually forgets the workaround is compensating for a critical failure mode.
This is how the 2021 Colonial Pipeline incident happened — not because the controls were nonexistent but because the company's IT and OT environments had never been properly segmented, a known condition that had been managed around for years. It's how the MOVEit breach exposed hundreds of organizations: the SQL injection vulnerability was in code that had been deployed and trusted for years, well past any moment when anyone was actively thinking about it as a risk.
The danger Drumgoole is describing isn't novel threats. It's the things your teams have stopped seeing because they've made peace with them.
## What "Board-Level Responsibility" Actually Requires
The conventional advice — "make technology risk a board-level conversation" — is nearly useless without specifics. Boards have been getting this advice for a decade and the pattern of infrastructure failures hasn't meaningfully changed.
What actually differentiates boards that manage technology risk effectively isn't that they have CISO presentations at every quarterly meeting. It's that they've restructured how they receive information so that the absence of problems isn't treated as the presence of health.
The practical version of this looks like: mandatory disclosure of critical technical debt items in board materials, independent technology risk assessments that report around the CTO rather than through them, and explicit board authorization for infrastructure investments that have no revenue case — just risk reduction.
It also means treating vendor concentration as a first-class board risk. After the CrowdStrike incident in July 2024 took out roughly 8.5 million Windows systems globally, the boards that got the clearest picture of their exposure fastest were the ones that already had vendor dependency maps at the board level. Most didn't. Most were asking their CIOs to explain why a software update to a security product had grounded airlines and shut down hospital systems.
---
## HackWire Analysis
The timing of Drumgoole's piece is notable even if the argument isn't new. We're roughly 13 months past the CrowdStrike outage — long enough for the immediate crisis response to fade but not long enough for most boards to have made structural changes to how they govern technology risk. That gap is historically where the next failure incubates.
There's a pattern worth naming explicitly: every major infrastructure failure produces a wave of board-level governance conversations, followed by a wave of consultants and vendors positioning to serve those conversations, followed by incremental change that doesn't address the underlying structural problem. DXC, to be clear, is a beneficiary of this cycle — which doesn't make the diagnosis wrong, but does mean the prescription (hire better advisors, engage more actively, demand better reporting) should be read critically.
What the piece undersells is the regulatory dimension that's actually forcing this issue more than any amount of board enlightenment. SEC cybersecurity disclosure rules now require public companies to report material cybersecurity incidents within four business days, and to disclose annually how their boards oversee cybersecurity risk. That's a structural forcing function the voluntary governance conversation never produced. Companies that haven't built the internal processes to answer those questions accurately — not just compliantly — are sitting on undisclosed liability.
The real vulnerability here isn't in the boardroom. It's in the gap between what boards are told and what's actually true about their infrastructure. That gap is where the next Southwest-style failure is hiding, right now, in a system someone's team has been working around for years.
Defenders at the operational level should be documenting those workarounds. Not to fix them immediately — budgets rarely allow that — but because a written inventory of "known conditions we manage around" is the starting point for an honest risk conversation with leadership that most organizations have never had.
— HackWire Editorial
---
## Related Coverage