For most of its life, the Digital Operational Resilience Act read like another compliance project: a regulation to map, a gap analysis to commission, a register to populate. That framing is now out of date. DORA has applied to in-scope financial entities since 17 January 2025, and 2026 is the year supervision turns from implementation planning into active enforcement. Regulators have moved from asking whether you have a framework to testing whether it works under stress — and to asking who signed off on it.

That last question is what changes the personal stakes for security and resilience leaders. DORA does not treat ICT risk as a back-office technical matter to be delegated downward. It places ultimate accountability for the ICT risk management framework on the entity’s management body, and it gives competent authorities the power to sanction individuals, including prohibiting them from holding management positions. If you lead security, operational resilience, or technology risk at a bank, insurer, or fintech, your governance decisions now carry consequences that attach to people, not just to the institution.

Why DORA raises the personal stakes

DORA’s design philosophy is that operational resilience is a governance responsibility, not a control to be owned solely by an IT function. Article 5 makes this explicit: the management body bears ultimate responsibility for managing the entity’s ICT risk. Board members and senior managers are expected to define the ICT risk management strategy, actively engage in its execution, allocate adequate budget, and keep their own knowledge of the ICT risk landscape current. “We outsourced it” and “the technical team handled that” are no longer defensible postures — the regulation anticipates and forecloses them.

The enforcement toolkit reflects this. Administrative sanctions available to competent authorities go well beyond fines. They include public censure that names the responsible person, orders to cease the offending conduct, and — most consequentially for individuals — temporary bans on members of the management body or other natural persons from exercising management functions. For an executive, a prohibition on holding management roles is a career-ending sanction in a way that a corporate fine, however large, is not. This mirrors the direction of travel across EU digital regulation; the same logic underpins the management-body duties we covered in NIS2 personal liability.

The point is not that regulators are eager to bar executives. It is that the legal architecture now makes individual accountability available, documented, and expected. When a major ICT incident triggers a supervisory review, the question of who approved the framework, who understood the risk, and who acted on the testing results becomes a matter of record.

What DORA actually requires

DORA organises its requirements into five pillars. At leadership altitude, the value is in understanding what each pillar demands of governance, not in reciting the technical standards beneath them.

ICT risk management (Articles 5–16). The foundational pillar. Entities must maintain a sound, documented ICT risk management framework covering identification, protection, detection, response, recovery, and learning. The framework must be approved and periodically reviewed by the management body. This is where individual accountability bites hardest: the board’s approval is not a formality but an assertion of oversight that can be examined after the fact.

ICT-related incident management and reporting (Articles 17–23). Entities must classify incidents using harmonised criteria and report major ICT-related incidents to their competent authority on a defined multi-stage timeline — an initial notification, an intermediate report, and a final report. Reporting decisions are time-pressured and consequential; getting classification and timing wrong is itself a compliance failure.

Digital operational resilience testing (Articles 24–27). All in-scope entities must run a testing programme spanning vulnerability assessments, scenario-based testing, and more. Significant entities — those identified by authorities based on size and systemic importance — must additionally perform Threat-Led Penetration Testing (TLPT) at least every three years, following the TIBER-EU-aligned methodology. TLPT is not a routine pen test; it is a live red-team exercise against production systems covering critical or important functions, including those running on outsourced and third-party infrastructure. Leadership owns the risk acceptance for testing against live systems.

ICT third-party risk management (Articles 28–30). Entities must maintain a register of information on all contractual arrangements for ICT services, perform due diligence before contracting, and ensure contracts contain DORA-mandated provisions — audit rights, exit strategies, sub-outsourcing controls, and incident cooperation clauses. Concentration risk must be assessed and managed at the board level.

Information sharing (Article 45). DORA encourages, on a voluntary basis, the exchange of cyber threat intelligence among financial entities within trusted communities. It is the lightest-touch pillar, but it signals the regulator’s expectation that resilience is a collective, not purely defensive, posture.

For a fuller picture of how these obligations sit alongside the broader regulatory load on security leaders this year, see our hub analysis, The State of Security Leadership in 2026.

How DORA applies — and to whom

