Automating DORA Gap Analysis: a practical guide for financial entities.
DORA — the EU's Digital Operational Resilience Act — is the first piece of regulation written for an industry that runs on third-party software. Most financial entities now have a draft compliance program. The question is whether it actually closes the gaps the regulator will look for. Here's how to do that with AI.
This guide is built from real engagements with global systemically important banks (GSIBs), regional financial entities, and asset managers. It's the workflow our team uses inside RegAI, written down so a compliance lead with no AI background can run it themselves.
What DORA actually demands
DORA is dense — 64 articles, hundreds of detailed requirements across five pillars: ICT risk management (Art. 5–16), incident reporting (Art. 17–23), digital operational resilience testing (Art. 24–27), third-party risk (Art. 28–44), and information sharing (Art. 45). The Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) add another ~400 pages of operational detail.
A typical mid-sized bank's existing ICT-risk policy library covers maybe 60–70% of those requirements. The gap analysis needs to find the missing 30–40%, and produce defensible evidence that what does exist is actually compliant. Doing this by hand is a 10–14 week sprint with three to five FTEs.
Phase 1 — scope and source list
Before any AI runs, you need three inputs:
- Entity scope. Which legal entities, products, and jurisdictions are in scope. DORA applies to financial entities and to "critical ICT third-party service providers." Both have different obligations — get it right up front.
- Source list. The DORA Level 1 text, the published RTS/ITS, ESA Q&As, and any national-competent-authority overlay (e.g., BaFin's positions on Article 28).
- Internal corpus. Your existing ICT-risk policies, BCM/DR plans, third-party risk procedures, incident-response runbooks, and prior audit findings.
Get all three into a single workspace before doing anything else. The single most common cause of weeks lost on a DORA project is realizing partway through that two business units defined "critical function" differently.
Phase 2 — obligation extraction with traceback
An LLM that's been calibrated to regulatory text can extract obligations from DORA Level 1 + the RTS/ITS in hours. The non-negotiable property: every extracted obligation must link back to its source paragraph — Article and paragraph number — so legal review can verify the extraction.
If you can't click on an obligation and jump to the regulator's exact paragraph that produced it, the AI's output is a starting point, not a defensible artifact.
For DORA you should expect ~600–900 distinct obligations after deduplication across Level 1 + RTS/ITS, depending on how granularly your taxonomy breaks down each article.
Phase 3 — applicability triage
Not every obligation applies to every entity. Article 16 ("simplified ICT risk management framework") only applies to small and non-interconnected investment firms. Article 28's third-party risk requirements are different for entities classified as critical ICT third-party service providers vs. those merely consuming them.
RegAI's applicability layer takes each obligation and runs it against your entity profile (legal type, scale thresholds, products, ICT-third-party role). Output: applicability status (Applies / Does not apply / Conditional) plus a written justification per obligation. The justification matters — that's what your auditor reads when they ask "why does this entity not apply rule X?"
Phase 4 — gap analysis against existing policies
This is where the AI value compounds. Each in-scope obligation is mapped against your internal corpus using semantic embeddings (not keyword search), and the coverage scored as:
- Full — the policy explicitly addresses the obligation, with concrete wording.
- Partial — the policy covers the obligation in spirit but lacks specifics (e.g., references "recovery objectives" but not explicit RTO/RPO targets).
- Not covered — no internal document addresses the obligation.
Each score carries a rationale. For Partial scores, the AI flags exactly what's missing — that's the input to Phase 5.
Phase 5 — drafting controls for the gaps
For every Partial or Not-covered obligation, RegAI drafts replacement or new control language modeled on the obligation's requirements. The drafts are starting points; a Senior Legal Counsel review is mandatory before adoption. But starting from a 70%-good draft beats starting from a blank page.
Practical tip: review controls in batches by topic, not by article. Multiple DORA articles touch on third-party risk; reviewing them together produces consistent language. RegAI's batch-review view groups drafts by topic automatically.
Phase 6 — evidence pack and ongoing monitoring
The compliance matrix exports to your GRC (Archer, ServiceNow, MetricStream, OneTrust) with a citation graph attached: every obligation, score, and draft control linked to its source. That's the artifact you hand to internal audit.
Ongoing: RegAI's horizon-scanning layer monitors EBA, ESMA, and EIOPA for updates to the RTS/ITS and ESA Q&As, and flags any obligation whose source paragraph has changed. The matrix isn't a snapshot — it's live.
Common pitfalls
- Starting with the wrong scope. Re-running a 600-obligation extraction because you re-defined "critical function" mid-project is painful. Lock scope first.
- Treating AI extractions as final. The LLM is a fast, accurate first reader. Legal review is non-negotiable before any control ships.
- Ignoring the RTS/ITS. The Level 1 text is high-level; the RTS/ITS contain the actual operational requirements. A compliance program built on Level 1 alone fails its first audit.
- One-shot delivery. DORA continues to evolve via ESA opinions and Q&As. The matrix needs to live in a system that updates with the source — not a Word doc.
What this looks like at scale
On a recent GSIB engagement covering 100+ regulations including DORA, RegAI extracted 7,000+ pages of regulatory text into a structured matrix in 3 weeks of platform setup + 2 weeks of analysis. The team reported saving 7,000 manual review hours and a 67% reduction in review time. See the full banking case studies →
Get started
If you're staring at a DORA spreadsheet and wondering how it ever ships in time, we run a 45-minute walkthrough on a slice of your own DORA scope and a sample policy. Real numbers, no slides. Book a demo →