Why start from a case study rather than the guide
ANSSI's EBIOS Risk Manager method reads quickly and applies slowly. The guide describes five workshops, but the hard part is almost never understanding what a business value or a strategic scenario is: it is knowing how far down to go, when to stop, and how what comes out of one workshop feeds the next. A worked example settles those questions faster than any definition. The case below is entirely fictional, in the same spirit as the one illustrating ANSSI's guide: it exists to show the sequence, not to describe a real organisation. Take a mid-sized company running an online ordering platform for business customers, with a small IT team and two critical service providers.
Workshops 1 and 2: scope, security baseline and risk sources
Workshop 1 sets the scope and identifies the business values: here, order capture, the pricing repository and customer billing data. Each one rests on supporting assets: the web application, the database, the directory, the hosting. This is also where the severity scales are fixed, and that decision governs everything downstream: a badly calibrated scale produces scenarios that are all critical, and therefore useless. Workshop 1 finally establishes the security baseline, meaning the gap between the applicable frameworks and what is actually in place. Workshop 2 identifies risk source and target objective pairs: a cybercriminal group after financial gain, a competitor after the pricing repository, a careless provider. You keep the relevant pairs, not every conceivable one.
Workshops 3 and 4: from the ecosystem to attack paths
Workshop 3 steps outside the information system to look at the ecosystem: the stakeholders holding access or creating a dependency, so the two providers, the hosting company, and the business customers themselves. Each is rated on threat level and dependency, which surfaces strategic scenarios internal analysis alone never sees, for instance a compromise arriving through the application maintenance provider. Workshop 4 drops to the technical level and turns those scenarios into attack paths: initial access, lateral movement, action on the objective. It is the most demanding workshop, because it needs real knowledge of the architecture and of how attackers operate. It is also the one teams rush the most, for lack of time.
Workshop 5: risk treatment, and what breaks afterwards
Workshop 5 decides: which controls, in what order, at what cost, and which residual risk management formally accepts. It produces the treatment plan and the continuous improvement plan. On our fictional case, the analysis lands on three structural decisions: harden provider access, separate the pricing repository from the application database, and monitor access to billing. The problem comes later. Six months on, a provider changes, the architecture moves, and the question becomes whether the whole thing has to be redone. With deliverables written in a word processor from a spreadsheet, the answer is almost always yes, and the analysis is never revisited. That is where tooling matters more than method.
What to have ready before workshop 1 opens
An EBIOS RM workshop rarely fails during the session: it fails because the raw material is missing. Four things should be in place before workshop 1 opens. A written mandate naming who arbitrates and who will sign off the residual risk: with no name attached, workshop 5 ends without a decision. A scope that fits in one sentence, stating what is explicitly out of it. A list of the business processes involved, each with an owner able to say what two days of unavailability actually cost. And an inventory of supporting assets, even a rough one: an approximate map beats three sessions spent rebuilding it. Then comes the question of who sits in the room, which is routinely underestimated. The business side is indispensable in workshops 1 and 5, architecture and operations in workshop 4, procurement or legal in workshop 3, because they alone know which security clauses were actually signed with the providers. One last thing: come to workshop 1 with a draft severity scale already written, ready to be validated in the session. Starting from a blank page turns a working session into an argument about wording.
Where the analysis derails, and why
Five mistakes come back again and again, and each has an organisational cause rather than a methodological one. Mixing up business values and supporting assets: when workshop 1 is run by the IT team alone, the list fills with servers and the analysis ends up measuring outages instead of consequences. Chasing completeness in workshop 2: keeping ten risk sources guarantees that workshops 3 and 4 never finish, whereas three well chosen pairs cover what matters. Building the workshop 3 stakeholder list from the contracts rather than from the access actually granted: it then describes what was signed, not what is plugged in. Writing generic attack paths, from phishing to exfiltration, that would fit any organisation: that is the signature of a workshop 4 held without an architect, and nothing actionable comes out of it. And closing workshop 5 with controls that carry neither an owner nor a date, because nobody holding a budget was in the room: the file looks presentable and changes nothing.
The signals that an analysis still does real work
An analysis that still earns its keep shows a few verifiable signals. First, the share of treatment plan controls carrying a named owner and a due date, then the share of those dates actually met: the harshest indicator of the set. Second, the lag between a real change, a provider replaced or an architecture component added, and the update of the scenarios it affects: past a few weeks, the analysis describes a system that no longer exists. Third, the number of scenarios modified at the last review: zero means nobody reopened it. The most telling signal remains an architecture or investment decision that was settled by explicit reference to the analysis. Regulation mostly moves the burden of proof: an entity within the scope of NIS2, or a financial entity under DORA, has to be able to present a risk assessment that is documented, kept current and extended to its providers. That upkeep cost is exactly what Vailor's AI assistance reduces: around 70% less time spent on risk analyses.
What this example is meant to show
A useful EBIOS RM case study does not chase completeness: it closes all five workshops on a narrow scope and produces a treatment plan someone can act on. A finished analysis of one critical application beats an analysis abandoned at workshop 4 across the whole information system. The second lesson is about shelf life: an analysis that cannot be updated cheaply stops being true within the year. Vailor keeps the links between business values, scenarios, attack paths and controls, regenerates the deliverables without re-keying, and turns a review from a project into an update. Book a demo to run these five workshops on your own scope.