Randy Lindberg
Pull up your current risk assessment and look at what the rows actually are. For most institutions, they are threats: ransomware, phishing, insider misuse, vendor breach, each scored for likelihood and impact and sorted into high, medium, and low. That is a threat-based risk assessment, and it is how most credit unions have always done this. Here is the problem: a threat floating free of any system cannot be scored honestly, because the impact of a threat is determined almost entirely by where it lands. This post explains what the threat-based approach gets right, where it breaks, and how adding the asset layer turns a list of worries into math you can defend.
An Examiner Approved Cyber Risk Model
Check out the Cyber Risk Management Model that examiners reference below
What is a threat-based risk assessment?
A threat-based assessment starts from the adversary. You build a list of the bad things that happen to institutions like yours, estimate how likely each one is and how much it would hurt, and rank the results. Most risk registers I have reviewed over the years are exactly this: a threat catalog with scores.
To be clear, starting from threats is the right instinct. Risk comes from real attacks, not from spreadsheets, and a threat list keeps the assessment pointed at things that actually happen. Frameworks like MITRE ATT&CK have made this half of the job stronger than ever, because you can ground every scenario in publicly documented adversary behavior instead of imagination.
So the standard approach is not wrong. It is half finished.
The problem: "how bad is ransomware" has no answer
Try to score the threat of ransomware for your institution as a whole. What is the impact? The honest answer is: it depends entirely on what gets hit. Ransomware on the core processor is an existential event. Ransomware on a marketing workstation is a bad Tuesday. Same threat, wildly different loss, and the difference is not in the threat at all. It is in the system.
Likelihood has the same dependency. The probability that a credential attack succeeds is not a property of credential attacks in general. It depends on which system the credentials open, how it is exposed, and what controls sit in front of it.
That is why a threat-only assessment always ends in a shrug dressed up as a score. When impact is "greatly determined by the system where the risk lives," and your assessment has no systems in it, every number in the register is a gut call averaged across your whole environment. Two smart people can score the same threat a 2 and a 4 and neither can prove the other wrong, because the question as posed has no right answer. Asking "how bad is ransomware" without naming a system is like asking "how bad is a fire" without saying what building it is in.
What the asset layer adds
An asset-based, or system-based, view starts from an inventory: your systems, the types of data on each one, the record counts, and how important each system is to daily operations. Those four facts are precisely the ones that were missing from the score.
Data types and record counts drive breach impact. Two hundred thousand member records on the core is a quantifiable loss; you can price the notification, the remediation, the fraud exposure, and the reputational hit. Operational criticality drives outage impact. If the core is down, the institution is down, and every hour has a dollar figure. None of that is knowable from the threat side. All of it is knowable from the asset side.
The asset layer alone is not an assessment either. An inventory with CIA scores and no threats describes your furniture and never mentions the burglars. The two halves answer each other's questions: threats supply the "what could happen," assets supply the "what it would cost and how likely here."
The complete model: threats assessed per system
The fix is to stop choosing and connect them. Assess each threat in the context of each system it applies to. Ransomware against the core. Credential theft against online banking. Vendor breach against the loan origination platform. Every row in the assessment becomes a threat-and-system pair, and suddenly both numbers are computable: likelihood from adversary behavior and that system's exposure and controls, impact from that system's data and operational role.
This is exactly how Rivial's cyber risk model is built. It has eight elements running along one chain: threats, the vulnerabilities they exploit, the systems they land on, the data and business value at stake, the controls in the way, and the loss out the other end. Remove the threat half and you cannot defend likelihood. Remove the asset half and you cannot size impact. Connect the chain and you can run it through a Monte Carlo simulation and get what your board actually wants: expected annual loss, in dollars, per system and per threat.
The dollar step matters more than either label. A connected assessment that still outputs high, medium, and low is better inputs wasted on the same mushy output. When the examiner asks how you decided "high" was acceptable, the room goes quiet. When you can say this scenario on this system carries about $400,000 in expected annual loss against a board-approved tolerance of $600,000, the conversation is over.
In the Rivial platform, this is the default shape of the work: you maintain the system inventory, assess each system against a threat catalog grounded in MITRE ATT&CK and real breach data, and the platform runs the simulation and tags every risk with a dollar value that flows straight into a board report. The examiner gets an assessment specific to your institution, and the board gets it in a language they already speak.
How to upgrade a threat-based assessment
If your current assessment is a threat register, you are not starting over. You are adding the missing half.
1. Build the system inventory first. List your systems, and for each one capture the data types, record counts, and how critical it is to operations. This is the foundation, and it is the step most threat-based programs skipped.
2. Keep your threat catalog. It is the half you already have. Tighten it by mapping each threat to MITRE ATT&CK techniques so every scenario carries a public reference.
3. Connect threats to systems. For each system, identify which threats genuinely apply. The core faces different attacks than the HR platform. This mapping is the heart of the exercise.
4. Score with data, not vibes. Use published breach frequency and cost data as the baseline for likelihood and impact, adjusted for each system's controls and exposure. Document the adjustments. Defensibility lives there.
5. Put the output in dollars. Translate each threat-and-system pair into expected annual loss and compare it to a board-approved risk tolerance. This is the step that turns a compliance document into a decision tool.
Whatever word your examiner uses, this connected version is the thing they are probing for: an assessment that reflects real threats against your actual systems, not a generic list that could belong to any institution in the country.
See the connected version on your own systems
The fastest way to feel the difference is to watch your own numbers change when the asset context gets added. Our free cyber risk assessment quantifies the risk on five of your critical systems using the full threat-and-system model, and we guarantee it will identify at least $100,000 in risk reduction. It takes about two hours of your team's time, and there is no sales call required to get your report.
Here are the key takeaways from this blog:
- Most risk assessments are threat lists: starting from threats is the right instinct, but a threat with no system attached cannot be scored honestly.
- Impact lives in the asset: the data on a system, its record counts, and its operational importance determine what a threat costs, and likelihood depends on that system's exposure and controls.
- Assess threats per system: every row becomes a threat-and-system pair, which makes both likelihood and impact computable instead of guessed.
- Dollars finish the job: run the connected model through simulation and report expected annual loss against a board-approved tolerance, and both the examiner and the board get their answer.
An Examiner Approved Cyber Risk Model
Check out the Cyber Risk Management Model that examiners reference below