How Dangerous, How Exposed, What Remains: A Working Model for Residual Risk

Effective risk assessment is not about producing a number. It is about understanding exposure, communicating priorities, and enabling informed decisions — and a rating only does those things when the reasoning behind it survives contact with a skeptical reader.

A meaningful risk assessment answers three questions, in order:

1. How dangerous is the threat?
2. How exposed are we to it?
3. What risk remains, given the controls we actually have?

The model in this article answers each question with its own determination — Threat, Vulnerability, and Residual Risk — each produced by its own formula, each rated through its own matrix, each with its own recorded rationale. It is the risk model we built into CtrlFort Assess™, and it works on a whiteboard exactly as it does in the platform. Keeping the three apart is what makes the final rating explainable to both technical and business stakeholders, and defensible when someone pushes back.

Why Separate the Three at All#

Many risk assessments struggle because threat, vulnerability and risk blur into a single impression, scored in one step. The result is inconsistent ratings, unclear rationale, and remediation lists nobody can prioritize — because a single blended number cannot say whether the problem is a dangerous adversary, a wide-open door, or both.

Scroll sideways to see the full diagram →

The anchor for all three is a finding — typically a control assessed against the current Government of Canada catalogue, ITSP.10.033, that came back Partially Met or Not Met.¹ The finding is evidence, already agreed with the system owner; the model turns it into a risk a decision-maker can act on.

This is also exactly how CtrlFort Assess has incorporated the model. Findings flow in from control assessment already linked to their controls and evidence; the three formulas run in the platform's deterministic engine, so the lookups are computed rather than eyeballed; and the AI layer drafts the residual risk statement from the structured result. The sections below walk the model step by step, noting what the platform does at each one — and How CtrlFort Runs This Model closes the loop.

Step 1 — Threat: How Dangerous Is the Threat?#

The formula is not invented vocabulary — it rates exactly what the published definitions describe:

[A threat is] any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.

NIST SP 800-30 Rev. 1 — Glossary

ITSG-33's glossary — still the operative GC vocabulary, since ITSP.10.033 defines neither term itself — compresses the same idea: an IT threat is "any potential event or act, deliberate, accidental or natural hazard, that could compromise IT assets."⁴ Both definitions describe a potential, and the threat determination rates that potential on two dimensions: how likely the event is, and how capable the source behind it would be. That is the same characterization NIST SP 800-30 applies to adversarial threat sources, whose capability, intent and targeting are what drive the likelihood that an attack is initiated at all.²

The determination deliberately ignores your weaknesses — the same adversary is just as dangerous whether your controls are strong or weak. What changes with your controls is the vulnerability, and that is Step 2's job.

Threat Likelihood#

Likelihood reflects the probability that a threat event occurs in this operating environment. Ground it in observables: industry trends, known threat activity, environmental exposure, historical incidents and available threat intelligence.²

Threat Capability#

Capability reflects the sophistication, resources, persistence and intent of the most realistic threat source for the scenario — not the worst imaginable one. The scale aligns with the deliberate threat agent categories in ITSG-33 Annex 2:³

The Td scale covers the deliberate threat class. For accidental threats and natural hazards — the other two classes in the ITSG-33 definition — read the capability column as the plausible magnitude of the event instead, which is how the Harmonized TRA Methodology treats them.⁷

The Threat Matrix#

Worked rating. An internet-facing administrative portal does not require multi-factor authentication for privileged accounts. The portal is a valuable target for credential theft, and similar attacks are commonly observed across cloud environments — likelihood Likely. The most realistic threat source is an organized cybercrime group — capability Td4. The matrix returns Threat = High, and the rationale is on record: a capable, motivated actor is expected to target privileged access because it is a direct path to data and control.

In CtrlFort Assess, those two selections and their rationale are recorded against the finding, and the engine performs the lookup — the same T for the same inputs, whoever runs the assessment.

Step 2 — Vulnerability: How Exposed Are We?#

Here too, the model rates what the standards define:

[A vulnerability is] a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

NIST SP 800-30 Rev. 1 — Glossary

Read against the model, the mapping is one-to-one. The finding is the vulnerability in NIST's sense — a weakness in internal controls or their implementation. The V rating then expresses what ITSG-33's glossary emphasizes: "an attribute of an IT asset or the environment in which it is located (including the security solutions) that increases the likelihood of a threat event."⁴ Prevention Weakness asks whether the weakness could be exploited — would the attack work; Response Weakness asks what follows if it is triggered — would we catch it. Assigning the weakness a level is exactly what the Harmonized TRA Methodology does, rating vulnerabilities by their impact on the probability of compromise.⁷

