Security Hot Takes: Cyber Resilience, the New Baseline

Table of Contents

• Module 1: Cyber Resilience Is the New Security Baseline
  • Setting the Scene: Why Resilience Is Suddenly Everywhere
  • Security vs. Resilience: What Actually Changed
  • Operational Failures Hit Just as Hard as Cyberattacks
  • The CrowdStrike Outage as an Architectural Dependency Problem
  • What Resilience Looks Like in Practice
  • Designing Cloud Architecture to Bend, Not Break
  • Why Compliance Does Not Equal Readiness
  • Lessons from Identity Failures and Diversification
  • Lessons from Ransomware: Coordination and Communication Under Pressure
  • Where a CISO or Engineering Leader Should Start
  • Closing Principles
• Summary

Module 1: Cyber Resilience Is the New Security Baseline

Setting the Scene: Why Resilience Is Suddenly Everywhere

The word “resilience” is now showing up everywhere in the cyber landscape, and it is not a passing buzzword. It is baked directly into formal regulatory and framework language:

• NIST CSF 2.0 — resilience-oriented functions are now built into the core framework structure.
• DORA (Digital Operational Resilience Act) in the EU — a binding regulation for financial-sector operational resilience.
• SEC disclosure rules in the US — requiring public companies to disclose material cybersecurity incidents and their risk-management processes.
• UK operational resilience guidance — regulatory expectations that firms can continue to deliver important business services through disruption.

This is a blunt signal: basic security is now assumed. For years, security programs focused almost entirely on preventing bad things from happening — firewalls, controls, audits, checklists. Those are still necessary, but reality keeps proving that even with all of that in place, things still break: ransomware hits, vendors get compromised, cloud configurations drift.

The question can no longer simply be “are we secure?” The real question is: can your organization sustain its mission when security fails? If that question makes you uncomfortable, the resilience shift is not abstract — it directly affects how organizations design, fund, and prioritize their day-to-day security and engineering work.

mindmap
  root((Why Resilience Now))
    Regulatory Drivers
      NIST CSF 2.0
      DORA (EU financial sector)
      SEC disclosure rules
      UK operational resilience guidance
    Reality Check
      Ransomware still hits
      Vendors still get compromised
      Cloud configs still drift
    New Question
      Old: Are we secure?
      New: Can the mission survive failure?

Security vs. Resilience: What Actually Changed

The last few years have exposed a simple truth: you can have good security and still end up in a bad place. Organizations have invested heavily in prevention, and that investment matters — but prevention alone does not carry an organization through the moments that actually count.

A concrete illustration discussed is the wave of ransomware attacks that hit the UK retail sector. Some of the affected businesses had decent controls in place; they were not negligent or ignoring the basics. But once attackers gained access and systems began locking up, everything came down to continuity:

• Could the business still trade?
• Could stores still take payments?
• Could suppliers still move stock?
• Could leadership communicate clearly and keep customers calm?

That is the core distinction:

Security is about trying to stop something from happening. Resilience is about being able to absorb the hit when it does happen and keep functioning without breaking trust.

Notably, the organizations that handled those incidents well were not necessarily the ones with the fanciest tooling. They were the ones with clarity on what really mattered, who had rehearsed their recovery processes, and whose teams could make decisions under pressure without panicking. Resilience is not a buzzword — it is a recognition that the operating environment has fundamentally changed and expectations have changed along with it.

flowchart LR
    subgraph Prevention["Prevention-Focused Mindset"]
        A1[Firewalls & Controls] --> A2[Audits & Checklists]
        A2 --> A3[Goal: Stop the incident]
    end
    subgraph Resilience["Resilience-Focused Mindset"]
        B1[Know what matters most] --> B2[Rehearse recovery]
        B2 --> B3[Decide under pressure]
        B3 --> B4[Goal: Sustain the mission]
    end
    Prevention -.->|insufficient alone| Resilience

