Information Security Risk Management: One Method, Many Obligations

Most organisations we meet are running four or five risk processes at once. One for GDPR, because Article 32 demands security appropriate to the risk. One for ISO 27001, because clause 6.1.2 requires it. One for NIS2, because the management body has to approve it. A separate ICT risk framework if DORA applies. And now a sixth, because the AI Act wants a risk management system for high-risk AI.

They are usually documented in different places, by different people, in different formats. Often on the same handful of systems.

That duplication is not required by any of these rules. Information security risk management is one discipline with one method, and the European regulations mostly ask for the same underlying work presented in different ways. This guide explains the method, names the standards that define it, sets out exactly what each regulation requires with article numbers, and shows how a single documented risk scenario can satisfy several obligations at the same time.

Key takeaways

What is information security risk management?

Information security risk management, often shortened to ISRM, is the coordinated set of activities an organisation uses to identify, assess, treat, monitor and report on risks to its information. It covers confidentiality, integrity and availability, and it spans both digital and physical information.

The term is frequently used interchangeably with two others it is not interchangeable with. Here is the distinction that ISO 31000 and ISO/IEC 27005 actually draw:

The practical consequence is that "we did a risk assessment last year" is not the same as "we have risk management". One is an activity. The other is a system with owners, criteria, review cycles and reporting lines.

If you want to go deeper on how information security relates to cybersecurity, we have covered the difference between cybersecurity and information security separately.

The standards that define the method

There is no need to invent a risk methodology. Several mature standards already define one, and European regulators increasingly point at them. The trick is knowing what each is for and which ones you can actually be certified against.

ISO 31000: the process everyone else borrows

ISO 31000:2018 has three components: principles, framework and process. The process is the part you will recognise in every regulation that follows.

1. Scope, context and criteria. What are you assessing, in what environment, and what counts as acceptable?
2. Risk assessment. Identification, then analysis, then evaluation against your criteria.
3. Risk treatment. Select and implement options, then check whether the residual risk is tolerable.

Three activities run continuously alongside all of it: communication and consultation, monitoring and review, and recording and reporting. That last one is what turns a spreadsheet exercise into evidence you can show a supervisory authority.

ISO 27005: two ways to find risk

The 2022 edition of ISO/IEC 27005 made a change that matters more in practice than it sounds on paper. It sets out two complementary ways to identify risk, and says you can map between them. Both approaches are covered in detail in our article on ISO 27005.

The asset-based approach works bottom up. You start from an asset, list the threats against it, then the vulnerabilities that make those threats viable. A customer database faces unauthorised access and malware; the vulnerabilities might be weak authentication and unpatched software; the treatment is multi-factor authentication, a patching regime and encryption at rest.

The event-based approach works top down. You start from risk sources and strategic scenarios: who would want to harm us, why, and through which route? A state-aligned actor targeting a telecoms provider in order to reach customer communications is an event-based scenario. It might never surface from an asset inventory, because the asset that matters is the relationship, not the server.

Most organisations do the asset-based half and stop. That is how you end up with a very tidy risk register that misses the scenario that actually happens.

ISO 27001: where risk becomes auditable

ISO/IEC 27001:2022 is the certifiable one, and it is specific about risk:

• Clause 6.1.2 requires a defined information security risk assessment process, including the identification of risk owners
• Clause 6.1.3 requires risk treatment, comparison of your chosen controls against Annex A, and production of a Statement of Applicability that justifies every inclusion and exclusion
• Clause 8.2 requires assessments at planned intervals and whenever significant changes occur
• Clause 8.3 requires the risk treatment plan to actually be implemented

Annex A in the 2022 edition contains 93 controls across four themes: organisational (A.5), people (A.6), physical (A.7) and technological (A.8). The older figure of 114 controls in 14 domains belongs to the retired 2013 edition, whose certificates expired in October 2025. Read our full guide to ISO 27001 compliance and our introduction to ISMS for the wider picture.

What European law actually requires

Each of the following creates a documented risk obligation. The wording differs, the substance rarely does.

GDPR: two separate risk duties

These get conflated constantly, so it is worth separating them. Article 32 requires security measures appropriate to the risk. That obligation applies to every controller and processor, all the time. Article 35 requires a data protection impact assessment only where processing is likely to result in a high risk to data subjects, with three named triggers in Article 35(3): systematic and extensive automated evaluation including profiling with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and systematic monitoring of a publicly accessible area on a large scale.

So a DPIA is not always required. A risk assessment always is. We have written a full guide to data protection impact assessments and a practical walkthrough of the GDPR risk assessment process.

NIS2: ten measures and a board that cannot delegate

Article 21(2) lists ten cybersecurity risk management measures that apply identically to essential and important entities:

1. Policies on risk analysis and information system security
2. Incident handling
3. Business continuity, including backup management, disaster recovery and crisis management
4. Supply chain security
5. Security in acquisition, development and maintenance, including vulnerability handling and disclosure
6. Policies and procedures to assess the effectiveness of the measures
7. Basic cyber hygiene practices and cybersecurity training
8. Cryptography and, where appropriate, encryption
9. Human resources security, access control policies and asset management
10. Multi-factor or continuous authentication, and secured communications

