ISO 27005 vs NIST RMF vs DORA: Which Risk Framework to Choose for Financial Sector in 2026

Two deadlines are converging on financial institutions right now. The National Bank of Ukraine's Resolution No. 143 requires non-banking financial institutions (NBFIs) to implement an information security management system (ISMS) by 13 December 2026. DORA — the EU Digital Operational Resilience Act — has been in force since 17 January 2025, with supervisory audits already underway across EU member states. Banks and fintechs operating in both markets are asking the same question: which risk framework do we actually build on?

This article maps the three most relevant frameworks — ISO/IEC 27005:2022, NIST Risk Management Framework (RMF), and DORA's own ICT risk approach — explains where each fits, and offers a decision structure for choosing or combining them.

Why a Risk Framework Is No Longer Optional in 2026

A risk framework is a structured method for identifying, assessing, treating, and monitoring information security risks. Every major compliance standard now requires one — not as a concept, but as documented, operational evidence.

NBU Resolution No. 143 (adopted 2023, enforcement deadline 13.12.2026) requires NBFIs to establish an ISMS aligned with ISO/IEC 27001. ISO 27001 in turn references ISO 27005 as the standard risk management methodology. DORA Articles 5 through 15 mandate a fully documented ICT risk management framework with annual reviews, board-level accountability, and audit trails. NIS 2 Directive Article 21 requires entities in scope to implement risk analysis and information system security policies as a minimum security measure.

What changed between 2022 and 2026 is not the concept — it is the enforceability. Regulators now have audit frameworks, supervisory teams, and sanctions. The European Supervisory Authorities (EBA, ESMA, EIOPA) published the joint regulatory technical standards under DORA throughout 2024, providing the detailed expectations against which financial entities are now examined.

Choosing a risk framework is therefore a compliance decision with cost, timeline, and audit implications — not just a methodology preference.

ISO/IEC 27005:2022 — The ISMS-Native Approach

ISO/IEC 27005:2022 is the international standard for information security risk management within the context of an ISMS (Information Security Management System). The 2022 revision restructured the standard around ISO 31000 risk management principles and removed prescriptive methodology requirements — organisations now have more flexibility in how they conduct assessments.

What it covers:

• Risk identification: assets, threats, vulnerabilities, and the relationships between them

• Risk analysis: qualitative and quantitative approaches, likelihood and impact estimation

• Risk evaluation: comparing risk levels against acceptance criteria

• Risk treatment: four options (modify, retain, avoid, share) with treatment plan requirements

• Risk monitoring and review: ongoing process, not a once-a-year exercise

• Communication and consultation: stakeholder involvement throughout the cycle

Where it works well:

ISO 27005 is the right choice when an organisation is building toward ISO 27001 certification, because the two standards share scope definitions, terminology, and document structure. Auditors from accredited certification bodies (CBs) will expect to see a risk treatment process that maps directly to Annex A controls — ISO 27005 makes that mapping straightforward.

It is also practical for organisations that serve multiple jurisdictions and need a single, internationally recognised risk methodology. ISO 27005 is jurisdiction-neutral. A Ukrainian insurance company preparing for both NBU Resolution No. 143 compliance and potential EU market entry can use one ISO 27005 process to satisfy both.

Where it requires augmentation:

ISO 27005 does not address operational resilience as a separate discipline. It does not have specific provisions for third-party ICT risk, incident classification, or the testing requirements that DORA introduces. For organisations in DORA scope, ISO 27005 is necessary but not sufficient.

NIST RMF / SP 800-37 — The US Government Standard That Crossed Over

The NIST Risk Management Framework, documented in Special Publication 800-37 Revision 2 (2018), was originally developed for US federal information systems. Over the past decade it has been adopted broadly by US financial institutions, defence contractors, and technology companies — including non-US entities that serve US regulated markets or are working toward SOC 2 certification.

The seven-step process:

1. Prepare — organisational context, risk tolerance, role assignments (added as a new initial step in Rev 2)

2. Categorize — information and systems by impact level (low / moderate / high) using FIPS 199 criteria

3. Select — baseline security controls from NIST SP 800-53

4. Implement — controls, with documentation of implementation decisions

5. Assess — evaluate whether controls are implemented correctly and operating as intended

6. Authorize — senior official accepts residual risk and authorises the system to operate

7. Monitor — continuous monitoring of controls and risk posture

Where it works well:

NIST RMF is the natural choice for SaaS companies and technology firms pursuing SOC 2 Type II, because SOC 2's Trust Services Criteria map well to NIST SP 800-53 controls. It is also the framework of choice for organisations contracting with US government agencies or defence primes, where NIST alignment is explicitly required.

For fintech companies with US investors conducting due diligence, or Ukrainian companies with a US subsidiary, NIST RMF provides a familiar reference that US-side auditors and counsel will recognise.

Where it requires augmentation:

NIST RMF is not designed for DORA compliance. The framework does not address DORA's specific requirements around ICT-related incident classification (Article 18), the register of information assets (Article 8), or the mandatory testing programme including Threat-Led Penetration Testing (TLPT) under Article 26. Organisations using NIST RMF as their primary framework for DORA compliance will need to build a supplementary layer.

NIST SP 800-37 also uses US-centric impact categorisation that does not translate directly to EU regulatory language. Mapping exercises are required when using NIST artefacts for EU regulatory submissions.

DORA ICT Risk Approach — Articles 5 Through 15

DORA (Regulation EU 2022/2554) does not name a methodology. Instead, it specifies outcomes and processes that financial entities in scope must implement. Articles 5 through 15 define the ICT risk management framework requirements. This is not a reference framework in the ISO or NIST sense — it is a regulatory mandate.

Core requirements under Articles 5–15:

