Giving Executives What They Need to Make Risk Decisions
Security teams have more data about exposure than ever. But somewhere between the scanner and the boardroom, much of the context that makes that data useful gets stripped away.
Executives do not need another vulnerability list, risk score, or heat map. They need to understand what is exposed, what it means for the business, and what decision needs to be made.
01 What Executives Need From Exposure Reporting ▾
What Executives Need From Exposure Reporting
A useful executive risk discussion has to preserve enough context for leadership to understand the exposure, challenge the assumptions behind it, and decide what to do about it.
That means moving beyond a single status or score. The seven practices below turn technical exposure into the business context, evidence, tradeoffs, and recommendations executives need to make a decision.
Connect Exposure to Business Functions
Describe Realistic Attack Scenarios
Communicate Likelihood
Express Business Impact
Present Response Options
Define Residual Risk
Make a Recommendation
A simple test: Could an executive who disagreed with your conclusion reconstruct how you reached it and identify the input they would challenge? A stoplight fails that test.
The goal is to preserve the decision inputs. Simplify the technical detail without compressing away the reasoning leadership needs to act.
With those inputs preserved, exposure reporting becomes something leadership can actually interrogate and act on. The challenge is building each one from evidence rather than judgment.
That starts by connecting technical exposure to the business function it can actually affect.
1. Connect Exposures to Business Functions
Most exposure reporting starts from the asset inventory and works outward toward relevance. Reverse the direction of travel.
Sit down with the CFO and COO and build a list of eight to twelve business functions by asking one question: what has to keep working for us to make money, serve customers, and stay compliant this quarter? Order-to-cash. Claims adjudication. Plant scheduling. Payroll. Customer onboarding. Clinical documentation. Trade settlement. These are things the executive team already has opinions about, budget lines for, and named owners over.
Then trace each function downward through everything it depends on, the applications that run it, the identities that can change it, the cloud services and network paths that reach it, the third parties that touch it. Those are domains within your attack surface rather than surfaces of their own, and one business function depends on all of them at once, so an exposure in any of them is an exposure to that function.
Two things fall out of this exercise, and both are more useful than the ranked vulnerability list you started with.
- Concentration. Six of your twelve critical functions turn out to depend on the same identity provider, jump host, or over-privileged service account. Forty findings on one unremarkable server suddenly outrank four hundred spread across a lab environment, and you can say why in a sentence.
- Orphans. Systems nobody claims, running processes nobody documented, still authenticating to something that matters. These are the assets that will not appear in any risk register organized by owner, because they have none.
The output is a service-to-exposure register: a living map from each named business function to the exposures that materially affect it, with the executive who owns that function named on the row. That last column changes the conversation more than anything else on the page. Risk is now attached to a person whose objectives depend on the function continuing to work.
One exposure, two owners
One exposure, in one domain, reaching two functions with different owners.
Applications, identity, network and third parties are domains within the attack surface, not peers of it — and a single business function usually leans on several at once. Mapping downward from the function is what surfaces concentration: here, one service account carries two unrelated functions, so a third-party exposure becomes a payroll problem too.
One discipline to hold throughout: an exposure earns its place on this register through its connection to a function, not through its severity score. Severity helps you sequence work within a function. It does not decide what reaches the board.
“I’ve gone into some organizations, right? And… and evaluated risk and to me this was high risk-based on the different people I talked to and they got actually the true business leaders in there and they go actually we know about this and actually it’s marked lower because we know this over here and you’re like I didn’t know about that.”
Jeff MooreCISO at H&MSee it in the transcript at 9:49 · How a CISO Protects Billion-Dollar Brands → 2. Describe Realistic Attack Scenarios
Business-function mapping tells the room what is at stake. It does not tell them how a bad day begins. That requires a scenario: a specific, defensible narrative of how an attacker gets from outside to a business consequence.
A usable scenario has five parts:
- Entry – how they get in
- Escalation – how they obtain the privileges the objective requires
- Movement – how they reach the systems that matter
- Objective – what they are trying to accomplish: encryption and extortion, wire fraud, data theft, sabotage
- Consequence – what stops working, for whom, and for how long
Write the first four in the language of adversary behavior; MITRE ATT&CK gives you and your team a shared vocabulary that survives translation, and the fifth in the language of the business.
Three rules keep scenarios credible.
- Include only steps you can evidence, and label the evidence. A scenario assembled entirely from tier four is fiction. One with a tier-one spine and tier-three shoulders is testimony.
- Tier one: validated ourselves through a penetration test, purple team exercise, or attack path analysis.
- Tier two: observed in our own telemetry.
- Tier three: reported in the wild against organizations like us.
- Tier four: theoretically possible, untested.
- Say what you do not know. “We validated the first three steps in February. We have not tested whether our endpoint controls would interrupt step four; that exercise is scheduled for October.” An executive who hears you name the limits of your own evidence will believe the parts you sound confident about.
- Bring two or three scenarios, not twenty. One developed scenario with real evidence behind it moves budget; a catalog of twelve thin ones moves nothing.
Here is what one looks like written out:
Order-to-Cash Disruption
How the Scenario Unfolds
Evidence Behind the Scenario
Where Response Options Change the Outcome
A scenario built this way does more work than a thousand-row spreadsheet because every step connects technical evidence to a business consequence, and every assumption can be challenged under questioning.
3. Communicate Likelihood Without Pretending Certainty
“High likelihood” sounds informative, but it leaves the most important part unstated: how likely? One executive may hear “high” and think the scenario is slightly more likely than not. Another may hear it and assume there is an 80 percent chance it happens this year. Both leave the meeting believing they understood the risk.
State likelihood as a frequency over a defined horizon instead: we estimate a 45 to 65 percent chance of Scenario A occurring at least once in the next twelve months.
For Scenario A, that estimate should be built from evidence the room can examine:
- Exploitability. Does a working public exploit exist? Is the vulnerability listed in CISA’s Known Exploited Vulnerabilities catalog? What does its EPSS score suggest about exploitation activity? These inputs are external, checkable, and change over time.
- Reachability. Is the entry point exposed to the internet, or does exploitation require an existing foothold? In Scenario A, the vulnerable MFT appliance is internet-facing, and the path from it toward the ERP has already been validated.
- Adversary interest. Are groups actively using this technique or targeting organizations like yours? Threat intelligence should change the estimate when the threat environment changes.
- Control efficacy. When you tested the scenario, did your controls actually interrupt it? Validation turns “we have endpoint detection” into evidence about what happens when an attacker follows this particular path.
The result is still an estimate, not a prediction. Give a range and characterize your confidence in it: “We estimate a 45 to 65 percent annual likelihood, with moderate confidence. The attack path is validated; adversary activity and control performance account for most of the remaining uncertainty.”
That is more useful than false precision, and much more useful than a label alone.
Annual Likelihood of Scenario A
Same scenario. Three very different ways to communicate its likelihood.
A range communicates both the estimate and its uncertainty. “High” communicates neither. Two people can agree on the label while leaving the same meeting with materially different probabilities in mind.
Resist one more temptation: do not multiply likelihood by impact into a single risk number early in the conversation. That is the stoplight again. Keep the two visible and separate for as long as the decision allows, so the room can argue about the right variable.
4. Express Impact in Units the Business Already Uses
Impact reported as “severe” fails for the same reason. Denominate it in whatever your CFO already tracks (revenue, throughput, days, contractual exposure) and decompose it rather than presenting one large number.
A workable loss estimate usually has four or five components:
- Interruption. Revenue or throughput lost while the function is down. Take the daily figure the business already reports and multiply it by a realistic recovery duration from your last restore test, not from the RTO in your policy document.
- Response. Incident response retainer, forensics, overtime, outside counsel, notification and monitoring services.
- Obligation. Regulatory notification, SLA credits, customer make-goods, disclosure requirements where they apply.
- Recovery. Rebuild effort, replacement infrastructure, and the migration you planned for two years from now, compressed into two months.
- Consequence. Churn, deal slippage, insurance repricing, and the remediation commitments your largest customers will extract afterward.
You will not get these exactly right, and exactness is not the objective. Ranges are. “Four to eleven million dollars, with the width driven almost entirely by recovery duration, which we have assumed at five to twelve days based on our last full ERP restore test taking six days against a smaller dataset.”
Now the room can attack the assumption. That is precisely the conversation you want, and it is where the funding for a better backup architecture comes from, not from a red square, but from a CFO who decides that a twelve-day tail is unacceptable to him.
Structured quantification methods such as FAIR are useful here, and worth studying. But you do not need a formal quantification program to get most of the benefit. You need the discipline the method encodes: decompose the loss, use ranges, state your assumptions out loud.
5. Present Response Options and Their Tradeoffs
A CISO who brings one course of action has brought a request, not a decision. Bring three or four real options, and make one of them “accept and monitor” described as neutrally as the others, because sometimes it is the correct answer and the room needs to see that you know that.
Describe every option using the same fields:
- What it changes about the scenario – name the specific step it breaks.
- What it costs you – money, headcount, elapsed time.
- What it costs the business – process friction, downtime windows, delayed roadmap, vendor commitment.
- When it takes effect – a control that helps in nine months is not an answer to a scenario that is live today.
- What it leaves behind – the residual, covered next.
Group options by what they do to the attack chain, because that is the tradeoff executives can reason about without security expertise:
Naming the step each option breaks makes an uncomfortable fact visible: three inexpensive options may leave the scenario entirely intact, while one expensive option ends it. That is a legitimate business tradeoff, and executives are well equipped to make it once they can see it.
Finally, distinguish the instance fix from the root cause. Patching the appliance closes this scenario’s front door. Fixing the process that allowed an internet-facing system to authenticate with a domain-wide service account closes the next twelve doors before anyone opens them. Boards will fund root causes when you show them the recurrence rate; you force them to fund instances forever when you do not.
“You have to be very, very selective in terms of what where you want to approach your your controls and how to apply it. Given the fact that all of us are concerned about budgeting and what we can do.”
Al Imran HusainCISO at MillerKnollSee it in the transcript at 4:24 · How AI Has Elevated the Path to Compromise in Manufacturing → 6. Explain Residual Risk as a Deliverable, Not a Disclaimer
Residual risk is usually the sentence at the bottom of the slide that nobody reads. It deserves to be the most carefully written paragraph in the package, because it describes what the organization is actually choosing to live with.
State it in the same units as the original estimate:
Residual Risk Decision Record
Segmentation confines encryption to the ERP tier while backups remain recoverable. The scenario becomes less likely to produce a widespread business interruption and the expected loss falls with it.
What we are still choosing to live with
Scenario A is not eliminated. An attacker with a novel exploit against the replacement appliance could still reach the ERP. In that event, we expect to detect and contain the activity within 24–48 hours rather than prevent it outright.
Segmentation completes by January and standing privileges are not restored under release pressure.
A network merger, control regression, or material change in exploit activity requires the estimate to be rebuilt.
If an assumption fails or likelihood materially increases, bring the residual risk back to the committee rather than carrying forward the old acceptance.
Three things separate an honest residual statement from a decorative one.
- Name the assumptions it rests on. “This assumes the segmentation project completes by January, that the service account cleanup holds, it has been reverted twice by application teams under release pressure, and that restore times match our last test.”
- Name what would invalidate it. “If we acquire another business unit and merge its network before segmentation completes, this estimate is void. If a wormable exploit appears against the replacement product, likelihood returns to the original range and I will bring this back to the committee.”
- Name the owner. Residual risk belongs to the executive who owns the business function, not to the CISO. Security owns the analysis, the options, and the recommendation. It does not own the decision to accept. Making that explicit in the memo and in the minutes is not defensive bureaucracy. It is what turns acceptance into a real business decision rather than something the security function quietly absorbs on everyone’s behalf.
Then set a review date. Residual risk accepted in March under one set of assumptions is not still accepted in November when three of them have changed.
7. Make a Clear Recommendation
Every step above can be executed well and still fail at the end, because the CISO declines to say what they think.
The reluctance is understandable. Recommending is accountable. But a room of executives who are not security experts is poorly served by neutrality from the one person who is. You did the analysis. Say what you would do.
Recommend Option 2
It breaks the privilege path, not just the individual vulnerability.
That also addresses the six similar exposures identified on other integration systems rather than closing Scenario A one instance at a time.
Where the Recommendation Changes Scenario A
If segmentation slips beyond the January change window, revisit the decision. The interim exposure remains meaningful enough that I would return with a bridging option rather than carry the current risk through another quarter.
Recommendation, reasoning, cost, residual, owner, and the condition that would change your mind, under two hundred words.
Two habits strengthen it. First, say what you would do if it were your own money; it forces you to weigh cost as seriously as risk. Second, say what you are not recommending, and why. “I am not asking for the full identity overhaul this year. It is the better long-term answer, but it is an eighteen-month program, and it does not change this scenario in this fiscal year.” Restraint you volunteer is credibility you spend later.
And when you are overruled, you will be, sometimes correctly, because executives see cost pressures and strategic commitments you do not; document the decision rather than the disagreement. Record the option chosen, the residual accepted, the owner, and the review date. Then move on. The CISO who takes a “no” cleanly is the one who gets a “yes” next time.
“I have definitely been in a position where I’ve thought whatever the solution was, it was the right thing for the organization. Some of those didn’t go because of pure cost. Some were just the effort it was going to take across multiple teams to deliver on these things, where the business, evaluating the two, decided, hey, can we do something a little less heavy, a little less impactful, but still get there?”
Ken LawrenceCOO at Lighthouse Credit UnionSee it in the transcript at 15:39 · From Protecting the Business to Running It → What It Looks Like on One Page
The analysis behind an exposure decision may be extensive. What reaches leadership should not be.
A decision-ready exposure brief should preserve the seven inputs that matter while moving the supporting technical detail to an appendix. The result is something an executive can understand quickly without losing the reasoning behind the decision.
Seven Inputs. One Decision.
That is the standard: leadership should be able to reconstruct the decision from the page. If someone disagrees with the recommendation, they should be able to point to the function, scenario, evidence, estimate, option, or assumption they disagree with.
And the format should stay consistent. Use the same structure quarter after quarter, and the conversation shifts from how many findings did we close? to how has exposure to the business actually changed?
The Stoplight Was the Symptom
There is nothing inherently wrong with putting a red, yellow, or green indicator on a board slide. The problem is when the color becomes the analysis instead of the summary of it.
A useful status has something underneath it: a business function, a realistic attack scenario, evidence, likelihood and impact, response options, residual risk, and a recommendation. Without those inputs, leadership is being asked to accept security’s judgment. With them, leadership can challenge the assumptions, weigh the tradeoffs, and make a decision.
That is the difference between reporting security activity and communicating risk in a form the business can act on.
Turn Exposure Into Decisions. Turn Decisions Into Risk Reduction.
See how TrollEye connects business context, exposure prioritization, validation, and remediation into a continuous process for reducing risk.
Frequently Asked Questions
Why is a red, yellow, or green status not enough for executive risk reporting?+
A stoplight is a summary, not an analysis. The color is only useful when something sits underneath it: the business function at stake, a realistic attack scenario, the evidence behind it, likelihood and impact stated separately, response options, residual risk, and a recommendation. Without those inputs, leadership is being asked to accept security’s judgment. With them, leadership can challenge the assumptions and make an informed decision.
What makes an exposure report decision-ready?+
Seven inputs: exposures tied to business functions, a realistic attack scenario, likelihood expressed as a frequency over a defined horizon, impact denominated in units the business already tracks, three or four response options with their tradeoffs, an honest residual-risk statement, and a clear recommendation. The test is whether leadership can reconstruct the decision from the page. If someone disagrees, they should be able to point to the function, scenario, evidence, estimate, option, or assumption they disagree with.
How do you decide which exposures reach the board?+
Through their connection to a business function, not their severity score. Start with the eight to twelve functions the CFO and COO already have opinions about — order-to-cash, claims adjudication, payroll, customer onboarding — and trace each one down through the applications, systems, and identities it depends on. Severity still helps you sequence work within a function. It does not decide what reaches the board.
How should likelihood be communicated without pretending to certainty?+
As a frequency over a defined horizon rather than a label. “High” means slightly more likely than not to one executive and an 80 percent chance this year to another, and both leave the meeting believing they understood the risk. A stated range — a 45 to 65 percent chance over the next twelve months — can be argued with. Resist collapsing likelihood and impact into a single risk number early in the conversation. Keep the two visible and separate for as long as the decision allows, so the room can argue about the right variable.
How should the impact of an exposure be quantified?+
In whatever units the CFO already tracks — revenue, throughput, days, contractual exposure — and decomposed rather than presented as one large number. “Severe” fails for the same reason “high” does. A workable loss estimate usually has four or five components, starting with interruption: the revenue or throughput lost while the function is down, built from the daily figure the business already reports.
Should a CISO present options or make a recommendation?+
Both. A CISO who brings one course of action has brought a request, not a decision, so bring three or four real options and describe each one with the same fields — including “accept and monitor,” described as neutrally as the others. Then say what you think. A recommendation fits in under two hundred words and covers reasoning, cost, residual risk, the owner, and the condition that would change your mind. Saying what you are not recommending, and why, makes it stronger.
How should residual risk be handled?+
As a deliverable, not a disclaimer. It describes what the organization is actually choosing to live with, so it belongs in the same units as the original estimate. An honest residual statement names the assumptions it rests on and what would invalidate it. A decorative one names neither.
How often should exposure reporting like this happen?+
Whatever cadence you choose, keep the format the same. Using the same structure quarter after quarter is what shifts the conversation from how many findings did we close to how has exposure to the business actually changed.
