Miss one control under DORA, and the real failure often isn’t technical. It’s the missing evidence, unclear owner, or unseen vendor dependency behind it.
By 2026, most EU-regulated firms aren’t asking what DORA is. They’re asking whether their teams can prove compliance under pressure. That means tighter records, faster incident handling, and better third-party oversight. Start with the operating model, not the policy binder.
What DORA means for IT teams in 2026
DORA has applied since January 17, 2025. In 2026, the pressure shifts from awareness to proof. Supervisors want current records, tested processes, and roles that work during outages and cyber incidents.
For IT teams, the challenge is scope. DORA reaches across operations, security, vendor management, risk, and compliance. ISO 27001 can help structure controls, and NIS2 may overlap on cyber risk, but DORA adds financial sector duties around ICT incident reporting, sector testing, and formal ICT third-party records. The EIOPA DORA page and this RTS and ITS overview are useful when you need the rule text behind a task.
These are the checkpoints many teams plan around in 2026:
| 2026 checkpoint | What IT teams should have ready |
|---|---|
| RoI submission window | A current Register of Information, with local filing dates confirmed early because portal timing can vary |
| Major ICT incidents | A workflow for the reporting pattern used in DORA standards, initial notice within 4 hours, fuller update within 72 hours, final report within 1 month |
| TLPT preparation | Scope, providers, and evidence planning now, if your firm may fall into the significant-entity group ahead of 2028 |
Many firms entered 2026 with their Register of Information spread across procurement files, CMDB exports, and spreadsheets. That setup breaks fast under review.
The main lesson is simple. DORA doesn’t reward late clean-up. It rewards clear ownership and records you can produce fast. Confirm deadlines and filing details with legal and compliance counsel, because national supervisory instructions can differ.
A working DORA compliance checklist for day-to-day operations
A good DORA compliance checklist reads less like a policy and more like a runbook. Each item needs an owner, a review cycle, and evidence your team can pull without a fire drill.
Use this baseline for daily operations:
- Governance should link board-approved ICT risk policies to named owners in engineering, security, operations, and vendor management.
- Critical and important functions should map to applications, infrastructure, data stores, recovery targets, and upstream vendors.
- Access control, logging, vulnerability management, backup, and recovery controls should tie back to business services, not only systems.
- Incident playbooks should classify ICT events, route escalations fast, and assign reporting tasks before a real event lands.
- Testing should cover backup restores, failover, detection, crisis communications, and lessons learned, not only penetration testing.
- The Register of Information should include contracts, subcontractors, criticality, concentration risk, and exit data.
- Monitoring should track service health, security events, control exceptions, and overdue remediation in one operating view.
Keep the evidence set lean but consistent. Auditors and second-line teams usually ask for the same patterns, approved policies, inventories, tickets, test results, and proof that exceptions were fixed.
This table shows the records IT teams should keep close:
| Area | Evidence to maintain |
|---|---|
| Governance | ICT risk policy, committee minutes, risk acceptance records, named control owners |
| Operations | Asset inventory, service maps, backup reports, recovery test results, patch and vulnerability records |
| Incidents | Classification matrix, timeline logs, communications record, post-incident review, regulatory filing copies |
| Vendors | Contract clauses, due diligence, risk scores, exit plans, subcontractor list, review notes |
If your team can’t pull the evidence in one hour, tighten the process before the audit asks.
A short example makes this real. Suppose a payment gateway fails because a cloud DNS dependency breaks. Your DORA file should show the affected business service, severity decision, escalation trail, vendor contact path, recovery actions, and whether the event triggered supervisory reporting. If those pieces live in four tools with no owner, the control is weak even if recovery worked.
Also, don’t treat the checklist as a one-time gap exercise. Re-run it after major releases, vendor changes, mergers, and new cloud rollouts. DORA is about continuity under pressure, so the checklist should change when your estate changes.
Third-party oversight, testing, and ongoing monitoring
Most DORA gaps in 2026 sit outside the data center. They sit in contracts, shared cloud platforms, SaaS tools, and fourth-party chains you may not see until something fails.
Start with service mapping. For each critical or important function, name the ICT providers, subprocessors, data flows, and exit path. Then check whether contracts support audits, incident notice, data access, continuity, and termination support. A vendor security score alone won’t satisfy DORA. You need operational context.
Testing matters just as much. Basic control testing should happen every year. Larger and more significant entities also need to prepare for threat-led penetration testing by January 2028. That makes 2026 the right time to define crown-jewel services, line up providers, and clean up scope gaps. For a practical field view, see Fortra’s DORA summary.
Ongoing monitoring closes the loop. Track vendor incidents, SLA breaches, open audit findings, concentration risk, and overdue remediation. Then bring those metrics into the same dashboard used for operational risk and security operations. Where policy allows it, sector threat-sharing can also sharpen detection and response.
The hardest part of DORA in 2026 isn’t writing policy. It’s turning policy into evidence, ownership, and tested response paths.
Teams that handle DORA well treat the checklist as a living control set. When the next outage hits, they don’t scramble for proof. They already have it.
