ZetrixwebWhy 2026 is different from 2025
The Digital Operational Resilience Act (DORA) became applicable across the EU in January 2025, but its first year was largely about financial entities standing up internal frameworks and filing initial documentation. That changed in 2026: national competent authorities and the European Supervisory Authorities are now conducting formal compliance assessments, cross-checking Register of Information submissions against actual contracts, and issuing remediation orders where gaps surface. The posture is interventionist - regulators are examining for compliance evidence, not remediation plans.
What Articles 28-30 actually require
DORA imposes a structured third-party ICT risk regime on financial entities, which flows directly into vendor contracts:
Register of Information
Every ICT third-party arrangement must be logged, with a criticality classification - "supports a critical or important function" gets a materially higher level of scrutiny.
Due diligence & oversight
Financial entities must assess a provider's ICT risk profile before signing, and maintain continuous oversight afterward - not a one-time vendor questionnaire.
Mandatory contract provisions
Specific clauses - audit rights, incident notification timelines, sub-outsourcing controls, data location - are required in the contract itself, not left to negotiation norms.
Exit planning
A documented exit strategy must exist for every critical ICT arrangement - meaning a vendor's replaceability and data portability are now a scored risk factor, not an afterthought.
Not sure what your bank or insurer client actually needs from you under DORA, or whether your platform's architecture supports it? Get a free DORA vendor-readiness review.
Where the Register of Information becomes a real audit trail
Supervisors typically start an examination at the register, then trace forward: from the entry to its criticality classification, to the contract's actual clauses, to the concentration assessment (how much of one function depends on one vendor), and finally to what the board was told about that risk. A gap at any one of those links - a contract missing an audit-rights clause the register implies should exist, say - generates a finding against the financial entity. That finding becomes pressure on the vendor to fix the underlying gap fast, often on a timeline the vendor doesn't control.
The practical shift for ICT vendors
Being "DORA-ready" as a vendor increasingly means being able to answer specific technical questions on demand: what's your sub-processor chain, what's your documented incident-notification SLA, what does data portability actually look like if the client needs to leave, and can you demonstrate (not just describe) your operational resilience testing. Vendors who can answer these before being asked win procurement cycles against ones who scramble when a Register of Information audit surfaces a gap.
| DORA area | What changed in 2026 |
|---|---|
| Enforcement posture | Moved from supervisory dialogue to active compliance review |
| Register of Information | Now actively cross-checked against real contracts by supervisors |
| Penalties | Up to 2% of global turnover or €10M for the entity; up to €1M personally for senior managers |
| Vendor pressure | Contract clauses, audit rights, and exit plans increasingly enforced, not just documented |
Key takeaways
- DORA enforcement moved from documentation-gathering to active supervisory review in 2026, with formal remediation orders now issued.
- Articles 28-30's third-party ICT risk regime is formally aimed at financial entities, but reaches vendors directly through mandatory contract terms.
- The Register of Information is the audit's starting point - gaps between what's logged and what's actually in the contract generate findings.
- Vendors who can demonstrate resilience, sub-processor transparency, and exit-plan readiness proactively have a real procurement advantage.