Cyber risk assessment: what it is really for
Whether you call it a cyber risk assessment, a cybersecurity risk assessment or an IT risk assessment, it answers a simple question: what could go wrong for the organisation, how likely is it, what would the consequences be, and what do you decide to do about it? It is not an inventory of every possible threat, and it is not a compliance audit, which checks whether requirements are met. Its useful output is a decision: prioritised measures, a budget, and a residual risk that someone accepts knowingly. You run it on a project, an application, a site or a wider scope, before go-live or when something important changes. Regulation has made it more visible: article 21 of NIS2 lists risk analysis policies among the expected measures, and DORA requires financial entities to have an ICT risk management framework. This guide sets out a neutral method, step by step, that works whatever approach you choose.
The definitions to agree on before you start
Most assessments that go off the rails do so over vocabulary. Seven notions are enough. A business value is what the organisation needs to protect from the point of view of its activity: a process, a piece of information, a service delivered. A supporting asset is the technical, human or organisational element it relies on: an application, a server, a provider, a team. A risk source is whatever can harm the business value, intentionally or not: a cybercriminal group, an insider, a handling error. A scenario describes how that source reaches its objective and what follows. Likelihood measures how possible it is that the scenario occurs, and severity measures how large its consequences are for the business. Residual risk, finally, is what remains once the measures are in place, and it is what management accepts or refuses. Setting these definitions down at the start saves hours of debate in the room.
Steps 1 and 2: set the scope, then link business values to supporting assets
The first risk assessment steps fix the scope, the objectives and the participants. A good scope fits in one sentence and states explicitly what is out of it. This is also the moment to name the person who will arbitrate and sign off the residual risk: with no name, the assessment ends without a decision. Scoping also sets the severity and likelihood scales that everything downstream relies on. Next comes identifying the business values, with the business owners and not with the IT team alone: they are the ones who know what two days of downtime or a leaked customer file actually cost. Each business value is then linked to its supporting assets. That map does not need to be perfect, but it has to exist: it is what lets you turn an abstract scenario into concrete measures on identified components. A rough but shared inventory beats an exhaustive map that never arrives.
Step 3: identify risk sources and build scenarios
The next step is to identify who or what could harm the business values, and to what end. Risk sources are described by their motivation and their resources: an opportunistic attacker has neither the means nor the patience of a group that targets the organisation specifically. The common mistake is chasing completeness. Three or four genuinely relevant source and objective pairs are worth more than ten pairs nobody will have time to handle. Scenarios then connect those sources to the business values through the supporting assets, and through the ecosystem: providers, hosting companies, partners holding some access. Many attacks come in through a third party, and an assessment that stops at the edge of the information system misses part of the picture. A useful scenario is specific to the scope under review: an attack path that would fit any organisation does not help you decide on any measure.
Step 4: evaluate risk with scales and a matrix
Each scenario gets a severity rating and a likelihood rating, on the scales set during scoping. A severity scale is written in concrete business consequences: length of disruption, harm to people, legal impact, financial loss expressed in orders of magnitude that make sense for the organisation. Four levels are usually enough. Beyond that, participants spend more time hesitating between two ratings than discussing substance. Plotting both ratings on a matrix places each risk and shows the zones considered unacceptable, to be monitored, or acceptable. The matrix is not an exact calculation: it is a sorting tool that makes trade-offs visible and comparable from one assessment to the next. That is why it pays to keep the same scales across the whole organisation, or at least within each entity, so that two risks rated critical are critical for the same reasons.
Step 5: treat the risk and build the action plan
For each risk there are four options: reduce it with measures, avoid it by giving up the activity or feature involved, transfer it, for instance by contract or insurance, or accept it as it stands. The choice belongs to the owner named during scoping, not to the analyst. The measures you keep form the action plan. Each one needs an owner, a due date, a priority and an estimate of effort and cost, otherwise it stays an intention. You then re-rate the risk assuming the measures are in place: that is the residual risk, which management formally accepts or which triggers further measures. A short action plan whose measures are actually funded is worth more than a long list of recommendations nobody owns. Linking each measure to the risks it treats then tells you what changes when a measure slips.
Choosing a cybersecurity risk assessment methodology
EBIOS Risk Manager, published by ANSSI, the French national cybersecurity agency, organises the work into five workshops: scope and security baseline, risk sources, strategic scenarios that include the ecosystem, operational scenarios, then risk treatment. It is the reference in France for sensitive projects, and it is compatible with the principles of ISO/IEC 27005. That international standard gives guidelines for information security risk management, in support of ISO 27001, without prescribing a specific method: it describes a process each organisation equips in its own way. For less critical projects, many teams use a flash assessment, lighter, which keeps the reasoning (business values, scenarios, evaluation, measures) with less depth. Finally, many organisations have built an in-house method suited to their sector and culture. None is better in absolute terms: what matters is that it is applied consistently and that it produces decisions.
Matching cyber risk assessment depth to project criticality
Not every assessment deserves five workshops. An effective practice is to qualify each project upfront, with a few questions on the data handled, exposure, dependencies and regulatory obligations, and then route it: a full assessment for critical projects, a flash assessment for the others, a simple reminder of the security rules for the most straightforward ones. That qualification protects expert time, which is the scarce resource. It also means involving business teams early. They know the value of what they handle and the consequences of an incident far better than the security team, but they have neither the vocabulary nor the time for long sessions. Asking them simple questions, in their own words, and letting security translate and qualify gets better results than summoning them to a three-hour workshop. An assessment started early in the project is also much cheaper to act on than one run the day before go-live.
Keeping a cyber risk assessment alive: register, follow-up and review
A cyber risk assessment describes a system at a given date. As soon as a provider changes or an architecture component is added, it starts to age. Three tools keep it current. The risk register consolidates the risks from every assessment, with their level, owner and status, so you can compare scopes and report to management. The action plan tracks the measures: owner, due date, progress. Indicators, finally, tell you whether the whole thing still works: the share of measures with an owner and a due date, the share of due dates met, the lag between a real change and the update of the scenarios it affects. You also need a periodic review and review triggers: an incident, a change of scope, a new critical provider, a regulatory change. An assessment whose objects stay linked gets updated. An assessment frozen in a document gets redone.
Where AI helps in a risk assessment, and what it must not decide
Artificial intelligence is useful on the heaviest and least strategic part of the work: reading the project documents (architecture file, specifications, contracts) to extract what is needed to prefill the fields, and suggesting business values, supporting assets, risk sources or measures. It cuts the time spent rebuilding context. It must not rate severity in place of the business, select a scenario, decide on a treatment or accept a residual risk: those decisions commit the organisation and must stay with identified people. In Vailor, a three-phase pre-assessment is started by business teams in self-service, then qualified by security. The assessment is then carried out in EBIOS RM or as a flash assessment. The AI reads the project documents and prefills the fields from excerpts, which experts validate. Without documents, Vailor organises the collection from business teams with simple questions.
Key takeaways
A useful cyber risk assessment rests on a few principles: shared vocabulary, a clear scope, scales set before rating, few but specific scenarios, and an action plan in which every measure has an owner. The choice of method matters less than applying it consistently: EBIOS RM for sensitive projects, a flash assessment for the others, or your in-house method if it produces decisions. The real test comes six months later, when the assessment has to be updated. In Vailor, the risk register is linked to the measures in the action plan, each with its effort and cost, which turns a review into an update rather than a new project. Book 30 minutes: we listen to your context and tell you concretely how Vailor addresses it.