DORA Compliance for MSPs: How to Serve EU Financial Services Clients in 2026

DORA Is Live. Most MSPs Don’t Know It Yet.

The EU’s Digital Operational Resilience Act became law on 17 January 2025. It covers every financial entity operating in the EU — banks, insurers, investment firms, payment processors, crypto-asset service providers — and their ICT third-party suppliers.

That last part matters more than most MSPs realise.

If your client base includes any financial services businesses with EU operations, EU customers, or EU regulatory obligations, some of your clients are already subject to DORA. They have ICT risk management obligations they may not be meeting. They have incident reporting requirements with hard timelines — four hours for initial notification of a major incident. They have third-party contractual requirements that affect every IT supplier they use, potentially including you.

And most of them are struggling.

The financial services firms that have DORA fully under control are the large institutions with dedicated compliance and operational risk teams. The mid-market and smaller financial entities — the fintech, the payment company, the insurance broker, the investment manager — often don’t have that internal capability. They’re looking for external support.

That’s the MSP opportunity.

This guide explains what DORA actually requires, where the gaps tend to be, how to structure a DORA service offering, and what it takes to deliver it competently.

---

What DORA Actually Requires

DORA has five pillars. Understanding them is the basis for any advisory work.

1. ICT Risk Management

Every in-scope financial entity needs a documented ICT risk management framework approved at board level. This isn’t a one-time exercise — it’s a living governance structure that includes:

• An ICT risk strategy and risk appetite statement
• Asset identification and classification (covering all ICT systems, infrastructure, and data assets)
• Ongoing threat and vulnerability identification
• Protection and prevention controls
• Detection capabilities
• Response and recovery plans
• Communication procedures

The framework must be reviewed at least annually and after any major ICT incident. Board-level approval is required — not just sign-off from the CTO.

This is the governance work that vCISOs have always done. What DORA does is make it a regulatory requirement with a specific structure, specific documentation standards, and supervisory review.

2. ICT Incident Management and Reporting

DORA defines a classification scheme for ICT incidents based on criteria including the number of clients affected, the duration of the outage, the geographic spread, and the economic impact. A “major ICT incident” triggers a mandatory three-stage reporting obligation:

• Initial notification: within 4 hours of classifying an incident as major
• Intermediate report: within 72 hours
• Final report: within one calendar month

These go to the relevant European Supervisory Authority (ESA) — EBA for banks, EIOPA for insurance, ESMA for investment firms — or the national competent authority.

Four hours is not a lot of time to produce a regulatory notification if your detection and response workflow isn’t already set up for it. Most mid-market financial entities don’t have this plumbed in.

3. Digital Operational Resilience Testing

DORA mandates regular testing of ICT systems and resilience controls. There are two tracks:

Basic testing applies to all in-scope entities and includes vulnerability assessments, network security assessments, and scenario-based testing at least annually.

Threat-Led Penetration Testing (TLPT) applies to entities classified as significant and must be conducted every three years. TLPT is more demanding than a standard penetration test — it’s intelligence-led, it covers live production systems, and the methodology follows TIBER-EU or equivalent frameworks.

MSPs that have penetration testing relationships can position themselves as TLPT coordinators for smaller financial entities. Larger entities will run their own procurement, but smaller ones need help managing the process.

4. ICT Third-Party Risk Management

This is where things get interesting for MSPs specifically.

DORA requires financial entities to:

• Maintain a complete register of all ICT third-party arrangements — every cloud provider, software vendor, IT support contract, and managed service engagement
• Conduct due diligence before onboarding ICT third parties
• Include specific contractual clauses in all ICT supplier agreements covering audit rights, incident notification, sub-contracting restrictions, data portability, and termination assistance
• Define exit strategies for all critical or important ICT providers
• Assess concentration risk — if too many critical functions depend on a single third party

If your MSP provides services to a DORA-regulated client, you are an ICT third-party in scope of their DORA obligations. They should be asking you for security information, audit rights, and incident notification commitments. If they haven’t, they’re non-compliant — and if you can’t respond to those requests, you’re a gap in their framework.