DORA reaches two distinct populations. The first is financial entities: banks, investment firms, insurers and reinsurers, payment and e-money institutions, crypto-asset service providers, trading venues, fund managers, and others — roughly twenty categories. Scope is broad, though the regime applies proportionately, so a small payment institution carries a lighter testing and reporting burden than a globally systemic bank.

The second population is new and significant: critical ICT third-party service providers (CTPPs). DORA created a direct EU oversight regime for the largest technology providers serving the financial sector — major cloud platforms, core banking system vendors, and specialist fintech infrastructure. In November 2025 the European Supervisory Authorities published the first official list of designated CTPPs, naming nineteen providers. Each designated CTPP is assigned a Lead Overseer — the EBA, EIOPA, or ESMA — based on the predominant type of financial entities relying on it. The Lead Overseer can request information, conduct investigations, and carry out on-site inspections under Article 35. A non-compliant CTPP can face periodic penalty payments of up to 1% of its average daily worldwide turnover, charged for each day of breach for up to six months.

This matters even if your provider is not on the list. Designation is dynamic and updated annually, and the oversight regime changes the negotiating posture of the providers you depend on most.

The third-party risk angle

DORA’s treatment of third-party risk is where many financial entities have the most exposure and the least control. Your ICT estate is increasingly someone else’s infrastructure. DORA responds by making third-party dependency a governance object: it must be registered, contractually controlled, concentration-tested, and exit-planned.

Two consequences for leaders. First, the register of information is not a one-time deliverable. Authorities expect it to be accurate, current, and queryable on demand; an out-of-date register is evidence of weak oversight. Second, the contractual provisions DORA mandates — audit rights, defined exit strategies, incident cooperation — are leverage you must actually be able to exercise. A contract that grants audit rights you never use, or an exit strategy that could not survive contact with reality, will not satisfy a supervisor examining how you discharged your oversight duty.

The CTPP oversight regime helps here, because it puts independent pressure on the largest providers. But it does not transfer your accountability. If a critical provider fails and disrupts your critical functions, your management body still answers for whether the dependency was identified, assessed, and managed. Oversight of the provider is additive to your obligations, not a substitute for them.

What a security or resilience leader should do now

If your DORA programme was built for the January 2025 deadline and has not been revisited, treat 2026 as the year to move from documented to demonstrable.

Make management-body ownership real and recorded. The board’s approval of the ICT risk management framework must be a genuine, minuted decision informed by clear reporting — not a rubber stamp. Ensure board members receive ICT risk reporting they can actually interrogate, and that the cadence of review is documented. This record is your protection as much as your obligation.

Pressure-test incident classification and reporting before you need it. Run tabletop exercises specifically on the classification decision and the multi-stage reporting timeline. The failure mode under DORA is not usually the incident itself; it is mishandling the regulatory response under time pressure.

Treat the register of information as a living control. Assign clear ownership, reconcile it against actual contracts and live dependencies, and confirm you can produce it on request. Use it to surface concentration risk to the board.

Scope TLPT honestly if you are a significant entity. Confirm whether you fall in scope, map your critical or important functions including third-party-hosted ones, and plan the three-yearly cycle. Do not let scoping exclude the dependencies that matter most.

Get your own accountability in writing. DORA’s individual-sanction regime makes role clarity and liability protection a personal matter, not just an institutional one. Understand exactly what you are accountable for, what authority and budget you hold to discharge it, and what indemnification and insurance cover you. If you are negotiating or renegotiating terms, our guide to negotiating your CISO liability package walks through the protections worth securing before, not after, an incident.

Conclusion

DORA is no longer a future obligation or a paperwork exercise. It has applied since January 2025, its enforcement phase is underway in 2026, and it assigns ultimate accountability for ICT resilience to named individuals on the management body — backed by sanctions that reach those individuals directly. The five pillars describe what good looks like; the accountability regime describes who answers when it falls short.

For security and resilience leaders, the practical implication is twofold. Build a programme that is demonstrable under stress, not merely documented for an auditor. And make sure your own role, authority, and protection are defined in writing to match the accountability the regulation now places on you. In a regime where the worst-case sanction is being barred from management, governance is no longer something you advise on — it is something you are personally answerable for.

This article is provided for informational purposes only and does not constitute legal advice. DORA obligations and supervisory enforcement vary by entity type and jurisdiction; consult qualified counsel.