Step 3 · ISO/IEC 27005:2022, Clause 7
ISO 27005 level of risk: assessing consequences and likelihood
Analysis gives each identified risk a level, from two estimates: what the organisation would lose if the scenario happened, and the chances that it happens. It does not invent its scales: it applies the ones set with the context. The whole point is to rate in a justified and reproducible way.
- Clause
- 7, Risk assessment: analysis
- Participants
- Risk owners, business owners, CISO, CIO
- Deliverable
- Consequences, likelihood and level of each risk, justified
Guide chapters
In brief
-
Analysis consists of three operations: assessing potential consequences, assessing likelihood, then determining the level of risk. These are also the three points of clause 6.1.2 d) of ISO/IEC 27001.
-
It can be qualitative, semi-quantitative or quantitative. The choice depends on the data available, not on a hierarchy between the approaches.
-
Consequences are assessed with the business, on what has value; likelihood is assessed with those who know the systems, the threats and the controls in place.
-
Each rating comes with a written justification: this is what makes the assessment "valid" and allows it to be repeated the following year.
-
The level obtained takes existing controls into account. It will serve as the point of comparison for the residual risk after treatment.
Qualitative, semi-quantitative or quantitative
The standard allows three types of analysis. None is better than the others in itself: a quantitative analysis built on fragile figures is less reliable than a qualitative analysis whose levels are well defined.
| Type | Principle | Suitable when | Limit |
|---|---|---|---|
| Qualitative | Levels described in words (limited, serious, critical) | Little data, need to talk with the business | Depends on the quality of the definitions |
| Semi-quantitative | Levels associated with values or ranges | You want to rank and aggregate without precise measurements | The numbers give an impression of precision they do not have |
| Quantitative | Measured values: amount of losses, annual frequency | Reliable data history, financial trade-off to justify | Requires data that few organisations have |
Assess the consequences
You assume the scenario has happened, and you ask the business concerned what it loses. The scale set with the context serves as the reading grid: length of interruption, cost, breach of an obligation, harm to people or to reputation.
- Look at all three properties. The same event can affect availability (the workshop stops), confidentiality (drawings leak) and integrity (machining programs are altered). You keep the heaviest consequence and note the others.
- Count indirect consequences. Penalties, notification to an authority, loss of a customer: they often weigh more than the cost of restoration.
- Take timing into account. A three-day stoppage does not weigh the same in a quiet period and the day before a delivery.
- Have the business do the rating. The risk owner is best placed to say what an interruption costs.
Assess the likelihood
Likelihood is the chance of the scenario happening. For an accidental event, history helps: past failures, frequency of errors. For a deliberate act, you reason instead about the motivation and means of the source, the exposure of the targeted asset and the obstacles to get through.
- Exposure: can the asset be reached from the internet, by a supplier, by every employee?
- Known vulnerabilities: configuration flaws, missing patches, shared accounts, lack of separation.
- Controls already in place and their real effectiveness, checked rather than assumed.
- What is happening elsewhere: incidents already suffered by the organisation, by its peers, by its sector. Public reports from cybersecurity agencies are useful here.
Determine the level of risk
The level of risk is derived from the two estimates, using the rule set in the criteria: a reading in a grid, or a calculation. There is nothing to decide at this stage, only a rule to apply. If a result surprises everyone, it is a sign that a rating or a scale definition needs revisiting, not that the level should be corrected by hand.
The analysis covers the situation as it is, with existing controls. Some organisations also estimate a "gross" risk, with no controls at all; this is not an obligation, and the exercise is often artificial. Our article Inherent risk and residual risk reviews these notions.
Running example: analysing Mécanique Vauclair's four risks
| Ref. | Consequences | Likelihood | Level |
|---|---|---|---|
| R1 Ransomware through remote maintenance | 4: workshop stopped for more than ten days, late-delivery penalties | 3: permanent remote access, shared account without multi-factor authentication, network not separated | 12, high |
| R2 Theft of a customer's drawings | 4: breach of confidentiality, contract at risk | 2: email is filtered, but drawings are accessible to the whole design office | 8, medium |
| R3 Administration error on the ERP | 2: two days of re-entry, limited delays | 3: frequent interventions, no procedure or prior test | 6, medium |
| R4 Theft of a laptop | 1: loss of the hardware, encrypted disk | 3: frequent travel | 3, low |
These levels do not yet say what to do. That is the purpose of evaluation, which compares them with the acceptance criteria.
Frequently asked questions
How do you calculate a level of risk under ISO 27005?
The standard gives no formula. The level of risk is determined from the assessment of consequences and the assessment of likelihood, using the rule the organisation has set in its criteria: most often a grid that crosses two scales. Annex A of the standard gives examples, without imposing them.
Do you need a quantitative analysis?
No. ISO/IEC 27005 allows qualitative, semi-quantitative and quantitative analysis. A quantitative analysis is only worthwhile if you have reliable data on losses and frequencies. Most organisations start with a qualitative analysis with well-defined levels.
What is the difference between consequence, impact and severity?
They refer to the same idea: what the organisation loses if the risk materialises. ISO/IEC 27005:2022 uses "consequence", the ISO 31000 term. EBIOS Risk Manager speaks of "severity", and common usage of "impact". What matters is to use a single term in your documents.
Should existing controls be taken into account in the analysis?
Yes. The analysis describes the real situation: likelihood and consequences are assessed with the controls already in place, provided you have checked that they work. The level obtained then serves as the reference for measuring the effect of treatment.
Sources
This chapter summarises and rephrases the official publications below. If in doubt, the official text prevails.
- ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection: guidance on managing information security risks (4th edition), ISO, October 2022.
- ISO/IEC 27005:2022, public preview: scope, terms and definitions, table of contents, ISO, Online Browsing Platform.
- ISO/IEC 27001:2022, Information security management systems: requirements, ISO, October 2022.
- ISO 31000:2018, Risk management: guidelines, ISO, February 2018.
- EBIOS Risk Manager, the guide (version 1.5, in French), ANSSI.
A platform and service that adapt to you
Our platform is designed for fine-tuned configuration and broad adaptability to your needs.