5. Information and Intelligence Sharing

DORA explicitly encourages financial entities to share cyber threat intelligence with each other and with regulators. This is less of an operational burden than the other pillars, but it requires a process — and the intelligence shared has to come from somewhere.

---

Which Clients Are in Scope

The scope of DORA is broader than most people expect. It covers:

• Banks and credit institutions
• Payment and e-money institutions
• Investment firms and asset managers
• Insurance and reinsurance companies
• Crypto-asset service providers (CASPs) under MiCA
• Central counterparties and trading venues
• Credit rating agencies
• Pension fund management companies
• Data reporting service providers

The “EU operations” threshold is worth understanding precisely. A UK-based fintech that processes payments for EU customers, a payment institution that holds an EU e-money licence, an investment manager with an EU-passported fund — these entities all have DORA obligations. Post-Brexit, DORA doesn’t apply to purely domestic UK operations, but the overlap with UK entities is significant for any MSP with a UK financial services client base.

The regime also distinguishes between significant and non-significant entities. Significant entities face more demanding requirements — TLPT, more detailed incident reporting, enhanced third-party oversight. Your client’s classification will come from their supervisor, but MSPs should be ready to explain what the difference means in practical terms.

---

Where the Gaps Are

If you run a DORA gap assessment for a mid-market financial entity, you’ll almost always find the same set of problems.

The ICT asset register doesn’t exist or is incomplete. DORA requires a full inventory of ICT assets supporting critical or important functions. Most mid-market firms have partial inventories scattered across IT ticketing systems, spreadsheets, and people’s heads. Building one properly takes time and requires both IT and business input.

The third-party register is missing or out of date. Financial entities need to know every ICT supplier they use, what data those suppliers access, where that data is stored and processed, and what contractual protections are in place. Most have a rough list. Almost none have a maintained register with the detail DORA requires.

Incident detection and response processes are not aligned to DORA timelines. The four-hour initial notification window for major incidents requires a detection-to-decision workflow that most firms haven’t designed. Standard IT incident management processes don’t map cleanly onto DORA classifications.

Supplier contracts don’t contain the required clauses. DORA specifies what ICT supplier contracts must include. Most existing contracts predate DORA and don’t have audit rights, incident notification obligations, or exit support clauses. Renegotiating or adding addendums to every supplier contract is a significant body of work.

Testing is ad hoc, not structured. Annual vulnerability assessments and network testing exist in some firms. But DORA requires a testing programme — documented, risk-based, tracked against findings, with remediation timelines. One-off pentests filed in a drawer don’t meet the requirement.

Board-level governance isn’t there. Many smaller financial entities have a CTO or Head of IT who owns security. DORA requires the management body (board) to approve the ICT risk framework and be responsible for ICT risk oversight. Getting the governance structure right, and getting the board engaged in a meaningful way, is often the hardest part.

---

Building Your DORA Service Offering

The opportunity is clear. Here’s how to structure the service.

Stage 1: DORA Readiness Assessment (Fixed Fee: £4,000–£8,000)

The first engagement should be a structured assessment. This gives the client a clear picture of their current state and gives you the scope to design an ongoing service.

The assessment covers:

• Review of existing ICT risk management documentation against DORA Article 6 requirements
• ICT asset register review and gap identification
• Third-party register review
• Incident management process review against DORA reporting timelines
• Contract review across top 10 ICT suppliers for DORA-required clauses
• Testing programme review
• Board-level governance structure assessment

Output: a DORA gap report with findings rated by severity, effort, and regulatory risk, plus a recommended remediation roadmap.

This is a 3–5 week engagement for a mid-market entity. Price it at a rate that reflects the regulatory expertise required — not IT consulting day rates. Financial services compliance work commands a premium.

Stage 2: Remediation Programme (Fixed Scope or T&M)

The gap report generates a list of work. Some clients want you to run the remediation. Others have internal resource and need support. Either way, common work includes:

