"Risk management"


Categories: Club EBIOSEBIOS Risk ManagerQ&A

The EBIOS RM method was updated in 2018, and the ISO 27005 in November 2022. Both updates are major, and redefine the focus on risk management based on the business, cybersecurity and privacy. The objective of this article is to clarify the link and the existing relationship and compatibility between the ISO standard and the French method.

The ISO 27005 standard describes the general outlines of a cyber risk management: context establishment, identification and evaluation of the risks taken, and the risk treatment options to reach acceptable residual risk levels. It introduces a risk assessment process in accordance with the ISO 31000, without giving a method stricto senso. Strongly linked with the ISO 27001/27002 standards and using the vocabulary mainly defined in ISO 27000, the ISO 27005 uses, like many management systems, the logic of iteration and continuous improvement.

EBIOS RM is a security risk assessment method that is now 25 years old. It was defined by the ANSSI, with the support of the EBIOS Club. It describes in details the procedure to be followed to carry out a security risk assessment (general steps and good practices).

The latest update of the method is highlighting agility, and representativeness rather than exhaustiveness: the idea is no longer to identify all the security risks, but only the most important or significant ones. It is also intended to be more flexible based on the organisation’s maturity and the associated objective.

Questions about the link between the ISO 27005 & EBIOS RM are regularly raised, for the following reasons:

  • In France, EBIOS RM is widely known and used as a security risk assessment method. It is the national method and is referenced by ENISA. However, it does not have the same recognition beyond our borders, where the reference is the ISO 27005 framework instead of national methods.
  • As EBIOS RM is a method, by definition it is an instantiation of ISO 27005,and by consequence it is not a standard. By comparison, the ISO 27005 is a standard providing a model, but not specifying a method to implement it. In fact, when implementing an ISMS that follows the ISO 2700x family of standards, the need immediately arises to identify whether or not the risk assessment method selected is compatible with the chosen normative framework.
A framework relies on a model
A framework is based on a model, and is therefore a skeleton from which a concrete implementation can be made. It is a reification, providing a general logic. A method is the implementation of this abstraction, i.e., a real, materialized process, usable on concrete projects. It is by definition systematic but must remain adapted to the context.

Links EBIOS RM & ISO 27005

General workflow

EBIOS Risk Manager

EBIOS RM workflow
EBIOS proposes an approach built around 5 workshops. Each workshop importance will change according to the objective set for the risk assessment and the maturity of the scope concerned. The proposed workshops are as follow:

  • Defender point of view: what needs to be protected, and why?
    Workshop 1 focus on the scope of the study. The analyst seeks to define precisely the boundaries (where the study begins and ends), the situation with regards to the legal, normative or regulatory status (the security base), and what the business team fears.
  • Who is the attacker and why is he attacking?
    Workshop 2 is focusing on the attacker, whom we will try to evaluate in terms of resources and motivation.
  • Where will the attacker start?
    Workshop 3 focuses on the ecosystem (everything that interacts with the perimeter without being part of it) and its possible use by an attacker.
  • How will the attack be performed?
    Workshop 4 evaluates the likelihood of the possible attack paths identified, by looking at the operating methods (described in operational scenarios) used by an attacker.
  • Which treatment options for the risks identified?
    Workshop 5 is a classic remediation activity: now that the risks have been identified, how can they be reduced? Is the activity too risky to be performed? Should they be dealt with, transferred, can they be accepted?

ISO 27005

The approach proposed by ISO 27005 also includes 5 major steps:

  • The context establishment (§6)
  • Risk assessment:
    • The risk identification (§7.2)
    • The risk analysis (§7.3)
    • The risk evaluation (§7.4)
    • The risk treatment (§8)

The ISO 27005 is also adding two other parallel activities: communication (§10.3) and the monitoring & review activity (§10.5).
ISO 27005 workflow

Link between ISO 27005 activities & EBIOS RM workshop

The context establishment

ISO 27005 starts with the identification of the requirements of the stakeholders, including standards, contractual requirements ,regulations, possible addition from the SSIP , etc. It is a straight forward link to the EBIOS RM activity of establishing the security baseline.

