DORA — Requirements for IT suppliers in the financial sector

DORA (Digital Operational Resilience Act) is the EU regulation for digital operational resilience in the financial sector. It has been in force in Norway since 1 July 2025 and imposes strict requirements on banks, insurance companies, investment firms, payment services — and their ICT suppliers. If you provide software, cloud services, or IT operations to the financial sector, you are directly affected.

DORA represents a paradigm shift in how the EU and EEA regulate ICT risk in the financial industry. Previously, requirements were fragmented across various sector directives and national guidelines. Now the entire financial sector — and its supply chain — is subject to a single, detailed regulatory framework for digital resilience. For IT suppliers, this means that contractual terms, security processes, and reporting routines must meet specific regulatory requirements, not just customers' internal standards.

In this article, we provide a thorough overview of what DORA entails, who is affected, and concrete steps IT suppliers should take now.

What is DORA?

DORA — Digital Operational Resilience Act — is an EU regulation (2022/2554) adopted in December 2022 that took effect in the EU on 17 January 2025. Its purpose is to ensure that the financial sector can withstand, respond to, and recover from ICT-related disruptions and threats. The regulation has been incorporated into the EEA Agreement and has been applicable Norwegian law since 1 July 2025.

Unlike many other EU legal instruments, DORA is a regulation, not a directive. This means it applies directly in Norwegian law without the need for national transposition legislation — the requirements are identical across the entire EEA. This ensures a harmonised regulatory framework where financial institutions and their suppliers face the same requirements regardless of which country they operate in.

DORA is built on five pillars: ICT risk management, incident reporting, digital resilience testing, third-party risk management, and information sharing. Together, these form a comprehensive framework for digital operational resilience.

Background: Why DORA?

The financial sector is among the most digitised industries in Europe. Banks, insurance companies, and investment firms depend on complex ICT systems for everything from payment processing and securities trading to customer service and risk management. This dependency creates significant vulnerability.

In recent years, several serious incidents have demonstrated the consequences of inadequate digital resilience in the financial sector: denial-of-service attacks against banks, ransomware attacks on insurance companies, and downtime at critical payment providers that paralysed entire value chains. An outage at a single critical IT supplier can rapidly have systemic consequences — not just for the individual financial institution, but for the entire financial system.

Before DORA, ICT risk requirements in the financial sector were spread across various regulatory frameworks such as CRD IV, Solvency II, PSD2, and national ICT regulations. This led to inconsistent practices, overlapping requirements, and gaps in regulation — particularly regarding requirements for third-party suppliers.

DORA addresses this by establishing a single, cross-sector framework covering the entire value chain — from the financial institution itself to the smallest software supplier in the chain.

Timeline: From EU adoption to Norwegian reporting deadline

• December 2022: EU adopts the DORA regulation (2022/2554)
• January 2024: DORA formally enters into force in the EU (24-month implementation period begins)
• 17 January 2025: DORA becomes applicable law in EU member states
• 1 July 2025: DORA takes effect in Norway through EEA incorporation
• 13 March 2026: First deadline for Register of Information (RoI) — reporting to Finanstilsynet (the Financial Supervisory Authority of Norway)
• 2026–2027: Finanstilsynet conducts its first supervisory activities under DORA
• Ongoing: Continuous compliance and updating of ICT risk management frameworks

Who is affected by DORA?

DORA has a broad scope that extends far beyond traditional banks. The regulation covers more than 20 categories of financial entities — and, equally important, their ICT third-party service providers.

Financial entities

Category	Examples
Credit institutions	Banks, savings banks, credit companies
Insurance undertakings	Life insurance, non-life insurance, reinsurance
Investment firms	Brokerage firms, asset management companies
Payment institutions	Payment services, e-money institutions
Fund managers	UCITS managers, AIF managers
Trading venues	Stock exchanges, multilateral trading facilities
Securities registries	Central securities depositories
Pension funds	Occupational pension providers
Crypto-asset service providers	Exchanges, custody services for crypto-assets
Crowdfunding platforms	Crowdfunding service providers

