Scenario-based risk assessment

Scope: risk sources to a prioritised scenario set · Who: the officer whose assessment decides nothing · Prerequisites: approved criteria and stated objectives · First result: one scenario library

1. Why this exists (the failure mode it prevents)#

Four thousand rows, one per asset, each with a likelihood somebody guessed and a colour nobody chose. A quarter's work, and no committee has taken a decision from it.

The problem is the unit of assessment, not the effort. ISO/IEC 27002:2022 control 5.9 exists to identify information and other associated assets, then assign ownership ¹. An inventory is an input, not the assessment. Four symptoms follow.

Likelihood guessed per asset. A server cannot have a likelihood; only an event can. ISO/IEC 27005:2022 assesses it per scenario, from how often risk sources act and how easily weaknesses are exploited ².

A heat map nobody owns. Rows are coloured and sent to a committee with no decision attached, because owners were never named. The standard gives naming them a subclause of its own ³.

A set written once for the certificate. Never revisited, still describing an estate that has changed. The standard asks for two rhythms, a strategic cycle and a shorter operational one ⁴.

Quantification bought as precision. A loss figure to the currency unit, from inputs nobody calibrated. The annex is blunt: past a spread of roughly a thousand to one, more precision buys little ⁵.

How it surfaces#

ISO/IEC 27001:2022 places risk assessment at clause 6.1.2 and treatment at 6.1.3, repeating both as operations at 8.2 and 8.3 ⁶. Guidance says what the record carries: the risks with consequence and likelihood, the risk owners, the result of applying the acceptance criteria, and the treatment priority ⁷. An asset spreadsheet answers half of one. Under Directive (EU) 2022/2555 the measures rest on an all-hazards approach and open with policies on risk analysis and information system security ⁸. Under Regulation (EU) 2022/2554, financial entities review the risk scenarios affecting them at least yearly ⁹. Both are about scenarios.

One loop, not three silos#

Governance owns the boundary. It approves the criteria fixing what a consequence level means and where acceptance stops ¹⁰. It approves the scenario set, and names owners holding both accountability and authority ³. ISO 31000:2018 makes the same demand in its process clause: state how much risk, and of which kinds, the organisation will take against its objectives ¹¹. Risk owns the instrument, the scenario library: identification, analysis and evaluation run as scenarios rather than rows ¹². Compliance shows the loop closed: clause 6.1.2 records that compare across cycles, a decision per scenario, and an all-hazards answer that is not only about attackers.

2. Definitions (only the ones that cause disputes)#

Requirement text below is copyright and paraphrased; only clause numbers and printed titles appear as printed. Sources are ISO/IEC 27005:2022 throughout.

Term	Working definition	Source
Risk scenario	The sequence or combination of events running from an initial cause to an unwanted consequence.	ISO/IEC 27005:2022, 3.1.4
Risk source	An element that alone or combined can give rise to risk. Sorted as human, environmental or technical; a human source may act unintentionally.	ISO/IEC 27005:2022, 3.1.6
Desired end state	The situation a deliberate risk source wants to reach. It expresses motivation, which cannot be stated directly.	ISO/IEC 27005:2022, A.2.3
Event-based approach	Identification from risk sources and events, producing strategic scenarios without first enumerating assets.	ISO/IEC 27005:2022, 7.2.1, A.2.4
Asset-based approach	Identification from assets, threats and weaknesses, producing operational scenarios in those terms.	ISO/IEC 27005:2022, 7.2.1, A.2.5
Consequence	The outcome of an event as it affects objectives. One consequence can grow by cascading into others and by accumulating.	3.1.14
Likelihood	The chance of something happening, judged or measured. Broader than the mathematical reading of probability.	3.1.13
Level of risk	The significance of a risk, as the combination of consequences and their likelihood. No product is prescribed.	3.1.15
Risk owner	The person or entity with both the accountability and the authority to manage a risk. Two tests, not one.	3.1.5
Risk criteria	The terms of reference against which significance is judged, resting on objectives and context.	3.1.7

Those definitions were read in clause 3 ¹³. The end state and the two approaches sit in the annex ¹⁴. Strategic scenario and operational scenario are the standard's own names for what those approaches produce ¹⁵. Scenario library is defined nowhere: it is this publication's name for the maintained set, kept apart from the register, which holds decisions. Scenario owner and library keeper below are working terms too: the risk owner of one scenario, and whoever keeps the set current. Annex A is informative: it offers worked examples of technique for use during assessment ¹⁶.