Non-compliances: In both cases, the main idea is that identified non compliances will provide a clear view of the maturity of the studied perimeter, and feed the following subsequent risk assessment workshops. Indeed, each non-compliances or exceptions will be considered to assess the likelihood of the risk scenario to which the system under study is exposed.

Scales: To answer to how the risk assessment can be done and risk levels evaluated scales & matrices are identified: the severity of the feared events, the likelihood, and the policy of acceptance for the identified risks.

Consequences: For the evaluation of the severity, an important change of word appears: the ISO 27005 does not speak of feared events, but uses the term consequence (previously called impact). The evaluation is done through the criteria of consequences, and their severity, through the identification of the damage done. It simply corresponds to the notion of impacts existing in EBIOS RM.

Likelihood: For the likelihood, the ISO 27005 proposes the use of scales based on probability of occurrence or frequency. EBIOS RM let the user free to define its evaluation mechanism for likelihood, and is more focused on the success realism. The likelihood paramaters from an EBIOS RM risk assessment (if the method guides are followed) will probably require post-processing or adaptation in this case, following the ISO recommendations.

EBIOS RM has, in theory, a more continuous approach to the construction of these elements (they are defined as the study progresses), but in practice this is often a subject to define from the beginning. Criteria should be aligned with the one already existing in the company or organisation, to ease sharing the results obtained afterwards.

The last criterion is for the risk acceptance: according to the previous criteria (severity and likelihood to define a risk level), how does the organisation behave facing risks identified? It is directly linked to the security risk treatment. This assessment of risk appetite is not specific to the cyber sphere. The ISO 27005 and EBIOS RM are this time completely aligned.

Risk assessment

Risk assessment, in the ISO 27005, involves three steps: identification, analysis and evaluation.

Risk identification

Risk identification according to ISO 27005 is the process dedicated to recognising and describing risks. It involves determining the sources and what can happen. The objective is to have at the end of this activity a list of risks that can lead to the realisation of consequences, threatening the achievement of the identified security objectives. In EBIOS RM, the risks identification is not monolithic. It is carried out step by step, and each workshop will help to construct and specify it:

  • The first EBIOS RM workshop identifies the feared events and what needs to be protected (primary/business assets);
  • The second EBIOS RM workshop filters risk sources and target objectives associated to retain only the most relevant ones. It should be noted that there is a major difference in semantics between EBIOS RM and ISO 27005: EBIOS RM is only looking for intentional sources (the security baseline manages the accidental one), while ISO 27005 explicitly includes unintentional sources. Furthermore, ISO 27005 makes a distinction between the short-term objectives of the attacker and his long-term objectives (desired end state), whereas EBIOS RM does
    not explicitely distinguish the two elements. This topic is described in the (informative) annexes;
  • The third EBIOS RM workshop creates the link between feared events, risk sources and primary assets: the combination of these elements allows to identify risk scenarios, and thus to reach the objective of risk identification set by ISO 27005.

ISO 27005 identifies two approaches for risk identification: event and ecosystem-based or supporting assets based. Annex A clearly shows the direct link between these two approaches and workshops 3 (respectively 4) of the EBIOS RM method.
ISO 27005 links

EBIOS RM & ISO 27005
This relationship and the core definition of the 2 approaches defined in the ISO document is the pillar of the compatibility between EBIOS RM method and the ISO 27005 standard.

Vulnerabilities: There is, however, a concept spelled out in ISO 27005 that is not directly identified in EBIOS RM: the vulnerability management. In conjunction with the workshop 4 (or the asset-based approach), the integration of vulnerabilities into the risk assessment process allows the organisation to propose a specific treatment of the risk at a detailed level. This proposal can be seen as an extension to the EBIOS RM approach, but is in no way contradictory.

Risk analysis and assessment

