Every CISO has been in this room. The slides are ready. The risk register has been summarized into something presentable. The scores are color-coded — red, yellow, green — because color is universal. And then a board member asks the question:
“Why is this one red?”
What happens next reveals everything about the quality of the assessment that produced the score.
If the answer is “because it scored a 4.2 on likelihood and a 4.8 on impact based on the control gaps identified in domains 3 and 7 of our assessment framework” — the room has already moved on. Not because the board is unsophisticated. Because that answer has no meaning outside of the framework that produced it.
If the answer is “because the person who sets up new vendors in our AP system can also approve payments to them, and we have no monitoring in place to catch it” — the room understands immediately. Every board member in that room has spent a career thinking about financial controls, accountability structures, and what happens when the same person initiates and approves a transaction. You haven’t translated cybersecurity into business language. You’ve spoken business language from the start.
The difference between those two answers is not communication skill. It is the quality of the inputs that built the score.
Why Most Risk Scores Can’t Be Explained
A risk score is only as explainable as the evidence underneath it. And most risk assessments produce scores that are built on compliance evidence — checkbox answers to framework questions — rather than operational evidence from the business workflows the assets actually support.
When an assessor asks “do you have access controls in place” and records the yes, they have produced a data point. That data point can be aggregated into a score. But it cannot be narrated. “We scored this High because access controls are in place but we couldn’t verify they were functioning” is not a sentence that connects to anything a board member experiences in their day-to-day governance responsibilities.
The score exists. The story doesn’t.
This is not a failure of the scoring model or the framework. It is a structural consequence of asking questions that were designed to produce documentation rather than understanding. Compliance questions produce compliance findings. Compliance findings produce compliance scores. And compliance scores, when brought into a boardroom, require a translator — someone who can take what the framework produced and reconstruct it into language that maps to business risk.
Most CISOs become that translator by necessity. They learn to reframe findings on the fly, to find the business analogy that makes a technical risk legible to a non-technical audience. It is a skill, and it is genuinely valuable. But it is also a workaround for a problem that shouldn’t exist.
The Board Already Understands Risk
Board members are not risk novices. They are risk experts in their own domain.
They understand fiduciary risk. They understand reputational risk. They understand the risk of a key person dependency, or a supplier concentration, or a contract that doesn’t adequately protect the organization’s interests. They have spent careers making decisions under uncertainty, weighing probability against consequence, allocating resources toward the risks that matter most.
What they don’t understand is cybersecurity as a technical discipline. And they shouldn’t need to. The CISO’s job is not to teach the board cybersecurity. It is to connect the risks that live in the technical environment to the categories of risk the board already thinks about.
That connection is easy to make when the assessment was built on business-context questions. It is nearly impossible to make when the assessment was built on framework checkboxes.
A board member who hears “our CRM scored High because a sales rep who has decided to leave can download our entire customer database before anyone in IT knows they’re leaving, and we have no monitoring in place to catch it” does not need a cybersecurity background to understand that finding. They understand customer data. They understand competitive exposure. They understand what it means to have no early warning system for an event that has direct business consequences.
That sentence came from a workflow question, not a compliance question. It exists because an assessor asked a sales operations manager “would you know if a rep exported your full contact database last month” — and the answer was no. The finding is explainable because the input was operational.
What an Explainable Score Actually Requires
Explainability is not a presentation problem. It is not solved by better slides, clearer visualizations, or a CISO who is more comfortable in the boardroom. Those things help at the margin. They do not address the root cause.
An explainable risk score requires three things that most assessments don’t produce:
A finding rooted in business context. Not “inadequate access controls in domain 4” but “the HR system allows managers to see compensation data for employees outside their team because the role model was designed for administrative convenience, not organizational boundaries.” The finding has to describe something that happened in a real system, in a real workflow, with real consequences.
A clear owner. Every explainable risk has a person attached to it — not a system, not a domain, not a control category. “The AP system” is not an owner. “The finance operations team, whose administrator currently has both creation and approval rights in the vendor management workflow” is an owner. The board can ask follow-up questions about a person. They cannot ask follow-up questions about a domain.
A consequence that maps to something the board already cares about. Fraud. Competitive exposure. Regulatory liability. Reputational damage. Operational disruption. Every technical risk has a business consequence. The score should arrive in the boardroom already translated — not as a technical finding awaiting interpretation, but as a business risk with a technical root cause.
The Conversation Changes When the Score Has a Story
When a risk score is built from workflow-level inputs — from questions that asked asset owners to describe how their systems actually behave, who can do what, and whether anyone would know if something went wrong — the boardroom conversation changes fundamentally.
Instead of defending a methodology, the CISO is presenting findings. Instead of translating technical language into business language on the fly, they are narrating a story that was already embedded in the assessment. Instead of answering “why is this red” with a framework reference, they are answering it with a sentence that connects directly to the business risks the board is already accountable for.
The board doesn’t need to speak cybersecurity. The assessment does.
A score that came from “do you have controls in place” will always require an interpreter in the boardroom. A score that came from “can someone in your AP system approve a payment to a vendor they also created, and when did anyone last look at whether that happened” arrives in the boardroom already speaking the board’s language.
That is not a communication strategy. It is an assessment strategy. And it starts long before the slides are built — in the questions that were asked, of the people who know how the business actually runs.