3. The method — numbered steps, each with input, activity, output and owner#

3.1 Establish the context and reuse the criteria#

• Input: the approved scope, the objectives stated to the board, the obligations that bind the organisation.
• Activity: confirm scope and purpose, list the documents setting security rules inside it, reuse the criteria.
• Output: a one-page context note and a named version of the criteria set.
• Owner: the risk or management-system manager.

Clause 6.1 attaches organizational considerations to the management-system context, asks that the risk-owner role be determined, and expects appetite to be set and reviewed by top management. Clause 6.2 asks which reference documents define security rules inside the scope: the reference control set, sector standards, regulation, internal rules and contract terms. Clause 6.3 notes that assessments are embedded in many processes and should together cover the issues in scope ¹⁷. The scales belong to clause 6.4, not here ¹⁸. Take them from Risk appetite and criteria, and stamp the version used.

3.2 Choose the approach, and write down why#

• Input: the context note, the question this assessment must answer, the time available.
• Activity: decide whether identification starts from risk sources and events, or from assets and weaknesses.
• Output: one paragraph on the Read first sheet naming the approach and the reason.
• Owner: the risk manager.

Clause 6.5 asks for the chosen approach to be documented. It also requires repeated assessments to hold three named properties: consistency between assessors, comparability across risks, and validity against reality ¹⁹. Clause 7.2.1 settles the usual argument: the routes differ only in the level at which identification starts, and both can describe the same scenario. The event-based route drills down from the general level; the asset-based route searches upward from the asset ¹². So start event-based, where objectives are stated, and refine asset-based wherever a consequence cannot be sized without knowing which system carries it.

3.3 Build the risk-source list and the desired end states#

• Input: threat intelligence output, incident history, the supplier and partner map, the objectives.
• Activity: list the credible risk sources; for each deliberate one write what it wants to reach, for the rest write not applicable and why.
• Output: the Sources sheet, with a relevance rating and a basis on every row.
• Owner: the risk manager, with the function running threat intelligence.

The annex characterises a deliberate source on two axes, its motivation and its ability to act, with an example table of source types and their usual methods. Motivation cannot be stated directly, so it is expressed as a desired end state: the situation the source wants to be in afterwards. Beneath it sit target objectives, the things the source must do to the organisation's business assets to get there. Its classifications are examples, not a required taxonomy ²⁰. Write sources the organisation can evidence, and do not stop at deliberate ones. The definition covers human, environmental and technical sources alike ²¹, which is what an all-hazards duty asks for ⁸. ISO/IEC 27002:2022 control 5.7 asks that threat information be analysed into threat intelligence, across strategic, tactical and operational layers ²². NIST CSWP 29 records the activity at ID.RA-02 and ID.RA-03 ²³.

3.4 Write the scenario set#

• Input: the risk-source list, the objectives, the service and activity map, last cycle's library.
• Activity: write fifteen to forty scenarios, each naming a source, an event, the activities affected, the assets, the consequence type and the objective at risk.
• Output: the Scenarios sheet, a proposed owner per row, not yet scored.
• Owner: the facilitator, with the proposed owners present, not represented.

The grammar is the standard's. Clause 7.2.1 asks that the risks tied to losing confidentiality, integrity or availability be identified. It describes identification as finding, recognising and describing risks through their sources and events ¹². ISO 31000:2018 lists what identification should consider: sources, causes and events, weaknesses and capabilities, the value of assets, and the biases of the people in the room ²⁴. The annex shows the shape a finished scenario takes, pairing the strategic form with the operational form for one source and target objective ²⁵. Owners are named in the same sitting, an activity the standard gives its own subclause ³.

Fifteen to forty is a working range, not a rule from any standard: below fifteen the set describes favourite worries, above forty the forum cannot hold it. Coverage is the test. Assets enter as the thing the consequence lands on, not as the row. The annex asks that dependencies between business and supporting assets be documented, so one risk is not assessed twice ²⁶. Classification against the organisation's security needs ²⁷ is what this method uses to decide which earn a scenario of their own.

3.5 Assess consequences over time and against objectives#

• Input: the scenario set, the approved consequence scale, the objectives, the existing controls.
• Activity: work out what is lost when confidentiality, integrity or availability fails, in the owner's terms, then score against the anchored scale.
• Output: scored consequences, each recording the dimension that set the level.
• Owner: the scenario owner, advised by the function running the activity.

