EBIOS Risk Manager common mistakes
EBIOS Risk Manager · Understand the traps and how to avoid them.
Treating the five workshops (cadrage, sources de risque, scénarios stratégiques, scénarios opérationnels, traitement du risque) as an unordered checklist and answering questions about their outputs without placing them in the correct sequence.
Candidates memorize the workshop names from a summary sheet but never internalize that each workshop consumes the previous one's deliverables: the cadrage fixes the scope and values, the risk sources feed strategic scenarios, strategic scenarios are declined into operational scenarios, and only then is treatment defined. Without the chain, questions about 'which workshop produces X' become guesswork.
What to do instead
Build a one-page flow diagram showing each workshop's inputs and outputs, and for every term in the method (valeur métier, source de risque, couple SR/OV, partie prenante, actif support) write which workshop introduces it and which workshop uses it. Rehearse by covering the diagram and reconstructing it from memory.
Confusing the strategic scenario with the operational scenario, for example describing a ransomware intrusion path on servers as a strategic scenario or describing business impact on a mission as an operational scenario.
Both are called 'scénarios' and both mention the same threat events, so candidates distinguish them by length or detail rather than by their object. The exam tests precisely this distinction with short scenario descriptions that must be classified.
What to do instead
Anchor on the object each one describes: the strategic scenario is a couple of a risk source and a business value (SR/OV) expressed as a high-level event against the organization's missions; the operational scenario is the concrete sequence of actions on supporting assets that makes the strategic scenario possible. Practice by rewriting five strategic scenarios into operational ones and noting what information was added (assets, access paths, kill chain steps).
Building a risk source list from generic threat catalogues only (hackers, insiders, natural disasters) and omitting the EBIOS expectation to characterize each source by motivation, resources, and activity, and to consider the organization's own ecosystem and stakeholders as potential sources.
Most study material lists threat categories, so candidates reproduce a taxonomy instead of applying the method's characterization grid. They also forget that a risk source in EBIOS is defined relative to the study scope and can include partners, service providers, or states.
What to do instead
For each of at least six risk sources, write a short profile covering motivation, resources, and known activity, and state why it is relevant to the given scope. Explicitly include at least one source from the ecosystem (supplier, subcontractor, client) and one internal source, and be able to justify exclusion of sources too.
Treating the risk assessment as a purely qualitative exercise and being unable to explain how gravity and likelihood are evaluated, or how the method combines them to prioritize.
Candidates learn the vocabulary of 'gravité' and 'vraisemblance' but skip the scales, so they cannot answer questions about how impacts on business values (including human, environmental, and regulatory impacts) feed gravity, or how likelihood draws on the risk source's capability and the effectiveness of existing controls.
What to do instead
Write out the gravity scale and the likelihood scale you would use for a sample study, with one sentence of criteria per level, and show how existing controls lower likelihood rather than gravity. Then take three scenarios and assign levels with a written justification for each, so the reasoning is reproducible.
Jumping to treatment options (avoid, reduce, transfer, accept) before the risk has been formally evaluated and without linking the treatment to the strategic or operational scenario it addresses.
Treatment feels like the practical, familiar part of risk management, so candidates rush to it and produce generic control lists that are not traceable to a scenario or a level of risk. Exam items often present a measure and ask which scenario level it acts on or whether it reduces likelihood or gravity.
What to do instead
For each proposed measure, state the scenario reference it addresses, whether it acts on likelihood or gravity, and which type of treatment it represents. Practice classifying measures as preventive (reducing likelihood) versus protective (reducing gravity or limiting consequences), and note that acceptance must be justified and owned by a named authority.
Describing the risk register as a flat list of risks without the EBIOS structure that links risk sources, business values, strategic scenarios, operational scenarios, and assets in a traceable chain.
General risk-management habits lead to a simple risk log, but EBIOS expects the study to remain auditable: any retained risk should be traceable back to the source and value that generated it and forward to the assets and measures concerned.
What to do instead
Draft a sample register with explicit columns or links for source, business value, strategic scenario, operational scenario, supporting asset, existing controls, gravity, likelihood, and treatment decision. Be able to explain why traceability matters for review and for communicating with management.
Confusing the roles in the method: treating the risk manager as the sole author of the study, or failing to distinguish the study pilot, the sponsor who validates, and the contributors who provide knowledge of the business and technical assets.
Candidates skim the governance section and assume a single analyst does everything. Questions about validation of deliverables or about who arbitrates residual risk then get answered with the wrong role.
What to do instead
Map each workshop deliverable to the role that produces it and the role that validates it, and note that the sponsor's arbitration is what makes risk acceptance legitimate. Memorize this as a small table and test yourself by asking 'who signs off on this output' for every deliverable.
Treating the EBIOS study as a one-off deliverable and ignoring the requirement to keep it alive through monitoring, review triggers, and updates when the scope, the ecosystem, or the threat landscape changes.
Study guides emphasize the five workshops and stop there, so the ongoing-governance dimension is under-rehearsed, and questions about review frequency or about what triggers a re-run are answered with vague statements.
What to do instead
List concrete review triggers (new business value, new supplier, major incident, significant change in threat activity, change of scope) and define what a review revisits in each workshop. Link monitoring indicators to the likelihood and gravity assumptions so a change in an indicator is visibly a reason to re-evaluate.
Confusing EBIOS Risk Manager with ISO 27005 or with a control framework such as ISO 27001 Annex A, and answering method questions with control-catalogue logic.
Candidates often prepare with ISO 27005 material because it is widely available, and both address risk, so terminology overlaps while the workshop structure and the SR/OV formalism are specific to EBIOS. The exam checks that you use the method's own constructs.
What to do instead
Write a short comparison noting what each framework provides (EBIOS RM: workshop-based, scenario-driven, SR/OV couples, ecosystem-aware; ISO 27005: generic risk process; ISO 27001: requirements and controls). Then answer ten practice items using only EBIOS RM vocabulary and check that no answer relies on a control-catalogue reference as the justification.
Producing vague, unspecific scenario wording such as 'a cyberattack could compromise the service', which cannot be evaluated or traced to assets, instead of a scenario naming the source, the objective, the value targeted, and the operational path.
Candidates know the concepts but write summaries at the level of generality they use in everyday reporting, which hides missing analysis. Exam items asking to identify the weakness in a scenario description target exactly this.
What to do instead
Adopt a template and apply it to every scenario you write: source and its motivation, business value targeted, expected impact, and for operational scenarios the sequence of actions and the supporting assets involved. Review each written scenario against the template and rewrite any element that is missing or generic before considering it complete.