Cybersecurity and AI: Why the Risk Belongs in the Boardroom, Not the Server Room

Most boards think they’ve addressed cyber risk when they approved the security budget. This post explains why that’s a really risky assumption.

The harder truth is that security spend is often mistaken for risk resolution. At best, it’s only risk reduction, and that’s under ideal conditions. And as I’ve said before, incident avoidance is not a survival strategy. That’s what most organizations have never seriously planned for, and that gap is about to get a lot more expensive.

AI-Powered Cyberattacks Are Accelerating Faster Than Organizations Can Respond

Anthropic’s Claude Mythos just changed the math on cybersecurity risk.

Still in limited release, Mythos has already identified thousands of previously unknown zero-days across major operating systems, browsers, and foundational open-source libraries. We’re talking bugs that survived decades of human security review, and it found them in weeks. Competing AI capabilities from other labs are expected within 12 to 18 months.

Here’s the problem: organizations cannot patch fast enough on a normal day. And thanks to AI, “normal” days may be a thing of the past.

When this wave of newly discovered vulnerabilities hits the broader market through CVE publications, scanner updates, and eventually direct AI-powered discovery tools inside enterprises, security teams will face a volume of critical findings they have no operational capacity to clear in time. Some will get patched, but many won’t. Attackers will know exactly which ones to target.

The result is predictable. Ransomware, outages, account takeovers, payment misdirection, data breaches, and every threat category you’ve seen over the past two decades, compressed into a much shorter window.

AI is accelerating both attack capability and impact timelines, which makes recovery planning just as critical as prevention. The organizations still treating this as a future problem are already behind.

Why Cybersecurity Prevention Alone Is Not a Business Resilience Strategy

Most mid-market companies I work with are reasonably good at avoiding cyber incidents. They invest in the right controls, including monitoring, vulnerability management, and user training. But since incident avoidance is only half the survival equation, the half that gets skipped is business resilience.

What happens to your organization when something gets through anyway?

Can you continue to service customers if critical systems are offline for two months? Can you process payments, fulfill contracts, and meet regulatory requirements? Most companies genuinely don’t know. And the not knowing is the real risk. You can’t prepare for a scenario you haven’t mapped.

Think about it. Two months of critical systems being offline. Most companies haven’t run that scenario once, not even on paper. Because running it produces an answer nobody wants to present to the board.

Better security programs will help, but no program eliminates the risk entirely. The organizations that believe otherwise aren’t more secure; they’re just less prepared for the moment their assumptions fail.

Third-Party and Vendor Cyber Risk: The Resilience-Planning Blind Spot

Now, what if it’s not your systems that go down, but a critical vendor or partner you depend on to operate?

That question is the one most resilience plans never answer, because it requires mapping dependencies you’d rather not think about. 3rd-party risk is the blind spot in most incident response plans: you’ve tested your own recovery, but you never tested your critical vendor’s.

The simple fact is, your vendor going down is your problem, too. Most organizations haven’t internalized that. Yet. Best not to wait until it happens.

A powerful real-world example of third-party dependency risk in healthcare is the 2024 Change Healthcare ransomware attack. Change Healthcare is a critical infrastructure provider that processes claims and payments for hospitals, physician practices, and pharmacies across the country. When ransomware took their systems offline, the ripple effect across the healthcare ecosystem was immediate and severe — estimated at $1 billion per day in impact to providers.

Tens of millions of insurance claims were affected. The disruption was significant enough that the Department of Health and Human Services stepped in and authorized advance payments to help affected providers stay afloat. The outage persisted for up to three months, creating catastrophic impacts on both clinical operations and financial services for healthcare organizations that had no contingency for their most critical vendor going dark.

This is exactly the scenario most resilience plans don’t account for. Change Healthcare’s customers had their own DR plans. What they didn’t have was a plan for what happens when a vendor they depend on every day simply isn’t there.

What a Tested, Funded Cyber Resilience Plan Actually Looks Like