Put plainly: prevention weakness governs how often you get hit; response weakness governs how long it lasts and how far it spreads. Neither answers the question alone, which is why the model asks both.

That also explains the shape of the matrix. Weak prevention with strong response means incidents happen but get shut down quickly. Strong prevention with weak response means incidents are rare, but the rare one runs unchecked. Only when both are weak is the organization both easy to compromise and blind to it — and that is the corner the matrix rates High.

This is also the step where existing safeguards earn their credit: every control that genuinely works lowers one of the two ratings. Both are judged against what the control assessment found actually implemented and operating — not against what the documentation claims.

Prevention Weakness#

How far do implemented controls fall short of stopping the threat? Missing multi-factor authentication, weak access control, poor segmentation, insecure configuration and inadequate policy all raise it.

Response Weakness#

If prevention fails, how far does the organization fall short of detecting, containing and recovering? Limited monitoring, weak logging, incomplete incident response and poor recovery capability all raise it.

The Vulnerability Matrix#

Note that the grid is not symmetric: low prevention weakness with high response weakness rates Medium, while the reverse rates High. That is deliberate — response limits damage, it does not stop compromise, so a missing preventive control costs you more than a slow one.

Worked rating. For the same portal: the absence of MFA on privileged accounts is a missing critical preventive control — prevention weakness High. Centralized logging and some monitoring exist, but alerting and incident response are not fully mature — response weakness Medium. The matrix returns Vulnerability = High: the environment lacks a critical preventive control and may not detect misuse quickly enough to limit the impact.

This is where CtrlFort's control intelligence pays off: the platform already knows which preventive and which detective controls came back Partially Met or Not Met, so both ratings are grounded in the control assessment rather than re-argued from scratch.

Step 3 — Residual Risk: What Remains?#

[Residual risk is] a risk that remains after security controls have been selected, approved and implemented.

ITSG-33 Annex 5 — Glossary

The formula delivers that definition automatically: both weakness ratings were judged against the safeguards actually in place — what they stop, and what they catch — so their credit sits inside V before the final lookup runs: no separate discounting step, and no way to count the same safeguard twice.

The philosophy matters more than the mechanics. A threat does not automatically create risk, and neither does a weakness. Risk becomes meaningful where a capable threat intersects a realistic opportunity for exploitation — and the Residual Risk Matrix encodes exactly that intersection, spanning the full five-level scale — from Very Low where a modest threat meets a well-defended environment, to Very High in the corner where both dimensions peak.

The Residual Risk Matrix#

The Model End to End#

Scroll sideways to see the full diagram →

Finding. Administrative accounts for a customer-facing cloud portal do not require multi-factor authentication — a gap against the identification and authentication controls of ITSP.10.033.¹ The portal is internet-accessible and holds sensitive customer information; administrators can manage accounts, permissions and configuration.

1. ThreatLikely × Td4 (organized cybercrime) → High
2. VulnerabilityPrevention Weakness High × Response Weakness Medium → High
3. Residual riskHigh × High → Very High
4. DecisionMitigate, accept, share, or avoid — the risk owner's call

The team's recorded rationale, step by step: the portal is an attractive, commonly attacked target and a capable actor is realistically motivated (Threat High); a critical preventive control is absent and detection is only partly mature, so a credential attack would probably succeed and might not be caught quickly (Vulnerability High); a capable threat therefore has a realistic opportunity against a significant weakness, and existing safeguards do not sufficiently reduce either the likelihood or the consequence (Residual Risk Very High).

The Rating Is Not the Deliverable#

The rating sorts the queue. What the risk owner actually accepts — in the report, in front of the authorizing official, in the record of the decision — is the residual risk statement: what remains exposed, why, what would follow if exploited, and what was already credited.

From there, the options are the standard four — mitigate, accept, share, or avoid⁵ — and the model's job is done: it made the choice an informed one without making it.

Where This Goes Wrong#

• Rating the worst imaginable adversary. Capability should reflect the most realistic threat source for the scenario. Rating every finding against Td7 makes everything High and nothing actionable.
• Crediting safeguards twice. Controls are counted once, inside the vulnerability rating. Discounting the residual rating again "because we have logging" double-counts the same safeguard.
• Crediting safeguards that were never seen. A control lowers prevention or response weakness only if the assessment saw evidence it is implemented and operating. A planned control reduces nothing.
• Re-scoring instead of re-assessing. If nothing was remediated and the threat environment has not moved, the rating should not move either. A rating that drifts without new evidence is an opinion with a history.

How CtrlFort Runs This Model#

Every one of those failure modes is a consistency failure — and consistency is precisely what is hard to sustain when a program runs this model by hand, across dozens of findings, multiple assessors and quarterly cycles. This is the class of problem CtrlFort Assess was built for, and the division of labour is the same one described in our assessment intelligence architecture: code evaluates, AI explains, humans decide.

