Why Companies Are Betting on Cyber Resilience

Published: 2026-10-21  |  Last reviewed: 2026-10-21

The security perimeter is dead. Companies now ask not just "can we stop attackers?" but "can we keep operating while they're inside?"

For a long time, the dominant logic in enterprise security was build a better wall. Firewalls, intrusion prevention systems, endpoint protection, perimeter controls—the whole industry was oriented around keeping attackers out. The implicit assumption was that a successful breach represented a security failure, and that with enough investment, failure was avoidable.

That assumption hasn't aged well. A string of high-profile breaches—organizations with substantial security budgets, mature programs, and well-credentialed teams—made it increasingly difficult to argue that prevention alone was a viable strategy. The honest reality is that determined attackers, supply chain compromises, and credential theft regularly bypass perimeter controls. The question most security teams now face isn't just how do we stop intrusions, but what happens when one gets through?

This shift isn't informal. It's showing up in frameworks, government strategy, and in how breach costs actually behave in practice.

Why does a prevention-only approach eventually fail?

Short answer: Attackers have too many entry points, and defenders can't close all of them simultaneously. Supply chains, stolen credentials, and zero-day vulnerabilities all create paths that bypass perimeter controls. The Verizon 2025 DBIR found that third-party involvement in breaches doubled to 30% in a single year—an attack surface most organizations don't directly control.

There's also a structural asymmetry. Defenders have to be right about everything, every time. Attackers only have to find one gap. That's not a pessimistic observation—it's just how the math works.

The Verizon 2025 Data Breach Investigations Report, which analyzed over 22,000 security incidents including 12,195 confirmed breaches, found vulnerability exploitation surged as an initial access vector by 34% year-over-year [1]. System intrusion breaches—complex, multi-step attacks—climbed from 36% to 53% of breach patterns [2]. These aren't the kind of breaches you stop with a better firewall rule.

Meanwhile, phishing as an initial access vector accounted for 16% of attacks in IBM's study—the leading root cause [3]. Human error accounted for 26%. Roughly 49% of all breaches in the Verizon data involved stolen credentials. These are inherently hard to prevent at the perimeter level. You can add MFA, you can train users, but you can't make credentials un-phishable across an entire organization indefinitely.

None of this means prevention is worthless—patching, MFA, least-privilege access, and strong perimeter controls absolutely reduce the attack surface. The argument for resilience isn't that these controls don't matter; it's that they're necessary but not sufficient. A resilient organization uses prevention to reduce the likelihood of a breach and uses detection, containment, and recovery capabilities to limit the damage when prevention fails. Understanding how to triage high and medium CVEs effectively is one part of that prevention layer, but it's not the whole picture.

What does cyber resilience actually mean in practice?

Short answer: Cyber resilience means your organization can detect a breach quickly, limit what the attacker can reach, maintain critical operations during the incident, and recover without catastrophic delay. It's operationally distinct from prevention—it assumes failure will happen and prepares for it.

The practical components break down into four areas:

• Detection speed. How quickly does your SOC or detection tooling identify anomalous activity? IBM's 2025 data shows the global average at 181 days to identify a breach—better than the 194-day figure from 2024, but still six months of potential attacker dwell time [1]. That's the population-wide average across 600 organizations globally. Organizations with better detection capability—especially those using modern EDR, XDR, or MDR solutions—perform significantly better.
• Containment capability. Once a breach is detected, can you isolate the affected systems without shutting down the business? Network segmentation and zero trust architecture directly determine the blast radius. A flat network turns a single endpoint compromise into a wide-scale incident.
• Business continuity. Can critical systems stay online during an active investigation? IBM found that nearly all of the 600 organizations it studied suffered operational disruption following a breach—not just data exposure [3]. Resilience planning includes determining which systems are non-negotiable to keep running, even degraded.
• Recovery and restoration. How long does it take to get back to normal? IBM's 2025 average containment time was 60 days—down from 64 in 2024, but still two months [1]. Nearly two-thirds of IBM's breached organizations were still recovering at the time of the survey [3].

What makes dwell time numbers slightly tricky to interpret: IBM's 241-day lifecycle is a survey-based average across a diverse set of organizations and breach types. Mandiant's M-Trends, which reflects cases Mandiant's teams actually investigated directly, shows a median closer to 11 days. These measure different things—one is a broad survey average, the other is median dwell time in actively investigated incidents. The honest reading is that detection capability varies enormously by organization and incident type, and averages mask that spread.

How have official frameworks formalized this shift?

Short answer: NIST CSF 2.0 (February 2024) added a sixth core function—Govern—and for the first time included a dedicated Technology Infrastructure Resilience category. CISA's strategic plan explicitly lists shifting agency mindsets from "prevent breach" to "assume breach" as a named objective.

NIST released CSF 2.0 in February 2024, the framework's first major revision since 2014. The original five functions—Identify, Protect, Detect, Respond, Recover—remain, but the new Govern function sits above them, requiring organizations to treat cybersecurity risk management as a strategic business concern, not just an IT operational issue [4]. CSF 2.0 also added a Technology Infrastructure Resilience subcategory under Protect, and substantially expanded the Respond and Recover functions with more specific, actionable guidance.

The emphasis on Detect, Respond, and Recover—three of the six core functions—signals something important: the framework explicitly balances prevention against response capability. You can't claim CSF compliance by focusing only on the Protect pillar.