This step is designed to evaluate the identified risks through a set of criteria determined beforehand. This work will enable each risk to be associated to a risk level defined as a combination of consequence severity & likelihood defined during the assessment. It is (again) carried out during the various EBIOS RM workshops:

  • the willingness to act in workshop 2, known as “relevance”;
  • the severity is assessed during Workshop 1, when the feared events are identified;
  • the likelihood is assessed in a general way in workshop 3, or/and in a detailed way in workshop 4. In both cases, and whether in EBIOS RM or ISO 27005, the difficulty of the exercise and its necessary subjectivity are underlined.

These values will then be used to classify the risks by comparing them with the risk acceptance criteria defined by the organisation: this equivalent to placing each risks on a risk acceptance matrix, where each cell reflects these criteria.

Risk treatment

The ISO 27005 proposes a general treatment of risks split in several steps:

  • choosing the most appropriate risk treatment option, assuming that reduction is the priority choice;
  • preparing a Statement of acceptability (SoA), in line with Annex A of ISO 27001;
  • formalising a risk treatment plan;
  • accepting the residual risks.

The ISO recommends to identify if a control is identified in the ISO 27002 before creating a new one.

EBIOS RM simplifies the choice of the risk treatment option, giving priority to reduction or acceptance according to risk levels. The notion of a SoA does not appear either, but it is a documentary production that can be made from the results obtained in each workshop. The risk treatment plan definition and the acceptance of residual risks are nearly done in the same way.

Transversal process: communication and monitoring

The ISO 27005 presents the communication process in the following way: “information on risks, their causes, consequences, likelihood and the means of control implemented to deal with them are communicated […] to the interested parties”. This communication is present in EBIOS RM, but is not identified as a specific activity. Instead, it is an integral part of each step, because it is part of the mindset of the method: risk assessment is by definition a tool for sharing and communication.
The several graphic representations (radar, strategic and operational scenarios, etc.), but also the strong desire (in terms of vocabulary and implementation) to place the business as the central point are the concrete proofs.

Monitoring scenarios: Among the communication and monitoring activities, the translation of risk scenarios into monitoring scenarios and correlation rules to be integrated in the detection tools of an organisation ensures that the most critical risks can be detected. Or at least it can help an organisation to identify a lack of detection capability. This part, which makes the link with ISO 27035 (standard on security incident management) and SOC activities, is not in the EBIOS RM method but comes from a contribution of the Club EBIOS (French security risk assessment expert community) resulting from the feedback of its practitioners.

Trigger: For the review and monitoring process, the ISO 27005 provides details on the implementation of the monitoring of identified risks. The notions of strategic and operational cycles are taken up stricto senso, but the ISO 27005 introduces the trigger notion, a condition that effectively initiates the risk assessment update.

Summary of wording equivalences

Stakeholder Interested parties
Scope and Security baseline Context establishment
Strategic scenario Event based approach & Strategic scenario
Operational scenario Asset based approach & Operational scenario
Feared event Consequence
Intermediate event Intermediate consequence
Business asset Primary asset & business asset
Supporting asset Supporting asset
Risk origin Risk source
Threat level Danger level
Security continuous improvement plan Risk treatment plan
Impact Consequence criteria
Security need Security target
Severity Severity
N/A Trigger criteria


The general approach proposed by ISO 27005 allows to identify the necessary steps to perform a risk assessment, without making mandatory a specific process to perform it. The main novelty of ISO 27005 is the dual approach by events and/or by supporting assets, and this dual approach is a core part of EBIOS RM. The concepts used on both sides are then coherent, even if few are only explained/detailed on one side or the other.

Article about the changes between ISO 27005:2018 and ISO 27005:2022


Categories: Club EBIOSEBIOS Risk ManagerQ&A

This content is password protected. To view it please enter your password below:


Categories: Club EBIOSGuidancePrivacy

For all those who wish to use EBIOS Risk Manager to conduct a PIA (Privacy Impact Assessment, commonly, or Data Protection Impact Assessment – DPIA, in the specific context of the Article 35 of GDPR), here is an infographic which summarizes the approach:

Broadly speaking, information security / cybersecurity and privacy are both about data protection.
The goal is different: in the information security field, the goal is to protect the organization, while in privacy, the goal is to protect individuals / data subjects.
But the way to manage risk is perfectly compatible!

