Step 5 — From Finding to Risk Statement
A failed control is not a risk. It is an input to one — and the translation between them is where most assessment reports lose their executive audience
"MP-6 not met."
To an assessor that is a complete sentence. To the executive who has to decide what to do about it, it is not even a language. This post is about the translation in between — from a statement about a control to a statement about the organization — and it is a skill that is rarely taught.
A finding says what is wrong with a safeguard. A risk statement says what that could cost, to whom, and how badly.
One thing this post deliberately does not do: score the risk. How dangerous, how exposed, what remains — the three-formula model — is in our residual risk post. That post starts from "you have a threat and a vulnerability". This one is about where those come from.
A Finding Is Not a Risk#
A finding is a judgment about a control against a requirement — the output of Step 4. It is precise, technical, and addressed to people who know what MP-6 is.
A risk is a statement about what could happen to the organization. It is addressed to the person who will decide whether to carry it, and that person may never have read the catalogue.
ITSG-33's ISSIP — its process for building security into a system across the project lifecycle — keeps the two tied together by insisting the whole exercise exists for the business:
The goal of ISSIP is to help IT projects implement security solutions in information systems that satisfy the security objectives of confidentiality, integrity, and availability of the departmental business activities that information systems support.
ITSG-33 Annex 2 § 1.1Business activities.2 The control exists to protect them. The risk statement is what reconnects a failed control to the activity it was protecting.
What a Risk Statement Has to Contain#
Scroll sideways to see the full diagram →
| Part | Answers |
|---|---|
| Weakness | What is actually wrong |
| Exposure | What that makes reachable |
| Threat source | Who or what would credibly exploit it |
| Consequence | What happens to the organization, in business terms |
| Scope | How much of the estate |
| Existing mitigation | What already reduces it |
NIST SP 800-30 frames risk as a function of threat, vulnerability, likelihood and impact;1 the six parts are that framing written for a decision-maker rather than a model. Every one is needed. Miss scope and the owner cannot size it. Miss existing mitigation and you have described the inherent risk, which is not the one they are carrying.
From Control Language to Business Language#
The craft is in the consequence line. Three pairs:
| Control language | Business language |
|---|---|
| AC-2(D) partially met — leaver accounts not disabled within the period | Former staff may retain access to case records for up to 90 days after departure |
| SC-8 not met — internal service traffic unencrypted | Personal information crossing the internal network is readable by anyone with access to that segment |
| CP-9(B) not met — backup restoration untested | If the case system fails, there is no evidence it can be recovered within the statutory processing deadline |
The test: could the person who has to decide explain it to their own director without reading it aloud? And the opposite failure exists too — a statement so business-flavoured it no longer says what is technically wrong. The finding and the risk statement are linked, not merged.
One Risk, Many Findings#
Six findings about patching in six components are usually one risk with six contributing weaknesses. Reporting them as six risks inflates the register and hides the real exposure.
One Finding, Many Risks#
The reverse case. A single logging gap is an incident-detection risk owned by operations and a privacy-obligation risk owned by the privacy office. Different consequence, different owner, different decision.
Split when the owner or the consequence differs. A risk with two owners is a risk with none — the risk register post is firm on this, and the translation step is where it is enforced.
Findings That Are Not Risks#
Not every failed control escalates. Some are housekeeping — a document version out of date. Some are already mitigated to the point of irrelevance. Some describe a weakness with no credible threat source in this environment.
Say so explicitly. Record the finding, close it with a reason, and do not promote it. A register full of trivial risks is a register nobody reads, and the one that matters drowns.
Handing Off to Scoring#
Once the statement exists, it gets rated. The three questions the model asks are how dangerous is the threat, how exposed are we, and what remains after mitigation — and the mechanics, the matrices and the worked examples are in How Dangerous, How Exposed, What Remains.
The six parts feed it directly: threat source and consequence inform the threat rating; weakness, exposure and existing mitigation inform the vulnerability rating. A well-written statement scores itself.4
Where CtrlFort Fits#
Translation done by hand is inconsistent by nature — the same finding becomes a crisp risk under one assessor and a pasted control ID under another, and neither is comparable across systems.
In CtrlFort Assess a finding is promoted to a risk rather than retyped. Promotion carries the finding, the control, the evidence and the system link across, so the risk is built on the same object the assessor described. CtrlFort AI drafts the risk statement from the structured result — what is exposed, why, what would follow, what was credited — and the assessor edits a specific claim instead of composing from nothing.
Every risk carries exactly one Business Risk Owner by role, and the rating runs on the deterministic model from the structured inputs, so the number and the words cannot disagree.5
Final Thoughts#
Write the risk so the owner can decide. That is the entire job of this step, and everything that makes a risk register useful depends on it being done here.
Previous: Step 4 — Assessing Control Effectiveness · Next: Step 6 — Security Assessment Reports and POA&Ms
Frequently Asked Questions#
What is the difference between a finding and a risk?#
A finding is a judgment about a control against a requirement. A risk is what that could cost the organization — what is exposed, to whom, with what consequence. Findings are inputs; risks are what owners decide about.
Should every failed control become a risk?#
No. Promote a finding when it has a credible threat source and a consequence someone must decide about. Close housekeeping findings with a reason. A register that contains everything is a register that prioritizes nothing.
When should related findings be combined into one risk?#
When they share a consequence and an owner. Six patching gaps leading to the same exposure for the same system owner are one risk with six contributing findings underneath it.
Who writes the risk statement — the assessor or the system owner?#
The assessor drafts it, because they hold the evidence and the finding. The system owner corrects the business consequence and scope, because they know what the activity is worth. The final statement is the assessor's, informed by the owner — and then the owner decides.
References#
- NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/30/r1/final
- ITSG-33 Annex 2 — Information System Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
- ITSG-33 Annex 1 — Departmental IT Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-1-departmental-it-security-risk-management-activities-itsg-33
- ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
- NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/37/r2/final