The zero trust model is the architectural expression of this logic. Zero trust's defining principle—"never trust, always verify"—only makes sense if you're already assuming that some identities and devices within your environment may be compromised. It's a resilience-first architecture, designed so that a successful initial intrusion doesn't automatically grant access to everything else. For organizations considering this approach, a practical zero trust implementation guide is a reasonable starting point before committing to a full architectural overhaul.

What changes operationally when resilience becomes the goal?

Short answer: Security teams shift investment priorities toward detection engineering, incident response preparedness, segmentation, and recovery infrastructure—not just prevention tools. The metrics change too: time-to-detect and time-to-contain become more relevant than perimeter vulnerability counts alone.

A few concrete changes that show up in practice:

• Incident response planning moves earlier. Resilient organizations write and test IR plans before a breach happens, not during one. IBM's data consistently shows that organizations with tested IR plans and retained IR teams have significantly lower breach costs. Having a well-structured incident response plan is a foundational requirement, not a compliance checkbox.
• Detection investment increases. Spending more time tuning SIEM rules, deploying behavioral analytics, and reducing false-positive fatigue. The organizations cutting their breach lifecycle the fastest are those investing in detection engineering and automation—not those buying more perimeter products. IBM found that security AI and automation cut breach timelines by 80 days and saved roughly $1.9 million per breach on average [1].
• Backups and recovery get treated as security controls. Immutable and air-gapped backup infrastructure aren't IT hygiene—they're a direct counter to ransomware's leverage. CISA guidance specifically calls out air-gapped or immutable backups given that many ransomware strains actively target reachable backup systems.
• Segmentation becomes strategic. The difference between a one-machine ransomware infection and an organization-wide outage is often whether the network was flat or segmented. Containment speed depends directly on how blast radius was designed in advance.
• Third-party risk gets more attention. The Verizon 2025 DBIR's finding that third-party involvement doubled to 30% of breaches signals that resilience planning has to extend beyond the internal network. Supply chain attacks and vendor compromises require their own containment playbooks [2].

How can your team assess its current resilience posture?

Short answer: Resilience self-assessment focuses on four capability areas: detection, containment, continuity, and recovery. The questions below are designed to surface gaps—not achieve perfect scores.

Cyber resilience self-assessment across the four core capability areas:

What resilience doesn't solve

Cyber resilience is a valuable reframing, but it's worth being honest about its limits. A focus on detection and response doesn't eliminate the need for strong prevention controls—it complements them. Organizations that cut prevention investment in favor of detection will find themselves dealing with more incidents, which increases IR costs even if each incident is handled faster.

Resilience also doesn't help much if containment capabilities aren't built before an incident. The benefit of network segmentation only materializes if it was in place before the attacker arrived. The same goes for IR playbooks, recovery infrastructure, and detection tooling—these require investment and testing in advance.

There's also a measurement problem. Mean time to detect (MTTD) and mean time to contain (MTTC) are useful metrics, but organizations often don't know their true MTTD until after a breach. Proactive approaches like red team exercises and breach and attack simulation help surface realistic capability gaps. Hunting for living-off-the-land techniques in EDR telemetry is one way to probe detection coverage without waiting for an incident to reveal blind spots.

Finally, resilience doesn't reduce regulatory exposure. Data breach notification laws, GDPR, HIPAA, and sector-specific requirements still apply whether your response was fast or slow. A quick containment doesn't necessarily mean a breach falls below regulatory reporting thresholds. Having a breach notification plan ready is part of the resilience picture that often gets overlooked until it's urgent.

Strategic Implications

The shift from prevention to resilience is real and it's being formalized at every level—NIST frameworks, CISA strategy, and the data coming out of IBM's annual breach research. But it's worth resisting the temptation to treat "resilience" as a simpler answer than it is. Prevention-versus-resilience is a false binary. The organizations handling breaches best are doing both: tightening controls to reduce the probability of intrusion, and building the detection and response machinery to limit the damage when intrusion happens anyway.

The IBM 2025 data is instructive here. Breach lifecycle time fell to a nine-year low—not because organizations stopped getting breached, but because they got faster at finding and stopping what was already inside. That improvement was driven largely by AI and automation in security operations, not by blocking more traffic at the perimeter. The organizations still taking near-300-day breach lifecycles aren't failing at prevention; they're failing at detection and containment.

For security leaders, this suggests a concrete budget argument: investments in detection engineering, IR readiness, segmentation, and recovery infrastructure have quantifiable return in reduced breach cost and duration. The IBM data showing $1.9M in average savings per breach from AI and automation deployment is unusually specific for this kind of research. That's a business case, not just a security recommendation.

The harder shift is cultural. Telling executives that a breach is survivable—and that the organization's security investment is oriented around surviving it well—is a different conversation than promising prevention. It's also more honest. The organizations getting that framing right are the ones building security programs that scale with the threat environment instead of chasing a zero-breach goal that the data consistently shows is out of reach.

Sources & References

1. IBM Newsroom — Cost of a Data Breach Report 2025 press release (July 30, 2025)
2. Verizon Business — 2025 Data Breach Investigations Report press release (April 23, 2025)
3. CyberScoop — IBM Cost of a Data Breach 2025 (July 30, 2025)
4. Kiteworks — NIST CSF 2.0 overview and six core functions
5. Dark Reading — CISA's Strategic Plan and the assume-breach shift