To conduct a PIA with EBIOS Risk Manager, all you have to do is:

  1. take the processing of personal data considered as the subject of the EBIOS Risk Manager study;
  2. assess compliance with the fundamental principles (determined purpose, minimized data, informing people, enabling them to exercise their rights, etc.), and this can be done as part of the Security basline of workshop 1 of EBIOS Risk Manager ;
  3. identify the potential impacts on the data subjects and estimate their severity, and this can be done in the context of the feared events of the same EBIOS Risk Manager workshop 1.

All the information required in a PIA is all found in the study:

  1. the description of the treatment is taken from Workshop 1;
  2. the assessment of the necessity and proportionality with regard to fundamental principles and rights also came from Workshop 1;
  3. the study of data security risks and their potential impacts on privacy is the result of workshops 1, 2, 3 and 4;
  4. the controls envisaged to deal with the risks emerge from workshop 5.


Collaborate efficiently for your EBIOS Risk Manager analyses!

From the EBIOS Risk Manager method to its agile and collaborative application

Agile Risk Manager is designed to support you in the implementation of risk analysis using the EBIOS Risk Manager method. Take advantage of the strength of an adapted tool to focus on the fundamental values highlighted by the method: knowledge, agility and commitment.

Agile Risk Manager brings you the efficiency and ergonomic facilities of an on-premise solution, while allowing a complete and intuitive collaborative work. From change history to role and access management on your shared analyses, everything is done to enable you to work as a team.

The power of a fully customizable tool

Go even further with the strength of a dedicated software that guides you without restricting you. Agile Risk Manager adapts its presentation to your needs, making recommendations while leaving you in control of your choices.

Customize your experience:

  • Select data from the integrated knowledge bases
  • Use the standard reference systems available (ISO 27001, IEC 62443, PSSIE, NIS, etc.)
  • Define your own enterprise repositories to facilitate collaborative work
  • Select the workshops and activities to be carried out according to your objectives

Start with an existing asset and enhance your data

Thanks to an Excel data import and a simple open template, you can directly retrieve your existing analyses in Agile Risk Manager. Preserve your data capital and improve it in our tool, or simply start new analyses.

Agile Risk Manager also allows you to exchange data with customers or colleagues by exporting every table to Excel and every graph and matrix as an image. A global report can also be generated at any point in your analysis. The content of this report is customizable and you can export it in different formats, such as HTML, Word and PDF.

How can you try Agile Risk Manager?

Taking our software in hands is simple and easy. Get started directly with our integrated examples and take advantage of a dedicated support with our online demonstrations and a free evaluation.

For more information or to request your evaluation version, contact us at contact [at] all4tec.net or visit https://www.all4tec.com/.


ALL4TEC designs and distributes risk analysis tools for cybersecurity and operational safety, in order to answer to the twofold “Safe & Secure” issue which is more and more present among large industrials, operators and IT contractors.



Categories: Other originPrivacyTool

The open source PIA software helps to carry out data protection impact assesment.

The PIA software aims to help data controllers build and demonstrate compliance to the GDPR. The tools is available in French and in English (and many other languages). It facilitates carrying out a data protection impact assessment. This tool also intends to ease the use of the PIA guides published by the CNIL.




The following document can be used for determining the baseline of the Workshop 1 of EBIOS Risk Manager, when the scope of the study is a processing of personal data:
> Download

It constitutes a declaration of applicability relating to the fundamental principles related to the protection of privacy.

The other Workshops of the study makes it possible to satisfy the obligations of the GDPR in terms of security (cf. art. 32) if you assess the impacts on the data subjects in addition to those on the organization.
You can thus use EBIOS Risk Manager to carry out a PIA (cf. art. 35).


Categories: Other originPrivacyStandard

This international standard defines the vocabulary and principles that must be respected by any specific approach to privacy.

>See the standard (for free)


This international standard defines the vocabulary that must be respected by any approach specific to information security.

>See the standard (for free)

Categories: Other originPrivacyStandard

This international standard defines the principles that must be respected by any risk management approach specific to privacy.