Article 21(1) frames all of this as an all-hazards approach, applied proportionately to the entity's size, exposure and societal importance. Article 20 then puts the management body on the hook: it must approve the measures, oversee implementation, can be held personally liable, and must undergo training itself.

Two figures worth getting right, because they circulate incorrectly. Incident reporting under Article 23 is a three-stage clock: a 24-hour early warning, a 72-hour incident notification and a final report within one month. Fines under Article 34 are tiered: at least 10 million euro or 2% of global annual turnover for essential entities, and at least 7 million euro or 1.4% for important entities. The 20 million euro or 4% figure you sometimes see quoted for NIS2 is the GDPR ceiling, not this one.

For scope and sector questions, see our NIS2 introduction.

DORA: ICT risk with the board's name on it

DORA has applied to financial entities since January 2025. Chapter II sets out the ICT risk management framework: Article 5 makes the management body define, approve, oversee and remain accountable for it, including setting the ICT risk appetite and maintaining enough ICT knowledge to do so. Article 6 requires the framework itself to be documented and subject to regular internal audit. Articles 8 to 13 walk through identification, protection, detection, response and recovery, backup and learning. Article 16 offers a simplified framework for smaller entities.

Articles 28 to 30 extend the same logic to third-party ICT providers, with a register of information and mandatory contractual provisions. If you already manage supplier risk properly, much of this is a documentation exercise rather than a new programme. Our guide to vendor audits covers the practical side.

AI Act: risk management as a lifecycle, not a document

Article 9 requires a risk management system for high-risk AI systems, and it is explicit that this is "a continuous iterative process planned and run throughout the entire lifecycle". You identify and analyse known and reasonably foreseeable risks to health, safety and fundamental rights, evaluate risks arising from intended use and foreseeable misuse, adopt measures, and judge whether the residual risk is acceptable.

Timelines around the AI Act are currently being revised through the European Commission's simplification work. The obligations themselves are not being removed, so we would build for the obligation and treat the dates as provisional. Our article on who must comply with the AI Act sets out the roles.

The point: one scenario, several obligations

Here is the argument this whole guide rests on. Take a single asset, a customer database, and write a single documented risk scenario for it. That one piece of work can serve five regulatory purposes at once.

This is not a vendor's claim. ENISA published a mapping table alongside its NIS2 technical implementation guidance that crosswalks each requirement of the implementing regulation to ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST CSF 2.0 and several national frameworks. ENISA is careful to call it a navigation aid rather than a statement of equivalence, and that caveat is fair. You still have to check the gaps. But the structural overlap is officially documented, and there is no reason to rebuild the same risk register five times.

The catch is tooling. If your risk assessments live in five spreadsheets owned by five people, reuse is theoretical. It only becomes real when one risk record can carry multiple framework tags and one treatment task can close obligations in more than one place. That is exactly what our frameworks module is built to do.

How to do information security risk management in practice

1. Set scope, context and criteria

Decide what is in scope, which regulations apply to you, and what your risk criteria are before you assess anything. Criteria are the yardstick: at what combination of likelihood and impact does a risk become unacceptable, and who gets to decide? Without this, every later step becomes an argument.

2. Identify risks, both ways

Run the asset-based pass over your systems, suppliers and processes, and run an event-based pass over the strategic scenarios that would actually hurt you. Feed both into the same register. If you already maintain a record of processing activities or an asset inventory, you have most of the input for the asset-based half.

3. Analyse likelihood and impact

Pick a scale and use it consistently. The common options trade off in predictable ways:

Choose the smallest scale that still lets you make genuinely different decisions. A 5x5 that produces the same three actions as a 3x3 is just extra meetings.

4. Evaluate against your criteria

Compare each analysed risk to the criteria you set in step one. This is the step that turns a score into a decision. Our guide to the risk assessment matrix covers the mechanics in detail.

5. Treat the risk

ISO 31000 and ISO 27005 give you four options, and the terminology is worth using precisely because auditors notice:

• Avoid the risk by not starting or by discontinuing the activity
• Modify it by changing the likelihood or the consequence, which is what most controls do
• Share it, through insurance, contracts or outsourcing
• Retain it by informed decision, which means someone has formally accepted it

Note that sharing a risk does not remove your accountability. Outsourcing processing to a supplier transfers some financial exposure and none of your regulatory responsibility.

6. Record it properly

A risk register that omits ownership or review dates is a document, not a control. At minimum, each entry should carry a risk ID, the scenario description, the linked asset or process, the named risk owner, inherent likelihood and impact, existing controls, residual likelihood and impact, the chosen treatment option, treatment actions with deadlines and owners, current status, and the next review date.

7. Monitor, report and reassess

Review on a fixed cadence, at least annually, and reassess on a trigger. Triggers include a significant change to a system or process, a new processing activity, an incident, onboarding a supplier, or a regulatory change. GDPR Article 35(11) and ISO 27001 clause 8.2 both require this explicitly.

