About Author
Kristian Wright
Kristian Wright is CEO and co-founder of enhanced.io, a channel-only SOC-as-a-Service provider built for MSPs. He has over 30 years in IT leadership and has co-founded three service delivery businesses.
enhanced.io, the channel-only Open XDR SOCaaS for MSPs
TL;DR
DORA applies to financial entities operating in the EU and their critical ICT third-party providers. If your clients include banks, insurers, payment processors or investment firms, DORA is their problem and your opportunity.
The regulation requires evidenced ICT risk management, incident classification and reporting, resilience testing and third-party risk documentation. Each of these needs an audit trail.
MSPs who monitor, detect and respond to threats on behalf of financial clients are providing ICT services under DORA. That changes the commercial conversation.
The hardest part for most MSPs is not the security. It is the documentation. DORA requires structured, retrievable evidence, not just good tooling.
SOC as a service that produces compliance-ready reporting is the infrastructure your DORA clients need and most of them are not getting it from their current MSP.
What DORA is and why it matters to MSPs
DORA, the Digital Operational Resilience Act, came into force across the EU in January 2025. It applies to financial entities, including banks, insurers, payment institutions, investment firms and crypto asset service providers, and to the critical ICT third-party providers that serve them.
If you serve clients in any of those sectors, DORA is already in effect for them. The question is whether you are helping them meet it or whether you are invisible to the conversation.
I want to be direct about the opportunity here. MSPs who deliver security monitoring, incident detection and response, and demonstrating compliance to clients are sitting at the center of what DORA requires. The MSPs who treat DORA as a procurement problem for someone else to solve are going to lose these clients to providers who understood the brief.
What DORA actually requires
ICT risk management
DORA requires financial entities to maintain a documented ICT risk management framework. That means an asset inventory, a risk register, defined risk tolerance levels, and controls mapped to identified risks. For MSPs, this is the technical foundation you are already building. What DORA adds is the requirement for documented evidence, not just the controls themselves.
Your clients need to produce this documentation for regulators and auditors. If your monitoring platform does not export structured risk data in a format that feeds into their ICT risk register, you are creating manual work for them. That is a retention risk.
Incident classification and reporting
DORA defines specific criteria for classifying ICT incidents as major or non-major, and sets reporting timelines. A major incident requires an initial notification to the competent authority within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.
This is where most MSPs are completely unprepared. Incident classification and reporting under DORA is a structured, time-bound process with specific data requirements. If your SOC cannot produce a DORA-format incident report, your client is doing that work manually after the fact, under time pressure, during or immediately after an incident. That is not a process that survives an audit.
Resilience testing
Article 25 of DORA requires financial entities to test their ICT systems at least annually through vulnerability assessments and threat-led penetration testing. For significant entities, that testing standard is TLPT (Threat-Led Penetration Testing), which follows the TIBER-EU framework.
MSPs are not required to run TLPT themselves, but your clients need vendors who understand what the test is covering and can provide clean telemetry during testing. If your security stack generates false positives during a red team exercise and your client cannot explain why, that is a problem in the audit report.
Third-party risk management
DORA requires financial entities to maintain a register of ICT third-party service providers, assess concentration risk, and ensure that contracts with critical providers meet specific requirements. This is the article that makes MSPs directly relevant to the regulation.
If your client classifies you as a critical ICT provider under DORA, you will be subject to contractual requirements including audit rights, incident notification obligations and exit plan documentation. Start that conversation before the client's next compliance review, not during it.
Where most MSPs are falling short
The security controls are rarely the gap. Most MSPs serving financial clients are running adequate detection and response tooling.
The gap is documentation. DORA auditors want structured evidence: timestamped incident timelines, classification rationale, response actions taken, systems affected and resolution status. They want it in a retrievable format. They want it to cover a defined period. They want it to map to the risk register.
If your reporting infrastructure produces a monthly summary email and a dashboard screenshot, that is not DORA-compliant evidence. Turning monitoring into audit-ready evidence is the operational shift that separates MSPs who win regulated clients from those who lose them at renewal.
What the commercial conversation looks like
DORA gives you 4 concrete things to put in front of a financial services prospect: ICT risk management documentation support, structured incident reporting that meets the 4-hour/72-hour/30-day timelines, resilience testing coordination and third-party provider compliance evidence.
That is not a cybersecurity conversation. That is a regulatory obligation conversation. And it is one the client's finance director, risk committee or board is already having internally.
The MSPs I see winning in this sector are the ones who walk into that conversation with a DORA readiness framework and a clear answer to the question: if we have a major incident tomorrow, what does your reporting infrastructure produce and in what timeframe? If you cannot answer that clearly, your SOC as a service is not fit for this client category.
That is not a guess. That is what we see every day.
FAQ
Does DORA apply to UK-based MSPs serving EU financial clients?
DORA applies to financial entities operating in the EU and their ICT providers, regardless of where those providers are based. If you are a UK MSP providing ICT services to an EU bank or insurer, the financial entity has obligations to manage and document your services under DORA. That means your client will impose DORA-related contractual requirements on you even if DORA does not apply to you directly. Expect audit rights, incident notification clauses and exit planning requirements in your contracts with EU financial clients.
What is the difference between DORA and NIS2 for an MSP?
DORA applies specifically to the financial sector and focuses on operational resilience, incident reporting and third-party risk management for ICT providers. NIS2 scope is broader, covering essential and important entities across multiple sectors including energy, transport, health and digital infrastructure. An MSP serving both financial clients and public sector clients may be operating in the scope of both regulations. The reporting timelines and evidence requirements differ between them.
What does a DORA-compliant incident report look like?
DORA specifies the content requirements for initial, intermediate and final reports. The initial notification within 4 hours of major incident classification needs to include the nature and impact of the incident, the systems affected and the initial response actions taken. The final report after 30 days needs to include a root cause analysis, the full incident timeline, the controls that failed and the remediation actions implemented. Your SOC needs to produce this data from monitoring telemetry, not from post-incident reconstruction.
How do I identify whether my client is in scope for DORA?
DORA applies to credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto asset service providers and several other categories of financial entity defined in Article 2. If your client holds a financial services license issued by an EU competent authority, they are in scope. MSPs serving those clients as ICT providers are within the regulation's third-party management framework, which determines the contractual and reporting obligations your client places on you.
What reporting format does DORA require?
The European Banking Authority, European Insurance and Occupational Pensions Authority and European Securities and Markets Authority have published joint regulatory technical standards specifying the templates for major incident reporting under DORA. Your clients' compliance and legal teams will be working from those templates. Your SOC's incident reporting output needs to produce the data fields those templates require, ideally in a format that feeds directly into the template rather than requiring manual extraction.
Is DORA relevant to MSPs who do not serve banks?
DORA defines financial entities broadly. Payment processors, investment managers, insurance brokers and fintech platforms all fall within scope. If any of your clients handle financial transactions, manage investment portfolios, process insurance claims or provide regulated financial services in the EU, DORA is relevant to the ICT services you provide. The threshold for classification as a critical third-party provider is set by the European Supervisory Authorities and depends on the concentration of financial entities using a given provider.