>See the standard (paying)

This international standard defines the vocabulary and the principles which must be respected by any risk management approach specific to information security.

> See the standard (paying)

Categories: Other originRisk managementStandard

This international standard defines the vocabulary and the principles which must be respected by any risk management approach, whatever its field of application.

>See the tandard (paying)

Categories: Club EBIOSQ&AWorkshop 1

Answer from a Club EBIOS member: “Pay attention to scales using several types of impacts”

EBIOS guide reminder: “This action [scale development] consists of creating a scale describing all possible levels of impacts, just like the scales of needs, a scale of impact levels is usually ordinal (the objects are classified in order of magnitude, the numbers indicate ranks and not quantities) and composed of several levels to classify all risks“.Therefore, it is usual to see users of the method build several ordinal scales depending on the nature of the impact (financial, legal, operations, privacy…) to estimate the severity of the feared events. The construction is then done by individually scaling each type of impact, without worrying about the consistency between the levels.

However, only a global result is used in risk maps to assess the severity of each compared to the others. Information on the nature of the impacts is lost.

To avoid misleading conclusions about the importance of risks, care must be taken to check the transverse coherence of the gradation of impacts in the scales. For example, checking that the estimatation of a level 3 impact on operations will be of the same value for the organization as the financial and legal impacts of the same level.
Where possible, the pivotal criterion (for consistency) may be the financial scale. If this is not the case (often the case), the side-by-side impacts should be presented and their importance assessed by those seeking consensus. In this case, the scales can have empty boxes (level having no equivalence for all types of impacts considered). This can be the case when one estimates the loss of human lives for example.

It is sometimes difficult for managers to establish these scales in a generic way. A good solution is then to ask the stakeholders to prioritize the feared events after identifying the impacts, and build the scales based on this estimate.

Answer from another member: “It is useful to have heterogeneous impact scales, it is an important means of communication with the business”

In addition, the ideal is in my opinion:

  • to have a scale for each type of impacts (financial, image, legal, operation, privacy…) by covering the entire spectrum of possibilities (from worst to best);
  • to present the impacts side by side when analyzing the feared events and consider their severity;
  • to recall the different impacts and their estimation when presenting the risks map (which only keeps the most important value).

This makes it easy to carry out a study of both information security and privacy by presenting side-by-side the impacts to the organization and the impacts to the individuals (data subjects).

Categories: Club EBIOSQ&AWorkshop 1

Answer from a Club EBIOS member: “Two options”

Several proposals are possible to demonstrate that the problems associated with traceability are treated in an EBIOS study without considering traceability as a criterion:

  • an elegant but somewhat theoretical solution: we consider the information “traces” (or “proof”, or “log”) as an essential asset, and the traceability becomes the integrity and the availability of this essential asset. This means limiting the study to the traces that induce a feared event and to put the others out of the perimeter of the essential assets, in order to avoid the columns filled with “0”;
  • an applied solution: traceability is not a criterion, but a security measure. Being able to trace an action is a measure of both deterrence and recovery, and to consider traceability as such allows us to limit ourselves to the study of (really) feared events: we admit that not being able to trace is not really the feared event, but reduces the associated risk.

Another answer’s response: “Traceability is not a security criterion”

The security criteria are used to assess the impacts in case of reaching each of them, and in particular to study the security needs. In information security, only availability, integrity and confidentiality are considered as security criteria (see in particular ISO/IEC 2700x).They should not be confused with the topics of security measures or regulatory references. Indeed, the (false) need for traceability comes from the fact that we want to know what happened after an incident (detection measure) and/or various obligations (legal, regulatory, sectoral or security policy-related). It is therefore useless and even counterproductive to study the need for traceability.

In addition, a scale of needs and a scale of impacts related to traceability should be available. It is often by trying to build them that one realizes that it is a “desire of someone” that falls under security measures or coverage of a legal “risk”.

Finally, this would involve studying all the threats that lead to the loss of traceability! Actually, this is related to the good implementation of a security measure, which is not necessary to treat as a risk (or otherwise it should be done for encryption, access control, etc.).