• Article 5 — Governance: management body directly responsible for ICT risk; can not be delegated. Specific training requirements for board members on ICT risk.

• Article 6 — ICT risk management framework: documented, integrated into overall risk management, subject to annual internal review and annual audit.

• Article 8 — Identification: register of information assets (hardware, software, data, ICT third-party services). Business impact analysis linked to the register.

• Article 9 — Protection and prevention: access controls, cryptography, patch management, physical security for ICT infrastructure.

• Article 10 — Detection: monitoring and logging to detect anomalous activity. Log retention requirements.

• Article 11 — Response and recovery: incident response plans with defined roles, recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical functions.

• Article 12 — Backup and recovery: backup policies, restoration procedures, annual testing.

• Article 13 — Learning and evolving: post-incident reviews, lessons learned integration into risk management.

• Article 14 — Communication: crisis communication plans, internal escalation, public and regulatory communication.

• Article 15 — Further harmonisation: EBA/ESMA/EIOPA joint technical standards (published 2024) specify additional requirements for significant financial entities.

What makes DORA different from a methodology standard:

DORA is law. Non-compliance is not a gap to be noted in an audit report — it is a regulatory breach. The European Supervisory Authorities (ESAs) have supervisory and investigative powers, and national competent authorities (NCAs) carry enforcement responsibility in each member state. Fines under DORA can reach up to 2% of total annual worldwide turnover for financial entities, and up to €10 million for individuals in management positions.

DORA also covers entities that ISO 27005 and NIST RMF do not specifically address: ICT third-party service providers (including cloud providers) are subject to oversight under Articles 28 through 44.

Comparison Matrix

A Custom Hybrid Approach: What We See in Practice

Few regulated financial entities in 2026 operate in a single compliance context. A Ukrainian fintech with EU operations, ISO 27001 certification, and SOC 2 requirements from enterprise clients needs elements from all three frameworks.

In practice, a workable hybrid looks like this:

Foundation layer — ISO 27005 methodology: Use ISO 27005 as the risk identification and assessment engine. This satisfies the risk management requirements of ISO 27001 (and by extension NBU Resolution No. 143) and gives you a jurisdiction-neutral methodology that certification auditors recognise.

Overlay layer — DORA-specific requirements: Map your ISO 27005 risk treatment process to DORA Articles 6–15. The register of information assets (Article 8) becomes a structured output of your asset identification process. Your incident response plan (Article 11) is designed to meet DORA reporting timelines from the start. Third-party risk receives separate treatment under Article 28 requirements.

Evidence layer — NIST SP 800-53 controls: For organisations serving US markets or working toward SOC 2, map your ISO 27001 Annex A controls to NIST SP 800-53 control families. Many controls are equivalent; the mapping exercise creates artefacts that satisfy both US and EU audit requirements without building two separate control frameworks.

The key principle is to avoid building three separate frameworks. Risk is assessed once. Controls are implemented once. The evidence is organised so it satisfies multiple audit frameworks simultaneously.

How to Choose: Five Questions for Your Business

Before selecting a primary framework, answer these:

1. What is your regulatory jurisdiction? If you are an EU-regulated financial entity (bank, payment institution, investment firm, insurance company, crypto asset service provider), DORA compliance is mandatory regardless of what other frameworks you use. Start with DORA and build outward.

If you are a Ukrainian NBFI under NBU Resolution No. 143, ISO 27001 (and ISO 27005) is the referenced standard. DORA applies only if you have EU-licensed entities or serve EU-regulated clients in a way that brings you into DORA scope.

2. Do you hold or are you pursuing ISO 27001 certification? If yes, ISO 27005 is the natural methodology. If no, but you are in DORA scope, you can build an ISO 27005-aligned process without pursuing certification — the methodology is independent of the certification scheme.

3. Do you have US enterprise clients or US regulatory obligations? If enterprise clients require SOC 2 evidence or ask about NIST alignment in security questionnaires, incorporating NIST SP 800-53 control language into your control framework reduces friction. You do not need to implement the full NIST RMF process — the control vocabulary is what matters for SOC 2 mapping.

4. What is your third-party ICT exposure? If you use critical cloud providers, payment processors, or outsourced ICT services, DORA Article 28 applies (for in-scope entities) or NIS 2 Article 21(2)(d) applies (for NIS 2-covered sectors). ISO 27005 addresses third-party risk at the ISMS level; for DORA you need a distinct TPRM (Third-Party Risk Management) programme.

5. What does your board risk appetite look like? DORA Article 5 requires management body accountability for ICT risk. If your board has not formally adopted an ICT risk tolerance statement and does not review ICT risk at least annually, that gap exists regardless of which framework you choose. Framework selection without governance change does not resolve a DORA compliance issue.

Getting This Right in 2026

The organisations that are in compliance trouble today are not those that chose the "wrong" framework. They are the ones that treated risk management as a documentation exercise — producing a risk register, filing it, and revisiting it only when an audit was scheduled.

The frameworks described here are processes, not documents. ISO 27005 works when risk assessments feed into treatment decisions that feed into control implementation. NIST RMF works when the authorisation to operate is tied to evidence that controls are functioning. DORA works when the board receives regular ICT risk reporting and can demonstrate that to a supervisor.

The deadline structure in 2026 is unambiguous. NBU No. 143: 13 December 2026. DORA supervisory cycle: already active. NIS 2: transposition completed in most EU member states, enforcement ongoing.

If you are in scope for any of these and have not yet established a formal risk management framework, the time to start is now — not because of the penalty risk, but because the implementation timeline for a credible ISMS or DORA-compliant ICT risk framework is six to twelve months minimum, depending on organisational maturity.

If you are deciding which approach fits your organisation's regulatory context, we are open to a conversation. Get in touch.