I’m building DORA-first.
The reason is simple: after spending time studying DORA and thinking about how it actually gets implemented inside an organization, I realized the hard part is not reading the regulation. The hard part starts when IT and compliance teams try to turn those requirements into day-to-day work.
DORA, the European Union’s Digital Operational Resilience Act, is now a mandatory financial-sector resilience regulation. It applies across many types of financial entities, including banks, payment institutions, e-money institutions, investment firms, insurance and reinsurance companies, trading venues, central securities depositories, fund managers, crypto-asset service providers, and other regulated financial entities.
That scope matters. DORA is not a single checklist. It touches ICT risk, third-party dependencies, incidents, business continuity, disaster recovery, recovery targets, subcontracting, evidence, reporting, and many other operational obligations.
The real problem is operationalization
When I studied DORA carefully, the first problem was obvious: it is hard to remember everything. But the deeper problem appears only when you try to turn the requirements into day-to-day work.
The information needed for DORA is scattered across architecture documents, cloud assets, vendor registers, policies, incident records, BCP/DR materials, contracts, SOC 2 and ISO evidence, subcontractor records, and internal control data. Manual review is slow. Mapping requirements to controls is painful. Evidence quality is uneven. And not every IT team member will study the regulation deeply.
This led me to a simple conclusion: DORA compliance is not only a regulatory reading problem. It is a data, mapping, evidence, and risk-judgment workflow problem.
What existing tools taught me
Looking at the market was useful. Formalize shows that DORA can become a structured compliance workspace: obligations, tasks, controls, evidence, and registers. SureCloud shows that DORA eventually enters broader GRC operations: risk, incidents, third parties, business continuity, and control monitoring. Vanta shows the importance of automated evidence collection and continuous control monitoring.
My takeaway is not that these products are wrong. The opposite: they validate the market direction. DORA will not remain a PDF-reading exercise. It will become operational software.
But I also saw an opportunity. Traditional GRC still requires heavy manual configuration, requirement mapping, evidence judgment, and risk explanation. Many tools can tell you whether a control exists or whether evidence was collected. Fewer tools clearly explain why something is a DORA risk, what evidence is missing, which obligation is triggered, and what remediation should happen next.
What DORA-first is
DORA-first is my attempt to build an AI-native DORA GRC platform for IT and compliance operations. The core idea is not to build another generic chatbot. The core AI capability is a Risk Copilot.
DORA-first uses AI to turn DORA requirements into executable GRC workflows.
The product model is a chain: regulatory source library, obligation tags, document and evidence graph, AI risk engine, remediation actions, and continuous monitoring. The goal is to connect external regulatory requirements with internal enterprise data, then produce explainable and auditable risk judgments.
Risk Copilot, not chatbot
I keep coming back to this distinction because it affects the whole product. A chatbot can answer questions. A Risk Copilot has to participate in a compliance operating process.
The Risk Copilot should read requirements from DORA, RTS/ITS, regulatory guidance, supplementary materials, and version changes. It should understand internal data such as architecture documents, cloud assets, vendor evidence, policies, BCP/DR, and incident records. It should explain risk: why this is a risk, what evidence is missing, which DORA obligation is triggered, and what remediation should happen next. It should also support continuous monitoring as both regulatory sources and internal data change.
The guardrails are equally important: traceable official sources, evidence-based judgment, visible confidence, and retained human review.
The MVP starts with ICT third-party risk
The first version should stay narrow. A broad demo is easy to build and easy to forget. The MVP should go deep on one high-value scenario: ICT third-party risk.
That loop starts by identifying critical ICT third parties from vendor registers, architecture notes, and cloud assets. Then it collects evidence such as SOC 2, ISO, BCP/DR, incident records, contracts, subcontractor information, and related documents. The Copilot aligns requirements and evidence, judges sufficiency, explains the risk, and generates remediation actions, evidence requests, owners, and follow-up checkpoints.
The MVP value is not showcasing a model. It is proving that a Risk Copilot can enter real compliance operations and continuously produce auditable risk judgments and remediation actions.
Where this can go
If the ICT third-party risk loop works, the same object model can expand into evidence workflows, continuous monitoring, team collaboration, audit packs, multi-framework GRC, and evidence reuse across DORA, NIS2, ISO 27001, SOC 2, and other frameworks.
The long-term vision is to move from one-off compliance checks to continuous regulatory readiness.
DORA is not only something financial institutions need to comply with. It is also a forcing function for companies to understand their ICT risk, third-party dependencies, operational resilience, and evidence quality much more deeply.
That is what I want DORA-first to help with.
Product: dora-first.org