May 15, 2026 · ~6 min read

Cyberbasics — Episode 2: risk analysis

This article is the second episode of the cyberbasics series, dedicated to the fundamentals of software security.

A marmot analyses a risk matrix

Risk analysis: a tool for awareness and prioritisation

Let's start with a simple premise: the worst risk is the one you don't know about. Even though risk analysis is meant to prioritise the security measures we want to put in place, personally I like to position it, first and foremost, as an exercise in transparency and intellectual honesty.

It's OK to do nothing, as long as you're willing to look risks in the face! The whole challenge is to understand them properly.

If you're not comfortable with the risks you're assessing, then you should do what is within your power to reduce them. And to be efficient, you need a risk analysis to know how to set priorities and act within your means.

No! Security is not an open-ended investment made blindly! It's an investment in risk reduction.

Step 1: define the scope

Simple enough — you define the assets you have and their degree of exposure. This can involve an exhaustive mapping of your assets, or simply a rough estimate of what you need to protect (client data, infrastructure secrets, reputation).

Two examples of how to frame the analysis:

The lightweight Rapid Risk Assessment (RRA): ideal for a simple application. You write the data model dictionary for the service or product in question.
The long and rigorous approach proposed by EBIOS: ideal for a whole organisation or to achieve ISO 27001 certification. You run EBIOS Workshop 1, which aims to define the scope of the study in a formal framework, notably by mapping the "values" to protect, the stakeholders, and the supporting assets that generate those values. This workshop alone can take days.

Step 2: calculate a risk

Here is a simplified but universal definition of risk, which you will find in all the main methodologies (EBIOS, ISO 27005, RRA, ...).

Risk = probability × impact

Impact is not very difficult to define — a simple scale generally works:

critical = the company goes under
severe or high = the company is in danger
medium = our activity is disrupted
low = negligible

An impact is calculated in relation to feared events affecting your valuable assets. For example: data theft, compromise of a server or admin account, ...

Probability

To assess the probability of a risk, you absolutely need to define attack scenarios — in other words, put yourself in the shoes of an attacker. The most useful resource here is the MITRE ATT&CK framework, which is very close to the methodologies used by offensive security teams and attackers alike.

To get started, my favourite approach is to follow the framework proposed by EBIOS for formalising operational risks (EBIOS Workshop 4), which breaks an attack scenario into 4 major stages:

Reconnaissance: is it easy to find any OSINT information about my organisation (or my service)? Here is a small tip to get a feel for it: try tools like crt.sh or any of the OSINT tools in the Exegol suite. Play around and see what you find :)
Initial access: I'll spare you the effort — there are typically 3 vectors within this stage: 1) vulnerability exploitation to breach your network, 2) phishing of all kinds to steal legitimate credentials, and 3) insider corruption.
Lateral movement: how an attacker can move through a system once they have access. We will typically talk about discovery, lateral movement, and other stages you will learn about by working with MITRE ATT&CK.
Exploitation: the attacker's ability to exploit the system remotely once they have successfully compromised your information system.

It is really interesting to build these scenarios, even if you only do a few and are "clumsy" at first — the idea is to improve over time. From my modest experience, even without deep security expertise, some scenarios can provide very structuring strategic directions (this is a spoiler for the next article).

Finally, if you don't have the skills, the ideal is to delegate this work to an offensive security engagement (pentest or red team), which also has the benefit of validating attack scenarios through actual testing. A pentester will often ask you for elements of your risk analysis (feared events, assumptions, attack paths to validate) before starting their engagement.

Step 3: reduce unacceptable risks

The strategic document that serves as a basis for decisions (i.e. allocating resources, or not, for security) is the risk matrix. Here is an example:

Risk matrix — probability × impact

As for the colours, everyone can choose their own algorithm for setting risk levels, and you can always draw inspiration from EBIOS Risk Manager.

Once you have this matrix, the goal is simple: add tasks to your backlog to bring the level of a risk down, for example by making an attack scenario harder to exploit. Typically, if you do the exercise of properly defining your scenarios, you will probably find that the definitions and risk levels proposed by CVSS (i.e. the score given to CVEs affecting your software) will become much clearer.

To conclude

There are two risks to avoid with risk analysis: 1) not doing it at all, and 2) getting into a scheme that is too complex or too costly. On the other hand, you are allowed not to be perfect from the first attempt, and I strongly advocate a continuous improvement approach on this topic.

To make all this a bit more concrete, the next article in the cyberbasics series will present some evocative risk analysis results from my modest experience.