Write a security risk statement as one sentence with three parts: the condition that exists, the event that could follow, and the consequence for the business. For example: "Because the payment export has no access check, any logged-in user could download all invoices, exposing customer billing data."
The pattern
Fill in this sentence:
"Because [condition], [actor] could [event], resulting in [consequence]."
Each slot has a job.
| Slot | What it is | Weak example | Strong example |
|---|---|---|---|
| Condition | A fact about the system today | "Poor security" | "The staging database accepts connections from the internet" |
| Actor | Who or what triggers it | "Hackers" | "An unauthenticated visitor" |
| Event | What happens | "A breach" | "read customer email addresses" |
| Consequence | What the business loses | "Bad things" | "triggering breach notification duties and support load" |
If you cannot fill a slot, you have found what you need to learn before writing the finding.
Three tests before you send it
- Could a stranger verify the condition? If the condition is a feeling, rewrite it as something you can check.
- Would the reader care about the consequence? A product owner cares about customers and revenue. A finance lead cares about cost and obligations. Pick the consequence that matches the reader.
- Does it contain a recommendation? It should not. The statement describes the risk. The next line proposes options.
Avoid the common traps
Fear words. "Catastrophic" and "critical" do not add information. Replace them with a concrete outcome.
Hidden multiple risks. "Our dependencies are old, secrets are shared and logging is thin" is three risks. Write three sentences so each can be owned and closed separately.
Likelihood by adjective. If you say "likely", say why: the service is internet facing, the flaw is public, an exploit is known. If you do not know, say that likelihood has not been assessed.
Made-up numbers. Do not attach a dollar figure or a percentage unless you can show where it came from. A range with stated assumptions beats a precise guess. Likelihood and impact both need support.
Put it to work
A risk statement is the first line of three documents: the ticket, the exception request and the executive summary. The same sentence can open all three, with detail growing underneath. This keeps the story consistent as it moves from engineer to manager to board.
For a vulnerable dependency, a good version reads: "Because the order service uses a library version with a known remote code execution flaw, and the affected function is called from a public endpoint, an attacker could run commands on the server, risking customer data and downtime." Whether the function is really called is a fact you can check with reachability analysis, which Safeguard provides, and the free scan at gold.safeguard.sh/scan gives a starting inventory.
Quick check
How long should a risk statement be?
One sentence for the statement itself. Supporting evidence goes underneath in a short list.
Do I need a risk score in the statement?
No. Add a rating beside it if your process uses one, but keep the sentence factual.
Last reviewed: 19 October 2026.
