If you run engineering or product at a Nordic fintech, you have been hearing DORA in every compliance conversation since 2024. Your board has asked about it. Your bank partners have sent you questionnaires. Your legal team has flagged it. And most of the written material out there is either a law-firm memo that explains nothing operational, or a vendor piece that concludes, surprise, you should buy their resilience platform.

This article is neither. It's a working CTO's view of what DORA actually requires, how it connects to work you are already doing on ISO 27001 and NIS2, and what 90 days of focused execution looks like.

What DORA actually is, in one paragraph

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is an EU regulation, not a directive, which means it applies uniformly across member states without national transposition in the way NIS2 does. It covers the digital operational resilience of financial entities and their ICT third-party providers. It has applied from 17 January 2025. Supervision in Denmark sits with Finanstilsynet; in Sweden with Finansinspektionen; in Norway with Finanstilsynet (Norway); in Finland with Finanssivalvonta.

DORA replaces a patchwork of overlapping requirements (EBA ICT guidelines, EIOPA guidelines, ESMA cloud outsourcing guidance) with a single rulebook. If your compliance programme was built around those older guidelines, DORA is a consolidation rather than a revolution, and most of your existing work carries over with reshaping.

Are you in scope?

The simple test: read Article 2 of the regulation. It lists 21 categories of financial entity, from credit institutions and payment service providers to crypto-asset service providers, investment firms, insurers, UCITS, AIFMs, and credit rating agencies. If your authorisation sits in any of those, you are in scope.

A few practical patterns for Nordic fintech:

  • Payment institutions under PSD2 authorisation: fully in scope.
  • E-money institutions: fully in scope.
  • Investment firms: fully in scope.
  • Crypto-asset service providers authorised under MiCA: fully in scope.
  • SaaS vendors selling into financial entities but not themselves authorised: you are not a financial entity for DORA purposes, but you will be treated as an ICT third-party provider and will answer third-party risk questionnaires as if you were.

The last case is where most Nordic B2B SaaS founders get confused. You are not subject to DORA directly. But the entire fifth pillar of DORA is your customers evaluating you, so practically every question your customers will ask you in 2026 maps to a DORA requirement they are pushing through their supply chain. Answering "we are not in scope of DORA" satisfies nothing.

The five pillars of DORA, translated

Pillar 1: ICT risk management (Chapter II)

Article 5 requires a documented ICT risk management framework proportionate to your size and risk profile. Article 6 sets out the required components: a strategy, policies, procedures, protocols and tools to protect information assets. Article 8 requires identification of ICT-supported business functions and supporting ICT assets.

If you have a working ISO 27001 Information Security Management System, the bones of this pillar are already built. DORA requires specific additions: a written ICT strategy approved by the management body, explicit ICT business continuity and disaster recovery policies, and documented ICT third-party risk management. The gaps are usually documentation, not substance.

Pillar 2: ICT-related incident management and reporting (Chapter III)

Article 17 requires a documented incident management process. Articles 19 and 20 set out classification criteria and reporting timelines. The reporting cadence for major ICT incidents: initial notification within 4 hours of classification as major, intermediate report within 72 hours, final report within 1 month.

The trap here is the classification test. Most firms under-report because they under-classify. The criteria (clients affected, geographical spread, duration, data loss, economic impact, reputational damage, critical services affected) are set by the Regulatory Technical Standards and you need a written decision tree that your on-call engineers can use at 2am.

Pillar 3: Digital operational resilience testing (Chapter IV)

Article 24 requires a testing programme. Article 25 lists the types of tests: vulnerability assessments, scenario-based tests, performance tests, compatibility tests, penetration tests, source code reviews. Article 26 introduces Threat-Led Penetration Testing (TLPT) for significant entities.

Most growing fintechs are not immediately in the TLPT population. For the baseline regime, you need an annual test plan, documented execution, and remediation tracking. Where teams get this wrong is treating it as a once-a-year pen test. The regulation contemplates a programme of varied tests across the year, not a single snapshot.

Pillar 4: ICT third-party risk (Chapter V)

This is the pillar with the most operational impact. Article 28 requires a strategy and policy. Article 29 sets conditions for pre-contractual assessment. Article 30 defines mandatory contractual clauses including audit rights, data access, exit strategies, and subcontracting restrictions. Article 31 introduces the Union-level oversight framework for critical ICT third-party service providers.

Practical requirements you need to execute:

  • A Register of Information covering every ICT third-party arrangement, with the structure defined by the ITS.
  • A pre-contractual due diligence process that actually runs before a contract is signed, not after.
  • Contract renegotiation for existing providers where clauses don't meet Article 30 minima. This is the single largest operational cost of DORA.
  • An exit strategy for every ICT third-party supporting a critical or important function.

Pillar 5: Information-sharing arrangements (Chapter VI)