However, as the study of the needs is a communication tool with business, it is possible to integrate traceability into the security criteria so that business becomes more involved in the process by seeing its point of view taken into account…

Categories: Club EBIOSQ&ARisk management

Answer from a Club EBIOS member: “We can act on several elements so that the result corresponds to the expectations”

Studies are sometimes criticized because of the combinatorial explosion of the elements to be studied. Therefore, before or at the beginning of any study, it is necessary to wonder what the sponsor is able to accept in terms of readability.Some wish to have as much detail as necessary to treat the risks (and/or justify the measures) in a fine way.

In this case, it is possible to handle the entire combination of events and threat scenarios.

If this is not the case, here are some tips that will help you reduce the entropy of the analysis:

  • act on the presentation: keep the detailed study as a “working document” and group the risks into families in a “summary document” to facilitate decision-making. This “summary document” may only highlight the most important risks (in terms of severity and/or likelyhood), as well as those of specific interest to the sponsor;
  • act on the number of assets: to group the essential assets and/or the supporting assets in the context study. It is possible for example to adapt the level of detail of the modeling without necessarily seeking homogeneity in the model. For example, the description of supporting assets may contain both systems (for assets on which the threat analysis does not need to be detailed) and network, hardware, and software elements (for assets on which the threat analysis must be more refined);
  • act on the hypotheses: to limit the complexity of the study by reducing the combinatorics of the analysis to the only questions or justifications that one wishes to expose. To do this, it is possible to set hypotheses in the context of the study. Thus, it can be considered as a postulate that a supporting asset (or an essential asset) is protected against a type of threat (for example, “a homologation proves that the servers and workstations are sufficiently protected from all the malicious scenarios coming from ‘external attacks’). One can also consider that a risk is sufficiently covered by a certification without requiring a decomposition of this risk (for example, “the private key stored in the certified electronic chips is sufficiently protected against all threats leading to a disclosure”). It is also possible to make assumptions about residual risks for which the study is not expected to provide justification or that the study acts on the related supporting asset (for example, “the GPS is considered as no reliable, it is likely to provide bad location data “);
  • act on the decomposition into several studies: another method can consist of breaking down the studied system to transform a complex analysis into several less difficult studies to carry out. In this case, particular attention should be paid to the interfaces between these subsystems.


Categories: ANSSIEBIOS Risk ManagerMethod

EBIOS, the French reference method, helps organizations to identify and understand their own digital risks. It allows determining security controls that suit to the threat and setting up the monitoring and continuous improvement framework following a risk analysis shared at the highest level.

On the ANSSI website: EBIOS Risk Manager
EBIOS Risk Manager

Listen to the podcast with Fabien CAPARROS (ANSSI) on NoLimitSecu.


Categories: Club EBIOSMethodRisk management

This guide is the EBIOS* generic approach. It provides a common base to any sector-specific breakdown. Initially designed for information security, EBIOS can be employed in all fields using the appropriate techniques and knowledge bases.

EBIOS allows us to assess and treat risks. It also supplies all the information required for communication within the organization and with its partners, and for validation of the way risks have been treated. It thus constitutes a complete risk management tool.

This is a real toolbox, from which we choose the actions to be implemented and the method of using them according to the objective of the study. It allows us to assess the risks using scenarios and to develop a coherent policy from them, based on concrete and assessable controls.

> Télécharger

*EBIOS – Expression des Besoins et Identification des Objectifs de Sécurité (expression of needs and identification of security objectives).


Categories: MethodOther originPrivacy

The CNIL’s PIA Guides have been updated to provide a tool for the General Data Protection Regulation (GDPR).
The methodological approach is a privacy specific instantiation of the EBIOS toolbox.
It allows to build and demonstrate compliance with the GDPR of a processing of personal data.
The guides (the methodology, the templates and the knowledge bases) are provided with a free software, case studies, guidelines, etc.

On the CNIL’s website: Privacy Impact Assessment (PIA)

*PIA – Privacy Impact Assessment, or Data Protection Impact Assessment in the GDPR context.