Operational Failures Hit Just as Hard as Cyberattacks

Cloud outages have demonstrated that operational failures can hit an organization just as hard as any cybersecurity attack. Whether the root cause is an availability zone (AZ) impairment, a regional networking issue, or an identity plane outage, the business impact looks the same: customers are locked out, payments stall, and teams get stuck.

The key takeaway is that resilience must cover everything, not just security events — root cause doesn’t matter. If an organization’s architecture cannot handle failure, it goes down regardless of whether the failure originated from an attacker or from an internal fault. Most organizations have far more single points of failure than they realize.

mindmap
  root((Sources of Business-Impacting Failure))
    Security Events
      Ransomware
      Vendor compromise
      Data breach
    Operational Events
      AZ impairment
      Regional networking issue
      Identity plane outage
      Third-party SaaS outage
    Common Impact
      Customers locked out
      Payments stall
      Teams stuck

The CrowdStrike Outage as an Architectural Dependency Problem

A widely discussed real-world example is the CrowdStrike global outage: one bad update glitch propagating through the supply chain from a single security vendor took down endpoints, airlines, hospitals, banks, and governments simultaneously.

This was not bad luck — it was an architectural dependency problem. If a business grinds to a halt because a single security tool glitches, that organization is not resilient, regardless of how strong its security posture otherwise appears. This incident is treated as a case study for concentration risk: a monoculture dependency on one vendor for endpoint protection created a single point of failure across a huge portion of the global economy.

flowchart TD
    A[Single Vendor Update Glitch] --> B[Endpoint Agents Fail Globally]
    B --> C1[Airlines Grounded]
    B --> C2[Hospitals Disrupted]
    B --> C3[Banks Offline]
    B --> C4[Government Services Down]
    C1 & C2 & C3 & C4 --> D[Root Cause: Architectural Dependency, Not Attacker Action]
    D --> E["Lesson: A resilient business shouldn't halt<br/>because one security tool glitches"]

What Resilience Looks Like in Practice

Stripping away the buzzword talk, resilience in practice shows up in how well an organization keeps operating when something important breaks — and that starts with clarity.

Know what actually matters to the business. Not every system is equal, and not every process is mission-critical. Organizations that handled the UK retail ransomware incidents well were not magically immune to attack; they simply had a clear understanding of their “crown jewel” systems — the things that keep the lights on — and they protected and rehearsed around those specifically.

Rehearsal matters more than documentation. The difference between a team that has practiced recovery and one that has not is night and day:

• A practiced team moves with purpose: they know who decides what, who talks to whom, what gets brought back online first, and how to communicate with customers.
• An unpracticed team ends up in well-intentioned chaos — and that chaos is where trust with customers and stakeholders gets lost.

Resilience is not purely technical. It is about leadership clarity, culture, and knowing how to operate under pressure — and it is built through preparation, not paperwork. Once an organization understands what needs to stay standing, it can start thinking about how it stays standing, which is where architecture comes into play. Even a well-run organizational side can be undone by a brittle technical backbone.

flowchart TD
    A[Identify Crown-Jewel Systems] --> B[Map Dependencies]
    B --> C[Rehearse Recovery Scenarios]
    C --> D[Build Decision-Making Clarity]
    D --> E[Establish Customer Communication Playbook]
    E --> F{Incident Occurs}
    F -->|Rehearsed| G[Coordinated Response, Trust Maintained]
    F -->|Unrehearsed| H[Well-Intentioned Chaos, Trust Lost]

Designing Cloud Architecture to Bend, Not Break

From the cloud infrastructure perspective, resilience is about intentional design choices that let systems fail gracefully rather than collapse outright. Practical elements of this approach include:

