Risk Management Frameworks for EU Organisations

ISO 31000:2018 (Risk management — Guidelines) is the most broadly applicable risk management framework available. It is sector-agnostic, hazard-agnostic, and deliberately high-level — providing principles, a framework structure, and a process for managing risk across any domain. Its core process follows a logical sequence: scope, context, and criteria definition; risk assessment (identification, analysis, evaluation); risk treatment; monitoring and review; and recording and reporting. Surrounding this process is a framework that addresses leadership commitment, integration into organisational processes, design, implementation, evaluation, and improvement.

ISO 31000's strength is its universality. It works equally well for cybersecurity risk, operational risk, strategic risk, and financial risk. For EU organisations subject to multiple regulatory obligations, this breadth is valuable: ISO 31000 can serve as the overarching risk management philosophy into which domain-specific frameworks (ISO 27005 for information security, DORA's ICT risk framework for financial services) are nested. It provides common terminology — risk appetite, risk criteria, risk owner, risk treatment — that enables cross-domain risk conversations at the executive and board level.

Its weakness is that universality comes at the cost of specificity. ISO 31000 does not prescribe risk scoring methodologies, does not specify which threats to assess, and does not mandate particular controls or treatments. An organisation that adopts ISO 31000 alone, without domain-specific supplementation, will have an elegant risk process but no practical guidance on what to do with it in a cybersecurity context. For NIS2 and DORA compliance, ISO 31000 is necessary but not sufficient — think of it as the operating system on which more specific frameworks run.

ISO 31000 is complemented by ISO 27005:2022 (Information security risk management), which applies ISO 31000's principles specifically to information security. ISO 27005 provides more concrete guidance on threat identification, vulnerability assessment, and risk evaluation in an IT context, making it a natural bridge between ISO 31000's generality and the specific control requirements of ISO 27001 Annex A. For EU organisations pursuing ISO 27001 certification, combining ISO 31000 and ISO 27005 creates a risk management approach that is both principled and operationally actionable.

While ISO 31000, NIST RMF, and COSO ERM are voluntary standards that organisations adopt by choice (or customer demand), DORA and NIS2 impose mandatory risk management requirements with regulatory force. Understanding their specific frameworks — and how they interact with voluntary standards — is essential for EU compliance.

DORA Chapter II (Articles 5-16) prescribes the most detailed ICT risk management framework in European law. Article 6 requires financial entities to maintain a comprehensive, documented, and continuously updated ICT risk management framework as part of their overall risk management system. This framework must include strategies, policies, procedures, and ICT protocols necessary to protect all relevant physical components, infrastructure, and ICT assets. Article 7 mandates specific ICT systems documentation, Article 8 requires identification of all ICT-supported business functions and information assets, Article 9 details protection and prevention measures, Article 10 covers detection capabilities, Article 11 addresses response and recovery, and Articles 12-13 cover backup, restoration, and learning processes. Critically, DORA Article 5(2) requires management body members to actively and continuously maintain sufficient knowledge and skills to understand and assess ICT risk — making risk framework governance a personal obligation of board members.

NIS2's risk management requirements are less prescriptive than DORA's but equally mandatory. Article 21(1) requires appropriate and proportionate technical, operational, and organisational measures to manage risks to network and information system security. Article 21(2)(a) specifically lists risk analysis and information system security policies as the first mandatory measure category. Unlike DORA, NIS2 does not prescribe a specific framework structure — it leaves implementation flexibility to entities, subject to the proportionality principle. This means NIS2-obligated organisations have more freedom to choose their framework but must demonstrate that whatever they choose adequately addresses the ten measure categories in Article 21(2).

For organisations subject to both DORA and NIS2 — which includes most EU financial entities, since the banking sector appears in NIS2 Annex I — DORA's lex specialis principle (Article 1(2)) means DORA takes precedence for ICT-related risk management. However, NIS2 may impose additional requirements in areas not fully covered by DORA, such as supply chain security beyond ICT third-party providers, or physical security of network infrastructure. The safe approach is to implement DORA's ICT risk management framework fully and then conduct a gap analysis against NIS2 Article 21 to identify any residual obligations.

Implementing a risk management framework is fundamentally a governance exercise, not a technology exercise. The most common failure mode is purchasing a GRC tool, populating it with a risk register, and declaring the framework implemented. A framework is implemented when risk identification feeds into investment decisions, when risk treatment plans are resourced and tracked, when risk appetite statements constrain operational choices, and when the board reviews risk posture with the same rigour it reviews financial performance. Technology enables this; it does not constitute it.

A second common pitfall is framework proliferation. Organisations that acquire different frameworks for different regulatory requirements — one for DORA, another for NIS2, a third for ISO 27001, a fourth for GDPR — end up with duplicated risk registers, conflicting risk scoring methodologies, and no coherent enterprise-wide risk view. The solution is a single risk management process with multiple compliance overlays, not multiple processes with partial overlap. Every risk in the register should be assessed once, treated once, and mapped to all applicable regulatory requirements — not assessed differently depending on which framework the assessor happens to be working in.

Documentation quality determines framework sustainability. EU regulators under both NIS2 and DORA have examination powers that include reviewing risk management documentation. This documentation must demonstrate not just that a framework exists but that it operates: risk assessments were actually performed (with dates, participants, and methodologies recorded), risk treatment decisions were actually made (with rationale, resource allocation, and timelines), and risk reviews actually occurred (with meeting minutes, actions taken, and escalation records). A beautifully designed framework document that was last updated eighteen months ago is worse than a simple spreadsheet that is reviewed monthly.

Finally, plan for framework evolution. The EU regulatory landscape is not static: DORA technical standards are being refined, NIS2 transposition is still underway in several Member States, the EU AI Act introduces new risk management requirements for AI systems, and the Cyber Resilience Act will impose product-level security requirements. Your framework must be designed to absorb new regulatory requirements without wholesale reconstruction. Build modularity into your framework architecture — the core risk process should remain stable even as the specific requirements it addresses expand over time.