ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 threats and vulnerabilities are the raw material of a scenario-based or asset-based risk assessment. A threat is something that could cause harm, such as a ransomware group, a careless employee or a flood. A vulnerability is a weakness that a threat could exploit, such as unpatched software, weak access control or a single supplier. A risk exists where a threat meets a vulnerability in a way that could damage confidentiality, integrity or availability of information.
Teams often ask which ISO 27001 threats and vulnerabilities to list first; start with the assets that matter most to the business.
This guide explains how to identify threats and vulnerabilities for an ISO 27001 risk assessment, how to describe them clearly, how to link them to assets and controls, how to turn them into risk scenarios and how to keep the lists current. It is general guidance, and you should read the requirements of the standard itself and its companion guidance.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
ISO/IEC 27001 clause 6.1.2 requires you to identify information security risks associated with the loss of confidentiality, integrity and availability, and to identify risk owners. The standard does not prescribe an asset-and-threat method, so you may use asset-based, scenario-based or event-based approaches. But almost all methods rely on understanding what could go wrong and why it could happen, which is what threats and vulnerabilities describe.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Companion guidance such as ISO/IEC 27005 describes these concepts in detail, and public sources such as NIST SP 800-30 on conducting risk assessments provide catalogues and structured approaches. Use them as inspiration, and adapt the lists to your environment. See asset-based risk assessment and scenario-based risk assessment for how the concepts are used in each approach.
Start with who or what can cause harm. Threat sources include external attackers, insiders, suppliers, natural events, technical failures and human error. Then list threat events: phishing, ransomware, denial of service, data theft, accidental disclosure, misconfiguration, theft of equipment, power or network outage, fire, flood and legal or regulatory action.
Use several inputs: threat intelligence, incident history, industry reports, sector alerts, audit findings and staff knowledge. Consider both malicious and accidental threats. Note which are relevant to each asset or process; a laptop is exposed to theft in ways a data centre server is not.
Vulnerabilities can be technical, such as unpatched software or weak encryption, organizational, such as unclear responsibilities or missing procedures, physical, such as poor access to server rooms, or human, such as lack of training. They can also be structural: a single point of failure or dependence on one supplier.
Find them through vulnerability scanning, penetration tests, control assessments, internal audits, incident reviews and interviews. Compare the current state with your control set, including the controls in Annex A. A missing or weak control often marks a vulnerability. See ISO 27001 control assessment and ISO 27001 gap assessment for methods.
| Concept | Definition | Example |
|---|---|---|
| Asset | Something of value to the organization | Customer database, payment system |
| Threat | A potential cause of an unwanted incident | Ransomware attack, insider misuse, power failure |
| Vulnerability | A weakness that could be exploited | Unpatched server, shared admin account |
| Control | A measure that modifies risk | Patching process, multi-factor authentication |
| Risk scenario | Threat exploiting a vulnerability to harm an asset | Ransomware exploits unpatched server and encrypts customer database |
A risk arises only where a threat can act on a vulnerability of an asset that matters. Map them: for each important asset or process, list the threats that could affect it and the vulnerabilities that would let them succeed. This avoids listing every threat for every asset, which creates a huge and unusable register.
Also consider the value of the asset in terms of confidentiality, integrity and availability, since that determines the impact. A vulnerability in a low-value system is less critical than a similar weakness in a system holding sensitive customer data or supporting a critical service.
Combine the elements into a scenario statement: a threat exploits a vulnerability, affecting an asset and leading to a consequence. For example: “A phishing attack captures the credentials of an administrator without multi-factor authentication, allowing access to the customer database and leading to a data breach and regulatory penalties.”
Clear scenarios are easier to rate and to treat. They show which controls would help: multi-factor authentication, training, monitoring. Keep scenarios specific but not so numerous that they cannot be maintained. Group similar scenarios where they share causes and treatments.
For each scenario, note the controls already in place, and assess how effective they are. A vulnerability is only meaningful in the context of the controls that protect against it. Controls include technical measures, procedures, training and physical protections. Use evidence, such as test results and audit reports, to judge effectiveness.
Then rate likelihood and impact using your ISO 27001 risk criteria, considering the controls. Document the reasoning and the evidence. The result feeds your risk treatment plan; see the ISO 27001 risk treatment plan.
Threats and vulnerabilities change quickly. New attack techniques appear, software reaches end of life, suppliers change and business processes evolve. Review your threat list at least annually, and after significant incidents, alerts or changes to the environment. Feed vulnerability scan results and penetration test findings into the register regularly.
Assign an owner for threat intelligence and for vulnerability management. Link them to the risk process, so new findings trigger reassessment. Clause 8.2 of the standard requires risk assessments at planned intervals or when significant changes are proposed or occur.
Standard catalogues of threats and vulnerabilities help you avoid gaps, but they can also produce long lists of irrelevant items. Use them as checklists, and select only those relevant to your assets, environment and history. Add threats specific to your sector, such as fraud in finance or supply chain attacks in software.
Record why you excluded items, at least at a summary level. That shows the selection was deliberate. Compare with standards such as those in ISO 31000 vs ISO 27005, which explain how the risk management standards relate.
Frequent errors include listing generic threats without linking them to assets, confusing threats with vulnerabilities, ignoring insiders and suppliers, relying on scanner output without context, writing scenarios that are too vague to rate, forgetting non-technical vulnerabilities and never updating the lists. Another is producing thousands of scenarios that nobody can review.
Avoid these by focusing on important assets, writing specific scenarios, using evidence and reviewing regularly.
Security specialists know technical weaknesses, but process owners know how work is really done, where shortcuts are taken and which systems are critical. Run short workshops with both groups, and ask front-line staff about workarounds, shared accounts and unofficial tools, which often hide serious vulnerabilities. Include HR, facilities, procurement and legal, since threats and weaknesses arise in their areas too. Recording who contributed also helps show auditors that the identification was thorough and drew on the right expertise.
A company identifies its customer portal as a critical asset. Relevant threats include credential stuffing, exploitation of software flaws and denial of service. Vulnerabilities from scans and reviews include an outdated library, no rate limiting on login and no multi-factor authentication for administrators.
Three scenarios are written and rated using the risk criteria. Existing controls include a web application firewall and monthly patching. The team decides to treat the highest-rated scenario by adding multi-factor authentication and rate limiting, assigns owners and dates, and records the residual rating. The register links each scenario to the asset, the threat, the vulnerability and the control.
Use the results to prioritise vulnerability remediation, control improvements and monitoring. Report top threats and vulnerabilities to management as part of the ISMS review, together with trends: new threats, repeat findings and time to fix. Highlight where vulnerabilities persist because of resource or process gaps.
Keep evidence of the identification process for audit: sources used, meetings held, lists reviewed and decisions made. Auditors want to see that the process is systematic and repeated, not a one-time brainstorm.
If you want a report and workbook that link assets, threats, vulnerabilities, controls and ratings in a consistent structure, the ISO 27001 Risk Assessment Report and Workbook provides a layout for ISO 27001 risk assessment. Whatever tool you use, a clear understanding of ISO 27001 threats and vulnerabilities makes risk scenarios specific, ratings defensible and treatments targeted.
A threat is something that could cause harm, such as an attacker or a flood. A vulnerability is a weakness that a threat could exploit, such as unpatched software.
No. The 2022 edition does not prescribe a method. You can use asset-based, scenario-based or other approaches, provided the process is defined and consistent.
Threat intelligence, incident history, industry reports, vulnerability scans, penetration tests, audits, control assessments and staff knowledge.
Enough to cover important assets and risks, but not so many that they cannot be reviewed. Group scenarios that share causes and treatments.
At least annually and after significant incidents, new threat information or changes to systems, suppliers or processes.
September 30, 2026