• Building the ICT asset register and third-party register from scratch
• Designing the ICT risk management framework and supporting policies
• Creating DORA-aligned incident classification and reporting procedures
• Developing supplier contract addendums
• Setting up a testing programme and managing first-year execution
• Board reporting preparation and presentation

This work varies too much to package into a fixed tier. Price it on scope — but make sure the scope is defined precisely, because this kind of project expands if left unmanaged.

Stage 3: Ongoing DORA Compliance Maintenance (£3,500–£9,000/month)

Once the framework is built, it needs to be maintained. This is where the recurring revenue lives.

What ongoing maintenance looks like:

• Quarterly ICT risk assessment updates
• Third-party register maintenance as suppliers change
• Incident monitoring and detection workflow management
• Quarterly DORA reporting to management and board
• Testing programme execution and tracking
• Regulatory change monitoring (DORA guidance and RTS/ITS updates)
• Support for any supervisory reviews or information requests

Price this based on entity complexity. A small payment institution with a simple tech stack and five key suppliers sits at the lower end. A mid-size investment manager with a complex cloud environment and 30+ ICT third parties sits at the higher end.

The vCISO function is the natural pairing for DORA maintenance. If you’re already delivering quarterly risk assessments, maintaining the ICT risk framework, and presenting to the board — that’s what a vCISO does, with a DORA lens on top.

---

The Third-Party Provider Angle

There’s a specific DORA classification that MSPs need to be aware of: Critical Third-Party Provider (CTPP).

If a large number of financial entities rely on a single ICT provider for critical or important functions, the European Supervisory Authorities can designate that provider as a CTPP. CTPPs face direct regulatory oversight — inspections, information requests, recommendations, and ultimately oversight reports.

Most MSPs won’t be designated as CTPPs. The CTPP framework is aimed at large cloud providers (AWS, Azure, Google) and major technology vendors. But the process of designation involves the ESAs reviewing the concentration of financial entity reliance on specific providers — which means financial entities have to report their critical third-party arrangements, including their MSP.

Practically, this means:

• Your financial services clients should have you listed in their third-party register
• They should have audit rights over your security controls in their contract
• They may ask you to complete a security questionnaire or provide SOC 2 / ISO 27001 certification
• If you have a significant concentration of financial services clients, understand whether you could be in scope for CTPP designation

This is also an argument for MSPs to get their own compliance posture in order. If you’re advising financial services clients on DORA third-party risk management and you can’t evidence your own controls — that’s a credibility problem.

---

Pricing and Positioning

DORA compliance commands a different conversation than standard MSP security services. Financial services clients expect regulatory expertise, not just technical delivery. They’re dealing with supervisors, audit committees, and board-level risk appetites. They want a partner who understands that context, not just someone who can run a vulnerability scan.

Price accordingly. The benchmark for regulatory compliance advisory in financial services in the UK is £250–£400/hour. Your packaged service should reflect that — which means a Tier 2 DORA compliance maintenance engagement at £5,000/month is entirely justifiable for a mid-size entity.

On positioning: don’t try to compete with the Big Four on DORA advisory for Tier 1 banks. That market requires armies of consultants, existing regulatory relationships, and frameworks that take years to build. The opportunity for MSPs is the mid-market and smaller financial entities that can’t afford Big Four pricing and aren’t getting the attention they need from generalist accountancy firms.

That positioning is: a specialist vCISO practice that understands DORA, delivers hands-on support (not just advice), and can run the ongoing compliance function at a price point that makes sense for a 50-person investment manager or a Series B fintech.

---

What You Need to Deliver It Well

DORA advisory requires specific knowledge and tooling that a standard managed security service doesn’t.

On the knowledge side: You need consultants who understand the DORA text, the Regulatory Technical Standards published by the ESAs, and the supervisory expectations of EBA, EIOPA, and ESMA. The regulatory nuance matters — DORA’s ICT incident classification criteria are specific, and getting them wrong has real consequences.