• Multi-AZ by default — spreading workloads across multiple availability zones as a baseline architecture decision, not an afterthought.
• Multi-region only when the business truly needs it — multi-region adds significant complexity and cost, so it should be reserved for workloads where the business impact of a full regional outage justifies it.
• Graceful degradation — systems designed to degrade in capability rather than collapse entirely when a dependency fails.
• Managed services with well-understood failover designs — leaning on cloud-provider services whose failover characteristics are documented and predictable, rather than hand-rolled failover logic.

The framing question used to guide these tradeoffs: “If this service is down for 30 minutes, what actually happens?” If the answer is “everything stops,” the architecture should reflect that criticality with proportional investment in redundancy. If the answer is that impact is limited, it is reasonable to keep the design simple rather than over-engineering resilience nobody needs.

This same logic mirrors a long-standing approach to backup strategy: the guiding questions are how long can the business tolerate being down, and how quickly does it need to be back up — commonly formalized as Recovery Time Objective (RTO) and Recovery Point Objective (RPO) — and those answers should drive the solution design, not the other way around.

flowchart TD
    A["Ask: If this service is down<br/>for 30 minutes, what happens?"] --> B{Business Impact}
    B -->|Everything stops| C[Invest in Multi-AZ + Multi-Region + Automated Failover]
    B -->|Limited / tolerable| D[Keep architecture simple, avoid over-engineering]
    C --> E[Test failover regularly]
    D --> E

Why Compliance Does Not Equal Readiness

Many teams meet compliance requirements but still struggle during real incidents. The core problem: compliance proves you can fill out the paperwork — it doesn’t prove you can perform under pressure. Most controls in a compliance framework are designed with auditors in mind, not for the moment an organization is actually under attack. During a real incident, the gap between those two realities becomes painfully obvious.

In the UK retail ransomware cases, teams often believed they were prepared because their documentation looked clean — policies existed, plans existed, roles were defined. But none of it had actually been stress-tested. When a plan has never been rehearsed, responders end up trying to interpret a PDF while the business is metaphorically on fire, and that is exactly when hesitation, conflicting decisions, duplicated effort, miscommunication, and tense silence creep in.

Compliance also tends to assume linear, predictable behavior — “if X happens, then do Y.” Real incidents do not work like that: they are messy, involve partial information, emotional pressure, and cascading failures. That requires muscle memory, not checklists.

A related risk is overconfidence: passing an audit can give leaders a false sense that they have closed the risk gap, when in reality they have only closed the documentation gap. The same pattern shows up in cloud environments — beautiful architecture diagrams and recovery plans exist, but no one has ever actually tested DNS replication, IAM failover, or service endpoint failover during a drill. You only know you are resilient if you have tested it.

Tabletop exercises are one practical way to close this gap — they build the muscle memory that real incidents demand. As one framing puts it: if you don’t test your backup plan, you don’t really have a backup plan — you have a backup prayer.

flowchart TD
    A[Compliance Achieved] --> B{Has it been stress-tested?}
    B -->|No| C[Documentation Gap Closed<br/>Risk Gap Still Open]
    B -->|Yes, via drills/tabletop| D[Readiness Gap Closed]
    C --> E[Real Incident Hits]
    E --> F[Hesitation, conflicting decisions,<br/>miscommunication, tense silence]
    D --> G[Real Incident Hits]
    G --> H[Coordinated, confident response]

Lessons from Identity Failures and Diversification

Looking back on the incidents observed over the past year, a recurring pattern emerged: outages triggered by identity failures. In several cases, compute and storage infrastructure were completely fine, but nothing could authenticate — so everything froze regardless of the underlying infrastructure’s health.

• Teams that had fallback authentication, cached tokens, or manual procedures in place were able to stay operational.
• Teams that assumed identity services would simply always work were not.

A second lesson is about diversification — not necessarily multi-cloud, but more foundational diversification: redundant network paths, separate administrative planes, use of regional pairing features (e.g., Azure regional pairs), and simple manual fallback procedures. The most resilient organizations were characterized by flexibility and observability, not by chasing perfect redundancy.

