Incident Response is a Muscle — And Most Organisations Are Atrophied

The Operating Assumption That Failed at Medibank, Synnovis, and Change Healthcare

The cybersecurity industry has spent two decades training organisations to believe that incident response is a teachable, practisable muscle—but treating it as such has become the confession of systematic architectural defeat.

When Optus suffered the 2022 breach exposing 9.8 million customer records, the post-mortem centred on response speed: intrusion detection took three weeks. When Medibank fell to the LockBit affiliate in 2022, the narrative focused on dwell time and visibility gaps. When Synnovis (the NHS pathology provider) was encrypted by LockBit in June 2024, NHS England's review demanded faster detection and escalation protocols. When Change Healthcare was struck by BlackCat in February 2024, hitting RCTI systems across hundreds of US healthcare providers, the regulatory aftermath (FDA, OIG, state attorneys general) fixated on response time windows and communication cadence. The industry's response? Deploy more SIEM. Hire IR specialists. Run tabletop exercises. Conduct purple team assessments. Invest in SOAR playbooks. Fine-tune alert tuning. Adopt NIST CSF Incident Response function controls. Tighten ISO 27035 incident handling procedures.

All of this is operationally correct, and systemically useless.

The muscle analogy itself is the trap. Muscles atrophy because they are not used—or because they are used inefficiently and then removed from service. But the IR muscle is not atrophying because organisations are sedentary. It is atrophying because the environment in which it operates has already been compromised before a single alert fires. The industry narrative mistakes operational recovery time for security. It is not the same thing.

The Industry Narrative: Faster Response as a Control

The canonical incident response doctrine rests on a well-known tripod: Detection → Investigation → Containment → Recovery. This is the architecture of every NIST CSF Incident Response control, every ISO 27035 maturity model, every SANS Incident Handler's Handbook. The baseline assumption is sound: if you detect a breach faster, investigate it more methodically, contain it more rigorously, and recover more swiftly, damage is limited.

The evidence from recent major incidents suggests this assumption has inverted.

Optus 2022: Attackers accessed credentials and database dumps for 9.8 million customers. The breach occurred in September; detection happened in mid-September; disclosure began in October. The attack method? Exploitation of publicly documented API weaknesses (CVE-2020-5410 in Spring Cloud Config, allowing unauthenticated access to configuration data containing credentials). The post-incident review found that Optus had not patched the vulnerable endpoint; intrusion detection systems (Cisco Tetration, Splunk Enterprise Security) were configured but noise-filtered into ineffectiveness. Faster detection would have discovered the same problem—that the foundation was permeable. The response, however swift, could only exfiltrate and contain. The architecture had already failed.

Synnovis / NHS June 2024: LockBit 3.0 affiliate encrypted NHS pathology infrastructure, disrupting blood testing across London and the South-East for weeks. Initial intrusion was likely via weak or compromised RDP credentials (common LockBit ingress vector across CVSS 9+ vulnerabilities in internet-facing management interfaces). The NHS review, published by NHS England's Data Security and Protection Toolkit, documented: no network segmentation between pathology systems and administrative networks; no immutable backup copies offline; no zero-trust access controls on legacy Windows systems. The response was technically competent (power-down affected systems, isolate segments, stand up workarounds). But the breach was inevitable given the perimeter-defence architecture. Detection speed was irrelevant; the system had already chosen to be broken.

Change Healthcare 2024: BlackCat/ALPHV exploited a known Citrix Bleed vulnerability (CVE-2023-4966, CVSS 9.9) in internet-facing appliances. The ransomware disabled Change Healthcare's telephone systems, then encryption systems, affecting medication dispensing, claims processing, and payment handling across US healthcare. The intrusion dwell time was approximately 48 hours before encryption began. The company's SEC 8-K filing and subsequent OIG correspondence revealed: no zero-trust network segmentation; shared credentials across critical systems; backup infrastructure accessible from the same network perimeter; no air-gapped recovery capacity. The FBI coordinated response, CISA issued emergency directive 24-02, and HHS threatened regulatory action under HIPAA. Change Healthcare recovered, but only because BlackCat chose ransom payment over destruction (a criminal business decision, not a security win). Faster detection would have been academically interesting. The architecture was surrendered on day one.