Clause 7.3.2 asks that these consequences be identified and assessed, with existing controls among the inputs. It points at losses from interrupted operations, at how severe the outcome is judged, and at recovery cost ²⁸. Two refinements make the score usable. Score over time, not at a point: an outage of an hour, a day and a week are three different consequences. Score against the objective, not the system: clause 6.4.3.4 asks that ranking cover consequences at strategic, tactical and operational levels, and effects beyond the organisation's boundary ²⁹. Take the scale from the criteria workbook, whose six dimensions run from financial to reputation, with the highest setting the level; that breadth follows clause 6.4.3.2 ³⁰.

3.6 Assess likelihood as a stated judgement with its basis#

• Input: the scored scenarios, the likelihood scale, incident and near-miss records, sector reporting, test results.
• Activity: assess likelihood against the anchored bands, and in the same row write the basis supporting it.
• Output: scenarios carrying a band and a citable basis.
• Owner: the scenario owner, with the analyst who holds the evidence.

Clause 7.3.3 asks that likelihood be assessed using the established criteria. It separates deliberate sources, where motivation, capability and resources matter, from accidental ones, where geography and the conditions producing human error matter. Its most useful passage names three uncertainties: the assessor's personal uncertainty, the methodological uncertainty of tools that model events simply, and systemic uncertainty where evidence is thin. Four countermeasures follow: assess in a team, use outside sources such as breach reports, choose a scale that suits the organisation, and write unambiguous categories ². The annex adds that assessors should practise periodically against an anchoring reference scale ³¹.

3.7 Determine the level, evaluate against the criteria, prioritise#

• Input: scored consequences and likelihoods, the approved lookup, the acceptance criteria.
• Activity: read the level off the lookup, mark each scenario inside or outside appetite, then order what falls outside.
• Output: a dated, prioritised list for treatment, noting the confidence in each assessment.
• Owner: the risk manager, confirmed by the management forum.

Clause 7.3.4 has the level follow from assessed likelihood combined with assessed consequences, and notes the calculation need not be linear. The route must be the one the criteria already fixed ³². The annex adds a caution: a real risk profile is asymmetrical, so a matrix drawn symmetrically about its diagonal is unlikely to represent one ³³.

Evaluation is two acts. Clause 7.4.1 compares levels against the criteria, and asks that the degree of confidence be weighed. Any gap between the assessed level and the level the owner perceives is investigated ³⁴. Clause 7.4.2 prioritises what needs treatment, against objectives, obligations and interested parties ³⁵. ISO 31000:2018 puts evaluation at 6.4.4 and lists what it can lead to, from doing nothing further to reconsidering the objective ³⁶. The queue is the deliverable: a set that ranks nothing has been scored, not evaluated.

3.8 Hand off to treatment and acceptance#

• Input: the prioritised list, the acceptance criteria, the cost of the options.
• Activity: record one treatment option per scenario outside appetite, then hand it to the register, which holds the decision, approver and date.
• Output: register rows carrying an option; acceptance records where the option is retention.
• Owner: the scenario owner; acceptance above the delegated level goes to the forum.

Clause 8.2 lists the options, and the names it prints are risk avoidance, risk modification, risk retention and risk sharing. Selection weighs the assessment outcome against expected cost and benefit. Where sharing is chosen, at least one control must still change likelihood or consequence: the organisation has delegated the work, not the risk ³⁷. The register template's shorter forms (avoid, modify, retain, share) are the same four. Clause 8.3 admits only controls with more than a negligible effect ³⁸. The plan, approval and acceptance of residual risk are 8.6.1 to 8.6.3 ³⁹.

This seam is where the three disciplines stay one loop. Governance decides who may take which level and signs the set. Risk carries the scenario into a register row. Compliance shows one artefact chain, from a clause 6.1.2 record through a treatment decision to the applicability entry it justifies ⁴⁰. See The risk register other people trust and Risk acceptance and residual risk.

3.9 Where quantification helps, and where it lies#

Except where a clause is cited below, this step is GRCIDE's working view, not a requirement of any standard cited here, and names no method, product or supplier.

• Input: the scenarios at the top two levels, the finance function's loss conventions, the pending decision.
• Activity: for those scenarios only, state consequence as a range and likelihood as a frequency over a stated period.
• Output: a short quantified annex for the top two levels, and nothing for the rest.
• Owner: the risk manager, with the finance function.