Article 45 encourages but does not require information-sharing arrangements on cyber threat intelligence. Most firms participate in FS-ISAC or a national equivalent. In practice this pillar is the lightest lift, but if you are a significant entity, supervisors expect to see some form of information-sharing activity documented.

The 90-day plan for a 100-250 person Nordic fintech

Assuming you are behind (most are): here is what 90 days of focused work produces, assuming you already have a working ISMS and some form of incident process.

Days 1-30: scope, gaps, and the ICT strategy

  • Confirm scope under Article 2 with legal sign-off. Document the analysis.
  • Produce a written ICT strategy, approved by the management body.
  • Draft or update the ICT risk management framework policy, aligned to Chapter II.
  • Map existing ISO 27001 or SOC 2 controls against DORA articles. Produce a gap register with severity and effort estimates.
  • Build the Register of Information skeleton using the ITS template. Populate with your top 20 ICT providers.

Days 31-60: incident response and third-party

  • Finalise the incident classification decision tree, aligned to the RTS criteria.
  • Run a tabletop exercise on a major incident scenario. Document it.
  • Complete the Register of Information for all ICT third-party arrangements.
  • Identify the top 5-10 providers supporting critical or important functions. Assess Article 30 contract clause coverage. Begin renegotiation where gaps exist.
  • Draft exit strategies for the top 3 most critical providers.

Days 61-90: testing, governance, board

  • Produce an annual testing plan covering Article 25 test types proportionate to your size. Schedule the first round.
  • Run a management body training session on ICT risk. Article 5 requires it.
  • Draft the first quarterly ICT risk report for the management body.
  • Engage with Finanstilsynet (or your local supervisor) to share your readiness posture proactively if you haven't already.
  • Close the gap register to zero P0/P1 items or have a documented remediation plan with dates and owners.

Where DORA gets expensive

Four places. The Register of Information is tedious but cheap once the template is solid. The contract renegotiation is where real money goes: in a 250-person fintech with 150 ICT vendors, you will spend months pushing Article 30 clauses through vendor legal teams, and some contracts will require premium pricing to adopt the stricter terms.

The testing programme is the second cost centre. A credible programme combines internal vulnerability scanning, external network tests, scenario-based business continuity tests, and red-team exercises sized to your risk profile. Do not confuse a TLPT (which most small-and-medium fintechs are not required to run) with the baseline testing programme (which everyone runs).

The third cost is governance. Monthly reporting to the management body, documented training, and the decision trails required by the RTS. If you run a lean leadership team this is where the time goes.

The fourth, and most often missed, is the work of classifying "critical or important functions" properly. Many firms default to calling everything critical, which inflates the third-party regime beyond what the regulation actually requires. Good classification work is both compliance and operational cost control.

Common traps in Nordic implementation

A few patterns I have seen or heard repeatedly in Nordic fintech DORA programmes:

  • Treating DORA as a NIS2 variant. They overlap but aren't the same. Financial entities under DORA are carved out of NIS2 for ICT risk management, but national NIS2 sectoral rules can still reach you in specific cases. Read both.
  • Delegating it to Legal or Compliance alone. DORA is deeply operational. If Engineering is not in the core programme team, the testing and third-party pillars stall.
  • Copying a large bank's template. The regulation is explicitly proportionate. A 180-person fintech does not need a 400-page framework. You need a 40-page framework that your team can actually operate.
  • Missing the ICT third-party data flow. Article 28 applies to your providers. Your SaaS vendors' DPAs may already cover parts of it. Check before rewriting.
  • Ignoring exit strategies until the day before a supervisor asks. Article 28(8) requires them. They are the item most commonly raised in supervisory reviews.

How this connects to the ISO 27001 or SOC 2 programme you already run

If you have or are pursuing ISO 27001, roughly 60-70% of DORA's Chapter II (ICT risk management) overlaps with ISO controls and ISMS structure. SOC 2 Type II coverage is similar but thinner on governance. Neither covers the third-party contract renegotiation work, the Register of Information, or the incident classification/reporting cadence.

The most efficient path: treat DORA as a delta on top of your existing ISMS, not a parallel programme. Your Statement of Applicability maps to DORA articles, your risk register extends to cover ICT-specific risks, your third-party controls extend to cover Article 30 clauses. One programme, two audiences.

Primary sources worth reading directly

  • Regulation (EU) 2022/2554 on eur-lex.europa.eu (the DORA text itself)
  • The adopted Regulatory Technical Standards (multiple Commission Delegated Regulations, 2024)
  • The Register of Information Implementing Technical Standards
  • Local supervisor guidance: Finanstilsynet (DK), Finansinspektionen (SE), Finanstilsynet (NO), Finanssivalvonta (FI)
  • EIOPA and ESMA peer review publications on DORA implementation

If you are behind, the single most useful thing you can do this month is confirm scope, populate the Register of Information skeleton, and write the ICT strategy. The other pillars fall out of that work. If you want a second opinion or a structured 90-day plan, that is exactly what the Customer AI Readiness and Readiness Assessment products are shaped for.