Imagine a CISO on a Sunday night. A core identity service is down. A clinic's staff cannot reach the patient system. The fallback exists on paper, but no one has tested it under pressure. Last month's board packet rated the risk green.
That isn't a resilience surprise. It is a reporting failure.
The board packet has to do more than summarize what the security team completed. It must make a business decision visible while there is still time to act.
After two decades in cybersecurity leadership, I have watched polished heat maps sit beside open questions no one has owned. A dashboard can show a high rate of completed reviews and still leave directors unable to see what may fail, how that failure reaches a service, or which executive can change the exposure.
A color is not a decision.
Start with a scenario the business recognizes
Show one specific path from a technical weakness to a business interruption. If a core identity provider is unavailable, which service stops? Can staff use a tested alternative? How long can the business operate without that system? Who is affected first?
A patient waiting for a refill does not experience “identity risk” as a category. They experience a clinic that cannot retrieve the information needed to help them.
Describe the service, the dependency, the likely consequence, and the evidence behind your confidence. If the fallback has not been tested, say so. Do not let a green status imply certainty that the team has not earned.
Put a decision next to every material risk
For each top risk, state the choice that remains open. The executive team may need to fund a fix, change an operating process, accept exposure for a defined period, or stop a risky activity. Make the request explicit. Name the person who can make the call and the date by which it is needed.
If leadership accepts a risk, record who agreed and when that decision expires. If nobody has accepted it, do not describe it as accepted. Unassigned risk is not accepted risk. It is nobody's decision.
The board does not need every incident ticket. It needs to know which decision cannot wait for the next quarterly meeting.
Make green require evidence
Every status change should answer a simple question: what changed since the last review? A control may be newly installed. A recovery test may have passed against a defined target. A supplier may have removed privileged access. Put the evidence beside the claim, with an owner and date.
A tabletop can show that people know whom to call. It cannot prove a system can be restored. A vendor attestation can describe a provider's controls. It cannot prove that your own integration has a working failover path.
Set the condition for green before the review. If the condition is “recovery tested within the last year,” show the test date and result. If the evidence is missing, say “unknown.” That is more useful than an optimistic color.
Use board time for decisions
At the next review, I want to see the few risks that could interrupt a critical service, the decision each one needs, and the owner who will bring back proof of progress. I want to see when an accepted exposure expires. I want a direct explanation when a rating improves.
The board can fund a control, set a risk tolerance, or direct management to return with better evidence. The CISO's job is to make those choices legible, including the cost of doing nothing. A risk report should leave leaders clearer about what they own, not merely more informed about what the security team tracks.
The report itself will not stop an attacker. But it can expose a weak recovery plan before a patient pays for it.
That is the shift I am watching this quarter: from color-coded reporting to accountable decisions with dates and proof. Fellow CISOs and board members, what evidence makes you comfortable moving a cyber risk from amber to green?
Lekshmy Sankar, PhD