These are not anomalies. They are the predictable outputs of a security posture built on the assumption that breach response is a substitute for breach resistance.

The Structural Failure: Detection as Theatre, Response as Triage

The industry's investment in incident response infrastructure reflects a rational but inverted priority model. Organisations build:

— SIEM platforms (Splunk, Elastic Security, Cribl, Datadog) to ingest and correlate millions of events per second, then deploy analysts to distinguish signal from noise.

— EDR solutions (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Rapid7 InsightIDR) to monitor endpoint behaviour and apply YARA rules, Sigma rules, and MITRE ATT&CK mappings post-execution.

— SOAR orchestration (Palo Alto Cortex XSOAR, Splunk Phantom, Rapid7 InsightConnect) to automate playbooks: "if alert type X with severity Y, then execute playbook Z."

— Threat intelligence feeds and commercial breach databases to contextualise detections against known threat actor techniques.

— Incident response plans (tabletop exercises, call trees, escalation matrices, communication protocols) to ensure response is practised and rehearsed.

All of this is architecturally sound if the perimeter is defended. But the perimeter has not been defended at scale since 2015. The threat model has shifted from "external attacker tries to break in" to "external attacker breaks in (almost always through misconfigurations, unpatched internet-facing services, or credential compromise), then moves laterally across a flat network with administrative privileges and no real-time visibility into their actions."

Consider the geometry: a SIEM must process event streams from thousands of endpoints, routers, firewalls, and cloud services. CrowdStrike Falcon processes over 100 trillion events per day globally (2023 report). Splunk processes similar scale. The noise-to-signal ratio at most organisations is between 1,000:1 and 10,000:1. An analyst can investigate roughly 10–20 alerts per day competently. The mathematics are unambiguous: you cannot hire your way out of a detection problem that is fundamentally a structural problem.

The response, once initiated, is also constrained. A CISO or IR lead, faced with active encryption spreading across critical systems (as in Synnovis or Change Healthcare), has three moves: isolate (segment the network, shut down systems), wipe and rebuild (rebuild from clean backups), or pay and negotiate (ransomware), or accept the loss. None of these moves is "incident response mastery." They are triage options on a patient who is already in trauma. The muscle being exercised is not prevention; it is damage limitation. And damage limitation, once the perimeter is breached, is always incomplete.

The Architectural Inversion: From Response to Resistance

The PULSE doctrine inverts this priority entirely. Rather than design for rapid response to inevitable breaches, we design for breach resistance via architecture—and then, if resistance fails, for containment and recovery that requires no detection at all.

This requires three principle shifts:

Zero-Knowledge Substrate

The adversary cannot exfiltrate what does not exist in exploitable form. Traditional architecture stores plaintext or weakly encrypted data in databases or data lakes, assumes the perimeter holds, and then deploys DLP (Data Loss Prevention) rules—Symantec DLP, Digital Guardian, Forcepoint—to detect when that data is moving across the boundary.

A zero-knowledge substrate inverts this: data is encrypted at the source (before it reaches storage), encrypted in transit, and remains encrypted at rest. Decryption keys are held by different administrative domains or hardware security modules; no single system can decrypt the full dataset. Access is cryptographically mediated—the system grants temporary, domain-specific decryption rights based on real-time policy (time-bound, role-bound, context-bound), never monolithic keys.

When an attacker gains database access (as happened at Optus and Medibank), they encounter encrypted blobs. When they compromise a user workstation (as in Change Healthcare), they do not inherit global decryption capability. When they pivot laterally (as in Synnovis and NHS systems), they move through segments they cannot read—not because a firewall blocks them, but because the data plane is cryptographically impermeable.

Data-Plane / Control-Plane Separation

The control plane (authentication, authorisation, key management, policy enforcement) and the data plane (application logic, storage, computation) must be administratively and cryptographically independent.

