A method that starts with the attacker
Most risk assessments start with an inventory. You list the assets, cross them against a generic threat catalogue, and end up with a three-hundred-line register nobody opens again. EBIOS Risk Manager works the other way round: who has a reason to come after you, to obtain what, and along which path — knowing that the path rarely runs through your firewall and often through a supplier who was granted standing access six years ago.
The method is published by ANSSI, France's national cybersecurity agency, which released it in 2018 with the Club EBIOS practitioner community to replace the 2010 edition. A revision in March 2024 realigned its vocabulary with ISO 27005:2022; the old plan d'amélioration continue de la sécurité became, more plainly, a risk treatment plan. The break with the 2010 version is not cosmetic. EBIOS moved from an exhaustive, bottom-up analysis that tried to miss nothing, to a selective, top-down one that deliberately keeps a handful of scenarios and actually treats them.
The second shift is social, and it decides the outcome. EBIOS RM is not a form the security team fills in on its own. It is a series of ateliers — workshops — in which the business, IT, procurement and sometimes legal sit in the same room. When those sessions turn into internal security meetings, the method produces a deliverable rather than a decision.
The five workshops and what each one owes you
| Workshop | What it needs going in | What it must produce |
|---|---|---|
| 1. Cadrage et socle de sécurité (scoping and security baseline) | Business and technical scope, applicable frameworks, business people who will actually attend | Business values, supporting assets, feared events rated for severity, the baseline and its accepted deviations |
| 2. Sources de risque (risk sources) | Sector threat intelligence, observed adversary behaviour, the organisation's profile | Risk source / target objective pairs, each kept or dropped with a stated reason |
| 3. Scénarios stratégiques (strategic scenarios) | Ecosystem map, contracts, access granted to third parties | High-level attack paths, critical stakeholders, first measures on the ecosystem |
| 4. Scénarios opérationnels (operational scenarios) | Real architecture, technical exposure, offensive know-how | Step-by-step attack sequences, likelihood |
| 5. Traitement du risque (risk treatment) | Every scenario rated for severity and likelihood | Treatment plan, residual risks accepted by a named person, monitoring arrangements |
Each workshop runs half a day to a day, but the real work happens between sessions: consolidating, rating, preparing the material for the next one. Two to three hours of preparation for one hour of workshop is a realistic ratio, and ignoring it is how schedules slip.
Workshop 1: without the business, the rest is decoration
Workshop 1 asks you to name what genuinely hurts. Not "loss of availability of the production system", but "customer orders stop shipping for five days in the middle of the back-to-school campaign, and two distributors turn to a competitor". The difference is not stylistic. The first phrasing supports no severity rating at all; the second can be argued with a sales director in thirty seconds.
Who sits in the room therefore matters more than how well the session is facilitated. A valeur métier — business value, meaning something the organisation needs in order to operate — defined by IT is an application. Defined by the business, it is a process with deadlines, customers and revenue attached. Without someone who can say what an interruption costs, the four workshops that follow become a well-documented exercise with no consequences.
The same session sets the socle de sécurité, the security baseline: the framework the organisation holds itself to, and the deviations from it, each with a reason. That inventory is uncomfortable, which is exactly its value. It also gives you a stop test. If the baseline sits far from the target — no multi-factor authentication, backups never restored — say so and suspend the analysis. Modelling sophisticated attacks against an organisation that has not covered its fundamentals is studying a burglar's route to an open door.
Workshop 3 is where the method earns its keep
This is the workshop most often rushed, and the only one that on its own justifies the cost of the exercise. It maps the ecosystem — service providers, subcontractors, software vendors, subsidiaries, maintenance firms — then rates every stakeholder on four criteria: how dependent you are on them, how deeply they reach into your systems, their own cyber maturity, and how much you can reasonably trust them. The first two give exposure, the last two give reliability, and the ratio between them puts each third party into a watch, control or danger zone.
There is nothing magical about the arithmetic. What matters is the moment the map goes up on the wall and someone asks: "hold on, the integrator has standing access to the production directory?" Organisations rarely discover their exposure inside their own perimeter. They discover it in their partners — in a remote-maintenance agreement signed by a regional office, or at a three-person consultancy holding production credentials.
A strategic scenario then reads as a chain: risk source, then stakeholder, then internal supporting asset, then the business value that gets hit. It fits in one sentence and can be presented to an executive committee without translation. It also unlocks decisions before workshop 4 has even happened: rewrite a contract clause, filter a third-party connection, close a dormant VPN nobody thought to revoke.
The reason this workshop gets cut short is that it needs information the security team does not hold — suppliers live in procurement, access lives in the IAM, commitments live in contracts — and because it produces awkward findings about established commercial relationships. Both are handled by preparation, never in the session itself.
Don't collapse workshop 3 into workshop 4
The most common mistake is treating strategic and operational scenarios as one exercise. The result is always the same: the business view collapses into the technical one. You get a list of vulnerabilities, firewall rules and missing patches — a technical audit dressed in risk vocabulary, in which the question of who, and through whom has quietly disappeared.
The two workshops have different audiences and different purposes. A strategic scenario speaks to someone arbitrating a budget, a contract or a governance arrangement. An operational scenario speaks to someone deciding on architecture, segmentation or detection capability; it descends to the level of attack sequences and supports a defensible likelihood rating. Keeping them apart costs one extra session and preserves the one thing the method genuinely adds.
Selectivity follows from this. Not every strategic scenario needs a workshop 4. Working out the technical detail for the three or four most severe paths is plenty; doing it for fifteen guarantees that none of them will be treated.
What it costs, and when a lighter method serves you better
Be straight about the bill. On a meaningful scope, an EBIOS RM analysis takes five sessions, roughly ten people including several executives, and six to ten weeks of calendar once preparation and consolidation are counted. The workshop hours are not the expensive part. Senior business time is, and you will not get it twice in a year.
The spend is justified when a decision has to be argued in front of someone: a regulated sector, a sprawling ecosystem, an outsourcing deal or an acquisition, a project whose architecture is still open. It is also justified when nobody in the organisation has ever said out loud what a targeted attack would destroy.
It is not justified everywhere. On a small, homogeneous scope whose weaknesses the team already knows, on the annual review of an existing analysis — which should be updated, not redone — or on a product whose threat model fits on one page, a shorter approach gives a far better ratio of effort to decision. An organisation starting from scratch will gain more from working through the CIS Controls and closing the gap it finds than from modelling attacks against a system it has not hardened.
Alongside ISO 27005 and Annex A, not against them
EBIOS RM is a risk assessment method; ISO 27001 is a management system. They do not occupy the same space and neither replaces the other. ISO 27005 describes the risk management process an ISMS is expected to run without prescribing a method, and since the 2022 edition the two vocabularies largely overlap — which is what the 2024 revision confirmed.
In practice, the workshop output feeds ISO 27001's risk assessment and treatment requirements directly, and gives the Statement of Applicability what it almost always lacks: a reason. An Annex A control selected because it cuts a specific, named attack path holds up in front of an auditor. Selected because it appeared on the list, much less so.
FAIR sits somewhere else again. It quantifies loss as distributions of frequency and magnitude, where EBIOS RM structures scenarios and rates them on ordinal scales. Nothing stops you from quantifying the two or three worst scenarios from workshop 4 with FAIR afterwards, if you have the data to do it. The methods answer different questions and coexist comfortably.
What a regulator reads in an EBIOS RM deliverable
NIS2 Article 21 requires risk-management measures that are appropriate and proportionate. Proportionate demands a demonstration: proportionate to what, assessed how, decided by whom. The chain the method produces — feared events, severity, scenarios, measures, residual risk accepted by an identified person — is precisely that evidentiary trail, and the workshop 3 output covers the supply-chain security requirements, which are rarely documented convincingly anywhere else.
DORA reads just as well. The business values from workshop 1 line up with critical or important functions, the workshop 3 map feeds ICT third-party risk management and the register of information, and workshop 5 supplies formal residual-risk acceptance by the management body. The operational scenarios are also good raw material for scoping threat-led penetration testing: they are already in the shape those exercises ask for.
What facilitating these workshops teaches you
A few simple rules beat a forty-page internal methodology.
- Let the business phrase the feared event in its own words, and write it down as spoken. Translation into security language can wait for the minutes.
- Rate severity before anyone mentions a control. The moment a solution enters the conversation, thinking about what you are protecting stops.
- Cap the number of risk source / target objective pairs you keep. Past five or six, the rest of the analysis becomes unmanageable and nothing gets treated.
- Book the diary of the person who can accept residual risk at the start of the engagement. A workshop 5 without a decision-maker produces a wish list.
Then there is shelf life. An analysis expires at the speed of the ecosystem: a new supplier, an acquisition, a service moved outside, and the workshop 3 map no longer tells the truth. That is why risk mapping, scenarios and the severity/likelihood matrix are built into Elyys360, our GRC platform. Between two workshops an analysis has to stay readable, revisable and defensible — which a set of spreadsheets stops being within months.
The deliverable was never the point. The point is that a business director can say, in a meeting and without notes, which scenario worries them and what was decided about it. ANSSI's guide to the method is freely available, and it reads well before a first workshop.
