ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An ISO 27001 scenario-based risk assessment identifies information security risks by describing specific events that could happen, such as a ransomware attack on the finance network or the loss of a key cloud provider, and then rating each event’s likelihood and consequences. It starts from what could go wrong, not from an inventory of assets, and it often gives a clearer picture for leaders than a list of thousands of asset entries. This guide explains how an ISO 27001 scenario-based risk assessment works, what a good scenario contains, how to build and score a scenario library, how it can be combined with an asset-based approach, and what evidence auditors expect.
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:2022 requires a defined risk assessment process that produces consistent, valid and comparable results, identifies risks to the confidentiality, integrity and availability of information within scope, identifies risk owners, and analyzes and evaluates the risks. It does not prescribe assets, threats and vulnerabilities as the only route. The guidance standard ISO/IEC 27005:2022 describes two approaches: an event-based approach, which works with scenarios, and an asset-based approach. You can view the standard’s listing on ISO/IEC 27005:2022 on iso.org. Our guide to ISO 31000 and ISO 27005 explains how the two standards relate.
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
The choice is yours, provided you can show that the method meets the standard’s requirements and yields comparable results. For the asset-based alternative, see our guide to the ISO 27001 asset-based risk assessment.
A scenario is a short, specific story of a possible event and its consequences. Vague statements such as data breach are not scenarios, since they cannot be rated consistently. A well-formed scenario contains the following elements.
| Element | Question | Example |
|---|---|---|
| Threat source | Who or what causes the event? | Criminal group, malicious insider, supplier failure, natural event |
| Threat or event | What happens? | Ransomware encrypts file servers |
| Vulnerability or weakness | Why could it succeed? | Unpatched remote access, weak segmentation |
| Affected information and services | What is exposed or lost? | Finance systems, customer data |
| Consequences | What is the impact on the organization? | Three days of downtime, regulatory notification, financial loss |
| Existing controls | What already reduces the risk? | Offline backups, endpoint protection |
Start from sources that show what actually happens: your own incident history, near misses, audit findings, industry reports, regulator notices, threat intelligence and the experience of peers. Group scenarios by theme, such as cyber attack, data loss, supplier failure, insider misuse, physical event and human error, and by the business processes they affect. A library of thirty to sixty well-written scenarios is usually enough for a mid-sized organization, and it can be extended as new threats appear.
ISO/IEC 27005:2022 distinguishes scenarios at a strategic level from those at an operational level. Strategic scenarios describe events affecting the organization’s objectives, such as loss of a major customer’s trust after a breach. Operational scenarios describe technical sequences, such as compromise of an administrator account leading to data exfiltration. Using both lets leadership discuss strategic exposure while technical teams work on operational detail, and the two can be linked so that strategic scenarios are broken down into operational ones.
Rate each scenario using the same likelihood and consequence scales that your methodology defines. For likelihood, use evidence: how often similar events have happened in your industry and in your own history, the capability and motivation of threat sources, and the strength of current controls. For consequences, estimate the effect on operations, finances, legal obligations, customers and reputation, and use the worst credible case. Then compare the result with your acceptance criteria. Our guide to the ISO 27001 risk assessment methodology explains how to write those scales.
Where possible, use ranges and quantified estimates for the most important scenarios, for example the likely frequency of an event per year and the range of losses, since numbers support decisions on investment better than a colored cell. Record the basis of each estimate.
For each scenario above your criteria, choose treatment and link it to controls in Annex A of ISO/IEC 27001:2022, which contains 93 controls in four themes. A single control often addresses many scenarios, so show the mapping in both directions: the scenarios each control mitigates, and the controls that mitigate each scenario. The mapping shows whether a control is worth its cost and whether some scenarios lack any control. Our guide to the ISO 27001 risk treatment plan explains how the results feed the plan and the Statement of Applicability.
The two approaches can work together. A common pattern uses scenarios for strategic and cross-cutting risks and assets for detailed technical assessment of key systems. Another uses assets to build an inventory, then scenarios to identify the events that matter most for the important assets. Whichever pattern you choose, define it in the methodology so that results can be compared and consolidated in one register. Do not run two unrelated methods that produce numbers on different scales.
Assign a risk owner to each scenario, as clause 6.1.2 requires the identification of risk owners. Owners approve the treatment and accept the residual risk according to your criteria. See our guides to the ISO 27001 risk owner and to ISO 27001 risk acceptance. Keep the scenario library, the scores with their basis, the treatment plan, approvals and the review history as documented information.
Workshops are the usual way to build and rate scenarios. Invite process owners, IT and security staff, and someone from legal or compliance. Give them the draft library beforehand and ask them to add events they have seen or fear. Use a facilitator to keep discussion on evidence, and record dissent when people disagree on ratings. Keep sessions to about two hours, agree the ground rules at the start, and follow up quickly with the written results so that owners can confirm them.
A software company builds a library of forty scenarios. One reads: a criminal group gains access through a phished administrator account, deploys ransomware across the production environment and exfiltrates customer data before encryption, leading to several days of outage, regulatory notification and contract penalties. Existing controls include multi-factor authentication for most accounts, offline backups and endpoint detection. The rating shows a high inherent risk and a medium residual risk, driven by remaining accounts without multi-factor authentication and untested restoration. The owner, the head of engineering, accepts a treatment plan to close both gaps within a quarter, and the residual rating is reviewed after a restore test.
Auditors check that the method is documented, that scenarios are specific, that scores follow the defined scales and that owners and treatments are recorded. They test whether the scenarios reflect the organization’s real context, for example by asking why a scenario relevant to the business is missing. They also compare the risk register, the treatment plan and the Statement of Applicability for consistency. Be ready to explain why you chose the event-based approach and how you keep it current.
Teams write scenarios so broadly that they cannot be rated, use a long generic list unrelated to the business, forget to link scenarios to controls, assign no owners, mix scales between scenarios and assets, and never update the library after incidents. Another mistake is rating consequences by the best case. Use the worst credible case, and record it.
To avoid building the register from scratch, the ISO 27001 Risk Assessment Report and Workbook provides a structured report, scoring and a working register that can hold scenarios as well as assets. Whichever tool you choose, make the ISO 27001 scenario-based risk assessment specific, evidence-based and linked to owners and controls.
Yes. The standard requires a defined and consistent risk assessment process but does not prescribe assets and threats. ISO/IEC 27005:2022 describes an event-based approach.
Enough to cover your significant risks, commonly thirty to sixty for a mid-sized organization. Quality and specificity matter more than volume.
Using the likelihood and consequence scales in your methodology, with evidence for each rating and comparison against your risk acceptance criteria.
Yes, provided the methodology defines how they fit together and results are recorded on consistent scales in one register.
The documented method, the scenario library, scores and their basis, risk owners, the treatment plan and the Statement of Applicability, all consistent with one another.
September 30, 2026
