Draft for Tamir's review. Not published.
Containment is where the review starts
Ask for a timeline reconstructed from evidence, from the first signal to full recovery. The causes should cover detection and recovery as well as the trigger. If a review blames one operator or one vendor, ask which access, alerting and design factors were examined.
Each corrective action needs an owner, a date and a test that shows it worked. Ask whether the same weakness exists elsewhere in your systems. A forward fix alone leaves the people already affected, so ask who reviews and corrects past cases.
Who checks the fixes
The incident report is usually written by the team that ran the systems, or by the vendor whose system failed. Have the key changes verified by someone outside that team before you call them closed.
If a vendor caused it, service credits are its cheapest response. Demand the root cause in writing, preventive changes with dates and the right to verify them. Then look at your own fallback, because that part is yours.
Depending on your seat
If you're on the board, your decisions are the ones reserved for you: ransom position, disclosure, major communications and the response lead's authority. Ask for open items with owners and dates, and a report until they close. Also ask which smaller incidents stayed below your reporting threshold.
If you're the CEO and the board asks whether to replace IT leadership or the provider, start elsewhere. Get an account from someone who was not responsible for preventing it. Judge people on the decisions they were asked and funded to make. Assurance that it will never happen again is a promise nobody can make; assurance that known gaps are closed and monitored is.
What to check before you decide
- Ask for the entry path or trigger, and evidence that it is closed, verified by someone other than the responders.
- Ask why detection took as long as it did, and why recovery took as long as it did.
- Ask for each corrective action's owner, date and the test that proves it worked.
- Ask whether the same weakness exists elsewhere in your systems.
- Ask for the record of notifications to regulators, customers and insurers, and their timing.
- Ask what remains open, with owners, dates and the risk while it stays open.
- If a vendor caused it, read the contract for remedies beyond service credits.
Questions people ask
Audit committee received management's report that a cyber incident was handled well, how do we know it's true?
Ask for the evidence behind three statements: how the attacker got in and whether that path is closed, how long detection took and why, and what was changed since with proof. A report that answers those with logs and dates can be accepted; one that answers with adjectives cannot. It depends on whether anyone outside the response team has verified the changes.
Audit committee got management's outage report with a root cause and actions, how do we judge whether it's enough?
Check three things: whether the timeline is reconstructed to the minute from evidence, whether the causes cover detection and recovery as well as the trigger, and whether each action has an owner, a date and a test that shows it worked. A report missing any of those is incomplete. It depends on whether the outage involved vendors and on what the regulator expects to see.
A ransomware attack is under way, what is the board's role during the incident?
The board's role is the decisions that are the board's: payment questions, disclosure to regulators and markets, major customer and public communication, and the authority of the response lead. Everything else stays with management. Set a short update rhythm and a single point of contact. It depends on the company's disclosure obligations and on what the incident response plan assigns to the board.
Regulator opened an inquiry after our customer systems failed, how does the board prepare its own account of what it knew?
Reconstruct what the board received about the systems, resilience and incidents before the failure, and what it decided; then identify where it could have asked more. An honest account with changes already made serves the board better than a defensive one. It depends on what the board papers show and on what the inquiry asks about governance.
Our members' data was breached and management reported the response, what should the board require beyond the response?
Require the cause with evidence, the changes that close it with verification by someone other than the responders, the regulatory and member communications record, and a review of where else the same weakness exists. Then a reporting routine until the changes are verified. It depends on how the breach happened and on what the regulator's follow-up requires.
A security incident exposed our customers' prompts and data, what should the startup board require beyond containment?
Require the cause with evidence, the fixes verified by someone outside the team, the customer notifications and their timing, and the controls that would have prevented it: access, logging, data retention, environment separation. Then a plan to the certification customers will now demand. It depends on how the incident happened and on what customers' contracts require.
What should directors ask when a refinery incident review blames one operator?
Require an explanation that tests contributing controls and conditions. Useful closure depends on reproducible causes, evidence for rejected alternatives, and actions that address more than individual behavior.
Should an audit committee investigate technology incidents management did not escalate?
Review both the incidents and the rules that kept them out of view. The response depends on cumulative impact, repeated causes, and obligations assessed with relevant assurance and legal owners.
What should public oversight require after software applies the wrong service rules?
Require management to establish the affected scope, correction responsibilities, and evidence that the underlying rule is now applied correctly. A forward fix alone does not resolve historical impact, while legal and service owners must determine appropriate resident remedies and communications.
Our public online service failed after launch and I must explain it to a committee, how do I find out what happened quickly and credibly?
Build a short timeline from the decision to launch to the failure, with who decided what and on what evidence, and name the three causes with the fix for each. Committees accept a clear account with dates and owners. It depends on whether the failure was technical, a launch decision made against evidence, or a missing operational readiness.
A vendor outage stopped our clinics for a day and they offered credits, what should I demand instead?
Demand the root cause in writing, the changes that prevent a repeat with dates, and the right to verify them; credits are the vendor's cheapest response. Then check what the fund itself could have done to keep clinics working, because that part is yours. It depends on what the contract gives you beyond credits and on whether the clinics had any fallback.
After a breach the board asks if I should replace IT leadership and the service provider, how do I decide fairly?
Get an account of the breach from someone who was not responsible for preventing it: how it got in, why it was not detected, why recovery took as long as it did, and which of those were decisions versus bad luck. Then judge people on the decisions. It depends on whether the failures were in things they were told to do and did not, or in things nobody had decided.
After a cyber incident at our plant the board wants assurance, what can I give them with a straight face and how do I get it?
Give the board three things: what happened and why, what has been changed since, and what remains open with dates and owners. Assurance that it will never happen again is a promise nobody can make; assurance that the known gaps are closed and monitored is. It depends on how the incident got in and on whether the fixes were verified by someone other than those who made them.
How I can help with this decision
- Ask or talk (Free)
- I give my view on what to ask for in your incident's account, and which parts of such reports usually lack evidence.
- Review (Pay if it was worth it)
- I write an independent post-incident assessment of the cause, the fixes and the remaining exposure, in a form the board can rely on. I recommend what to accept, what to require and what to monitor.
- Retain (When it makes sense)
- I stay available until the open items close, reviewing management's evidence before each board or committee update.