Outside the Blast Radius: Where Every CISO Must Stand BEFORE the Incident
A CISO’s exposure in a breach is decided long before the breach. Not by how well they handle the incident, but by whether their mandate, their allocation of responsibility, and their board relationship were built while things were still calm. A working guide to positioning the role before you need it, so that when the fire comes, you’re the one running toward it, not the one it’s pointed at.
A long read, built to be returned to. Opinion frames the argument; the evidence is grounded in federal court records in United States v. Sullivan and SEC v. SolarWinds and Brown, current SEC disclosure rules, the EU's NIS2 Directive, and 2025–2026 research from IANS/Artico Search, Heidrick & Struggles, Deloitte, and Accenture.
Two CISOs, two outcomes, and one difference that mattered
In October 2022, a jury convicted Joe Sullivan, Uber’s former chief security officer, of obstruction of justice and misprision of a felony. When hackers stole records on 57 million Uber users and drivers in 2016, while Uber was already under FTC investigation for an earlier breach, Sullivan arranged a $100,000 payment through the bug bounty program, had the hackers sign non-disclosure agreements, and let the incident go unreported to regulators for nearly a year. He was sentenced to probation, not prison. The Ninth Circuit upheld the conviction in March 2025. He remains, as of this guide, the only security executive in the U.S. ever criminally convicted over how he handled an incident.
In October 2023, the SEC charged SolarWinds and its CISO, Timothy Brown, with securities fraud. This time the allegation wasn’t about the response to the 2020 Sunburst breach. It was about what the company had said, in writing, about its security posture before the breach happened, while Brown’s own internal risk assessments allegedly told a different story. A judge dismissed most of the claims in July 2024, but let one survive: the pre-breach “Security Statement.” That single surviving claim hung over Brown for another sixteen months before the SEC finally moved to dismiss it with prejudice in November 2025. A named CISO had spent two years as an individual defendant in a securities fraud case, for something he’d signed off on before any incident occurred.
Read those two cases side by side and a pattern emerges that has nothing to do with how good either man was at incident response. Sullivan’s exposure was created in the room during the crisis: an improvised decision, made under pressure, with no documented mandate for making it. Brown’s exposure was created in a different room, months or years earlier: a public statement about the company’s security posture that his own internal knowledge should have qualified, and didn’t. Different moments, same lesson. By the time the incident happens, your legal and reputational exposure as a CISO has usually already been set. What you do during the fire barely moves the needle compared to what was, or wasn’t, built before it started.
Sullivan’s mistake was made in the crisis, with no mandate to fall back on. Brown’s was made years before the crisis, in a statement nobody had built the governance to properly check. Both prove the same point: the incident is not where a CISO’s exposure gets created. It’s where it gets revealed.
Even the better outcome, Brown’s eventual dismissal, took two years and a federal court case to arrive at. Documentation built in advance is what makes that process faster, or unnecessary.
This guide is about the work that happens in the calm period, so that when the fire comes, it doesn’t come looking for you personally. That means three things done properly, and done before anything happens: a clearly documented mandate that puts real authority behind the CISO title, a mesh of allocated responsibility so the CISO isn’t quietly holding accountability that belongs to legal, comms, or the business, and rehearsed muscle memory so the first hours of an incident run on a plan rather than improvisation. Get those three right and the CISO who walks into an incident room isn’t defending themselves. They’re leading.
02 — THE REAL PROBLEM
It’s a positioning failure, not a technical one
The instinct, every time a breach makes headlines, is to ask a technical question: what vulnerability, what control, what patch. That’s the wrong first question for understanding why CISOs personally end up in the blast radius. The right first question is structural: where did this person sit in the organisation, who else had a documented duty alongside them, and was any of that written down before the incident, or only reconstructed afterward under oath.
Three structural gaps show up again and again, and none of them are new. They’re the same gaps the industry has been describing since the first wave of high-profile breaches over a decade ago, just with sharper legal teeth attached to them now.
The reporting line still runs through the wrong room
According to the 2026 State of the CISO Benchmark Report from IANS and Artico Search, surveying 662 CISOs, 64 percent still report into IT leadership, typically the CIO or CTO, the same executive whose budget and roadmap the CISO is meant to be checking. Only a small minority report directly to the CEO. Deloitte’s research on the same question found organisations where the CISO reports to the CEO experience roughly 20 percent fewer security incidents than those where the CISO reports into IT. The reporting line isn’t a chart-formatting question. It’s a structural conflict-of-interest question that most organisations still haven’t resolved.
The board is worried, and mostly can’t say why
Accenture’s research on board cyber engagement found 82 percent of board members describe themselves as concerned about cybersecurity. Only 38 percent say they actually understand the issue well enough to engage with it substantively. That’s not a knowledge gap the CISO can close with a better slide deck once a year. Ponemon’s research puts the typical board cadence at monthly reporting for only 40 percent of CISOs; for the rest, it’s quarterly, annual, or ad hoc. A board that’s anxious but not literate, briefed rarely and only in summary, is a board that will reach for someone to blame the moment a real incident forces a decision it was never equipped to make.
A board this anxious and this unbriefed isn’t a governance asset in a crisis. It’s a source of pressure the CISO will absorb personally unless the mandate is built to redirect it.
Compliance keeps getting mistaken for security
This is the one truly evergreen finding in the older CISO-accountability literature, and it hasn’t dated a day. An audit committee that has verified regulatory compliance often believes, wrongly, that it has verified security. The two are not the same test, and conflating them is exactly how boards end up shocked that a compliant company was still breachable. The fix hasn’t changed either: independent, adversarial testing that goes beyond the compliance checklist, commissioned and reviewed at board level, not folded into a once-a-year audit sign-off.
The reason this particular gap is so durable is that compliance and security answer different questions, and a board under time pressure will always reach for the one that’s easier to verify. Compliance asks: did we follow the documented process. Security asks: can a motivated attacker still get in regardless. A company can answer yes to the first and no to the second at the same time, and frequently does. The audit committee’s sign-off feels like reassurance precisely because it’s measurable and dated, while the security question is uncomfortable, open-ended, and never fully closed. A CISO who lets the audit committee’s compliance sign-off stand in for a genuine security assessment isn’t managing risk. They’re managing the board’s comfort, and comfort is not the same thing as safety.
Why this matters more now than a decade ago
A decade ago, getting these three things wrong cost a CISO their job. Today, per the SEC’s 2023 disclosure rules and the EU’s NIS2 Directive, getting them wrong can cost a named individual their license to work in the profession, a personal fine, or in Sullivan’s case, a federal conviction. The structural gaps are old. The stakes attached to leaving them unfixed are not.
03 — THE FRAMEWORKMandate, mesh, muscle memory
Here’s the model this guide is built on. Positioning a CISO so they lead a crisis instead of surviving one rests on three things, and like any real framework, they’re cumulative: you can’t substitute rehearsal for a missing mandate, and you can’t paper over a missing mandate with an org chart nobody actually follows under pressure.
Build left to right. A mesh without a mandate has no authority to enforce it. Rehearsal without a mesh just tests who talks over whom.
Mandate is the authority question: does the CISO have a documented reporting line, a board relationship, and a paper trail of risk decisions that were actually escalated and actually signed off, or is authority assumed rather than granted. Mesh is the allocation question: is responsibility for legal notification, public communications, regulatory filing, and business continuity explicitly assigned to named people other than the CISO, with their agreement, or does it all quietly default to security by omission. Muscle memory is the rehearsal question: has the actual plan been tested against a scenario nobody wrote the answer key for in advance, or does it exist only as a document nobody in the room has opened since it was filed.
The rule this model gives you
Don’t ask “do we have an incident response plan.” Ask “if this incident happened tomorrow, could I show a regulator, a plaintiff’s lawyer, or my own board exactly who decided what, and when, going back a year.” If the honest answer involves reconstructing anything after the fact, you have a positioning gap, not a readiness gap.
04 — PILLAR ONE
The mandate
A mandate is not a job title. It’s the answer to a specific question a regulator or a plaintiff’s lawyer will eventually ask: who had the authority to make this decision, and can you show me where that authority was granted.
Fix the reporting line, or document why you haven’t
The CIO-reporting conflict of interest described in the last section isn’t always fixable overnight; budgets, politics, and history are real constraints. But where it can’t be fixed immediately, it has to at least be named and compensated for, through a documented dotted line to the board or audit committee, a standing invitation to present directly rather than through the CIO, and a formal escalation path that doesn’t require the CIO’s sign-off to use. The Deloitte finding, roughly 20 percent fewer incidents where the CISO reports to the CEO, is exactly the kind of evidence a board should want on record when deciding how to structure the role, because it turns “we prefer the current structure” into a decision the board actually has to own.
Build board literacy deliberately, don’t assume it
Given the Accenture finding that most board members are worried but not literate, treating the annual cyber briefing as adequate education is a mistake that compounds. What works instead: shorter, more frequent updates in plain business language, a standing cyber risk item on every board agenda rather than an annual special session, and direct engagement between the CISO and individual directors outside the boardroom, so the first time a board member hears from the CISO isn’t in a crisis. NIS2’s Article 20, now in force across the EU including Germany’s revised BSI Act, has made a version of this mandatory for in-scope companies: management bodies must be trained specifically on assessing cybersecurity risk, not just briefed on it. That’s a floor other jurisdictions haven’t yet legislated, but it’s the right floor regardless of whether your regulator requires it.
Document risk decisions as they’re made, not after
This is the specific lesson from Brown’s case. The claim that survived the initial motion to dismiss concerned a public statement about SolarWinds’ security posture that allegedly didn’t match what internal risk assessments actually said. The defensible position isn’t “never disclose a risk publicly.” It’s “make sure every public or board-facing statement about your security posture is traceable to a documented internal risk assessment that was reviewed and signed off at the time, not reconstructed under subpoena two years later.” A risk register that exists, is actually current, and is reviewed on a real cadence is not a compliance exercise. It’s the paper trail that either protects you or convicts you, depending on whether it exists when someone asks for it.
The mandate test
Ask yourself: if a plaintiff’s lawyer subpoenaed every board presentation and risk assessment from the last eighteen months, would the story they tell match what actually happened, in the order it actually happened? If you’re not certain, that’s this quarter’s work.
05 — PILLAR TWO
The mesh
Sullivan’s case is, at its core, a story about a decision that should never have been his to make alone. Paying hackers, structuring an NDA, and deciding whether that satisfied a duty to disclose to the FTC are legal and business questions dressed up as a security question. He made that call inside the security function, without the documented involvement of the general counsel’s office at the moment it mattered, and it cost him a federal conviction. A properly built mesh exists precisely to stop that kind of decision from ever sitting with one person.
RACI, built before you need it, not during
Every organisation needs an explicit, named RACI for a cyber incident, built and agreed while everyone is calm: who is Responsible for containment, who is Accountable for the decision to notify regulators, who is Consulted from legal and communications before any external statement goes out, who is Informed and when. The RACI arguments and turf wars need to happen in a planning meeting, not in the first hour of a live incident when everyone is exhausted, scared, and reaching for whoever’s in the room. If your incident response plan names roles but not the actual humans who currently hold them, updated at least annually, it’s not a real RACI. It’s a hopeful document.
Pay particular attention to the handoffs the RACI creates, because that’s where Sullivan’s case actually went wrong. Uber had a general counsel’s office, and it had a security function, and the failure wasn’t that either was incompetent. The failure was that the moment a payment to hackers and an NDA started to look like a way of satisfying a disclosure obligation, nobody had a pre-agreed trigger that forced the decision out of security and into legal’s hands, with the CEO informed, before it was executed rather than after. A RACI that only lives in a document and never gets tested against exactly that kind of ambiguous, high-pressure judgment call is a RACI that will fail at precisely the moment it matters most.
Insure and indemnify the person, not just the company
The insurance landscape here has moved, and moved recently. As of the 2023 Heidrick & Struggles Global CISO Survey, 38 percent of CISOs weren’t covered by their own company’s D&O insurance, and another 18 percent didn’t know whether they were. By late 2025, per IANS Research reporting to CSO Online, that gap had narrowed, with just over half of CISOs in the US and Canada now receiving D&O coverage as part of their package, up from 40 percent the year before. But coverage and protection aren’t the same thing. The distinction that matters, as one insurance broker put it plainly, is that the D&O policy is how the company pays to protect its officer, while the personal indemnification agreement is what actually legally guarantees that protection exists. A CISO with a title but no indemnification agreement and no confirmed D&O coverage is carrying personal risk the company hasn’t actually agreed to share.
Understand that delegation of tasks is not delegation of liability
The EU’s NIS2 Directive makes this explicit in a way worth internalising even outside the EU: Article 20 places accountability for cybersecurity risk management directly and non-delegably on the management body, the board and senior executives, not the CISO. A board can delegate the operational work to a CISO or a risk committee, but it cannot delegate away its own legal obligation to approve, oversee, and be trained on the risk it’s accepting. Building your mesh properly means making sure the board understands this distinction before an incident forces a court to explain it to them. A CISO who has quietly absorbed accountability that legally belongs to the board hasn’t protected the board. They’ve just made themselves the more convenient person to blame.
The mesh test
Pick any major incident decision, notify the regulator, pay the ransom, disclose to customers, and ask who besides the CISO is named, in writing, as accountable for making that call. If the honest answer is “just the CISO,” the mesh doesn’t exist yet, whatever the org chart implies.
06 — PILLAR THREE
Muscle memory
A mandate and a mesh that only exist on paper are a liability disguised as a defence, because a plan nobody has tested collapses on exactly the details that matter most once real pressure hits. This is the pillar that turns documentation into something the organisation can actually execute under stress.
Tabletop the plan against a scenario you didn’t write the answer to
Research from incident response firms running these exercises converges on the same finding: the gaps a tabletop exercise reveals are almost never technical. RedLegg’s analysis of hundreds of client engagements found the most common failures involve communication protocols, decision-making authority, and financial tracking during an incident, not tools or technology. The design mistake most organisations make is running a tabletop that hands the team a clean, clearly-labelled scenario, “your EDR detected ransomware on one endpoint,” which lets everyone simply look up the right runbook. Real incidents arrive as ambiguous anomalies and partial information. A tabletop worth running deliberately introduces the escalation contact being unavailable, an assumption about backups turning out to be wrong, or two executives disagreeing about the call, because those are the failure modes that actually happen at 2am during a real one.
Pre-build the materiality determination, don’t invent it live
The SEC’s cybersecurity disclosure rule, in force since December 2023, requires public companies to disclose a material incident on Form 8-K within four business days, but the clock starts from the determination of materiality, not from discovery of the incident. That distinction is exactly where the next Sullivan-style mistake will happen if it isn’t pre-built: an organisation that hasn’t defined, in advance, who determines materiality and by what criteria will be tempted to simply delay the determination itself, which is precisely the kind of concealment-by-another-name that got Sullivan convicted. The fix is to document, before any incident, the specific people, the specific criteria, and the specific timeline for making a materiality call, so that when it matters, the process is followed rather than improvised under the same pressure that produces bad decisions.
Log decisions as they happen, not as they’re remembered
Every incident response plan should include a mandatory, contemporaneous decision log: who decided what, on what information, at what time, reviewed and initialled by someone other than the person making the call. This sounds bureaucratic until you read the Ninth Circuit’s account of Sullivan’s case, where a key piece of evidence against him was an email he sent a year after the incident still describing the hackers as “unauthorized,” directly undercutting his later legal argument. Memory reconstructed after the fact, especially under legal pressure, is exactly what gets used against you. A decision log built in real time is the difference between a documented, defensible process and a story someone has to piece back together while a prosecutor watches.
The muscle-memory test
Run a tabletop in the next quarter that nobody on the response team has seen in advance, and specifically design it to break an assumption they’re relying on. If the exercise confirms the plan without surfacing a single gap, it wasn’t rigorous enough to have told you anything.
07 — THE GOVERNANCE PROBLEM
Still unresolved, now with sharper consequences
If there’s one thing that genuinely hasn’t changed since the earliest CISO-accountability writing a decade ago, it’s this: the industry still hasn’t settled who’s actually supposed to own the risk of the CISO’s own exposure, and the regulatory environment has made the cost of that ambiguity far higher.
CISO tenure data tells its own version of the story. Hitch Partners’ 2026 survey found average current tenure varies sharply by company size: just 28 months at organisations under 500 employees, against 47 months at mid-market firms, a 40 percent gap that tracks almost exactly with how under-resourced and under-scoped the role is at smaller companies. Other industry surveys put average tenure closer to 26 months. Whatever the precise number, the pattern is consistent: the CISO role churns faster than almost any other C-suite function, and burnout, ambiguous authority, and personal exposure are consistently named as the drivers, not a shortage of technical talent.
The regulatory backdrop has, if anything, made under-positioned CISOs more exposed rather than less. NIS2 has expanded the number of regulated entities in Germany alone from roughly 4,500 to an estimated 29,000, bringing many mid-sized companies into a personal-liability regime for the first time, often without having built the governance to match. The SEC’s Item 1.05 and Item 106 disclosure requirements remain in force even after the SolarWinds dismissal, and the SEC has said publicly it repurposed part of its enforcement capacity specifically toward fraudulent cybersecurity disclosures. The SolarWinds outcome was, as one commentator put it, a reprieve for one CISO, not a pardon for the pattern of individual liability the case established.
What actually works
The organisations that get this right treat the CISO’s own positioning as a governance item in its own right, reviewed by the board on a cadence, not assumed to be fine because nothing has gone wrong yet. That means an annual review of the CISO’s reporting line and authority, an annual confirmation of D&O coverage and indemnification terms with the CISO present in the conversation, and a board that has explicitly acknowledged, in writing, that its own NIS2- or SEC-style obligations can’t be quietly delegated away to the security function. None of this is expensive. All of it requires the board to stop assuming positioning is the CISO’s problem to solve alone.
The other thing that actually works, and it costs nothing beyond honesty, is a board that asks the CISO directly, at least once a year, some version of the question this guide keeps returning to: if something went wrong tomorrow, are you positioned to lead the response, or are you exposed to become its story. A CISO who can answer that clearly, with reference to a documented mandate, a named mesh, and a recently tested plan, has told the board something more useful than any technical metric on a dashboard. A CISO who hesitates, or answers only in terms of tools and controls, has just handed the board its next governance priority, whether or not either side has said so out loud.
The governance test
Ask your board when it last reviewed the CISO’s reporting line, insurance coverage, and documented authority as a standing governance item, rather than reacting to a headline about someone else’s CISO. If the honest answer is “never, on our own initiative,” that’s the gap this whole guide is about.
08 — THE PRACTICAL BASELINE
Build this before you need it
This is the working checklist, organised by pillar, to run through in the calm period rather than during an incident.
Pillar one: the mandate
Is our reporting line documented and, if it still runs through IT, has that conflict been explicitly named and compensated for with a dotted line to the board or audit committee?
Does the board receive cyber updates on a real cadence, in plain business language, or only in an annual session most directors can’t meaningfully engage with?
Is every public or board-facing statement about our security posture traceable to a current, signed-off internal risk assessment, or could a regulator find a gap between what we said and what we knew?
Pillar two: the mesh
Does our incident RACI name actual current humans, not just roles, updated at least annually, for containment, notification, and external communication?
Is the CISO personally covered by D&O insurance and a signed indemnification agreement, confirmed directly with them rather than assumed from the corporate policy?
Has the board explicitly acknowledged which obligations it cannot delegate to the CISO, in line with frameworks like NIS2 Article 20, rather than assuming security owns all of it by default?
Pillar three: muscle memory
Have we run a tabletop exercise in the last twelve months designed to break an assumption, rather than confirm a runbook the team already knows?
Have we pre-defined who determines materiality for disclosure purposes, and by what criteria, so that call isn’t improvised under pressure during a live incident?
Does our incident response process require a contemporaneous decision log, reviewed by someone other than the decision-maker, rather than relying on memory reconstructed afterward?
How to use this list
Work through the mandate questions first. A mesh built on top of a missing mandate has no authority behind it, and rehearsal without either just practises the wrong instincts more confidently. Fix pillar one this quarter, whatever else is on the roadmap.
09 — THE HONEST CLOSE
What positioning can’t promise you
I won’t claim this framework makes a CISO bulletproof. It doesn’t, and anyone who tells you otherwise is selling something. Sullivan was a respected, experienced security executive; Brown ran the security programme at a major infrastructure vendor. Expertise alone didn’t protect either of them. What protects a CISO is whether the mandate, the mesh, and the muscle memory were built and documented before anyone needed them, so that a bad outcome traces back to a genuinely hard call made under real ambiguity, not to a missing authority, an undocumented decision, or a plan nobody had rehearsed.
That distinction, between judgment exercised under a real mandate and improvisation performed without one, is the same one running through the whole of this series. The future-of-work guide argues that the durable human skill AI can’t replace is judgment under ambiguity, exercised by someone with real accountability for the outcome. The IoT guide argues that the connected estate’s real vulnerability was never the device, it was the absence of clear ownership across the system built around it. This guide argues the same thing about the CISO role itself: the position, not the person, is what has to be engineered for resilience, and the engineering has to happen before the pressure arrives, not during it.
There’s a harder truth underneath all three guides, and it’s worth naming plainly here. Judgment, ownership, and mandate are all, in the end, forms of documented trust: a board trusting a CISO enough to grant real authority, a CISO trusting the mesh enough to let go of decisions that were never theirs alone, and an organisation trusting a rehearsed plan enough to follow it under pressure rather than improvise around it. None of that trust can be manufactured in the moment a crisis starts. It either already exists, built and tested while things were calm, or it doesn’t, and everyone in the room discovers the gap together, in public, while a regulator or a plaintiff’s lawyer watches.
The incident doesn’t create a CISO’s exposure. It reveals whether the mandate, the mesh, and the rehearsal were ever actually built. By the time the fire starts, that work is either already done, or it’s too late to start.
Don’t fire the CISO after a breach, and don’t let the CISO quietly absorb accountability that was never theirs to carry alone either. Build the mandate this quarter. Name the mesh in writing, with the people in it agreeing to their part before anything happens. Rehearse the plan against a scenario designed to break it, not confirm it. Do those three things while it’s still calm, and the day the fire actually comes, the CISO in the room is running the response, not defending the decisions nobody gave them the authority or the support to make well.
Outside the Blast Radius: Where Every CISO Must Stand Before the Incident
The opinions here are a point of view; the guidance is grounded in the Ninth Circuit's March 2025 opinion in United States v. Sullivan, the SEC's October 2023 complaint and November 2025 dismissal in SEC v. SolarWinds Corp. and Timothy G. Brown, the EU's NIS2 Directive (Article 20) and Germany's revised BSI Act, the SEC's Item 1.05 and Item 106 cybersecurity disclosure rules, and 2025–2026 research from IANS/Artico Search, Hitch Partners, Heidrick & Struggles, Deloitte, Accenture, Ponemon Institute, and RedLegg. Figures are directional and current as of 2026; legal outcomes are cited as of the date reported and may be further appealed or amended. This guide is the third in a three-part set, alongside The Fork in the Road on AI and the future of work, and Past The Device on securing IoT in the age of autonomous systems: the same thread runs through all three, that durable value now sits in documented judgment and clear ownership, built before the pressure arrives, not improvised once it does.
Report
There was a problem reporting this post.
Block Member?
Please confirm you want to block this member.
You will no longer be able to:
See blocked member's posts
Mention this member in posts
Invite this member to groups
Message this member
Add this member as a connection
Please note:
This action will also remove this member from your connections and send a report to the site admin.
Please allow a few minutes for this process to complete.