DORA Regulation for Fintechs: ICT and Third-Party Risk

What It Is

DORA is a regulation, so it applies directly across member states, supported by technical standards. It is built on five pillars. ICT risk management requires a documented framework covering identification, protection, detection, response and recovery, learning, and communication, with the management body ultimately responsible. ICT-related incident management requires classification of incidents and reporting of major incidents to the competent authority within set timeframes. Digital operational resilience testing requires a testing programme proportionate to the entity; certain entities designated by authorities must also undergo threat-led penetration testing under specific rules. ICT third-party risk management requires a register of information on all ICT service arrangements, risk assessment before contracting, specific contractual provisions, and exit strategies. Information sharing on threats is encouraged within trusted communities. Proportionality applies throughout, and a defined list of smaller entities, such as small and non-interconnected investment firms and certain exempted payment and e-money institutions, may apply the simplified ICT risk-management framework in Article 16.

Who It Is For

This guide is aimed at:

• Payment, e-money, crypto-asset, investment, and other licensed fintechs that fall within DORA's list of financial entities
• Compliance, risk, and technology leads building or reviewing a DORA programme
• ICT providers and software vendors serving financial entities and receiving DORA contract requirements
• Founders who need to explain DORA expectations to investors or boards

What It Helps Clarify

Reviewing the pillars helps clarify:

• Which critical or important functions your business supports and which ICT systems they depend on
• Whether your third-party register and contracts contain what DORA expects
• What your resilience testing programme should include given your size and risk profile
• Where technical evidence is missing to support governance documents

What's Included

• Governance: confirm management body approval and oversight of the ICT risk framework, and document roles
• Asset and function mapping: identify critical or important functions and the systems, data, and providers behind them
• Protection and detection: review access control, MFA, logging, and monitoring for those systems
• Incident management: define classification criteria, decision-makers, and reporting workflow for major incidents
• Continuity: test backup, restoration, and recovery objectives for critical functions
• Testing programme: plan vulnerability assessments, scenario tests, and penetration tests proportionate to risk
• Third-party register: list all ICT arrangements with function, data, location, and sub-contracting details
• Contracts: check for required provisions such as service descriptions, data location, audit and access rights, incident support, and exit terms
• Exit strategies: document how you would move away from a critical provider
• Concentration risk: note where several critical functions rely on one provider

What's Not Included

• Legal advice or regulatory interpretation for your specific licence
• Threat-led penetration testing under a regulator-designated framework
• Submission of incident reports or registers to authorities
• Certification or compliance approval

When to Choose It

Use this guide when preparing or reviewing your DORA programme, before renewing contracts with key ICT providers, and before your annual testing plan is set. If your competent authority has issued specific guidance or requests, follow those first. Vendors serving financial entities should use the third-party section to anticipate contract and audit requests. This article is general information and not legal advice.

Our Approach

Most fintechs find that documentation exists but technical evidence is thin. Start by mapping critical functions to systems and providers; this single exercise drives the register, testing scope, and continuity planning. Then gather evidence on how key controls actually work. Our Security Baseline Review can provide a written, severity-graded view of agreed assets, which helps show where configuration and access controls stand. For application and API testing within the resilience testing programme, our Penetration Testing service works from written scope and authorisation and delivers severity-graded findings, with retesting of agreed findings where included. Both complement regulator-designated threat-led testing, legal advice, and compliance approval, which follow their own processes. Keep each piece of evidence dated and linked to the function it supports, so management reviews and supervisory questions can be answered from records rather than memory.

Security Baseline Review

Frequently Asked Questions

Related Articles