ICT third-party service providers

Equally important as the financial entities themselves are the ICT third-party service providers that serve them. DORA defines an ICT third-party service provider as any undertaking providing digital and data services — including, but not limited to:

• Cloud providers (IaaS, PaaS, SaaS)
• Software vendors (core banking systems, payment platforms, CRM, risk models)
• IT operations providers (managed services, hosting, monitoring)
• Data analytics and reporting services
• Cybersecurity services (SOC, penetration testing, security consulting)
• Network and communications services

If your business provides any of these services to entities in the financial sector, you are subject to DORA's third-party requirements — regardless of your own size or sector.

The five pillars of DORA

DORA is structured around five core areas that together form a comprehensive framework for digital operational resilience.

1. ICT risk management

The first and most fundamental pillar requires financial entities to establish a robust ICT risk management framework. This includes:

• ICT risk management framework: A documented, comprehensive framework that identifies, classifies, and manages ICT risks. The framework must be reviewed and updated at least annually.
• Identification and mapping: All ICT assets, systems, processes, and dependencies — including third-party providers — must be mapped and classified by criticality.
• Protection and prevention: Technical and organisational measures to protect ICT systems, including access control, encryption, network security, and security awareness.
• Detection: Mechanisms to detect anomalous activities, threats, and vulnerabilities in ICT systems.
• Response and recovery: Documented plans for incident handling, crisis communication, and recovery of ICT services following disruptions.
• Learning and improvement: Systematic review of incidents and tests to improve the framework over time.

Management has an explicit responsibility to approve and oversee the ICT risk management framework. DORA requires that the board and senior management take active ownership of digital operational resilience.

2. Incident reporting

DORA introduces a standardised regime for reporting ICT-related incidents:

• Classification: All ICT incidents must be classified according to criteria such as duration, geographical spread, number of affected customers, data loss, and impact on critical services.
• Major incidents: Incidents meeting the threshold criteria (e.g., affecting critical services, impacting a large number of customers, or having financial consequences above a certain threshold) must be reported to Finanstilsynet.
• Reporting deadlines: Initial notification within four hours of classification, intermediate report within 72 hours, and final report within one month.
• Voluntary notification: Financial entities may also voluntarily report significant cyber threats they identify, even if these have not resulted in an incident.

For IT suppliers, this means that contracts with financial customers must contain clear terms on incident notification — including timeframes and reporting formats that enable the customer to fulfil its obligations to Finanstilsynet.

3. Digital resilience testing

DORA requires financial entities to conduct regular testing of their digital resilience:

• Basic testing: All entities must carry out annual testing including vulnerability assessments, network security tests, gap analyses, physical security testing, source code reviews, and scenario-based tests.
• Advanced testing (TLPT): Entities identified by Finanstilsynet — typically the largest and most systemically important — must conduct Threat-Led Penetration Testing at least every three years. TLPT must be performed in the production environment by qualified, independent testers and simulate realistic attack scenarios based on up-to-date threat intelligence.
• Testing of third parties: Entities using ICT third-party providers for critical or important functions must include these providers in their testing programme — either through joint testing or by requiring documentation of the provider's own testing.

TLPT is one of the most demanding provisions in DORA. For IT suppliers serving systemically important financial institutions, this means their systems and infrastructure may be directly subject to penetration testing — and that they must accommodate this in their agreements and processes.

4. Third-party risk management

Third-party risk management is perhaps the pillar with the greatest direct impact on IT suppliers. DORA sets out detailed requirements for how financial entities must manage the risk associated with their ICT providers:

