The DORA RegTech Explosion: 50 Vendors Competing for a $4 Billion Market

A Market Born From Regulation

On January 17, 2025, DORA became applicable. Within months, the RegTech vendor ecosystem responded with an explosion of DORA-specific products, features, and marketing claims. Existing GRC platforms added "DORA modules." Cybersecurity companies rebranded existing features as "DORA compliance." New startups launched with DORA as their sole focus. Consulting firms created DORA service lines.

The result is a crowded, overlapping market where financial institutions face the paradox of buying technology to manage ICT risk that itself becomes ICT risk. Every DORA compliance tool is an ICT third-party relationship under Art. 28. Every SaaS compliance platform is a dependency that must be managed, assessed, and included in the register of information.

The estimated market size reflects the scale of compliance demand. DORA applies to approximately 22,000 financial entities across the EU, plus their global operations and third-party chains. The compliance spending analysis confirms that institutions are investing significantly — but the question is whether that investment is producing genuine resilience or merely generating compliance documentation.

The DORA RegTech Landscape: Market Segments

Segment 1: Enterprise GRC Platforms (DORA Module Add-Ons)

Established GRC vendors — ServiceNow, Archer, MetricStream, OneTrust — have added DORA-specific modules to their existing platforms. These modules typically provide DORA control frameworks, assessment templates, and reporting capabilities layered on top of the vendor's existing GRC architecture.

Strengths: Integration with existing enterprise workflows, mature platform capabilities, established vendor relationships.

Weaknesses: DORA is one module among many, potentially surface-level coverage. May not address DORA's technical requirements (Art. 24-27 testing, Art. 28 third-party register technical specifications).

Segment 2: DORA-Specific Compliance Platforms

A new category of vendors has emerged with platforms built specifically for DORA compliance. These platforms focus exclusively on DORA's requirements and often provide deep coverage of specific pillars.

Strengths: Deep DORA expertise, purpose-built data models, regulatory-specific workflows.

Weaknesses: Narrow scope (DORA only), startup risk, potential lack of integration with existing enterprise systems.

Segment 3: Third-Party Risk Management (TPRM) Platforms

DORA's Art. 28-44 third-party risk management requirements have driven expansion in the TPRM market. Vendors like Prevalent, ProcessUnity, and specialized DORA-focused TPRM tools offer vendor assessment, register of information management, and concentration risk analysis.

Strengths: Focus on the most challenging DORA requirement (third-party risk), vendor assessment automation, register of information templates aligned with ESA technical standards.

Weaknesses: May not cover other DORA pillars adequately. Assessment questionnaires may not validate actual vendor resilience.

Segment 4: Resilience Testing and Continuous Assurance

Tools focused on Art. 24-27 testing requirements: automated vulnerability scanning, penetration testing platforms, chaos engineering tools, and continuous assurance platforms that provide ongoing resilience monitoring.

Strengths: Technical depth, automated evidence generation, continuous compliance monitoring.

Weaknesses: Require technical expertise to deploy and interpret, may not integrate with governance workflows.

Segment 5: Incident Management and Reporting

Platforms focused on Art. 17-23 incident management: incident classification, regulatory reporting, timeline management, and root cause analysis.

Strengths: Structured incident workflows, regulatory reporting templates, timeline enforcement.

Weaknesses: May overlap with existing ITSM tools (ServiceNow ITSM, Jira Service Management), creating duplicate incident management systems.

Mapping Vendors to DORA Pillars

Where Technology Adds Genuine Value

High-Value Technology Investments

Register of information automation. The Art. 28(3) register requires structured data about all ICT third-party arrangements. For institutions with hundreds of vendor relationships, manual register management is unsustainable. Technology that automates data collection, structures the register per ESA technical standards, and maintains it continuously delivers genuine value.

Automated testing and evidence collection. Art. 24-27 testing generates significant evidence. Technology that automates test execution, collects results, and organizes evidence for audit reduces the operational burden dramatically. The evidence management challenge is primarily an organization and retrieval challenge — technology excels here.

Incident classification and regulatory reporting. The Art. 17-19 incident reporting timeline is demanding. Technology that automates incident classification against DORA criteria, tracks reporting deadlines, and generates regulatory report templates reduces the risk of missed deadlines.

