ISO 27001 Threat and Vulnerability Catalogue: Use It Without Distorting Risk

A catalogue of threats and vulnerabilities can improve an ISO/IEC 27001 risk assessment, but only when it is used as a prompt. It is not a ready-made risk register, a universal statement of what will happen, or proof that every listed item applies.

The purpose is to help assessors notice plausible conditions and events they might otherwise miss. Each prompt still needs to be connected to the organisation’s services, information, assets, context, existing controls and potential consequences.

Keep the risk concepts distinct

Weak assessments often combine several concepts in one label. Separating them produces scenarios that people can evaluate and treat.

Concept	Working meaning	Example
Asset or service	Something the organisation values or relies on	Customer support platform
Threat	A potential cause of an unwanted event	Criminal credential theft
Vulnerability	A weakness or condition that could be exploited	Legacy authentication without stronger verification
Event	What may occur	Attacker obtains a support administrator session
Consequence	The resulting business harm	Customer data disclosure and service disruption
Control	A measure that changes risk	Phishing-resistant authentication and privileged-session monitoring

These descriptions are working aids, not reproduced definitions from the standards. Organisations may use different risk vocabularies. The important point is internal consistency and an intelligible path from cause to business impact.

What a catalogue should and should not do

A well-designed catalogue can:

• prompt consideration of human, physical, technical, environmental and supplier-related causes;
• improve consistency between assessors;
• support workshops without starting from a blank page;
• identify commonly overlooked conditions;
• help explain why a scenario was considered; and
• provide a controlled source that can be updated as context changes.

It should not:

• replace knowledge of the actual service and architecture;
• cause every prompt to be copied into the risk register;
• determine likelihood or impact without evidence;
• treat a missing control automatically as a vulnerability;
• prescribe treatment before risk has been evaluated; or
• imply that the catalogue is exhaustive.

The ISO 27001 risk-assessment guide explains the broader requirement for consistent criteria and repeatable results.

Organise prompts around credible sources

A flat list becomes difficult to navigate. Group prompts so assessors can choose the most relevant lens for the service under review.

Possible threat-source groups include:

• malicious external actors;
• insiders and authorised users;
• accidental human action;
• supplier and supply-chain events;
• technology or utility failure;
• physical and environmental events; and
• legal, regulatory or market change.

Possible vulnerability groups include:

• governance and ownership gaps;
• identity and access weaknesses;
• insecure configuration or software defects;
• insufficient monitoring or response capability;
• weak physical protection;
• inadequate resilience and recovery;
• supplier-control weaknesses; and
• poor information handling or lifecycle management.

Categories are navigation aids. They should not create artificial silos. A ransomware scenario may involve stolen credentials, weak segmentation, inadequate backups and delayed detection across several categories.

Turn prompts into business scenarios

The most useful unit of assessment is a scenario that connects a cause and condition to an event and consequence.

A simple construction is:

Because of a relevant threat and vulnerability, an unwanted event may affect a named service or information asset, leading to defined business consequences.

For example: because a support supplier uses shared privileged credentials and activity is not attributable, misuse or theft of those credentials could allow unauthorised changes to customer records, causing integrity loss, contractual breach and recovery work.

This is assessable. The team can inspect the supplier arrangement, access design, logs, incident history and affected service. “Cyberattack” alone is not specific enough to score or treat.

The risk register guide provides a practical structure for recording ownership, treatment and residual risk after a scenario has been articulated.

Adapt the catalogue to context

Start with relevant external sources, prior assessments, incident records, vulnerability-management results, supplier reviews, architecture work and staff knowledge. Then remove, add or refine prompts for the organisation.

Consider factors such as:

• industry and regulatory obligations;
• information sensitivity;
• service availability commitments;
• technologies and hosting models;
• geographic and environmental exposure;
• reliance on third parties;
• remote and mobile working;
• adversary interest and capability; and
• recent incidents and near misses.

A small software company and a hospital may share some prompts but apply them to very different assets, consequences and tolerances. The catalogue should reflect those differences.

Avoid common assessment errors

Copying prompts as risks

Rows such as “malware,” “fire” or “human error” lack an affected service and consequence. Require assessors to explain relevance before a prompt becomes a risk scenario.

Counting one scenario many times

Several vulnerabilities can contribute to the same event. Conversely, one vulnerability can contribute to several consequences. Use stable scenario identifiers and map contributing conditions to avoid inflating risk totals.

Confusing absence of a control with vulnerability

A control may be unnecessary because the scenario is not relevant, because another measure achieves the objective, or because risk is accepted within criteria. Describe the actual weakness—for example, inability to attribute privileged actions—not simply “control missing.”

Scoring without evidence

Likelihood should be informed by exposure, threat capability, control performance, change and observed events. Impact should relate to business consequences. The risk matrix guide explains how to keep scales intelligible.

Treating vulnerability scan output as the whole catalogue

Technical findings are one valuable source, but they do not cover people, suppliers, facilities, governance or business-process weaknesses. They also need asset and exploitability context before they support a risk conclusion.

Govern catalogue changes

Assign an owner for the catalogue and define when it is reviewed. Useful triggers include:

• a material incident or near miss;
• adoption of new technology or service models;
• threat-intelligence changes relevant to the organisation;
• new legal or contractual obligations;
• significant supplier or architecture changes;
• audit findings; and
• lessons from exercises and testing.

Version the catalogue, record the source and rationale for material changes, and explain how those changes affect existing assessments. Updating prompts without reconsidering current risks creates the appearance of maintenance without changing decisions.

Connect prompts to controls and treatment

Do not choose controls directly from a threat label. First evaluate the scenario using the organisation’s criteria, consider current controls, determine risk and decide treatment. Then select measures that change likelihood, consequence or both.

The ISO 27001 risk score calculator can help test a scoring approach. The Annex A control lookup can help explore relevant control purposes after the risk and treatment objective are clear. Neither tool replaces the organisation’s approved method or accountable decision.

Evidence that the catalogue improves decisions

Design evidence can include the taxonomy, source criteria, version control, ownership, review triggers and instructions for turning prompts into scenarios. Operating evidence should show actual use.

Useful operating evidence includes:

• workshop records showing considered and rejected prompts;
• scenarios traced to assets and business impacts;
• evidence supporting likelihood and impact judgments;
• updates following incidents or material changes;
• treatment decisions linked to evaluated scenarios; and
• approval of residual risk by the assigned authority.

An auditor can sample scenarios across different services and ask:

1. Which catalogue prompts informed this scenario?
2. Why are the threat and vulnerability credible here?
3. Which evidence supported the rating?
4. How were current controls considered?
5. Who owns treatment and residual-risk acceptance?
6. What would trigger reassessment?

An effective result shows a reasoned chain. A partial result shows a maintained catalogue but generic scenarios or weak evidence. An ineffective result shows bulk-copied prompts, inconsistent scoring and no connection to accountable decisions.

Use the catalogue as a thinking aid

The catalogue succeeds when it broadens attention while preserving context. It should help teams form clearer scenarios, not create more rows. Keep it current, tailored and linked to evidence, and it becomes a practical part of repeatable information-security risk assessment.

This guidance was cross-checked against the official ISO/IEC 27001 overview and the ISO/IEC 27005:2022 overview. AuditPrepared’s categories and examples are guidance rather than prescribed ISO language.