A technical risk can be described accurately and still arrive at leadership in a form that is difficult to use.
I see this most often when the specialist work has done its own job properly. A paper explains the vulnerability, control weakness, audit finding or supplier problem. It gives the issue a severity, describes remediation and may include a target date.
By the time it reaches the person who owns the operational or investment decision, there can be plenty of information about the technical condition and very little about the choice that follows from it.
My starting point is the decision the organisation may need to make. The technical language can remain precise. What needs adding is the context that makes the technical position governable.
I want to understand which part of the organisation depends on the thing we are discussing, what could happen if it fails or degrades, how much of that consequence the organisation is prepared to tolerate, what evidence supports the current position and what somebody actually needs to decide.
Financial consequence belongs in that discussion when it can be supported. If it cannot, I would rather leave the cost unquantified than manufacture a number simply because pounds look more relevant in an executive paper.
Start with the operation
A technical severity tells me something useful about the technical issue. It does not tell me enough about the organisation.
Take an illustrative weakness in a shared identity service.
The security team may have good reasons for treating it as serious. The leadership question begins with what depends on that service. If staff access to a critical business process relies on it, the discussion changes. We can now start examining what happens to that process if access is disrupted, what alternatives exist and how quickly the operational effect becomes material.
The technical finding has not changed. We have simply connected it to something the organisation is trying to keep running.
That connection is often more useful than trying immediately to turn the finding into a financial figure.
Sometimes the operational consequence will have a clear commercial effect. A delayed service may affect customers. An unavailable system may stop an organisation fulfilling an obligation. A control problem may constrain a planned change or create difficulty answering an important assurance question.
Those effects should be included where they are real. They should not be added simply to make every technical issue sound commercial.
Make tolerance usable
Risk appetite is useful at organisational level, but a live decision usually needs something more concrete.
The relevant tolerance might be the period a service can be unavailable before a workaround becomes ineffective. It might be a minimum level of capability that has to remain available during recovery, or a condition that needs to be satisfied before an activity proceeds.
There are also situations where nobody has actually agreed the tolerance.
That is not a reason to hide the gap. It may be the most important part of the briefing because defining the boundary becomes part of the decision.
I would much rather put “the business has not agreed how long this process can operate in degraded mode” in front of the responsible leader than disguise the uncertainty behind a red risk rating.
The first statement can be acted upon.
Show why you believe the current position
The next part of the translation is evidence.
A briefing should tell the decision-maker enough about the basis of the conclusion to understand how much confidence to place in it.
If the position is supported by a recent test, say so. If it relies on indirect evidence, supplier assurance or an assumption that has not yet been tested in the organisation’s environment, that matters too.
This becomes particularly important when a risk is being accepted or an expensive change is being deferred. Two situations can carry the same technical severity while giving leadership very different levels of confidence about what will happen under load.
The NCSC’s current Cyber Security Toolkit for Boards makes a related point. It connects technical assets to organisational objectives, describes cyber risk management as a way to improve decisions and cautions against using risk metrics without sufficient context. Its purpose is broader than the method described here, but the governance logic is consistent: the number or rating is useful only when the people making the decision understand what it means for the organisation.
Evidence also needs a date and a boundary.
A recovery test performed eighteen months ago tells me something different from one completed against the current environment. A supplier certificate can be useful evidence without proving every assumption we have made about our own ability to continue operating if that supplier fails.
The briefing does not need to contain the entire evidence pack. It does need to be clear about what the conclusion is based on and what remains uncertain.
Be careful when translating risk into money
Security professionals are often encouraged to make cyber risk more relevant by expressing it financially.
There are situations where that is exactly the right thing to do.
If the organisation has credible information about transaction volumes, contractual exposure, recovery costs, operational throughput or another measurable consequence, a financial estimate can improve the decision. The assumptions behind the estimate should remain visible.
The problem comes when technical precision is replaced by financial precision that does not actually exist.
A critical severity does not automatically become a credible six-figure loss. A probability selected from a risk matrix does not become financially reliable because somebody has multiplied it by a large impact number.
That kind of translation may look more commercial while making the evidence weaker.
When I cannot support a financial figure, I would rather describe the consequence accurately and identify the missing information. Sometimes that produces another useful decision: whether the potential exposure is important enough to justify better quantification before the organisation accepts it.
The same discipline applies to strategic consequences. If the issue could genuinely obstruct a customer commitment, planned acquisition, product launch or other significant activity, include that. If the relationship is speculative, leave it out.
Leadership needs an honest account of the consequence, not a larger one.
Put the actual decision on the page
The final step is the one that is surprisingly easy to miss.
What does somebody need to decide?
A briefing can contain a strong assessment, sensible remediation and good evidence while leaving the decision implicit.
“High risk. Remediation recommended.”
That tells me the specialist position. It does not tell me whether leadership is being asked to approve investment, accept continued exposure for a defined period, change the way an activity is delivered or set a tolerance that has never previously been agreed.
The decision also needs an owner.
That does not mean leadership should approve every security action. Most technical decisions should remain where the expertise and delegated authority sit.
Escalation becomes useful when the consequence or trade-off has moved beyond that delegated authority.
An illustrative decision statement might therefore say that the organisation is being asked to continue using a service until a planned control improvement is completed, with the current evidence unable to demonstrate recovery inside the operational tolerance already agreed for the dependent process.
That is a very different conversation from “the service is high risk”.
Leadership can now challenge the tolerance, ask whether the evidence is sufficient, change the timing, approve the exposure or require another course of action.
There is something to govern.
Better translation should make decisions easier
Good governance does not require every senior leader to reproduce the specialist assessment.
The NCSC Cyber Governance Code places critical governance actions with directors, while its supporting Board Toolkit is intended to help leadership and technical specialists have useful discussions about cyber risk.
In practice, that means the technical work still needs to be available and the specialist remains accountable for its accuracy. The leadership view can be smaller because it is answering a different question.
Before I take a technical risk upwards, I want the paper to make the operational dependency and credible consequence clear. It should also state the relevant tolerance, show the evidence and remaining uncertainty, and make the decision explicit. If any of that is missing, I usually have more work to do before the meeting.
Good translation keeps the technical truth intact while making the resulting decision easier to govern.
Decision-Ready Risk Briefing
Download the one-page briefing template for shaping technical risk into decision-ready leadership information.