A scoreable risk scenario is one sentence that names a threat, a weakness, an asset and a consequence. "Data breach" cannot be rated because it hides everything that matters. "An attacker uses a leaked access key to read customer files in cloud storage" can be rated, discussed and treated.
The sentence pattern
Use this shape: A [threat] exploits [weakness] to [action] on [asset], causing [consequence].
Examples:
- A phishing attacker takes over an administrator's session through a weak sign in flow and changes production configuration, causing an outage.
- A malicious package update runs code in our build, giving an attacker access to signing keys.
- A departing employee keeps access to a shared drive and copies customer contracts.
NIST IR 8286A describes the same idea: document scenarios that show how threats and vulnerabilities could affect enterprise assets, then record the likelihood and impact of those threat events in the risk register.
Why each part matters
- Threat. Who or what causes harm. This changes likelihood and which controls apply.
- Weakness. The gap that makes it possible. Without one, you have a threat, not a risk.
- Asset. What is harmed, so impact can be reasoned about.
- Consequence. The business result in plain words: outage, exposure, fraud, fines, lost contracts.
NIST SP 800-30 treats risk as a function of threat events, vulnerabilities, likelihood and impact, so a scenario missing one of those cannot be scored properly.
Too broad, too narrow
Too broad: "Ransomware." Many assets and paths hide inside it. Split by the entry route and the asset.
Too narrow: "Server 14 is missing a patch." That is a finding. If it supports a scenario, link it. If not, track it in your patch process.
A good size is one a single owner can act on. If two owners would need to respond, split it.
Add the scoring context
After the sentence, write down:
- Which existing controls reduce likelihood or impact.
- Which data you used, such as logs, incident history, or test results.
- Who rated it and when.
Those notes let a reviewer challenge the rating later without redoing the work.
A short test
Read the scenario aloud to someone outside security. Can they say what would happen to the business and roughly how bad it would be? If they cannot, add the missing piece.
An example, improved in three passes
Start: "Credential theft." Too vague to rate.
Second pass: "An attacker steals an engineer's credentials." Better, but the asset and result are missing.
Third pass: "An attacker steals an engineer's credentials through a phishing page and uses them to read our private source repositories, exposing proprietary code." Now you can discuss how often phishing reaches engineers, what stops credentials being usable, and what the exposure would cost.
Each pass added one element. If you are stuck, ask which of the four parts is still missing.
Quick check
Should a vulnerability scan finding be a risk entry?
Usually not. A finding is evidence. Group related findings into the scenario they support.
How many scenarios per asset?
Only as many as there are distinct ways it could realistically be harmed. Often two to five.
Sources
Last reviewed: 19 October 2026.