• Pre-assessment: Before entering into an agreement with an ICT provider, a financial entity must conduct a thorough risk assessment — including evaluation of the provider's security level, concentration risk, and exit options.
• Contractual requirements: DORA sets minimum requirements for the content of ICT provider agreements, including SLAs, audit rights, incident reporting, exit clauses, data handling, and sub-contractor control.
• Ongoing monitoring: Financial entities must continuously monitor ICT third-party risk, including regular audits and risk assessments.
• Register of Information (RoI): All financial entities must maintain an up-to-date register of all ICT third-party agreements, which must be reported to Finanstilsynet.
• Concentration risk: Financial entities must assess the risk associated with excessive dependence on individual providers.
• Exit strategies: Documented plans must be in place for terminating provider relationships without disrupting critical services.

For providers identified as critical ICT third-party service providers at EU level, DORA additionally introduces a direct supervisory regime led by one of the European Supervisory Authorities (EBA, EIOPA, or ESMA).

5. Information sharing

The fifth pillar encourages — but does not mandate — financial entities to share information about cyber threats, attack methods, and vulnerabilities among themselves. The purpose is to strengthen the collective resilience of the sector.

DORA facilitates the establishment of information-sharing arrangements between financial entities and ensures that such sharing can take place within the frameworks of competition law and data protection.

What does DORA mean for IT suppliers?

This is the core issue: DORA does not only affect financial institutions — it regulates the entire supply chain. If you provide ICT services to the financial sector, you are directly affected. Here are the most important implications:

New contractual requirements

Financial institutions are required to incorporate DORA's minimum requirements into all ICT provider agreements. Suppliers who cannot accept these terms risk losing existing contracts or being excluded from new tenders. Key contractual requirements include:

• Defined SLAs with measurable performance targets
• Full audit rights for the customer and Finanstilsynet — including the right to inspect the supplier's premises and systems
• Obligation to report ICT incidents within agreed timeframes
• Data handling requirements, including data location and procedures for return or deletion upon contract termination
• Sub-contractor control — the supplier must be able to document and manage the risk associated with its own sub-contractors
• Exit clauses ensuring orderly transition when changing suppliers

Audit access requirements

One of the most notable requirements for IT suppliers is that financial customers have the right to audit the supplier's ICT risk management. In practice, this means the supplier must be able to:

• Make documentation available for customer audits
• Facilitate inspections — either on-site or through pooled audits with multiple customers
• Grant Finanstilsynet access to relevant information and systems as needed
• Cooperate with external auditors appointed by the customer

Incident reporting up the chain

When an ICT incident affects the supplier's systems and impacts the financial customer's services, the supplier must be able to notify the customer quickly enough for the customer to fulfil its reporting obligations to Finanstilsynet. In practice, this means the supplier needs:

• Effective detection and classification mechanisms
• Pre-defined notification procedures and contact points
• Capacity to deliver qualified information about the incident's scope, cause, and expected resolution time
• Ability to support the customer's incident reporting with technical details

TLPT participation requirements

Suppliers providing critical services to systemically important financial entities may be included in threat-led penetration testing. This means the supplier must:

• Accept that its own systems and infrastructure are tested by independent threat actors
• Have processes to handle such testing without disrupting services
• Follow up on findings and implement remediation within agreed deadlines

What is the Register of Information (RoI)?

The Register of Information (RoI) is a central element of DORA's third-party risk management. All financial entities are required to maintain an up-to-date register of all their ICT third-party agreements. The register must contain detailed information about:

• The provider's identity and organisational structure
• Which ICT services are provided
• Whether the service supports critical or important functions
• Data location (processing and storage)
• Sub-contractors in the delivery chain
• Agreement duration, termination terms, and exit strategies

The first deadline for RoI reporting to Finanstilsynet was 13 March 2026. For IT suppliers, this means financial customers have requested — or will request — detailed information about the services you provide, the sub-contractors you use, and where data is processed and stored.

Suppliers who cannot deliver this information in a structured and verifiable manner represent a compliance risk for their financial customers — and risk being replaced by suppliers who can.

DORA and NIS2: How are they related?

