When something goes wrong - a breach, an audit finding, a vendor failure the board is now aware of — the forensic review doesn't start with the attacker. It starts with the decisions that preceded the incident. What was the security posture at the time? What risks were known? What was done about them? Who approved the direction that was taken?
Most technology leaders assume their exposure in that conversation is bounded by whether they acted in good faith. What the last few years of cybersecurity enforcement established is that good faith isn't the question. The question is whether the decisions made before the incident were reasonable, and whether there's documentation that demonstrates it.
Two Cases. One Lesson.
In 2022, Uber's former Chief Security Officer was convicted on two federal charges for concealing a breach from regulators who were actively investigating a prior incident at the same company. He was sentenced the following year to three years' probation. The breach itself was not the crime. The decision to conceal it — made after the fact, with knowledge of the regulatory context — was what created the criminal exposure.
In 2023, the SEC charged SolarWinds and its CISO with civil fraud for overstating the company's security posture in public disclosures while the CISO was internally aware of conditions that contradicted those statements. The case was ultimately dismissed in November 2025. But before it was dismissed, a federal court found one claim strong enough to survive: that the CISO knew the company's public security representations misrepresented the actual internal state of the program.
The lesson from both cases isn't really about regulatory exposure for public companies. It's that a security leader knew conditions internally that contradicted what was being communicated externally — and didn't disclose, escalate, or correct it. The breach was the trigger. The exposure came from the gap between what was known and what was said.
The Question That Follows Every Incident
After something breaks, there are two conversations. The first is technical — what happened, how it happened, how to contain it. The second is governance — what decisions were made before it happened, what information those decisions were based on, and whether the people who made them can demonstrate they acted reasonably given what they knew.
The second conversation is the one most technology leaders aren't prepared for. Not because they made bad decisions, but because the decisions weren't documented in a way that holds up to scrutiny from someone who wasn't in the room. The vendor was selected because the demo was compelling and the references checked out. The contract was signed because legal reviewed the terms. The security architecture was designed by the same provider selling the components.
None of that is necessarily wrong. But none of it is independently documented — and none of it answers the question a board, an insurer, or opposing counsel will eventually ask: what did you know, what did you consider, and why did you decide what you decided?
What Defensible Actually Means
Defensible doesn't mean the decision was right. Organizations with mature security programs get breached. Defensible means the decision was made through a process that was independent of the vendors selling into it, benchmarked against available alternatives, and documented in a way that survives scrutiny after the fact.
The most common failure isn't a bad decision — it's no record of the judgment behind it. The documentation gap tends to show up in three specific places: what was communicated to the board about security posture, and whether that communication reflected what was actually known internally; what risks were documented and whether they were formally escalated; and what the basis was for significant vendor decisions — whether alternatives were genuinely considered, and whether the rationale exists anywhere other than the memory of the people who made the call.
Four Questions to Ask Right Now
You don't need a breach to run this assessment. These are the questions that will be asked after one:
- Can you produce documentation showing what options were considered for your last major security vendor decision — not a comparison the vendor provided, but an independent evaluation?
- What risks are currently documented internally that haven't been formally escalated to the board or disclosed in relevant insurance applications?
- For your most significant security contracts, can you demonstrate that the terms you accepted reflect what protections are standard in the market — not just what the vendor proposed?
- Who owns the record of why security decisions were made — and does that record exist somewhere other than the people who made them?
If the answers to those questions are unclear, the exposure isn't the next breach. It's the conversation after it.
When the Decision Can't Be Traced
The governance conversation after an incident often traces back to the same point: what did you buy, why did you buy it, and what did you rely on to make that call? The security vendor landscape is large, the sales process is sophisticated, and the people most qualified to evaluate the options are frequently the same people selling them — an MSSP designing the architecture it also operates, a vendor supplying its own reference customers and comparison materials.
None of that means the decision was wrong. It means the decision was made inside an information ecosystem with an interest in the outcome and without independent validation at the time, there's no way to demonstrate otherwise after the fact.
If your board is asking how a security decision was made and the honest answer is that it rested primarily on vendor-provided information, that's the gap independent advisory exists to close before the incident creates the urgency, not after.