If you don’t have that in-house, partnering with a DORA-experienced regulatory consultant makes more sense than bluffing through it. The financial services market is small and reputation travels fast.

On the tooling side: Delivering DORA compliance at scale requires a GRC platform with the following capabilities:

• DORA framework mapping — controls mapped to DORA Articles and the supporting RTS/ITS
• ICT asset and third-party registers with relationship mapping
• Incident management workflow with classification logic and reporting timelines
• Risk assessment tooling with a financial services risk taxonomy
• Evidence collection and audit trail for supervisory review

Manual delivery in spreadsheets and documents works for one client. It doesn’t work at four or five. And when a supervisor asks for evidence, having it in a structured system is dramatically better than assembling PDFs from shared drives.

---

Getting Your First DORA Client

Start with your existing client base. If you have any financial services clients — fintech, insurance brokers, investment managers, payment processors — ask them directly: “Have you assessed your DORA obligations?”

Most will have heard of DORA. Many will have it on their internal compliance backlog. Very few will have done a proper gap assessment. The question alone positions you as someone who understands the regulatory environment.

The next entry point is the ICT third-party questionnaire angle. Many financial entities are now sending DORA due diligence questionnaires to their technology suppliers. If you receive one from a client, treat it as a conversation opener — offer to walk them through what their full DORA obligations look like, not just what your response to the questionnaire is.

A third route: UK-headquartered financial services firms with EU operations or passporting rights are often behind on DORA because they’re primarily focused on FCA obligations. They need help bridging from FCA operational resilience requirements (which they may be more familiar with) to DORA, which is substantively similar but more prescriptive. That comparison — FCA vs DORA — is a useful framing for the initial conversation.

---

DORA in the Context of a Broader Compliance Practice

DORA doesn’t exist in isolation. Financial services clients are typically subject to multiple regulatory frameworks simultaneously.

A UK fintech with EU operations might need:

• DORA for EU operational resilience
• FCA SYSC rules for UK operational resilience and outsourcing
• ISO 27001 for enterprise customer requirements
• SOC 2 for US customers or investors
• PCI DSS if they’re in the payment chain

Managing multiple frameworks simultaneously is exactly the use case for a multi-framework compliance service. Controls overlap significantly across DORA, FCA SYSC, ISO 27001, and NIST CSF. An MSP that can map those overlaps, maintain a shared evidence base, and give the client a single compliance dashboard is worth considerably more than one that handles each framework separately.

This is where the commercial model scales. A financial services client on a multi-framework compliance programme has a high switching cost, predictable recurring fees, and a natural requirement for vCISO-level engagement at the board level. That’s exactly the client profile you want in a recurring revenue practice.

---

What the Market Looks Like Right Now

DORA enforcement started in January 2025. Supervisory activity is increasing through 2026. ESAs are conducting thematic reviews, national competent authorities are asking for information, and smaller entities that thought DORA didn’t really apply to them are finding out otherwise.

The fintech market in particular is behind. Many Series A and B fintechs that expanded to the EU in 2022–2023 built their EU presence in the low-interest-rate era when compliance was treated as a later problem. They now have EU e-money licences or payment institution licences and live DORA obligations without the infrastructure to meet them.

That’s a specific buyer. They’re typically 30–100 people, have a Head of Compliance and a CTO but no security function, and are under pressure from their board and auditors to get compliant. They will pay well for a specialist who knows the regulation, can work at pace, and delivers tangible outputs — not a three-month discovery phase.

If you’re building a financial services compliance practice, this is the right time. The market is early, the competition is thin at the MSP level, and the regulatory pressure will only increase over the next 18 months as enforcement activity scales up.

---

Ready to Build Your DORA Practice?

GetCybr gives MSPs the platform to deliver DORA compliance services at scale — with DORA framework mapping, ICT risk management tooling, third-party register management, and multi-framework controls coverage across 50+ frameworks.

If you’re serving financial services clients or looking to break into that market, we can walk you through how the platform supports DORA delivery and what a repeatable engagement model looks like.

Book a demo →