DORA and NIS2 are two complementary EU regulatory frameworks that both address cybersecurity, but with different focus areas and scope. For organisations affected by both, it is important to understand the interplay.

Aspect	DORA	NIS2
Focus	Digital operational resilience in the financial sector	Cybersecurity across critical sectors
Type of regulation	Regulation (directly applicable)	Directive (requires national transposition)
Sector	Financial sector and ICT suppliers to finance	18 sectors incl. energy, health, transport, digital infrastructure
Supervision in Norway	Finanstilsynet	NSM, Nkom, and sector supervisors
Third-party requirements	Highly detailed — contractual requirements, RoI, TLPT	General supply chain security requirements
Incident reporting	4 hours (initial), 72 hours (intermediate report), 1 month (final report)	24 hours (early warning), 72 hours (incident assessment), 1 month (final report)
Resilience testing	Mandatory, incl. TLPT for systemically important entities	General security testing requirements
Lex specialis	DORA takes precedence over NIS2 for the financial sector	Applies where DORA does not have specific provisions

An important principle is that DORA is lex specialis — it takes precedence over NIS2 for the financial sector. Where DORA sets stricter or more specific requirements than NIS2, DORA applies. However, NIS2 may still apply to aspects that DORA does not explicitly cover.

For IT suppliers serving customers across multiple sectors, this means you may potentially need to comply with both regulatory frameworks. A pragmatic approach is to build a compliance framework covering the strictest requirements — typically DORA — and then map any additional NIS2 requirements for customers outside the financial sector.

What are the sanctions for DORA non-compliance?

Finanstilsynet has been granted significant enforcement tools under DORA. The sanctions regime affects both financial entities and, indirectly, their suppliers:

For financial entities:

• Administrative fines based on proportionality assessment — amounts are set nationally but must be "effective, proportionate, and dissuasive"
• Orders to cease conduct that breaches DORA
• Public disclosure of violations (naming and shaming)
• Temporary prohibition from exercising management functions
• Periodic penalty payments for non-compliance with orders

For critical ICT third-party service providers under direct supervision:

• Periodic penalty payments of up to 1% of average daily global turnover for each day of non-compliance, for up to six months
• Orders to change practices, procedures, or security measures
• Public disclosure of non-compliance
• Recommendation to financial entities to suspend or terminate service agreements

For IT suppliers not under direct supervision, the most tangible risk is indirect: financial customers who cannot achieve satisfactory compliance with their suppliers will be compelled to switch providers. DORA compliance thus becomes a competitive differentiator — not just a legal requirement.

Practical steps for IT suppliers

If you provide ICT services to the financial sector, you should already be well under way with DORA preparations. Here is a phased checklist:

Phase 1: Mapping and analysis (should be completed)

• Identify all customer relationships in the financial sector
• Map which services you provide that support critical or important functions at financial customers
• Conduct a gap analysis of existing agreements against DORA's contractual requirements
• Map your own sub-contractors and their role in the delivery
• Assess whether you could potentially be classified as a critical ICT third-party service provider
• Map where data is processed and stored for each financial customer

Phase 2: Adapting frameworks and processes (in progress)

• Update or establish an ICT risk management framework in line with DORA requirements
• Establish incident handling and notification procedures that support customers' reporting deadlines
• Implement or strengthen logging, monitoring, and detection capabilities
• Update security policies, access management, and encryption practices
• Prepare documentation supporting customers' RoI reporting
• Establish procedures for audits and inspections from financial customers

Phase 3: Contract and agreement updates (in progress)

• Update standard agreements with DORA-required clauses (SLA, audit rights, incident reporting, exit, data handling)
• Negotiate updated terms with existing financial customers
• Establish procedures for sub-contractor control and reporting
• Document exit strategies ensuring orderly transition upon contract termination

Phase 4: Testing and continuous improvement (ongoing)

• Conduct regular vulnerability assessments and security tests
• Prepare the organisation to participate in customers' TLPT programmes
• Practise incident handling through tabletop exercises with financial customers
• Conduct regular audits of sub-contractors
• Update risk management and documentation based on new threat intelligence and lessons learned
• Keep management and key personnel updated on regulatory changes

