Vendor Risk and Digital Operational Resilience (DORA) Readiness Guide

A practical guide to third-party risk management in the era of the Digital Operational Resilience Act (DORA): what the regulation requires of financial entities, what those entities now ask of every technology vendor they rely on, and how a vendor risk program produces the artifacts both sides need.

Operational Resilience as a Discipline

Operational resilience asks a harder question than availability: not "is the system up?" but "can the organization keep delivering its critical services through disruption — including disruption arriving through a supplier?" That framing moves third-party risk from a procurement checklist to a core resilience concern, because a dependency that fails is operationally indistinguishable from an internal failure, except that the organization holds less information and less control.

A resilience program therefore inventories critical services first, maps every dependency that supports them — internal systems, vendors, and the vendors' own subcontractors — and tests the mapped assumptions rather than filing them.

What DORA Is and Who It Reaches

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — harmonizes digital operational resilience requirements across the EU financial sector. It has applied since 17 January 2025; by now supervision is operational, registers of information have been collected by the authorities, and the first designations of critical ICT third-party providers have been made. Readiness language written in the future tense is out of date: for financial entities these are present obligations.

Scope is broad. Article 2 reaches roughly twenty categories of financial entities — credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, trading venues, fund managers, insurers and intermediaries, occupational pension institutions, crowdfunding providers, and more — with proportionality for the smallest entities, including a simplified ICT risk-management track. Technology vendors are reached two ways: indirectly, through the contractual and monitoring obligations their financial-entity customers must impose; and directly, only when the European Supervisory Authorities designate a provider as a critical ICT third-party provider subject to their oversight.

The DORA Requirement Areas

Article 1 organizes the regulation's substance into requirement areas — often summarized as pillars, though the count varies by summary and the article itself is the anchor:

The technical standards that make these areas operational are adopted and in force — incident classification and materiality thresholds, the register of information format, incident-report content and time limits, subcontracting conditions, and threat-led penetration testing among them. A readiness effort citing "pending technical standards" is working from stale notes.

Incident Classification and Reporting Under DORA

DORA's incident regime is where operational resilience becomes measurable, and where vendors feel their customers' obligations most directly. Financial entities classify ICT-related incidents against materiality thresholds — among them the criticality of the services affected, clients and counterparts affected, duration and service downtime, geographical spread, data losses, and economic impact — and a major incident triggers reporting to the authority on fixed clocks: an initial notification within hours of classification, an intermediate report within days, and a final report within a month, on templates fixed by the technical standards.

Two details matter for vendor relationships. First, the reporting clocks start from the entity's awareness and its classification of the incident — so a vendor that reports incidents to customers slowly is consuming its customers' regulatory time. Second, incident response duties do not transfer: the financial entity owns the report even when the root cause sits inside a supplier. A vendor's incident management process — detection, customer notification commitments, evidence preservation, post-incident analysis — is therefore evaluated as part of the customer's own resilience, and contractual notification windows are negotiated with the regulatory clocks in view.

Third-Party Risk in the Regulation's Own Terms

DORA's chapter on ICT third-party risk sets key principles for managing vendor risk across the full relationship lifecycle: pre-contract due diligence, contractual provisions, ongoing monitoring, and documented exit strategies. Three obligations shape day-to-day vendor management:

• The register of information. Financial entities maintain a structured register of all contractual arrangements for ICT services, at entity and group level, in a format fixed by an implementing standard — and authorities collect it. "Could you populate your customer's register entry accurately, today?" is now a fair diligence question for any vendor.
• Contractual provisions. The regulation prescribes minimum contract content — service descriptions, data locations, security requirements, incident notification, audit and access rights, termination and exit support — with stronger terms where the service supports critical or important functions.
• Subcontracting transparency. When a vendor subcontracts parts of a service supporting a critical or important function, the customer must be able to assess the arrangement: the conditions to be determined and assessed are fixed by the adopted technical standard. The obligation is risk assessment and contractual visibility of subcontracting — not an open-ended duty to monitor every link of every chain, a framing that appeared in draft-era summaries and did not survive into the final standard.

Building the Vendor Risk Program

For the organization buying technology, a vendor risk program that satisfies both good practice and supervisory expectations follows the lifecycle NIST SP 800-161 (Rev. 1, Update 1) describes for supply-chain risk and DORA prescribes for financial entities:

1. Tier vendors by dependency, not spend. The tiering question is what breaks if this supplier fails — mapped to the critical services inventory, not the invoice size.
2. Assess before contract. Due diligence proportionate to tier: security posture, resilience testing evidence, subcontracting structure, concentration exposure.
3. Contract the obligations. Notification windows, audit rights, exit assistance, data return — negotiated against the regulatory minimums where they apply.
4. Monitor continuously, not annually. Third-party risk changes when the vendor's circumstances change; annual questionnaires discover last year's risk.
5. Design the exit before it is needed. An exit strategy that exists only as a contract clause fails exactly when invoked; the workable version names the substitute, the data path, and the time to switch.

Concentration risk cuts across all five: when many critical services depend on one supplier — or many suppliers depend on one underlying platform — the aggregate exposure is itself a board-level topic, and one reason the regulation created direct oversight of designated critical providers.

What Financial Entities Now Ask Their Vendors

A vendor selling into the EU financial sector should expect, and be able to answer, a recognizable set of diligence requests — because each traces to the customer's own obligations:

None of this requires the vendor to be regulated itself. DORA compliance belongs to the financial entity; a vendor's role is to be ready to support it — and vendor risk diligence increasingly measures exactly that readiness.

AI Services Inside the Vendor Risk Perimeter

AI systems and AI-backed services supplied to financial entities are ICT services within the customer's third-party risk perimeter — the regulation's definitions do not carve them out. The practical consequence: AI vendors face the same register entries, contractual provisions, incident notification expectations, and exit questions as any other ICT supplier, plus diligence specific to the service — model change management, performance monitoring, data handling, and the vendor's own supplier risk for the platforms beneath the model.

Mapping AI governance evidence to vendor risk artifacts is the efficient move: a model inventory answers the service-description questions, model incident runbooks answer the notification questions, and documented model dependencies answer the subcontracting questions. One well-kept governance record serves both conversations.

Readiness Signals

Operational resilience and vendor risk maturity show up in artifacts, not intentions. The signals reviewers look for: a critical-services inventory with mapped dependencies; a vendor register that reconciles with reality; contracts whose notification and exit terms someone has actually tested; a subcontracting disclosure the vendor volunteered rather than surrendered; and a post-incident report where lessons changed something. Each is discoverable in an afternoon by asking for the artifact — and together they answer the question the Digital Operational Resilience Act institutionalized for an entire sector: can this organization keep operating when something it depends on does not? None of this replaces legal counsel on scope or compliance questions; it prepares the artifacts counsel and customers will ask for.