Information Security Risk: Threat, Vulnerability, Asset and Control
A threat is a potential cause of an unwanted incident. A vulnerability is a weakness of an asset or a control that can be exploited. A control is a measure that maintains and/or modifies risk. And risk itself is defined more broadly than most people expect: the effect of uncertainty on objectives.
A threat is a potential cause of an unwanted incident. A vulnerability is a weakness of an asset or a control that can be exploited. A control is a measure that maintains and/or modifies risk. And risk itself is defined more broadly than most people expect: the effect of uncertainty on objectives.
The information security risk chain, and why it is a chain
Asset → threat → vulnerability → risk → control. That chain is how most organisations think about information security risk, and an auditor uses it as a trail rather than as a definition list. One caution that matters in an examination: it is a method, not a requirement. ISO/IEC 27001 asks the organisation to identify risks to the confidentiality, integrity and availability of information within the ISMS scope; it does not prescribe how. Asset-based identification is one recognised approach, event-based identification is another, and an organisation using the second is not for that reason nonconforming.
That caveat is not pedantry. A candidate who believes asset-threat-vulnerability is mandatory will raise a nonconformity against a perfectly conforming event-based risk register, which is a wrong answer with a confident tone.
Those five words get used loosely everywhere, including by people who ought to know better. A phishing email is described as a risk; a missing patch is described as a threat; a firewall is described as a solution. None of that survives an audit, because the words are the reasoning. If you cannot say which is which, you cannot say what the finding is.
One point of housekeeping before the definitions, because it catches people out. These terms do not all live where you would expect. The family’s overview standard used to carry the whole vocabulary and no longer does; threat and vulnerability now sit in the risk management guidance for this family, risk and control come from the general risk management standard, and “asset” has not been a defined term in the overview standard for several editions — the familiar “anything that has value to the organisation” is from a superseded edition and survives in the guidance. Useful shorthand; not a current definition to quote.
Preparing for the PR373 exam?Full-length mock exams and exam application support are included.
Threat, vulnerability, asset, risk and control: the five words, precisely
| Term | Meaning | An example |
|---|---|---|
| Asset | Anything of value to the organisation — information, software, services, people, reputation. Widely used, but no longer a defined term in the family’s overview standard | The customer database, holding personal and payment data |
| Threat | A potential cause of an unwanted incident that may harm a system or organisation | An external attacker attempting to steal that data |
| Vulnerability | A weakness of an asset or a control that can be exploited by one or more threats | Administrator accounts protected by passwords alone, with no multi-factor authentication |
| Risk | The effect of uncertainty on objectives. Applied to information security, the potential that a threat exploits a vulnerability, expressed as a combination of consequence and likelihood | Unauthorised access leading to a data breach — assessed as high |
| Control | A measure that maintains and/or modifies risk — policies, processes, procedures and technical safeguards | Secure authentication (A.8.5), privileged access rights (A.8.2), logging and monitoring (A.8.15, A.8.16) |
Risk is defined as the effect of uncertainty on objectives. That is the definition to give if you are asked for one. In information security it is applied to the confidentiality, integrity and availability of information, and in practice organisations assess it as a combination of consequence and likelihood — which is the language the standard uses, rather than “impact”.
A control is a measure that maintains and/or modifies risk — policies, processes, procedures and technical safeguards. Both halves matter. A control that holds a risk at its current level is still a control, and the standards note that controls do not always exert the effect assumed of them, which is precisely why an auditor tests operation rather than intention.
Where a control does modify risk, it does so by changing the likelihood, the consequence, or both — a distinction worth carrying, because an organisation whose controls only ever address consequence has left every likelihood untouched, and that is a pattern worth asking about.
A worked information security risk example, all the way through
The chain is easiest to see run end to end on one risk.
Asset: the scheduling system that holds client contact details and appointment history. Valued highly, because losing it stops the business.
Threat: someone outside the organisation setting out to reach that data.
Vulnerability: privileged accounts that can be opened with a password alone, no second factor required.
Risk: one of those accounts being taken over and the data exposed. Rated at the organisation’s top level against its own criteria.
Risk owner: the Head of IT — identified, not implied.
Treatment option: modify.
Controls selected: secure authentication with multi-factor (A.8.5), privileged access rights (A.8.2), logging and monitoring (A.8.15 and A.8.16). Name the control reference, always — a finding is graded on whether it names the requirement.
Recorded: in the Statement of Applicability as applicable and justified, and scheduled in the risk treatment plan.
Residual risk: reassessed as low.
Acceptance: the Head of IT formally accepts the low residual risk, and there is a record of it.
Now read that as an auditor. Every one of those ten steps is a place where the chain can break, and a break at any of them is a finding. A risk with no named owner. A control with no justification. A residual risk nobody accepted. A treatment plan that exists but has not moved. The step that broke tells you which requirement to cite.
Want structured preparation?One year of LMS access and HD recordings come with the course.
ISO 27001 risk treatment options: modify, retain, avoid, share
An organisation can modify the risk by changing the likelihood or the consequence, retain it by informed choice, avoid it by not starting or continuing the activity that gives rise to it, or share it by splitting responsibility with another party.
Where the four come from matters. ISO/IEC 27001 itself does not list treatment options: Clause 6.1.3 a) requires the organisation to select appropriate options taking account of the risk assessment results, and stops there. Modify, retain, avoid and share are the set given in the risk management guidance in this family, and the wider risk management standard behind it gives a longer list — including taking or increasing a risk in order to pursue an opportunity, which the four-option version leaves out. An organisation using a different set of options is not for that reason nonconforming.
All four are legitimate. Accepting a risk is not a nonconformity, and an auditor who treats it as one has misunderstood the standard. What is auditable is whether the acceptance was a decision: made against defined criteria, by the person accountable, with a record.
Sharing deserves a second look: it is the option most often claimed and least often evidenced. An organisation saying a risk is transferred to a supplier should be able to show the contract term that does it, and should still be managing what it cannot transfer. Reputational damage does not move because a contract says a supplier is liable.
Not sure about the course yet?One year of free retraining on the same exam version is included.
Residual risk in ISO 27001, and who owns it
Residual risk is what remains after treatment. Two roles attach to it and they are not the same.
The risk owner is the person or entity with the accountability and the authority to manage a risk, and who accepts its residual level. Note both halves: accountability without authority is a name in a register. Note also that an entity qualifies — a named team or committee is not wrong in itself. The control owner is a different role: responsible for operating a control.
So a register naming a team as risk owner is not wrong on its face. What is worth testing is whether that team has the authority to manage the risk, and whether anyone in it has actually accepted the residual level with a record. A register where every risk belongs to “IT” usually fails the second test.
This is one of the most productive things to test in a real audit. Ask who accepted the residual risk on a specific high-rated entry, and ask to see the record. The answer is often a name from a policy rather than a decision.
Where risk vocabulary goes wrong in practice
A vulnerability described as a risk. “Unpatched servers” is not a risk; it is a weakness. The risk is what happens when something exploits it, and without that the impact was never assessed.
A control described as a risk. Registers that list “no encryption” as a risk are describing an absent control. The exposure it leaves is what needs assessing.
A threat with no asset. Threats are only interesting in relation to something of value. A register of threats with nothing attached to them cannot be prioritised.
Consequence and likelihood assessed with no criteria. Numbers exist and nobody can say what “4” means. The requirement is a process producing consistent, valid and comparable results, so this is a process finding rather than a quibble about the score.
Where the risk work meets the rest of the ISO 27001 ISMS
Those controls and their justifications land in the Statement of Applicability, required by Clause 6.1.3 d). It is the document an ISMS audit turns on, and it is not the risk treatment plan: the plan says how risks will be treated, the Statement says which controls are necessary, why each is included whether implemented or not, what its implementation status is, and why any Annex A control was left out.
Annex A supplies 93 controls in four themes — organizational (37), people (8), physical (14) and technological (34) — and the direction of travel is the thing to hold. Risk first, controls determined by the treatment, then Annex A as a completeness cross-check. The standard says in terms that its list is not exhaustive and that controls may come from any source, so a necessary control that is not in the annex belongs in the Statement of Applicability all the same.
An organisation that started from the 93 and worked backwards usually has a risk assessment written to justify decisions already taken. It reads differently, and it is worth spotting.
Threat, vulnerability, asset, risk and control: pick a term
Pick a term to see its precise meaning and an example.
How to use it: Choose the option that fits you from the list. The answer appears below.
From the table in this article. Keep the five words apart: confusing a vulnerability with a risk is the commonest slip in a risk register.
Frequently asked questions about threat, vulnerability, asset and control
What is the difference between a threat and a vulnerability in ISO 27001 risk assessment?
A threat is a potential cause of an unwanted incident — an actor or an event. A vulnerability is a weakness of an asset or a control that can be exploited. A threat with nothing to exploit produces no risk.
Is information security risk the same as likelihood times impact?
Risk is defined as the effect of uncertainty on objectives. The standard’s own language is consequence and likelihood, and it requires them to be assessed — not multiplied. What matters for an audit is that the organisation defined criteria and applies them consistently.
What is residual risk in ISO 27001?
The risk that remains after treatment. It must be accepted by the risk owner, and an auditor will look for a record of that acceptance rather than an assumption of it.
Can an organisation just accept a risk under ISO 27001?
Yes. Retaining a risk by informed choice is a recognised treatment option and is not a nonconformity. What is auditable is whether the acceptance was made against defined criteria by the risk owner, with a record.
Who is the risk owner in ISO 27001?
The person or entity with the accountability and the authority to manage a risk, and who accepts its residual level. Not the same as a control owner, who is responsible for operating a control.
Where to go next: more ISO 27001 Lead Auditor exam preparation
What an information security management system actually is
ISO/IEC 27001 explained for auditors, not implementers
Confidentiality, integrity and availability in an audit
Six myths that cost Lead Auditor candidates marks
3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP number 6039853. Its ISO 27001 Lead Auditor training course is the CQI and IRCA Certified ISO/IEC 27001:2022 Lead Auditor (Information Security Management Systems) Training Course. The course identification number is 2889. Both the partner approval and the course certification are on 3FOLD TRAINING’s Approved Training Partner record, and any provider’s certified courses can be looked up in CQI and IRCA’s own directory of certified courses and approved training partners. The course page carries the schedule and what the course includes. If you would rather ask a person first, use the course enquiry form.
Booking a PR373 course? See the schedule, trainers and what’s included.
Leave a reply