CISA Tested Two SOCs. Only One Had an Incident Response Plan That Held.

Same red team, same week, two very different outcomes#

A fox does not need to catch every scent in the hedgerow. It only needs to notice the one that matters before the trail goes cold. That is the entire lesson buried inside a dry-sounding advisory the Cybersecurity and Infrastructure Security Agency (CISA) published on 25 August 2026, and it is worth far more attention than its bureaucratic title suggests.

Advisory AA26-237A, "A Tale of Two SOCs", describes two simultaneous red team assessments CISA ran against two real critical infrastructure organisations using near-identical tradecraft. Nothing here was a criminal breach. Both engagements were authorised, both were mapped to the MITRE ATT&CK framework, and both organisations knew testing was underway. What differed, sharply and instructively, was what each security operations centre (SOC) did once the red team walked through the door.

Organisation A sat in the Government Services and Facilities Sector. Organisation B sat in the Water and Wastewater Systems Sector. CISA gave both a false name in the public advisory, but it gave every reader something far more useful: a paragraph-by-paragraph account of exactly how each SOC's incident response plan performed, or failed to perform, under live pressure. CISA's own companion release frames the whole exercise as a chance for other critical infrastructure operators to test their incident response plan against a real playbook rather than a tabletop guess, and The Hacker News's coverage of the advisory reached the same conclusion within hours of publication.

Read that chart the way a fox reads a hedgerow at dusk: the gap between the two organisations was never about budget or brand-new tools. Organisation B used the same commercial endpoint detection and response (EDR) software any mid-sized enterprise could buy. The difference was whether anyone had trained it to bark at the right scent.

This advisory did not describe two lucky guesses. Every incident response plan on paper looks roughly identical, listing the same standard incident response steps of detection, containment, eradication and recovery. CISA's contribution is showing precisely where, between those steps, two otherwise comparable organisations parted ways.

How Organisation A lost the trail completely#

CISA's red team got into Organisation A through a web application still carrying default credentials, a detail so ordinary it barely registers as tradecraft. From there they sent phishing emails from a trusted internal address and gained a foothold on four workstations.

From those four machines the red team used a customised BloodHound collector, quietly modified to dodge static EDR signatures, to map the entire Active Directory forest: users, computers, group memberships, access control lists, group policy objects. They found a Machine Account Quota of ten still sitting at its default, which let them mint a rogue computer account, and a misconfigured Active Directory Certificate Service template (the ESC1 flaw documented in SpecterOps' Certified Pre-Owned research) that let them request a certificate for practically any account in the domain, privileged ones included.

From full domain compromise the team moved on three separate sensitive business systems, using a different credential trick against each: cleartext passwords sitting in plain view on an admin's workstation, a decrypted developer-tool config file, and long-lived Amazon Web Services identity keys that had never once been rotated. They finished by compromising Organisation A's Microsoft Entra ID tenant, stealing a primary refresh token, and using it to read the mailboxes of the very SOC staff meant to be hunting them, purely to confirm nobody had noticed. Nobody had.

The advisory's own verdict is blunt: "the organization did not respond effectively to red team activity". SOC staff received medium- and low-severity alerts tied directly to the intrusion and never actioned a single one, because thousands of false positives from ordinary business operations, many rated more severe than the real alerts, buried the signal in noise every single day.

How Organisation B's incident response plan held#

Organisation B's opening chapter reads almost identically. The same red team, spearphishing from harvested public email addresses, got three users to click a malicious link and landed on three workstations. That is the entire advantage Organisation A ever had: one extra compromised machine.

The difference started within minutes. Each payload triggered a medium-severity alert, "an executable file loaded an unexpected DLL file", and Organisation B's SOC staff triaged and isolated all three workstations in ten, two and twenty minutes respectively, killing the red team's command-and-control before real damage could spread. Forced into an assume-breach model, the red team still eventually reached a domain controller, one sensitive business system, and a bastion host sitting inside the operational technology demilitarised zone. Every single one of those moves also tripped an alert, and every one was actioned.

Organisation B was not flawless. The red team still reached Entra ID through a Seamless SSO service account that carried no multi-factor authentication and excessive application permissions, and CISA's writers note the organisation had plaintext operational technology credentials sitting on a jump server. Good incident response readiness is not invulnerability. It is noticing fast enough that invulnerability stops being the point. That distinction matters more in the Water and Wastewater Systems Sector than almost anywhere else: it is one of sixteen sectors CISA designates as critical infrastructure precisely because an undetected compromise there stops being a data story and starts being a public safety one.

Why the same playbook produced two outcomes#

CISA's own lessons-learned section names three causes, and none of them is a tooling gap folkfox's clients could buy their way out of by Friday.

This is the part that should unsettle every marketing leader reading over a CISO's shoulder, not just the security team. An incident nobody notices for weeks does not stay a technical problem. It becomes the story a journalist tells, the line a competitor's paid social team quietly bids against, and the sentence a prospect remembers three renewal cycles later. Brand trust and incident response readiness are the same asset measured from two different desks.

Set against a worldwide median dwell time of fourteen days, reported in Mandiant's M-Trends 2026, or a mean identify-and-contain time of 247 days in IBM's 2026 Cost of a Data Breach report, twenty minutes stops looking like a lucky afternoon. It looks like the outcome a properly tuned incident response plan is actually supposed to deliver. Verizon's Data Breach Investigations Report has tracked this same gap for years: the tools rarely fail first, the process around them does.

Building an incident response plan that survives contact#

CISA's mitigations section reads less like a compliance checklist and more like a punch list any resourceful team could start this quarter. None of it requires the budget of a Fortune 100 SOC. It requires the discipline Organisation B already had and Organisation A did not. NIST's revised SP 800-61 now folds incident response planning into its five-function Cybersecurity Framework, and every one of CISA's key actions maps neatly onto the Detect and Respond functions specifically, which is exactly where this advisory shows the real gap sat.

The pattern across every recommendation is the same: detection is a discipline, not a purchase order. A tool that fires ten thousand alerts a day and gets tuned by nobody protects exactly nothing, and CISA's own case study proves it inside a single advisory rather than a hypothetical.

For any regulated brand folkfox works with, whether the sector is fintech, healthcare or straight cybersecurity vending itself, the marketing consequence of an undetected intrusion is rarely the intrusion. It is the six weeks of silence that follows it, and the story a competitor tells about that silence before you do. A tested incident response plan is not just a security asset. It is a communications asset nobody prices correctly until they need it.

This is also, quietly, a content opportunity. A security vendor that can show its own red-team results, its own detection times, its own honest gaps the way CISA just did for Organisation B, earns more trust in a single case study than a year of generic content marketing claiming to be "proactive" and "best in class". Specific numbers, sourced and dated, beat adjectives every time this checker has ever measured it.

Frequently asked questions#