The standard permits qualitative, quantitative and semi-quantitative scales, and argues against gold-plating: rough initial estimates can be enough for an efficient decision ⁴¹. Where numbers are used, clause 6.4.3.4 asks that scales rest on a reference everyone understands, and be re-calibrated at least periodically ²⁹.

• Ranges beat points. A single expected-loss figure hides the uncertainty that made it interesting; two numbers and a stated confidence invite the argument that improves it.
• Calibrated judgement beats uncalibrated data. A frequency band claimed against a dated record is evidence; the same band claimed against a feeling is not.
• Quantify only where a decision turns on it. If no decision changes when the number is wrong by a factor of three, the number is decoration.

3.10 Keep the set alive#

• Input: the scenario library, the change pipeline, the incident and supplier feeds, monitoring output.
• Activity: give every scenario a trigger and a review date, turn retained ones into monitoring scenarios, re-run the set annually and on major change.
• Output: a library where nothing is past its review date, plus a dated events log.
• Owner: the library keeper; the scenario owner reviews.

Clause 10.5.1 sets out what monitoring is for: confirming treatments work, improving future assessments, learning from incidents and near misses, detecting changes in context, and spotting emerging risk. It also makes the connection this step needs: retained risk scenarios can become monitoring scenarios ⁴². Clause 10.5.2 lists the factors to watch: newly reported weaknesses, assets brought into scope, changes in law, changes in appetite, and incidents inside and outside the organisation. It also asks that low and retained risks be reviewed one by one and in aggregate ⁴³.

The annex gives the mechanism a shape. Monitoring risk-related events means identifying the factors that show a scenario starting, and building them into the organisation's own monitoring. Its four-part model covers the source, the technique performed, what it is performed on, and the condition allowing detection ⁴⁴. Where those become standing measures, Key risk indicators that predict, not describe applies. Two rhythms run: the strategic cycle re-opens the whole set when context moves, the operational cycle reviews individual scenarios far more often ⁴. Clause 5.1 lets both iterate and add depth at each pass ⁴⁵. The cycle's report reaches the forum through management review ⁴⁶. None of this holds if the asset picture goes stale. Control 8.8 makes an accurate inventory a prerequisite for handling technical weaknesses ⁴⁷. NIST CSWP 29 places inventory maintenance at ID.AM-01 to ID.AM-04, and asset prioritisation at ID.AM-05 ⁴⁸.

3.11 The disruption seam#

• Input: the library, filtered to scenarios whose consequence is loss of an activity or service.
• Activity: hand those to the continuity method as disruption scenarios, and take back the recovery objectives it sets.
• Output: a marked subset, with consequence rows referencing those objectives.
• Owner: the risk manager, with the continuity owner.

The seam runs both ways. A continuity analysis needs disruption scenarios to test, and the library holds them already, owned and in one grammar. The assessment needs the recovery objectives that analysis produces: a service consequence cannot be scored without knowing how long the organisation has agreed to be down. Directive (EU) 2022/2555 puts continuity, backup, disaster recovery and crisis management in the same measures list as risk analysis ⁸. The continuity side is Business continuity under ISO 22301.

4. Deliverables (with template links)#

Deliverable	Format	Template	Retention
Risk criteria set, version stamped	xlsx	/templates/risk-criteria-and-appetite	Live version; superseded three years
Risk-source list with end states	xlsx, Sources sheet	/templates/scenario-library	Live version; snapshots three years
Scenario library and its prioritised list	xlsx, Scenarios sheet	/templates/scenario-library	One snapshot per cycle, three years
Register rows and decisions	xlsx	/templates/risk-register	Live version; snapshots three years
Monitoring events log	xlsx, Events log sheet	/templates/scenario-library	Three years

Retention periods are a working default; where the management system sets a rule for documented information, it wins.

5. What the auditor (and the board) will ask#

6. Failure modes we see and how they show up in findings#

7. Mapping to standards (clause table, verified)#

ISO/IEC 27001:2022 clause titles come from this site's source log, with its original access date ⁶. The rest were read in licensed copies ^{49 50}. The identifiers come from the CSF 2.0 appendix, where ID.IM-01 has improvements identified from evaluations ⁵¹. Annex A subclauses are informative and marked as such.

