Last updated: 13 November 2026
Quick answer: DORA compliance services for MSPs cover two things: meeting the contractual and security duties that financial clients must pass down to their ICT providers, and helping those clients run DORA programmes, from ICT risk frameworks and incident reporting to third-party registers and testing. The client always remains fully responsible for compliance.
Banks, insurers, investment firms, payment institutions and many other financial entities have been applying the Digital Operational Resilience Act since January 2025. Almost all of them depend on managed service providers for infrastructure, security monitoring, help desks or cloud management.
That dependency makes DORA both an obligation and an opportunity for MSPs and MSSPs. This guide explains what DORA expects from ICT providers, which advisory services financial clients actually need, and how to package DORA compliance services without overpromising.
Why do DORA compliance services matter for MSPs?
Because an MSP serving a financial entity is almost always an ICT third-party service provider under DORA, and the client must manage that relationship under strict rules. MSPs that understand those rules win and keep regulated clients; those that do not get stuck in contract negotiations.
Regulation (EU) 2022/2554 defines an ICT third-party service provider simply as “an undertaking providing ICT services”, and ICT services as digital and data services provided through ICT systems on an ongoing basis. Managed infrastructure, SOC monitoring, backup and help desk services all fit that definition.
According to EIOPA, DORA has applied since 17 January 2025 and covers 20 different types of financial entities. For an MSP, that means potential clients well beyond banks: insurers, crypto-asset service providers, investment firms, fund managers and payment institutions are all in scope.
In practice: DORA does not directly regulate most MSPs. It regulates the financial entity, which then imposes requirements on you through contracts, due diligence questionnaires and audits. Only providers designated as critical ICT third-party providers are supervised directly.
What does DORA require from ICT providers like MSPs?
DORA requires financial entities to include specific terms in every contract with an ICT provider, with extra terms where the service supports critical or important functions. As an MSP, you need to be ready to accept and operate those terms.
Article 28(1)(a) states that financial entities “remain fully responsible” for compliance when they outsource ICT services. Article 28(4) requires them to assess risks and conduct due diligence before signing. Article 30 then sets the minimum contractual content.
Contract terms for all ICT services (Article 30(2))
- A clear description of the services, including whether subcontracting of critical functions is allowed and on what conditions.
- Locations where services are provided and data is processed, with advance notice of changes.
- Provisions on availability, authenticity, integrity and confidentiality of data, including personal data.
- Access, recovery and return of data on insolvency, resolution, discontinuation or termination.
- Service level descriptions.
- Assistance on ICT incidents “at no additional cost, or at a cost that is determined ex-ante”.
- Full cooperation with competent and resolution authorities.
- Termination rights and minimum notice periods.
- Participation in the client’s ICT security awareness and digital operational resilience training.
Extra terms for critical or important functions (Article 30(3))
- Precise quantitative and qualitative service levels.
- Notice and reporting obligations for developments that could affect service delivery.
- Business continuity plans and appropriate ICT security measures, which you must implement and test.
- Participation and full cooperation in the client’s threat-led penetration testing (TLPT).
- Unrestricted rights of access, inspection and audit for the client and its regulator.
- Exit strategies, including a mandatory adequate transition period.
Common mistake: treating DORA clauses as a legal formality. If you agree to support TLPT, provide incident assistance at a pre-agreed cost or allow on-site audits, you need the processes, staff and evidence to deliver them.
Which DORA compliance services can MSPs offer financial clients?
Beyond being a compliant supplier, MSPs can offer advisory and managed services that map directly to DORA’s five pillars. The table below links each service to its legal basis and a typical deliverable.
| Service | DORA basis | Typical deliverable |
|---|---|---|
| ICT risk management framework gap assessment | Articles 5 to 16 | Gap report, remediation plan, policy set |
| Incident classification and reporting support | Articles 17 to 19 | Incident playbooks, classification matrix, reporting templates |
| Digital operational resilience testing | Articles 24 to 27 | Annual test programme, vulnerability scans, scenario tests, TLPT preparation |
| ICT third-party risk management | Articles 28 to 30 | Vendor due diligence, contract gap review, register of information support |
| Management body training and reporting | Article 5 | Board briefings, training records, ICT risk dashboards |
| Information-sharing readiness | Article 45 | Participation guidance and internal procedures |
ICT risk management and governance
Under Article 5(2), the management body must “define, approve, oversee and be responsible for” the ICT risk management framework. Article 5(4) adds that board members must keep sufficient knowledge and skills, including through specific training on a regular basis. A vCISO service that prepares board reporting and runs that training addresses a clear, recurring need.
Smaller entities can use the simplified framework in Article 16, so scope your services to the client’s category rather than using one template for all.
Incident management and reporting
Major ICT-related incidents must be reported to the competent authority. Delegated Regulation (EU) 2025/301 sets the time limits: an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report.
MSPs that run the client’s monitoring are often the first to see an incident, so contractual handover times and a shared classification process matter. Tools with structured incident and breach management workflows help keep the timeline and evidence in one record.
Third-party risk and the register of information
Article 28(3) requires financial entities to maintain a register of information on all ICT contracts and to report at least yearly to their authorities on new arrangements. The registers also fed the ESAs’ designation of critical providers: on 18 November 2025 the European Supervisory Authorities published the first list of critical ICT third-party providers. Supporting clients with vendor and third-party risk management and register upkeep is a natural extension for an MSP. Our DORA register of information guide covers the templates in detail.
If you want to see how partners deliver these services across many financial clients from one console, book a partner demo.
How should MSPs package DORA services?
Package by outcome and by client maturity, not by article number. Most financial clients buy a starting assessment, then a recurring managed programme, then targeted specialist support.
| Tier | Best for | What it includes |
|---|---|---|
| Readiness | Small entities and those new to DORA | Scoping, proportionality check, gap assessment against the ICT risk framework, remediation roadmap |
| Managed resilience | Entities with an agreed roadmap | Policy maintenance, incident playbooks, annual testing programme, board reporting, evidence collection |
| Third-party and contracts | Entities with many ICT suppliers | Due diligence, Article 30 contract reviews, register of information support, exit plan reviews |
| Specialist add-ons | Entities selected for TLPT or with complex estates | TLPT preparation and coordination with testers, concentration risk analysis |
TLPT applies only to entities identified by their competent authority, which must then test at least every three years under Article 26. Do not sell it to clients who are not in scope.
A DORA service checklist for MSPs
- Confirm which DORA entity type each client is and whether the simplified framework applies.
- Map every service you deliver to the client’s critical or important functions.
- Review your standard contract against Article 30(2) and 30(3) before the client asks.
- Document your own ICT security, business continuity and subcontractor chain, since clients will audit it.
- Agree incident notification times and classification support in writing.
- Keep one evidence library per client so audits and supervisory requests can be answered quickly.
- Define clear responsibility boundaries: you advise and operate, the client’s management body decides and remains accountable.
How does DORA relate to NIS2 for MSPs?
For financial entities, DORA takes precedence over the cybersecurity risk management and reporting rules of NIS2 as sector-specific law. For MSPs themselves, the NIS2 Directive can apply directly, because managed service providers and managed security service providers are listed in its Annex I.
That means many MSPs face NIS2 for their own operations while their financial clients push DORA terms down through contracts. Mapping both to a common control set, for example ISO 27001, avoids running two separate programmes. Enactia’s Compliance Universe cross-maps DORA, NIS2 and ISO 27001 controls so one piece of evidence can serve several requirements.
What should MSPs avoid when selling DORA services?
Avoid promising that a client will “be DORA compliant” because of your service. Article 28(1)(a) is explicit that the financial entity stays fully responsible. Your role is to provide expertise, operations and evidence.
- Overpromising scope: advisory services do not replace the client’s own governance and sign-off.
- Ignoring your own resilience: a provider that cannot show tested continuity plans will struggle in due diligence.
- Hidden subcontractors: clients must know and approve subcontracting of critical functions, so keep your supply chain documented.
- One-off projects only: DORA requires ongoing testing, reporting and review, which suits recurring managed services better than single assessments.
For a broader overview of the regulation, see mastering DORA compliance in 2026.
Key takeaways
- MSPs serving financial entities are ICT third-party service providers under DORA and must accept Article 30 contract terms.
- Financial entities remain fully responsible for compliance, so MSP services should support, not replace, client governance.
- High-demand DORA compliance services include ICT risk framework assessments, incident reporting support, testing programmes and third-party risk management.
- Major incident reports run on tight timelines of 4 to 24 hours, 72 hours and one month, which MSPs must support contractually.
- MSPs may also be in scope of NIS2 themselves, so one mapped control set saves duplicated work.
Frequently asked questions
Is an MSP directly regulated under DORA?
Usually not. DORA regulates financial entities, which must manage their ICT providers through due diligence, contracts and monitoring. MSPs are affected indirectly through Article 30 contract terms and audits. Only providers designated by the European Supervisory Authorities as critical ICT third-party providers fall under direct EU oversight, and the first list was published on 18 November 2025.
What contract clauses will financial clients ask MSPs to accept?
Expect clauses on service descriptions and locations, data security and return, service levels, incident assistance at no cost or a pre-agreed cost, cooperation with regulators, termination rights and training participation. For critical or important functions, add detailed service levels, business continuity, TLPT participation, full audit and access rights, and exit strategies with a transition period.
Can an MSP submit DORA incident reports for a client?
The reporting obligation stays with the financial entity, although Article 19(5) of DORA allows reporting to be outsourced to a third-party provider in line with Union and national law, with the entity remaining responsible. In practice, MSPs mostly support detection, classification evidence and drafting. Agree roles, notification times and approvals in the contract and incident playbook in advance.
Do MSPs need ISO 27001 to serve DORA-regulated clients?
DORA does not require ICT providers to hold ISO 27001 certification. However, financial entities must assess your security during due diligence, and a recognised certification or independent assurance report often shortens that process. Whatever you hold, be ready to show tested business continuity, incident handling and subcontractor controls mapped to the client’s requirements.
How often must financial entities test their digital operational resilience?
DORA requires a risk-based testing programme, and entities other than microenterprises must test all ICT systems and applications supporting critical or important functions at least yearly. Entities identified by their competent authority must also carry out threat-led penetration testing at least every three years. MSPs can support both, but TLPT should only be offered to in-scope clients.
Conclusion: build DORA into your service catalogue
DORA has turned operational resilience into a contractual expectation for every ICT provider serving the EU financial sector. MSPs that can demonstrate their own resilience, accept Article 30 terms confidently and offer structured DORA compliance services are well placed to grow with regulated clients. Enactia, the GRC platform for vCISO and vDPO services, supports partners through its multi-tenant MSP programme, with details of DORA coverage on the DORA framework page.
To discuss how you could deliver DORA services across your financial clients, contact us or book a partner demo.
This article is for general information and is not legal advice.
