Risk mapping: building it step by step
A six-step method, information system mapping according to ANSSI, a worked cyber example and NIS 2, DORA and Sapin II obligations.
Risk mapping is a process that lists the risks an organisation faces, assesses them by severity and likelihood, then prioritises them to decide which ones to treat first. In cybersecurity, it starts from business activities and information system assets, and results in a visual representation, a treatment plan and ongoing monitoring.
What is risk mapping?
The word “mapping” can be misleading: it is not just about drawing a map, but about following a line of reasoning. A risk map answers three questions in order. What matters to us? What could harm it? What do we decide to do about it? The graphic output, often a colour-coded risk matrix, is only the last step, the one that makes the result readable.
This vocabulary is shared by every risk discipline. ISO 31000 describes a common process (identify, analyse, evaluate, treat, monitor) found in enterprise risk management, anti-corruption compliance and workplace safety. In cybersecurity, ISO/IEC 27005 applies it to information security, and ANSSI's EBIOS Risk Manager method uses the term “risk map” for the representation of scenarios by severity and likelihood, before and after treatment.
What is a cyber risk map for?
- Focusing the security budget on the risks that really threaten activities, rather than on the most visible topics.
- Giving management an overview of the organisation's exposure, in its own language rather than in technical terms.
- Justifying decisions to an auditor, a regulator or an insurer: why a given measure, why a given risk was accepted.
- Preparing for regulatory obligations (NIS 2, DORA, security accreditation), which all call for documented risk management.
Enterprise risk map or cyber risk map?
In a large organisation, the risk department often keeps an overall map: strategic, financial, legal and operational risks. Cyber risk usually appears there on a single line, such as “major cyberattack”. The cyber risk map is the close-up: it breaks that line down into concrete scenarios, linked to specific activities and assets. Both must speak the same language. Using the same severity scales, or at least a correspondence table, lets critical cyber risks feed into the overall map without being translated for every committee.
Risk map, matrix, register: three tools not to confuse
The three terms are often used interchangeably. Yet they refer to different, complementary objects that follow on from each other.
| Risk map | Risk matrix | Risk register | |
|---|---|---|---|
| Nature | A full process | A scoring grid | A tracking table |
| Question | Which risks, at what level, and what do we do? | Where does this risk sit? | Who does what, by when? |
| Content | Scope, assets, risks, assessment, treatment, monitoring | Severity x likelihood, colour-coded levels | One row per risk: description, rating, measures, owner, due date |
| Audience | Management, CISO, risk manager | Management, committees | CISO and risk owners |
In short, risk mapping produces both the matrix (the snapshot) and the register (the roadmap). For details on scales and criticality scoring, see our guide to the risk matrix and its spreadsheet template.
How to build a risk map in 6 steps
Methods differ in vocabulary, but they all follow the same progression. Here are the six steps, each with its expected output, the people to involve and the most common pitfall.
Set the scope and criteria
What you do : Decide what the map covers (whole organisation, subsidiary, system, project), list the essential activities and set the severity and likelihood scales and acceptance thresholds.
- Output
- Scoping note approved by management, written scales.
- Who
- Management, CISO, risk manager.
- Pitfall to avoid
- Starting with too broad a scope: a narrow scope handled well, then extended, works better.
Identify assets and risks
What you do : List the business assets (processes, information) and the supporting assets that carry them, then the feared events and risk sources: attackers, errors, failures, suppliers.
- Output
- Asset inventory and raw list of risks.
- Who
- Business teams, IT, CISO, procurement for third parties.
- Pitfall to avoid
- Starting from a generic threat catalogue without linking it to the organisation's actual activities.
Assess severity and likelihood
What you do : Rate each risk on both scales taking account of the measures already in place, and write a one-sentence justification for each rating.
- Output
- Rated risks, initial risk.
- Who
- Cross-functional workshop.
- Pitfall to avoid
- Rating alone at your desk: the gaps between assessors are precisely what moves the analysis forward.
Prioritise and visualise
What you do : Place the risks on a severity x likelihood matrix, rank them by level and compare each level with the acceptance thresholds.
- Output
- Visual risk map and ranked risks.
- Who
- CISO, risk manager.
- Pitfall to avoid
- Leaving a maximum-severity risk in green because it seems unlikely.
Decide on treatment
What you do : For each risk above the threshold: reduce, transfer, avoid or accept. Define the measures, their owners and due dates, then estimate the residual risk.
- Output
- Treatment plan and formal acceptance of residual risks.
- Who
- Management, risk owners.
- Pitfall to avoid
- Accepting a risk with no written record and no review date.
Monitor and update
What you do : Track progress on measures, revise ratings when the context changes (new project, incident, new threat, new supplier) and carry out a full review at fixed intervals.
- Output
- Dashboard, version history.
- Who
- CISO, risk committee.
- Pitfall to avoid
- A frozen map that only comes out for the next audit.
Step 1: set the frame before assessing
Scoping is the step most often rushed, and the one that determines all the others. It sets the scope, the essential activities and above all the criteria: written severity and likelihood scales, acceptance thresholds approved by management. Without them, the assessment drifts into debates of opinion.
Steps 2 and 3: identify and assess with business teams
Identification starts from activities, not threats. For each activity, list the information and systems that carry it, then what could happen to them: attack, human error, failure, supplier default. Assessment takes place in a workshop with business teams, who are the only ones able to say what a day of downtime costs. A well-run risk analysis differs from a simple list of vulnerabilities precisely through this grounding in the business.
Steps 4 to 6: prioritise, treat, monitor
Once risks are rated and placed on the matrix, each level triggers a decision: reduce, transfer, avoid or accept. The chosen measures go into an action plan with owners and due dates, and management formally accepts the residual risk. Monitoring, finally, turns a one-off exercise into a management tool.
Start by mapping the information system
You can only protect what you know. Before mapping IT risks, you need to know what the information system is made of. ANSSI has a dedicated guide, “Mapping the information system, how-to guide in 5 steps”, published in November 2018. Written first for operators of vital importance, it presents itself as useful to any organisation, whatever its size. In its presentation of the guide, ANSSI points out that mapping is a necessary step in security accreditation.
The guide is organised around five questions: how to initiate the process, which model to adopt, which tools to use, how to build the map step by step and how to keep it alive. Above all, it proposes six views, grouped into three visions, which move gradually from business to technology.
- Ecosystem : The external entities you exchange with: customers, suppliers, partners, authorities.
- Business view of the IS : Business processes and activities, and the information they handle.
- Applications : The applications and services that support the activities, and their flows.
- Administration : Administration zones and means: privileged accounts, directories, admin workstations.
- Logical infrastructure : Networks, security zones, addressing and gateways.
- Physical infrastructure : The equipment, servers, sites and rooms that host everything.
The guide also defines three maturity levels: a first level limited to the essential elements, a second where all views are represented from a cybersecurity angle, and a third that is exhaustive and detailed. There is therefore no need to wait for a perfect map before starting risk analysis. The “ecosystem” and “business” views are enough to identify critical activities and the suppliers you depend on; third-party risk management then takes over for the latter. To build the information system map itself, view by view, see our article Information system mapping: building it step by step.
A cyber risk mapping example
Take a French inter-municipal authority that issues civil registry documents, pays its staff, runs a drinking water service and offers online services. The workshop brings together the CISO, the IT director, the director general of services and the heads of the departments concerned. The build follows the steps above: activities, supporting assets and dependencies, risks, then levels.
| Risk | S | L | Level | Chosen treatment |
|---|---|---|---|---|
| Ransomware spread through a directory administrator account | 4 | 3 | Critical | Dedicated admin accounts, MFA, tested offline backups |
| Remote takeover of water supervision | 4 | 2 | High | Industrial network segmentation, controlled remote access |
| Fraudulent change of a staff member's bank details | 3 | 3 | High | Call-back procedure, dual approval in the HR system |
| Leak of civil registry data at the software vendor | 3 | 2 | Moderate | Security clauses in the contract, annual supplier assessment |
| Denial of service on the citizen portal | 2 | 3 | Moderate | Host's anti-DDoS protection, fallback information page |
Two lessons stand out. First, the Active Directory is linked to three out of four activities: it is a concentration point of risk that only a dependency view reveals. Second, two of the five risks go through a third party (the software vendor, the portal host), which confirms the value of including suppliers in the risk map. To see how this is handled in a tool, explore our vendor risk management module.
Risk mapping: what NIS 2, DORA and Sapin II require
NIS 2: risk analysis policies
Article 21 of the NIS 2 Directive requires essential and important entities to take “appropriate and proportionate” measures to manage the risks to their network and information systems. These measures are based on an all-hazards approach and include first of all policies on risk analysis and information system security. An up-to-date risk map is the practical expression of this. To find out whether you are covered, read our article from NIS to NIS 2.
DORA: mapping assets and their interdependencies
For financial entities, the DORA Regulation, applicable since 17 January 2025, is even more explicit. Its Article 8 requires them to identify and document their business functions and their information and ICT assets, to map their configuration and the links and interdependencies between them, and to review the classification of these assets and the risk scenarios affecting them at least once a year. That is precisely what an IT risk map covers.
Sapin II: the historical reference in France
Outside cybersecurity, France's Sapin II law of 9 December 2016 made the term popular. Its Article 17 requires companies with at least 500 employees and turnover above €100 million to map their corruption risks, in the form of “regularly updated documentation”, supervised by the French Anti-Corruption Agency. The principle is the same: identify, analyse, prioritise and keep up to date.
Security accreditation
In the French public sector, the security accreditation of an information system also relies on a risk analysis, which the accreditation authority accepts knowingly.
Keeping the risk map up to date
A risk map loses its value as soon as it stops being current. A full annual review is a minimum, and DORA requires it for several of its elements. Between two reviews, some events should trigger a targeted update:
- a new project or a new internet-facing application;
- a new critical supplier, or a change at an existing one;
- a security incident, in your organisation or in comparable ones;
- a regulatory change or a reorganisation;
- the completion of a security measure, which lowers the residual risk.
A few simple indicators show whether the risk map is really alive: the date of the last review of each scope, the share of high and critical risks covered by a treatment plan, the rate of measures completed on time, and the number of accepted risks whose review date has passed. Presented to the executive committee two to four times a year, they are enough to keep attention without turning the map into a bureaucratic exercise.
This is often where spreadsheets show their limits: multiple versions, action plans tracked separately, no history of ratings. The Phinasoft Risk & Compliance module lets you run analyses for the whole organisation, a business unit or a project, with the EBIOS RM method certified by ANSSI, ISO 27005 or your own method. Each scope can be reassessed starting from the previous version, risk levels evolve as action plans progress, and the vendor risk management module helps you map your critical suppliers. To see what this looks like on your own scope, you can request a demo.
Summary
A process, not a drawing
Risk mapping identifies, assesses and prioritises the risks of a scope in order to decide how to treat them. The matrix is only its visual output.
Start from the activities
In cybersecurity, a solid risk map starts from business activities and the assets that carry them, hence the value of the information system map described by ANSSI.
A living document
NIS 2, DORA and Sapin II expect documented and regularly updated risk management. The map must keep pace with projects, incidents and threats.
Frequently asked questions
What is risk mapping?
It is a process that lists the risks an organisation faces, assesses them by severity and likelihood, then prioritises them to decide how to treat them. The result combines a visual representation, often a matrix, and a detailed register. In cybersecurity, it starts from business activities and information system assets.
How do you build a risk map?
Follow six steps: set the scope and assessment criteria, identify assets and risks, rate each risk for severity and likelihood, prioritise and visualise the results, decide on treatment with owners and due dates, then monitor and update. Involve business teams from the identification stage to avoid a purely technical view.
What is the difference between a risk map and a risk matrix?
A risk matrix is a grid that combines severity and likelihood to rate a risk. Risk mapping is the full process, from identification to monitoring, of which the matrix is just one output. The matrix is the snapshot; the risk map is the whole process that produces it and keeps it up to date.
What is the difference between a risk map and an information system map?
An information system map describes what exists: activities, applications, networks, equipment and their links, using the six views proposed by ANSSI. A risk map assesses what could go wrong within that scope. The first is the foundation of the second: without a reliable asset inventory, risk identification remains incomplete.
Is risk mapping mandatory?
It is explicitly required for companies subject to France's Sapin II law, for corruption risks. In cybersecurity, NIS 2 requires risk analysis policies and DORA requires financial entities to identify and map their ICT assets and risks. Even when it is not named as such, a risk map is therefore expected.
How often should a risk map be updated?
A full review at least once a year is good practice, and DORA requires it for several elements of ICT risk management. It should also be updated after any significant change: new project, new critical supplier, security incident, change in the threat or in regulation.
Who should build the risk map?
It is led by the CISO, the risk manager or the head of internal control, but it is not done alone. Business teams bring knowledge of activities and impacts, IT brings knowledge of systems, procurement knowledge of suppliers. Management approves the criteria, the acceptance thresholds and the residual risks.
Sources (10)
- ANSSI — Mapping the information system, how-to guide in 5 steps (ANSSI-PA-046, 2018)
- ANSSI — Information system mapping guide page (in French)
- ANSSI — EBIOS Risk Manager guide, version 1.5 (2024, in French)
- ANSSI — Information system security accreditation guide (2025, in French)
- ISO — ISO/IEC 27005:2022, Guidance on managing information security risks
- ISO — ISO 31000:2018, Risk management — Guidelines
- EUR-Lex — Directive (EU) 2022/2555 (NIS 2), Article 21
- EUR-Lex — Regulation (EU) 2022/2554 (DORA), Article 8
- Légifrance — Law no. 2016-1691 of 9 December 2016 (Sapin II), Article 17
- French Anti-Corruption Agency (AFA)
A platform and service that adapt to you
Our platform is designed for fine-tuned configuration and broad adaptability to your needs.