These cloud incidents exposed how much organizations depend on infrastructure they rarely think about directly — identity and authentication being a prime example of a dependency hiding in plain sight.

flowchart TD
    A[Identity Plane Outage] --> B{Fallback Auth / Cached Tokens Available?}
    B -->|Yes| C[Manual procedures kick in<br/>Business stays operational]
    B -->|No| D[Nothing can authenticate<br/>Everything freezes]
    E[Diversification Strategy] --> F[Redundant network paths]
    E --> G[Separate administrative planes]
    E --> H[Regional pairing]
    E --> I[Manual fallback procedures]
    F & G & H & I --> J[Flexibility + Observability<br/>over perfect redundancy]

Lessons from Ransomware: Coordination and Communication Under Pressure

On the cyber side, a related pattern held true across the ransomware incidents discussed. These were well-resourced businesses with mature security teams — but once the attacks landed, everything hinged on their ability to keep trading and communicate clearly.

Organizations that handled these incidents well were not necessarily the ones with the most advanced tooling. They were the ones that already understood what truly mattered to the business — payment systems, store operations, logistics, supplier access — had mapped those dependencies, and had rehearsed what to do if they lost them. When things went sideways, they could move with intent.

Where it broke down for other organizations was usually around coordination and communication:

• Internal teams were not aligned on who was leading what.
• There were delays in telling customers what was happening.
• There was confusion about which systems were safe to bring back online.

That uncertainty amplified the impact of the incident far more than the malware itself did. The core insight: resilience shows up in the moments between the purely technical events — the decisions, the communication, the trust maintained with customers and staff. If those moments have not been practiced, technology alone cannot carry an organization through.

sequenceDiagram
    participant Attacker
    participant Business Systems
    participant IR Team
    participant Leadership
    participant Customers

    Attacker->>Business Systems: Ransomware lands, systems lock up
    Business Systems->>IR Team: Incident detected
    alt Rehearsed / Mapped Dependencies
        IR Team->>Leadership: Clear roles, known priorities
        Leadership->>Customers: Timely, clear communication
        Note over IR Team,Customers: Trading continues on crown-jewel systems
    else Unrehearsed / Unclear Ownership
        IR Team->>IR Team: Confusion over who leads what
        IR Team--xLeadership: Delayed, conflicting decisions
        Leadership--xCustomers: Delayed or unclear communication
        Note over IR Team,Customers: Impact amplified beyond the malware itself
    end

Where a CISO or Engineering Leader Should Start

For a CISO or engineering leader starting from scratch, the recommended starting exercise is simple:

1. Work out what the business absolutely cannot afford to lose. Not everything needs the same level of protection or recovery capability — get clear on the handful of systems and processes that genuinely keep the organization running. This gives a focal point for everything else that follows.
2. Test the organization’s ability to operate when those things are disrupted. Not a scripted tabletop, but a real walkthrough of what happens if a critical system goes down right now: who leads, how decisions get made, how quickly the organization can get to a usable state again. A single honest rehearsal teaches more than a dozen beautifully written plans.
3. Look for the friction. Every test surfaces gaps — in communication, in access, in assumptions about who does what. That friction is the raw material of resilience. Fixing those gaps early means the next rehearsal starts from a stronger baseline.

Frameworks, tools, and maturity models should sit on top of this foundation — not substitute for it.

For an engineering/cloud leader, the parallel starting point is:

1. Start with real dependency mapping, beyond high-level architecture diagrams — list everything systems actually rely on: DNS, identity, third-party APIs, regional limitations, and so on.
2. Prioritize simplicity over complexity. A clean two-region design beats a messy single-region design that tries to do too much.
3. Assume failure as the default design condition — region unavailable, IAM degraded, replication behind — and design so the business can still function, even partially. That partial continuity is resilience.