Concentration risk analytics. HHI calculations and fourth-party dependency mapping require data aggregation and analysis that benefits from automation. Manual concentration risk analysis across hundreds of vendor relationships is error-prone and stale by the time it is completed.

Low-Value Technology Investments

DORA compliance dashboards without underlying data. A dashboard that shows DORA compliance status is only as good as the data feeding it. If compliance status is manually updated, the dashboard adds visualization but not accuracy. The investment should be in the data pipeline, not the dashboard.

Assessment questionnaires that replace due diligence. Sending a questionnaire to a vendor and recording the response is not risk assessment. It is documentation. Technology that automates questionnaire distribution without validating responses or correlating with independent data sources produces compliance theater.

Framework mapping tools. Tools that map DORA articles to internal controls provide a starting point but deliver diminishing returns. Once the mapping is complete, the value is in execution — testing the controls, collecting the evidence, managing the deviations — not in maintaining the map.

The Art. 28 Paradox: Your Compliance Tool Is a Third-Party Risk

Every SaaS DORA compliance tool is itself an ICT third-party arrangement. The institution must:

This paradox does not mean institutions should avoid technology. It means they should evaluate DORA tools with the same vendor risk scoring methodology they apply to other ICT third parties — including exit strategies, data portability, and concentration risk.

A Buyer's Framework for DORA Technology

Step 1: Identify Capability Gaps

Before evaluating vendors, identify where the institution's existing capabilities are insufficient for DORA compliance. Many institutions already have GRC platforms, ITSM tools, vulnerability scanners, and vendor management systems. The question is what incremental capability DORA requires that existing tools do not provide.

Step 2: Prioritize by Supervisory Focus

Supervisory examination focus areas should drive technology investment priority: the register of information (Art. 28), incident reporting (Art. 19), testing programme evidence (Art. 24-25), and board reporting (Art. 14).

Step 3: Evaluate Against Art. 28 Requirements

Apply Art. 30 contractual provisions requirements to any technology vendor. Require data portability, define exit procedures, assess vendor resilience, and include the vendor in the register of information.

Step 4: Prefer Integration Over Replacement

Where possible, extend existing platforms rather than adding new tools. Every new tool is a new vendor relationship, a new integration point, and a new training requirement.

Key Takeaways

• The DORA RegTech market exceeds $4 billion with 50+ vendors competing across five segments: enterprise GRC, DORA-specific platforms, TPRM, testing/assurance, and incident management.
• Highest-value technology investments are in register of information automation, automated testing and evidence collection, incident classification, and concentration risk analytics.
• Every SaaS compliance tool creates an Art. 28 dependency. Evaluate compliance vendors with the same rigor applied to other ICT third parties.
• Existing tools may cover more than expected. Identify capability gaps before purchasing — many DORA requirements can be met by extending existing GRC, ITSM, and security platforms.
• Compliance dashboards without underlying data quality are compliance theater. Invest in the data pipeline, not the visualization.
• Vendor viability and data portability are critical selection criteria for a market with many startups.

---

Resume en francais

DORA a cree un marche RegTech estime a 4 milliards de dollars avec plus de 50 fournisseurs en competition. Le marche se segmente en cinq categories : plateformes GRC d'entreprise (modules DORA), plateformes specifiques DORA, gestion des risques tiers (TPRM), tests et assurance continue, et gestion des incidents. Les investissements technologiques a plus forte valeur ajoutee sont l'automatisation du registre d'information (Art. 28), la collecte automatisee de preuves de test (Art. 24-27), la classification des incidents avec reporting reglementaire (Art. 17-19) et l'analytique de risque de concentration. Chaque outil de conformite SaaS est lui-meme un arrangement tiers TIC soumis a l'article 28 — le paradoxe de la conformite DORA. Les institutions doivent evaluer les outils RegTech avec la meme methodologie de scoring de risque que pour tout fournisseur TIC, incluant la portabilite des donnees, la viabilite du fournisseur et les strategies de sortie. Avant d'acheter, identifier les lacunes de capacite reelles — de nombreuses exigences DORA peuvent etre couvertes en etendant les plateformes GRC, ITSM et securite existantes.