DORA (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025, and for engineering teams it translates into five concrete workstreams: a complete ICT asset and dependency inventory, incident classification and reporting on fixed clocks, digital resilience testing up to threat-led penetration tests, a register of every ICT third-party arrangement, and contractual controls over software suppliers. Unlike NIS2, DORA is a regulation, not a directive — no transposition, no national variation in the core text, and the supervisors (EBA, ESMA, EIOPA, and national competent authorities) have been actively collecting data since the first register-of-information submissions in April 2025. Over a year in, the pattern is clear: the compliance team owns the paper, but the evidence lives in engineering systems.
Pillar by pillar, in engineering terms
DORA's five pillars map to work you can put on a sprint board:
| DORA pillar | Engineering deliverable |
|---|---|
| ICT risk management (Art. 5–16) | Asset inventory, dependency mapping, configuration baselines, backup/restore testing |
| Incident management and reporting (Art. 17–23) | Classification logic, reporting runbooks, evidence capture |
| Digital operational resilience testing (Art. 24–27) | Vulnerability scanning program, scenario testing, TLPT for designated entities |
| ICT third-party risk (Art. 28–44) | Register of information, exit strategies, contract clause verification |
| Information sharing (Art. 45) | Optional threat intel exchange participation |
The uncomfortable one is the first: Article 8 requires identifying and documenting all ICT assets and their dependencies, kept current. For a fintech running 200 microservices, "dependencies" includes the third-party libraries inside each service — which is why SBOM generation per release has become the standard implementation. If you can't answer "which of our services embed this library" in minutes, you don't have the Article 8 inventory, whatever the spreadsheet says.
The incident reporting clocks
The reporting RTS finalized the cadence for major ICT-related incidents: an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours from detection), an intermediate report within 72 hours, and a final report within one month. Classification itself follows Regulation 2024/1772's criteria — clients affected, duration, geographic spread, data losses, criticality of services, economic impact — with defined materiality thresholds.
Four hours from classification is an engineering problem disguised as a legal one. It requires monitoring that timestamps detection, a severity decision path that doesn't wait for Monday, and pre-drafted notification templates wired to the right national competent authority. Teams that treat this as a quarterly tabletop exercise hit the clock; teams that first open the RTS during an outage do not. Keep the classification worksheet in the incident channel topic, not in a compliance wiki nobody can find at 02:00.
Resilience testing: from scans to TLPT
Article 25 requires a proportionate testing program — vulnerability assessments, open source analyses, network scans, scenario-based tests — executed at least yearly on systems supporting critical functions. Note "open source analyses" appearing by name in a financial regulation: continuous SCA scanning of production services is now regulatory baseline, not best practice.
Entities designated by their supervisor must additionally run threat-led penetration testing (TLPT) every three years under the TIBER-EU-aligned RTS: real intelligence-led red teaming against live production systems, covering critical functions, with strict controls. If your firm is in TLPT scope you'll know — the supervisor tells you — but the engineering preparation (segmentation, detection coverage, tested rollback paths) takes quarters, not weeks.
The register of information and your software suppliers
Article 28 requires a register of all contractual arrangements with ICT third-party providers, reported to supervisors — the first industry-wide submissions happened in April 2025 and were a mess of entity-identifier and taxonomy problems. Engineering gets pulled in because the register wants facts only engineering knows: which providers support critical or important functions, what data they touch, where they run, and what the substitutability picture looks like.
Beyond the register, contracts for providers supporting critical functions must include audit rights, exit strategies, and — practically — the ability to get security evidence from the vendor on demand. This is the same flow-down dynamic as NIS2, from the buyer's side: expect your own vendors to receive your questionnaire, and expect your fintech customers' questionnaires if you're the vendor. The overlap with NIS2 Article 21 is deliberate; DORA is lex specialis for financial entities, so where both could apply, DORA wins. Our DORA deep dive covers the CTPP oversight regime for the hyperscalers, which runs on a separate track.
A realistic engineering backlog
A year of assessments has produced a fairly consistent gap list for mid-size fintechs: (1) dependency inventory exists per-repo but not per-service-in-production — fix with SBOM generation at build plus runtime correlation, the workflow SBOM Studio handles; (2) incident classification thresholds never encoded — fix with a one-page worksheet and two drills; (3) register of information data scattered across procurement and engineering — fix with a single owner and an export pipeline; (4) backup restores asserted but untested — fix by actually restoring, quarterly, with timestamps. None of this is exotic. All of it gets sampled by supervisors who, unlike SOC 2 auditors, can levy fines and compel remediation.
Frequently asked questions
Does DORA apply to fintechs that aren't banks?
Almost certainly yes — DORA covers 20 categories of financial entities including payment institutions, e-money institutions, investment firms, crypto-asset service providers under MiCA, and insurance intermediaries. Microenterprises get proportionality relief, not exemption.
What are DORA's incident reporting deadlines?
Initial notification within 4 hours of classifying an incident as major (at most 24 hours from detection), an intermediate report within 72 hours, and a final report within one month. Classification criteria and thresholds come from Regulation 2024/1772.
Does DORA require SBOMs?
Not by name, but Article 8's requirement to inventory ICT assets and dependencies, plus Article 25's open source analyses, are hard to evidence without one. Supervisory expectations published since 2025 increasingly reference component-level visibility for critical functions.
We're a software vendor selling to banks. What hits us?
Your customers must impose contractual terms under Articles 28–30: audit and access rights, incident cooperation, exit support, and security evidence. Expect SBOM requests, vulnerability SLA commitments, and register-of-information data requests as standard onboarding friction from 2025 onward.