• The findings arrive structured. Control assessments against ITSP.10.033 — or NIST SP 800-53, ISO 27001 and other supported frameworks — produce the Partially Met and Not Met findings this model consumes, already linked to their controls and evidence.
• The matrices live in the deterministic engine. Likelihood, capability and the two weakness ratings go in; T, V and the residual rating come out — the same inputs producing the same rating for every assessor, every cycle, with the Very High corner flagged the moment both dimensions peak. Because the lookup is code, a rating cannot drift without a change in its inputs, and every placement carries the rationale that produced it.
• AI drafts the statement, from the determination. CtrlFort AI generates the residual risk statement — what remains exposed, why, what would follow, what was credited — from the structured result, so the narrative can never quietly diverge from the rating it explains.
• People stay accountable. Assessors validate the placements, and the mitigate-accept-share-avoid decision remains where it belongs: with the risk owner.

The model does not need a platform to be sound. It needs one to stay consistent at scale — and consistency is what makes its ratings comparable across systems, defensible under challenge, and worth building decisions on.

Final Thoughts#

Effective risk assessment is built on clarity, consistency and sound judgment. Treating threat, vulnerability and residual risk as distinct determinations shows where exposure exists, why it exists, and where remediation belongs — and it keeps each judgment small enough to explain.

The goal is not the number. The goal is three answered questions — how dangerous is the threat, how exposed are we, what remains — answered consistently enough that everyone managing the risk is looking at the same picture.

Frequently Asked Questions#

Where does business impact fit? The formulas never mention it.#

It enters twice, at the edges of the model. Upstream, through security categorization: the system's categorization establishes what it holds and what a compromise would cost before any finding is rated, which is why the same missing control rates differently on a Protected B system than on a public website — likelihood and capability judgments reflect how attractive the target actually is. Downstream, in the residual risk statement, which must say what would follow if the exposure were exploited. The Harmonized TRA Methodology makes the same factor explicit by carrying asset value as a third dimension alongside threat and vulnerability; this model inherits it from the categorization context instead of re-scoring it per finding.

How do we rate likelihood with no incident history?#

Absence of incidents is weak evidence — it may only mean detection was weak. Rate from the environment instead: is the interface internet-facing, is the technique commonly exploited in the wild, does threat reporting show active campaigns against this sector, does the asset hold something a capable actor monetizes? A likelihood chosen from exposure and published threat activity survives review; "we've never seen it happen here" does not.

What stops two assessors from choosing different inputs?#

The matrices only fix the combination — likelihood, capability and the two weakness ratings are still judgments, and that is where variability lives. Three disciplines contain it: written definitions for every level in observable terms, a recorded rationale for every selection, and a second reviewer on any rating that drives a High or Very High result. When two trained assessors still disagree after that, the disagreement is usually informative — it means the evidence is ambiguous, and that itself belongs in the rationale.

How do individual residual risks roll up to a system-level picture?#

Not by averaging — a Very High buried among twenty Lows is exactly what an average hides. Report the distribution and let the highest ratings lead: the system-level risk statement names the worst residual risks, notes any concentration (five Medium findings against the same control family often matter more than one High), and states what the authorizing official is being asked to accept in aggregate. The individual rows stay in the register; the roll-up is a summary of them, never a replacement.

Does this replace assessment against ITSP.10.033?#

No — it consumes it. Control assessment against ITSP.10.033 produces the findings; this model turns a finding into a rated, explainable residual risk. The catalogue tells you what good looks like; the risk model tells you what a gap against it actually means for the organization.

Can this model be automated?#

The deterministic parts can and should be: the matrix lookups, the consistency checks, the link from finding to control to evidence. That is how CtrlFort Assess runs it — the engine computes T, V and the residual rating from the recorded inputs, and AI drafts the risk statement from the structured result. The judgment inputs — likelihood, capability, the two weakness ratings — and the final risk decision stay with people, which is exactly where a defensible assessment needs them.

References#

1. 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
2. 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
3. Annex 2 — Information system security risk management activities (ITSG-33) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
4. Annex 5 — Glossary (ITSG-33) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-5-glossary-itsg-33
5. ITSP.10.033 — Risk assessment ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033/risk-assessment
6. Cox, L.A. (2008). What's Wrong with Risk Matrices? Risk Analysis, 28(2), 497–512 ↩Wiley Online Library · https://onlinelibrary.wiley.com/doi/10.1111/j.1539-6924.2008.01030.x
7. Harmonized TRA Methodology (TRA-1) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/tools-services/harmonized-tra-methodology