Cyber Resiliency Board Briefing 14: The Hindsight Problem: Why Directors Will Be Judged on the Questions They Asked Beforehand
Every serious cyber incident eventually produces two investigations. The first asks how the attacker got in and what they did. The second arrives later, lasts longer and asks what the board knew, what it asked and what it did with the answers.
That second investigation may be run by a regulator, an cyber insurer, a parliamentary committee, a litigant or the press. Whoever runs it works from the same evidence: board updates, minutes, risk registers and the record of challenge. Sophisticated attacks happen to well-governed organisations, and most reviewers accept that. What they examine is whether the questions asked beforehand were the ones a reasonable director should have asked, and whether anyone followed up on the answers.
This board briefing is about building a record that survives that scrutiny, and about why the questions that matter most concern recovery rather than prevention.
The Minutes Are the Flight Recorder
When an aircraft is lost, accident investigators recover the cockpit voice recorder. Engines do fail, so the failure itself interests them less than what the crew noticed, what the pilots tested, what they said to each other and what they decided in the minutes before. A crew that worked the checklist and made a reasonable call on the information available is judged very differently from one that ignored a warning light.
Board minutes are the board's cockpit voice recorder. After a destructive attack they will be read line by line by people who already know how the story ends. A minute recording that "the Committee noted the cyber update" tells an investigator the board heard something and moved on. A minute recording a director asking how long it would take to restore payroll if the identity platform were destroyed, the answer given, and an action to test that claim, tells a very different story.
Neither minute would have stopped the attack. Only one of them demonstrates oversight.
Hindsight Makes Every Warning Look Obvious
Psychologists call it hindsight bias: once we know the outcome, we overestimate how predictable it was. After an incident, the penetration test finding from eighteen months ago, the unpatched VPN appliance and the backup platform sharing credentials with the domain line up into a neat chain of causation. At the time they were three items among three hundred on a risk register.
Directors cannot remove that bias from the people who will review them. What they can do is show that judgement was exercised at the time, on the information available, and that they sought better information where it was thin.
The regulatory direction makes this more pressing. DORA places ultimate responsibility for ICT risk management on the management body of financial entities. NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures and to undertake training, and allows them to be held liable for infringements. The SEC now requires listed companies to describe how their boards oversee cybersecurity risk. In the UK, the government's Cyber Governance Code of Practice sets out what directors are expected to own, alongside the existing Companies Act duty to exercise reasonable care, skill and diligence. I’ve recently met with Members of the UK Parliament, and it is likely that the upcoming Cyber Resiliency Act will have similar provisions.
How these obligations apply varies by jurisdiction, sector and individual role, so directors should take their own legal advice. The common thread is that accountability now attaches to the oversight itself, and oversight leaves a paper trail.
Green Dashboards Make Poor Evidence
Most board cyber reporting describes prevention: patching compliance, phishing click rates, maturity scores and the number of threats blocked. These measures have their place, but they record activity. A reviewer reconstructing a destructive incident will be asking about capability. Could the organisation operate without its core systems? Did it know which services formed its Minimum Viable Company? Had anyone proven that recovery to a trusted state was possible within a tolerable time, or had the board simply been told so?
A pack full of green indicators can make uncomfortable reading afterwards, because it shows the board was reassured about things that turned out not to matter. It resembles a ship's officers inspecting the polish on the brass while nobody checks the lifeboats. The questions that age well concern survivability: what happens when prevention fails, how long the organisation can endure disruption, and what evidence supports its recovery assumptions.
An Accepted Risk Is a Defensible Answer
Boards sometimes avoid hard questions because they fear the answer will create an obligation they cannot fund. In practice, an informed and documented decision to accept a risk is one of the most defensible positions a board can hold. A risk nobody asked about is one of the least.
If the executive team reports that recovering the trading platform would take three weeks, and the board accepts that exposure for another year with the costs and alternatives in front of it, the record shows judgement. If the same three-week outage is first discovered during the incident, the record shows only absence.
This is why a decision log matters. Each material cyber risk decision should record what was decided, by whom, on what information, which alternatives were considered and when it will be revisited. The same discipline applies in a crisis, when decisions must be taken at speed. A contemporaneous log of who authorised what, and why, is the evidence that accountability survived the pressure.
Assurance Starts With Testing the Assumptions
Every recovery plan rests on assumptions: that backups are clean and isolated from the attacker, that identity can be rebuilt in days, that key suppliers will be available, and that the people who understand the estate will be on hand. Most boards receive these as statements. Few ask when each was last validated, and how.
Assurance worth the name tests the assumptions behind the answer. Every recovery plan rests on a stack of them. The backups are clean. The platform you need to restore onto will be there. The right people will be reachable. The identities you’ll log in with can be trusted. Most are written down once and never challenged. Real assurance goes looking for the ones that break.
In practice, that means four things.
Tests run against real business services. Test the service the business depends on, such as payments, order processing or patient records, not the individual system underneath it. A server that restores cleanly tells you little about whether the service works end to end, in the right order, with all its dependencies.
Independent review of the results. The team that wrote the plan shouldn’t be the only one marking it. Independent challenge of both the scoping and the outcome is what stops a “pass” from meaning “we did what we planned to do.”
Scenarios that reflect reality. A drill that assumes everything except the attacked system is available is a rehearsal, not a test. A realistic scenario removes the platforms you rely on, including the ones your runbooks and contact lists live on. It puts key people under pressure to prioritise many conflicting asks at once, from executives, regulators, customers and the recovery team. And it assumes you can’t trust your security tooling, IT systems or identities. Your EDR, your directory and your admin accounts may all be compromised. My previous Cyber Resiliency Board Briefing was on this topic.
A clear record of what was proven. After every exercise, record which assumptions held, which failed, and which remain untested. Keep it as a living register that shows how confidence is changing over time, not a slide that disappears after the debrief. [LINK: your post on turning exercise findings into improvement]
What Good Looks Like
Boards with a defensible record treat cyber resilience as a standing governance topic, separate from the security update. Their packs carry recovery evidence alongside prevention metrics, including test results against agreed service priorities and the assumptions those tests validated or disproved.
Their minutes capture the substance of challenge, the answers given and the actions agreed. A maintained decision log records material risk acceptances with their rationale and review dates, and a crisis log is ready for use before it is needed. Directors build their own understanding through briefings and exercises, so their questions improve over time.
Most importantly, they ask the uncomfortable recovery questions while the answers can still be acted on.
Questions to Ask Your Executive Team
If our identity platform and core systems were destroyed tonight, how long would it take to restore our most critical services to a trusted state, and how do we know?
Which assumptions in our recovery plan have been validated by testing, and which have not?
Which cyber risks has the board formally accepted, and where is that decision recorded?
Who would maintain the decision log during a crisis, and has it been used in an exercise?
What would a reviewer conclude about our oversight from the last twelve months of minutes?
Closing Thought
No one can promise a board that an attack will not happen. Directors can decide today what the record will show when someone reads it with the benefit of hindsight. The questions asked, the decisions logged and the assumptions tested before an incident become the evidence afterwards, and they remain the cheapest resilience a board will ever buy.
Next briefing
The Evidence Problem: Why Boards See Security Metrics When They Need Proof of Recoverability.