Most organisations run both on shared infrastructure: a single Kubernetes cluster hosts application workloads and security tooling. A single Active Directory instance manages both user credentials and system access. A single HSM (Hardware Security Module) holds encryption keys. An attacker who compromises the control plane—a Kerberos vulnerability, an LDAP injection, a PKI trust anchor—gains leverage over the entire data plane.

In a properly separated architecture, compromise of the control plane does not grant access to data. The data plane enforces its own cryptographic boundaries; the control plane can revoke policies, but cannot decrypt historical data. Recovery from control-plane breach is administrative (reissue credentials, re-establish policies) rather than cryptographic (since the data plane never trusted the control plane absolutely).

Adaptive Adversarial Posture

Rather than rely on static rules (YARA, Sigma, Snort) to detect known attacks, we design for continuous adversarial posture adjustment. The system changes its configuration, network topology, cryptographic material, and API behaviour unpredictably and frequently—not in response to detected attacks, but continuously, ahead of observed threat.

This is the inverse of "purple teaming." Instead of blue team defending a static network against red team attack, the network itself is the moving target. An attacker mapping the network topology on Monday finds it altered on Tuesday. API endpoints shift. Encryption keys rotate. Access control lists rewrite. Not because a SIEM alert triggered, but because the system was engineered for continuous drift.

This requires domain-specific primitives built into the infrastructure—not bolted on via SIEM/SOAR—and managed through policy engines that execute at the data-plane layer.

Operational Consequences: What Changes

If an organisation adopts these principles, the incident response team's role fundamentally changes—and in most cases, shrinks.

Detection becomes irrelevant for common attacks (lateral movement, credential misuse, data exfiltration) because the architecture makes these attacks ineffective. The IR team's focus shifts to adversarial complexity: not "did someone break in?" but "what did they do, and how did we know it was abnormal?"

Response becomes isolation and audit, not containment. If a system is breached, the administrator isolates it (removing it from the network), but does not need to assume the adversary has read-access to the full dataset. Recovery is cryptographic and fast: reissue keys, rebuild from immutable backups, rotate secrets. No forensic triage of "how far did they get?"

This is not theoretical. It reflects the operational model of organisations managing sovereign-grade infrastructure—banking system operators, national security infrastructure, high-frequency trading firms—where breaches are assumed and architecturally contained.

Regulator Implications: DORA, NIS2, and the Shift

Recent regulatory frameworks (EU Digital Operational Resilience Act [DORA], NIS2 Directive, FCA's Senior Managers & Certification Regime [SM&CR], SEC 4-day breach disclosure rules, APRA's CPS 234 for Australian banks) are beginning to recognise that incident response time is not a meaningful control. DORA's "significant operational or security incident" reporting requirements (Article 19) do not ask "how fast did you detect it?" They ask "what was the impact?" and "what structural failures did it expose?"

The regulatory trend is toward resilience-by-design (DORA Articles 6–18) rather than response-by-procedure. NIS2's emphasis on "resilience" across operators of essential services (Article 1) and "supply chain risk" (Article 21) signals that regulators no longer accept that "we had a good incident response" is sufficient if the perimeter was indefensible to begin with.

Organisations investing heavily in SIEM, EDR, and IR hiring in 2024 are not preparing for NIS2 and DORA. They are preparing for regulatory failure.

The Closing Frame: Capability vs. Compliance

The cybersecurity industry has built an entire economy on the assumption that response is the primary control. Consulting firms size engagements on "how many incident response drills can we conduct?" Vendors measure success on "alert time to containment." Compliance frameworks reward "incident response plan" checklists.

None of this addresses the architectural question: could this breach have been made ineffective before detection?

If your answer is no—if an attacker gaining database access, Kubernetes cluster access, or domain administrator credentials can still read plaintext or weakly protected data—then your incident response team is not a muscle. It is a prosthetic limb replacing a missing architecture.

The organisations that will meet DORA, NIS2, and evolving regulator expectations are not the ones with the fastest IR cycles. They are the ones that make breaches irrelevant through architecture.

---

If you operate critical infrastructure or hold data that requires sovereign resilience against adaptive threat, we invite qualified teams to request a technical briefing under executed Mutual NDA.