The practical way to make this survive contact with a busy year is a compliance calendar, where the review is scheduled rather than remembered. That is what our compliance task management is designed around.

What the risk matrix can and cannot do

The likelihood-by-impact matrix is the default tool, and it deserves a more honest treatment than it usually gets. In a widely cited 2008 paper in Risk Analysis, Louis Anthony Cox Jr set out several documented problems with qualitative risk matrices.

• Poor resolution. A typical matrix can correctly and unambiguously compare only a small fraction of randomly chosen hazard pairs, and gives identical ratings to risks that differ substantially in quantitative terms
• Errors. A matrix can rate a quantitatively smaller risk as higher. Where frequency and severity are negatively correlated, Cox found the results can be worse than random
• Subjective inputs. The categories depend on judgement, so consistency across assessors is hard to achieve and harder to evidence

None of this makes the matrix useless. It remains a good triage and communication tool, and it is what a board will understand in thirty seconds. The honest position is that a matrix is for prioritising and communicating, not for proving that one risk is objectively larger than another.

Where the numbers matter, for instance when you are justifying a significant investment, quantitative methods are the escalation path. The main open model is FAIR (Factor Analysis of Information Risk), which decomposes risk into loss event frequency and loss magnitude to produce a distribution of expected losses in monetary terms. ISO 27005:2022 also added a semi-quantitative technique as a middle ground.

Terms that get confused

Who owns the risk?

In 2020 the Institute of Internal Auditors renamed its long-standing "Three Lines of Defence" to the Three Lines Model, dropping the defensive framing to emphasise value creation, the governing body's role and collaboration instead of silos. The structure still holds:

• First line: operational management, who own the risks and the controls that treat them
• Second line: risk, security and compliance functions, who set the method, support the first line and challenge it
• Third line: internal audit, providing independent assurance to the governing body

In an information security context the named roles usually break down like this. The asset or process owner holds the knowledge about how a system is actually used. The risk owner is formally accountable for a given risk being managed, and ISO 27001 clause 6.1.2 requires this person to be identified. The CISO or DPO defines the method, the threat scenarios and the criteria. The management body approves and is accountable.

That last role is no longer optional or advisory. NIS2 Article 20 and DORA Article 5 both make board approval, oversight and training a legal requirement. A risk report that never reaches the board is now a compliance gap, not just a governance weakness. For the wider structure, see our article on governance, risk and compliance.

Eight mistakes worth correcting

1. Treating risk assessment and risk management as the same thing. Assessment is one step inside management.
2. Claiming ISO 31000 certification. ISO 31000 is guidance and cannot be certified against. Individuals can hold credentials based on it, organisations cannot be certified to it.
3. Quoting NIS2 fines as 20 million euro or 4%. That is the GDPR ceiling. NIS2 is at least 10 million euro or 2% for essential entities, at least 7 million euro or 1.4% for important ones.
4. Describing NIS2 reporting as a single deadline. It is three: 24 hours, 72 hours, one month.
5. Saying a DPIA is always required. Only where high risk is likely. An Article 32 risk assessment, by contrast, always applies.
6. Citing 114 Annex A controls. That was ISO 27001:2013. The 2022 edition has 93 controls in four themes.
7. Using risk appetite and risk tolerance interchangeably. They are different concepts, and ISO and COSO do not define them identically.
8. Presenting the risk matrix as objective. It is a prioritisation and communication tool with documented limitations, not a measurement instrument.

Why this matters now

The threat picture is not abstract. ENISA's Threat Landscape 2025 analysed several thousand incidents across the EU and identified ransomware as the most impactful threat, accounting for the large majority of malware found in intrusions, with phishing and vulnerability exploitation as the leading access routes. Distributed denial of service dominated by volume, largely from hacktivist campaigns, though relatively few of those caused actual service disruption.

In Denmark, the national assessment Cybertruslen mod Danmark keeps the threat from both cybercrime and cyber espionage at the top of its five-point scale. And Datatilsynet, the Danish data protection authority, receives in the order of 10,000 personal data breach notifications a year.

You can read ENISA's material at enisa.europa.eu and Danish guidance at datatilsynet.dk.

None of these numbers tells you what your own risk is. That is the point of doing the work rather than reading the statistics.

How .legal supports information security risk management

Our platform is built around the idea that one piece of risk work should count in several places. In practice that means:

• One risk register, multiple frameworks. Tag a risk to GDPR, NIS2, ISO 27001 and DORA at once instead of maintaining parallel registers
• Cross-framework task mapping. A single treatment task can close obligations under more than one regulation, so the work is done once
• Named ownership. Risk owners, asset owners and deadlines are part of the record, which is what ISO 27001 clause 6.1.2 asks for
• A compliance calendar. Reviews are scheduled, not remembered, with triggers for reassessment
• Reporting the board can use. Exportable overviews that satisfy the approval and oversight duties in NIS2 Article 20 and DORA Article 5

See how it works in our enterprise risk management module, or book a demo and we will walk through your own scenario.