flowchart TD
    subgraph CISO["CISO / Engineering Leadership Starting Point"]
        A1[1. Identify what the business<br/>cannot afford to lose] --> A2[2. Run a real, unscripted<br/>disruption walkthrough]
        A2 --> A3[3. Capture the friction<br/>and fix it before next drill]
    end
    subgraph Cloud["Cloud / Infrastructure Leadership Starting Point"]
        B1[1. Map real dependencies:<br/>DNS, identity, third-party APIs] --> B2[2. Prefer simple<br/>two-region designs]
        B2 --> B3[3. Assume failure by default;<br/>design for partial continuity]
    end
    A3 --> C[Resilience Foundation]
    B3 --> C

Closing Principles

The discussion closes on two complementary framings of resilience:

Assume failure, and design so that the mission continues. If the business keeps moving when things break, it is resilient.

You cannot buy resilience — you build it. It comes from the way the whole organization thinks and operates, not from a single tool or control. It is a system capability that is part technical, part cultural, and part leadership. If any one of those legs is weak, the whole thing wobbles. But when they are aligned — when an organization knows what matters, rehearses, and tests honestly — it gets an organization that can take a hit and keep moving.

That is the real measure of readiness: not perfection, just the ability to stay in the fight when things go wrong.

Summary

This discussion reframes cyber resilience as the new baseline expectation for security programs — not a replacement for prevention, but a necessary complement to it. The shift is driven by concrete regulatory pressure (NIST CSF 2.0, DORA, SEC disclosure rules, UK operational resilience guidance) and by repeated real-world proof that strong prevention controls do not, by themselves, guarantee an organization can keep functioning when something inevitably goes wrong — whether that “something” is a ransomware attack, a cloud AZ impairment, an identity plane outage, or a single vendor’s bad software update cascading globally (as in the CrowdStrike outage).

Prevention vs. Resilience: Quick Comparison

Key Takeaways

• Security tries to prevent incidents; resilience ensures the mission survives when prevention inevitably fails.
• Root cause does not matter to the business impact — a cloud AZ outage and a ransomware attack can look identical from the customer’s perspective.
• Concentration risk (e.g., a single security vendor’s software update taking down endpoints globally) is an architectural dependency problem, not “bad luck.”
• Compliance proves controls exist on paper; only testing proves an organization can perform under real pressure.
• The organizations that recover well are rarely the ones with the fanciest tooling — they are the ones with clarity on what matters and rehearsed muscle memory for responding.
• Cloud resilience is a deliberate design choice: multi-AZ by default, multi-region only when truly justified, graceful degradation, and managed services with known failover behavior.
• Identity is a frequently overlooked single point of failure; fallback authentication and cached tokens can be the difference between staying operational and freezing completely.
• Resilience is part technical, part cultural, and part leadership — weakness in any one dimension undermines the whole system.

Resilience-Building Checklist

• Identify the handful of “crown-jewel” systems and processes the business cannot afford to lose.
• Map real technical dependencies beyond architecture diagrams — DNS, identity, third-party APIs, regional constraints.
• Design cloud architecture with multi-AZ as a default, reserving multi-region for genuinely critical workloads.
• Build in graceful degradation paths instead of all-or-nothing failure modes.
• Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) per workload based on actual business tolerance for downtime and data loss.
• Run real, unscripted disruption walkthroughs — not just scripted tabletop exercises — to build genuine muscle memory.
• Establish fallback authentication and cached-token strategies for identity plane outages.
• Diversify network paths and administrative planes rather than relying on a single vendor or region.
• Pre-define incident communication ownership: who leads, who talks to customers, and when.
• Track friction points surfaced during every drill and close them before the next exercise.
• Avoid over-engineering resilience for workloads where downtime impact is genuinely low — match investment to actual business criticality.
• Treat passing a compliance audit as closing the documentation gap only, not the risk gap.

Search Terms

security · hot · takes · cyber · resilience · baseline · threat · intel · networking · systems · failures