How we can help

At UNOS SOFTWARE AS, we work with Norwegian businesses that develop and operate technology solutions for regulated industries. Together with our partner Unos IT AS, we offer a complete range of services from development to operations. We understand the requirements DORA imposes on IT suppliers — because we ourselves operate in this landscape.

We can assist with:

• Secure software development for the financial sector — through our software development service, we build solutions with built-in security, logging, access control, and incident handling that meet DORA requirements
• Technical consulting on DORA compliance — our consulting service helps IT suppliers with gap analyses, design of ICT risk management frameworks, and preparation for audits
• System integration and API security — through our integration service, we ensure that the interfaces between your systems and financial customers' infrastructure meet security requirements
• Cloud infrastructure with built-in compliance — our cloud and infrastructure service delivers documented, monitored, and auditable environments tailored to regulatory requirements

DORA is not a one-off project — it is a continuous compliance regime that requires ongoing attention, updating, and improvement. The sooner you establish a solid foundation, the easier day-to-day compliance will be.

DORA is part of a broader regulatory wave from the EU. Also read about the Cyber Resilience Act (CRA), which sets security requirements for digital products, and the EU Data Act with new rules for data sharing and cloud portability.

Does your business need assistance with DORA compliance? Get in touch for an informal conversation about how we can help you meet the requirements.

Frequently asked questions about DORA

Does DORA apply to IT suppliers outside the financial sector?

Yes — DORA does not only affect financial institutions, but also all ICT third-party service providers that deliver services to them. If you provide software, cloud services, or IT operations to banks, insurance companies, or payment services, you are directly affected.

What is the difference between DORA and NIS2?

DORA is sector-specific to the financial sector and has more detailed requirements for third-party risk and resilience testing. NIS2 has broader coverage across critical sectors. DORA takes precedence (lex specialis) over NIS2 for the financial sector where requirements overlap.

What is TLPT, and must IT suppliers participate?

TLPT (Threat-Led Penetration Testing) is threat-based penetration testing that systemically important financial institutions must conduct at least every three years. IT suppliers providing critical services to these institutions may be included in the tests and must accommodate this.

What is the Register of Information (RoI)?

RoI is a register of all ICT third-party agreements that financial entities must maintain and report to Finanstilsynet. The first reporting deadline was 13 March 2026. IT suppliers must be able to deliver structured information about their services to financial customers.

What do IT suppliers risk from DORA non-compliance?

Critical ICT third-party service providers can be subject to periodic penalty payments of up to 1 percent of daily global turnover. For other suppliers, the greatest risk is indirect — financial customers who cannot achieve compliance will switch to suppliers who can meet the requirements.

---

Sources and further reading

• European Parliament (2022). "Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA)." eur-lex.europa.eu
• Finanstilsynet (2025). "DORA — requirements for digital operational resilience in the financial sector." finanstilsynet.no
• Finanstilsynet (2026). "Register of Information (RoI) — reporting guidance." finanstilsynet.no
• European Supervisory Authorities (2025). "Final Report on DORA Regulatory Technical Standards." eba.europa.eu
• EIOPA (2025). "DORA Implementation — Guidelines for ICT Third-Party Service Providers." eiopa.europa.eu
• Regjeringen (2025). "Implementation of DORA in Norwegian law." regjeringen.no
• NSM (2025). "National Digital Risk Assessment 2025 — the financial sector." nsm.no
• Finans Norge (2025). "DORA — guide for the financial industry." finansnorge.no

---

Get in touch

Do you provide ICT services to the financial sector and need help with DORA compliance? UNOS SOFTWARE AS — in partnership with Unos IT AS — assists with security, risk management, and compliance for IT suppliers. Send us an enquiry through the contact form — we will have an informal conversation about how your business can meet the DORA requirements.