Method step	ISO/IEC 27001:2022	ISO/IEC 27005:2022	ISO 31000:2018	NIST CSWP 29	Evidence
3.1 Context and criteria	6.1.2 Information security risk assessment	6.1, 6.2, 6.3; 6.4.2, 6.4.3	6.3.4 Defining risk criteria	GV.RM-01, GV.RM-02	Context note; stamped criteria
3.2 Choose the approach	6.1.2	6.5 Choosing an appropriate method	6.4.1	GV.RM-06	Read first paragraph naming it
3.3 Sources and end states	6.1.2	A.2.3, informative	6.4.2 Risk identification	ID.RA-02, ID.RA-03	Sources sheet with relevance and basis
3.4 Scenario set and owners	6.1.2	7.2.1; 7.2.2 Identifying risk owners; A.2.2, A.2.4 to A.2.6, informative	6.4.2	ID.AM-05, ID.RA-03	Scenarios sheet, owner per row
3.5 Consequences	6.1.2	7.3.2 Assessing potential consequences; 6.4.3.2	6.4.3 Risk analysis	ID.RA-04	Rating plus its dimension
3.6 Likelihood	6.1.2	7.3.3 Assessing likelihood; 6.4.3.3	6.4.3	ID.RA-04	Band plus a citable basis
3.7 Level and evaluation	6.1.2	7.3.4; 7.4.1; 7.4.2; 6.4.3.4	6.4.4 Risk evaluation	ID.RA-05	Prioritised list, dated
3.8 Treatment handoff	6.1.3 Information security risk treatment	8.2 Selecting appropriate information security risk treatment options; 8.3 to 8.6	6.5.2 Selection of risk treatment options	ID.RA-06	Register row: option, approver, date
3.9 Quantification	6.1.2	7.3.1; A.1.1.3.1, informative	6.4.3	GV.RM-06	Quantified annex, top two levels
3.10 Keep the set alive, report the cycle	8.2 and 8.3 as operations	5.1; 5.2; 10.4.3; 10.5; 10.6; A.2.7, informative	6.6 Monitoring and review; 6.7 Recording and reporting	ID.IM-01	Events log, review dates, forum minute
3.11 Disruption seam	6.1.2	7.3.2	—	outside the categories cited here	Marked subset; recovery objectives

Two instruments sit alongside the table. Directive (EU) 2022/2555 requires measures proportionate to exposure, size and incident severity ⁵². It opens with policies on risk analysis and information system security ⁵³. Regulation (EU) 2022/2554 asks financial entities to identify, classify and document ICT-supported business functions and their assets ⁵⁴. Entities other than microenterprises assess each major change ⁵⁵.

8. Checklist (interactive)#

• The criteria set applied this cycle is named and version-stamped.
• The chosen approach is written down with its reason, on the library's Read first sheet.
• The Sources sheet carries human, environmental and technical sources.
• Every deliberate source has a desired end state; every other source says not applicable, and why.
• The library holds fifteen to forty scenarios, and every stated objective appears in one.
• Every scenario names a source, an event, the activities affected and the assets involved.
• Every scenario names an owner role holding both accountability and authority.
• Every likelihood band cites a dated record, report or control test.
• Levels are read off the published lookup, never by multiplying two ordinal scores.
• Scenarios outside appetite are ordered and dated, each with one option in the register.
• Every scenario has a review trigger and a review date, and none is past it.
• Retained scenarios have become monitoring scenarios, with indicators someone watches.
• Quantified estimates exist only for the top two levels, each naming the decision it should change.

References#

1. ISO/IEC. Guidance on managing information security risks. ISO/IEC 27005:2022, fourth edition, licensed copy ⁵⁶
2. ISO/IEC. Information security management systems. ISO/IEC 27001:2022 ⁵⁷
3. ISO. Risk management — Guidelines. ISO 31000:2018, licensed copy of the identical national adoption ⁵⁸
4. ISO/IEC. Information security controls. ISO/IEC 27002:2022, licensed copy ⁵⁹
5. NIST. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 2024. https://doi.org/10.6028/NIST.CSWP.29 ⁶⁰
6. European Parliament and Council. Directive (EU) 2022/2555. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁶¹
7. European Parliament and Council. Regulation (EU) 2022/2554. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁹

Related: Risk appetite and criteria, The risk register other people trust, Risk acceptance and residual risk, An ISMS people actually use, Security risk inside enterprise risk management.

Scenario counts, review rhythms and the quantification tests above are working defaults, not requirements of any standard cited here.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.