As AI tools dramatically expand the attack possibilities and compress the timeline for successful breaches, the likelihood of a disruptive cyber event hitting your business or your supply chain is rising. The question is shifting from “if” to “when”, and “how prepared are we?” Most mid-market companies haven’t made that mental shift yet.

Planning for it isn’t pessimism. It’s risk management.

Here’s what a real resilience strategy requires: it has to be tested, and it has to be funded. Both words have equal weight here, because a plan without funding isn’t a plan; it’s a document. And a plan without testing is just a guess.

An untested plan exists on paper and fails in practice. Testing is what makes the difference.

What’s the minimum viable resilience test that gives you real signal without a full simulation? At minimum: a tabletop exercise with the actual decision-makers in the room. Not IT and/or the CISO. The CEO and the functional leads who own the customer relationships and the contracts.

Testing resilience plans is a nuanced conversation because the right cadence depends heavily on the organization’s risk profile and the specific processes being tested.

The right place to start is the business impact analysis. The BIA exists precisely to articulate which services and functions are most critical to the organization — and that prioritization should drive both the frequency and depth of your resilience testing. Higher-risk functions get tested more often and with greater rigor. Lower-risk functions can be tested less frequently.

For higher-risk organizations and higher-risk processes, testing should happen on a regular basis — in some cases as frequently as monthly. That said, most tests are limited in scope by design. Rather than testing the entire continuity plan at once, you’re focusing on a specific process, technology, or third-party dependency and working through a defined scenario: how does the business function if this particular element is disrupted?

These exercises don’t have to be complex or resource-intensive. A tabletop exercise, where key stakeholders walk through a disruption scenario together and talk through their response, is one of the most effective and accessible testing formats available. It surfaces gaps in the plan without requiring a full operational drill, and it builds the organizational muscle memory that makes real incidents more manageable.

The key is that testing has to be deliberate and recurring. A plan that was tested once at implementation and never revisited is not a tested plan; it’s an outdated one.

Why Cyber Risk Belongs on the CEO and Board Agenda, Not the IT Department’s

I’d tell any CEO or board right now that this is not an IT conversation. Business resilience planning is not about servers, encryption, or patch cycles. It’s about how your business functions under duress, and that conversation belongs at the executive level, not delegated to the technology team.

Passing it off to the technology team is how resilience planning becomes a compliance document nobody reads until it’s needed. And it doesn’t work.

The question every business leader should be asking has shifted from “how do we prevent an attack?” to “how do we survive one?” That’s a related, but completely different conversation, and one most companies haven’t started yet.

While the formal resilience planning process can be appropriately initiated by IT or cybersecurity leadership, the conversation has to be positioned carefully. Other executive leaders may not be looking holistically at broad, multifaceted business risk on their own, which is why IT and security leaders need to bring it to them.

The right venue is whatever forum technology leadership already uses to interact with the board, typically a board of directors meeting or a similar executive-level setting. But how the conversation is framed matters as much as where it happens. Technology leaders must resist the instinct to present this as an IT issue. Resilience planning touches finance, facilities, operations, clinical services, and other critical business functions. The conversation should reflect that scope from the outset.

Like any board-level discussion, this one should stay above the technical details. Metrics, architecture, and tool stacks belong in a different room. At the board level, the conversation should connect directly to business objectives and mission: What does a disruption cost us, what functions are most critical to our ability to serve our customers or patients, and how confident are we that we can keep operating when something goes wrong? That framing gets executive attention in a way that a technical briefing never will.

From “If” to “When”: Start the Board-Level Resilience Conversation Before You Need It

The companies that come through this period intact will have strong leadership, not just strong security programs. They’ll also have tested, funded resilience strategies that raise the issue of disruption to the level of business risk, not leave it as a technical problem for the IT guys to deal with.

Strong security and strong leadership. Most security content avoids naming both as required, because it’s harder to sell and harder to measure. But both are necessary: your security team can reduce the likelihood of a breach, but only your leadership team can ensure the business survives one.

Having that conversation now will be a whole lot easier than having it later.