Study Guide
Risk
What cybersecurity risk is: assets, threats, vulnerabilities, likelihood and impact, three short risk models, and how dependencies change the picture.
Lesson 5.3 Governance, Risk & Compliance
Every organisation has limited time and money, and it cannot protect everything equally. This lesson is about how to decide where to focus. The next three lessons build on it to assess, quantify and treat risks.
Stage: Think
A house in the street
Think it through
Think of a house. What would make it more at risk of being burgled, and what would make it less?
- Hint 1: What is inside that someone might want?
- Hint 2: How could someone get in? How often do break-ins happen in that street?
Show what happens
Keep your list: the next step sorts answers like yours into five groups.
Think it through
Show the answer
Answer: A. Very little: with nothing worth taking, there is little to lose.
A weakness on its own is not the whole picture. It matters when there is something worth harming and someone who might harm it, and how much it matters depends on how likely that is and how bad it would be.
Stage: Explain
The idea
Think about the risk of a house being burgled. It is not one thing. It is several things together.
- There is something worth taking: the contents of the house.
- There is someone who might take it: a burglar.
- There is a way in: a window left unlocked.
- There is how likely it is: higher in a street with many break-ins, lower with a neighbour always at home.
- There is how much it would matter: more if the laptop with the family photographs is on the table.
Take any one away and the picture changes. No burglar, no risk from burglary. A locked window, and the burglar needs another way in. Nothing worth taking, and it hardly matters.
Cybersecurity risk is built from the same parts. Risk is the possibility of harm: what could happen, how likely it is and how much it would matter to this particular organisation. A weakness in a system is one part of that picture. It is not the whole of it.
So an organisation deciding where to focus asks not “is this bad?” but “what could happen, how likely is it, and how much would it matter here?”
Stage: Explain
Assets, threats, vulnerabilities and business context
Each part of the burglary has a name.
| Term | Meaning | In the house |
|---|---|---|
| Asset | Something of value to the organisation: information, a service, equipment. | The contents of the house. |
| Threat | Something that could cause harm. | The burglar. |
| Vulnerability | A weakness the threat could use. | The unlocked window. |
| Incident | The harmful event, if it happens. | The break-in. |
| Impact | How much harm the incident does. | What was lost, and what it costs to put right. |
| Likelihood | How probable the incident is, over a stated period. | How likely a break-in is this year. |
The same five-part chain in two settings, one link at a time. A threat uses a vulnerability to reach an asset; that is the incident, and the harm it does is the impact. Likelihood is a judgement about the first three links; impact is a judgement about the last.
Threat
Step 1 of 5: Who or what could cause harm
House: a burglar. Organisation: an attacker using stolen passwords.
Vulnerability
Step 2 of 5: The weakness used
House: an unlocked window. Organisation: accounts protected by a password alone.
Asset
Step 3 of 5: What is reached
House: the contents. Organisation: the customer database.
Incident
Step 4 of 5: The event
House: a break-in. Organisation: unauthorised access to customer records.
Impact
Step 5 of 5: The harm done
House: loss, cost and distress. Organisation: exposed data, cost, and consequences under data-protection law.
Check your understanding
Show the answer
Answer: A. The out-of-date operating system on the laptops.
The criminal group is the threat, the laptops and their data are the assets, and the out-of-date operating system is the vulnerability: the weakness the threat could use.
Think it through
Show the answer
Answer: B. No: what each system is for changes how much it matters.
The event is identical; the setting is not. What a system is for, and who depends on it, decides how much an incident would matter.
Business context is what turns the general picture into a particular one. The same event matters very differently in different places: an hour’s interruption to a test system is an irritation, and the same hour’s interruption to a hospital’s records system is not. So always ask what the system is for, who depends on it, what information it holds, how exposed it is and what happens if it fails.
Where the house comparison stops. A house has one front door and a handful of windows. An organisation’s systems can be reached in thousands of ways, by attackers who never need to be nearby, which is why the parts have to be written down and assessed one risk at a time.
Stage: Experiment
The customer-database scenario
The example connects the following stages:
| Stage | Example |
|---|---|
| Asset | Customer database |
| Vulnerability | Weak access controls |
| Threat | An attacker using stolen credentials |
| Incident | Unauthorised access |
| Impact | Data exposure, financial loss or regulatory consequences |
Think it through
Before reading on: turn the five rows of the table into one sentence that says what could happen and why it would matter.
- Hint 1: Start with who: “An attacker using…”
- Hint 2: Then through which weakness, to which asset, and with what harm.
Show what happens
Compare your sentence with the one that follows. Yours is a good risk statement if someone reading it could see what to protect, against whom, and why.
The risk is more informative when expressed as a scenario: an attacker using stolen credentials may exploit weak access controls to access the customer database, exposing information and causing organisational harm. This states what could happen and why it matters, rather than merely listing “database” as a risk.
From that sentence the useful questions follow: which accounts can reach the records, what can each of them do, how would misuse be noticed, and how sensitive is the information? Data classification helps with sensitivity; least privilege helps explain why account permissions affect the possible damage. Disclosure threatens confidentiality, while improper edits or disruption could also affect the other CIA objectives.
Stage: Predict
A fictional example
Think it through
Show the answer
Answer: C. No: a different threat and weakness make a separate risk with its own fix.
Work through it in the example: the asset and impact stay the same, but the threat, the vulnerability, the likelihood and the fix all change.
Change one fact. Keep the same asset, the customer database, and change the route to it. This time the weakness is a web service that the organisation runs on the internet and has not updated, so it still contains a flaw that the software’s maker has already fixed.
- Write the new scenario. An attacker may use a known flaw in an unpatched internet-facing service to reach the customer database, exposing information and causing organisational harm.
- Compare the parts. The asset and the impact are the same as before. The threat and the vulnerability are different.
- Compare the likelihood. The first scenario needs an attacker to have someone’s password. This one needs only that the service can be reached and the flaw is widely known. If attack tools for the flaw are freely available, this route may well be the more likely of the two.
- Compare what would help. Better sign-in protection reduces the first risk and does nothing about the second. Installing the update removes the second and does nothing about the first.
What the comparison shows: one asset can carry several separate risks, each with its own likelihood and its own remedy. That is why a risk is written as a whole sentence, not as the name of an asset. It also shows that a vulnerability alone does not give a likelihood: the assessor needs to know how exposed the service is and how easily the flaw can be used.
Stage: Explain
Three risk models
Three short expressions for risk are in common use. They are conceptual models: each highlights part of the same idea. They are not interchangeable equations, and one cannot be converted into another.
| Model | What it helps you see | What it is not |
|---|---|---|
| Risk = Impact × Likelihood | The main assessment model. Consequence and chance both matter. A severe but very unlikely event, and a likely event with trivial effects, can both deserve less attention than a moderately likely, serious one. | A measured calculation, unless both values have real units. |
| Risk = Threat × Vulnerability × Asset | A risk needs three ingredients: something that could cause harm, a weakness it could exploit, and something of value. Remove any one and that particular risk disappears. | A sum to work out. There is no agreed unit for “threat” or “asset”. |
| Cyber Risk = Impact × Probability | The same idea as Impact × Likelihood. Probability is a more formal word for likelihood. | An invitation to invent a percentage without evidence. |
Notice that the second model is the empty house again: with no asset worth harming, that risk disappears, however weak the window.
Check your understanding
Show the answer
Answer: B. The model shows what risk depends on; it is not a sum to work out.
Risk = Threat × Vulnerability × Asset shows that all three ingredients are needed. It is not a calculation: there are no units to multiply.
In all three, the “×” means “depends on all of these together”. Numbers are only multiplied in two situations, both taught in later lessons:
- A risk matrix rates likelihood and impact on defined scales, such as 1 to 5, and multiplies the ratings to rank risks. The results are rankings, not probabilities or money. See Assessing Risk.
- A quantitative model such as ALE = SLE × ARO multiplies values that have real units: pounds and incidents per year. See Quantifying Impact: ALE and Business Impact Analysis.
Take the customer-database scenario: an attacker using stolen credentials against weak access controls.
- Threat × Vulnerability × Asset. The threat is an attacker with stolen credentials; the vulnerability is weak access controls; the asset is the customer database. Suppose the organisation enforces multi-factor authentication and removes unnecessary permissions. The threat and the asset have not changed, but there is less weakness to exploit, so this risk falls.
- Impact × Likelihood. The impact of unauthorised access stays serious, because the data is sensitive. The stronger access controls reduce the likelihood that stolen credentials alone lead to access. The overall risk falls because likelihood fell, not because the data became less important.
- What none of the models says. None of them turns this into a number on its own. That needs a defined rating scale or real estimates, both covered in the next lessons.
Stage: Explain
Four distinctions that are easy to blur
You have now met most of these pairs. They are worth separating explicitly, because later lessons rely on each.
- Threat and vulnerability. A threat is what could cause harm; a vulnerability is the weakness it could use. A burglar is a threat; an unlocked window is a vulnerability. Fixing the window does nothing about burglars, but it removes their route in.
- Impact and likelihood. Impact is how bad the outcome would be; likelihood is how probable it is over a stated period. A high impact alone does not make a high risk.
- Risk and technical severity. A vulnerability’s severity score describes the weakness, not what it means for a particular organisation. Assessing Risk explains why a CVSS 9.8 finding still needs business context.
- Inherent and residual risk. Inherent risk is assessed before the controls being evaluated; residual risk is what remains after them. Treating Risk develops this.
Stage: Predict
Vulnerabilities and dependencies
Think it through
Show the answer
Answer: A. The second, by installing the fix; the first needs other protection.
The two flaws call for different responses. Two terms name the difference.
Two kinds of vulnerability change a risk assessment in different ways. Vulnerabilities and Exposure taught the terms:
- A zero-day vulnerability is one the software’s maker does not yet know about, so no fix has been developed.
- A known, unpatched vulnerability is one the maker knows about, which is not yet fixed on a particular system, either because no fix exists yet or because it has not been installed. The unpatched web service in the “change one fact” example is one of these.
Where no fix exists, installing an update is not an option, so the risk has to be reduced in other ways: making the system harder to reach, adding other protections round it, and watching it closely. Where a fix exists and has not been installed, the risk is mostly a question of how quickly it can be.
Check your understanding
Show the answer
Answer: A. No: the maker knows and has a fix, so it is known and unpatched.
The maker knows about the flaw and has released a fix, so it is a known, unpatched vulnerability. The risk now depends mostly on how quickly the fix is installed.
Suppliers, services and software dependencies can introduce or change a risk even when an organisation’s own controls appear strong. That is why both the initial assessment and subsequent review need to consider the whole activity and its dependencies. Third-Party and Supply-Chain Risk develops this, and security frameworks and standards can structure the work; they do not remove the need for contextual judgement.
When someone says “that’s a big risk”, three questions turn the remark into something that can be assessed: what exactly could happen and to which asset, how likely is it over a stated period, and how much would it matter to this organisation? Writing the answer as a sentence, as in the customer-database scenario, is often the most useful first step.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
- Hint 1: Write it as who, through what weakness, to what, causing what harm.
Show the answer
Answer: C. Anyone who gets the link could read and expose members’ details.
A useful risk is a scenario sentence: a threat (anyone who obtains the link), a vulnerability (a link that grants access to anyone), an asset (members’ details) and an impact (exposure of personal data).
Apply it
- Hint 1: Which two things does a risk depend on?
Show the answer
Answer: B. The likelihood: a severe but very unlikely event can be a small risk.
Risk depends on likelihood as well as impact. A catastrophic but very unlikely event can rank below a frequent, moderately harmful one.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Asset: the appointment records. Vulnerability: the exposed shared password. Threat: the former contractor who might use it.
An asset is something of value, a vulnerability is a weakness, and a threat is a potential cause of an unwanted incident that may exploit a vulnerability. The records are what the clinic values, the exposed password is the weakness, and the former contractor is the potential cause of harm. Calling the contractor the vulnerability and the note the threat swaps the two: removing the note removes the route in, but it does nothing about the contractor. The sensitivity of data is part of why the asset matters, not a weakness.
Revision sources: Session 4: Governance, Risk and Compliance — In Depth (Classroom session record)
Show answer
Answer: Event B may be the higher risk, because a moderate impact with a high likelihood can outweigh a severe but very unlikely event.
Risk = Impact × Likelihood: high impact alone does not make a high risk, so Event A is not automatically higher. The factors do not cancel out into equal risk either. Such models are conceptual, not quantitative equations: comparing the events needs evidence-based ratings, not an exact financial value. “May” matters here: the ratings still need evidence and context.
Revision sources: Session 3: Governance, Risk and Compliance (Classroom session record) · Session 4: Governance, Risk and Compliance — In Depth (Classroom session record) · Risk (Supplementary Study Guide explanation)
Show answer
Answer: False
False. The same vulnerability does not carry the same risk in every situation. The models Risk = Threat × Vulnerability × Asset and Cyber Risk = Impact × Probability both depend on more than the weakness. A payment portal is a far more valuable asset, and compromise would have a much greater impact than on an empty test page.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record)
Study and revision
The Risk Management topic provides practice in this lesson’s asset, threat and vulnerability terms and risk models, and in assessment, ALE, BIA, treatment, residual risk, appetite, tolerance and capacity, linked from the next three lessons. Use its quiz and flashcards with the All topics track to include the GRC material. These course-backed additions are learning-only: they do not establish full topic coverage or verified exam alignment.
Stage: Consolidate
What to remember
- A risk is a scenario: what could happen, to which asset, through which weakness, how likely it is and how much it would matter here.
- Threats, vulnerabilities and assets are different things; removing any one removes that particular risk.
- One asset can carry several risks, each with its own likelihood and its own fix.
- The three risk models show what risk depends on; they are not calculations.
- A known, unpatched vulnerability is not a zero-day.
Key terms
- Risk
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
- Asset
Something an organisation values, such as information, a service, equipment or a business capability.
- Threat
A potential cause of harm, such as an attacker seeking unauthorised access.
- Vulnerability
A weakness that a threat may exploit.
- Likelihood
How probable it is that a defined event will happen over a stated period.
- Impact
How serious the consequences of an event would be for the organisation and the people affected.
Common misunderstandings
A vulnerability is one ingredient. Without a threat that could exploit it and an asset worth harming, it may pose little risk to this organisation.
The three expressions show what risk depends on. Numbers only multiply meaningfully in a defined rating scheme or a model with real units.
Impact is one side. A catastrophic but very unlikely event can rank below a frequent, moderately harmful one.
A flaw with a released fix that has not been applied is a known, unpatched vulnerability in every usage. In the narrower usage a zero-day is unknown to the vendor; the broad usage also covers a disclosed flaw with no fix yet.
Lesson sources and acknowledgements
Sources and scope
The house comparison, the table of terms with its house column, the five-part diagram and the “change one fact” comparison of two routes to the customer database are supplementary explanations; the organisation in them is fictional.
This lesson brings together Session 3 and Session 4, building on the earlier Session 2 foundations. The approved Learning Logs remain the record of tutor-led learning. Worked extensions draw on the supplied, reconstructed GRC educational reference, which is not a verbatim transcript. The scenarios illustrate decisions; they do not describe assessments, workplace implementations or labs I have completed.
- Taught in Session 2 (see the Session 2 Learning Log): the Risk = Threat × Vulnerability × Asset and Cyber Risk = Impact × Probability models; the point that the same vulnerability does not carry the same risk everywhere; zero-day vulnerabilities, described broadly.
- Taught in Sessions 3 and 4 (see Session 3 and Session 4): Risk = Impact × Likelihood; assets, vulnerabilities and threats; the customer-database scenario.
- Moved to later lessons: the assessment, ALE, BIA and treatment sections that were previously part of this page are now in Assessing Risk, Quantifying Impact and Treating Risk, with their wording and anchors kept. They are listed below with links.
- Supplementary explanation: the comparison of the three models, the worked application, the four distinctions, the professional zero-day distinction, the practical note and the misunderstandings.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the opening questions about a house, every question asked in the lesson with its feedback and hints, the school, test-system and hospital, two-program, sports-club and council examples and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. I have not carried out a professional risk assessment.
- Further reading: NIST’s risk glossary, NIST’s BIA definition and FIRST’s CVSS user guide.
The expected yearly loss from a risk, calculated as ALE = SLE × ARO.
The expected number of times an incident occurs per year. Once every four years is 0.25; twice a year is 2.
Something an organisation values, such as information, a service, equipment or a business capability.
An analysis of important activities, their dependencies and the consequences of disruption over time, used to set impact and recovery priorities.
The security objective of restricting information to authorised people, systems or processes.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
A standard for rating the technical severity of vulnerabilities. The same base score can carry different business risk depending on context.
Information becoming accessible to an unauthorised party. Disclosure threatens confidentiality, even if the original information is unchanged.
How far a system, service or piece of information can be seen or reached by others, especially from the internet.
An integrated approach connecting who sets direction and owns decisions (governance), how uncertainty is assessed and treated (risk), and which requirements must be met (compliance).
How serious the consequences of an event would be for the organisation and the people affected.
Risk assessed before the controls being evaluated are taken into account.
How probable it is that a defined event will happen over a stated period.
Authentication that requires two or more different types of factor, such as something you know and something you have.
The software that runs a computer and lets other programs use it. Windows, macOS, Linux, Android and iOS are operating systems.
Information relating to an identified or identifiable living individual.
The risk that remains after considering the demonstrated effectiveness of controls.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
A grid that rates likelihood against impact, often on 1 to 5 scales, to rank risks into bands.
The estimated loss if a particular incident happens once.
A potential cause of harm, such as an attacker seeking unauthorised access.
A weakness that a threat may exploit.
A vulnerability that the vendor does not yet know about, so no fix has been developed when it can be exploited.
Sections now in other lessons
Earlier versions of this page included these sections. Each now has a fuller explanation in its own lesson.
- Qualitative and quantitative assessment now in Assessing Risk
- Reading the 5 × 5 matrix now in Assessing Risk
- Technical severity and business risk now in Assessing Risk
- Annualised Loss Expectancy now in Quantifying Impact: ALE and Business Impact Analysis
- What £5,000 per year means now in Quantifying Impact: ALE and Business Impact Analysis
- Using the estimate in a treatment decision now in Quantifying Impact: ALE and Business Impact Analysis
- Business Impact Analysis now in Quantifying Impact: ALE and Business Impact Analysis
- Follow the activity, not just the server now in Quantifying Impact: ALE and Business Impact Analysis
- Measurement and lifecycle now in Treating Risk
- Risk treatment options now in Treating Risk
- The legacy-server scenario now in Treating Risk
- Inherent and residual risk now in Treating Risk
- Reassess the database scenario now in Treating Risk
- Risk appetite and risk tolerance now in Treating Risk
- Organisational context now in Treating Risk
- A measurable disruption threshold now in Treating Risk
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.