DORA Third-Party Rules: A Governance Checklist, Not a Risk Number
The EU’s Digital Operational Resilience Act tells financial entities exactly what to do about vendor risk. It does not tell them what that risk is worth, and that gap is where most third-party risk programs quietly stall.
What DORA actually asks for
Chapter V of DORA (Articles 28 through 44) gives financial entities a detailed governance obligation for ICT third-party risk: a contractual register of every provider, exit strategies before a contract is signed, a concentration-risk assessment across the vendor estate, and a formal Oversight Framework for providers designated critical at EU level. Read the text closely and a pattern shows up: every requirement is structural. Keep a register, define exit terms, assess concentration. Nowhere does the Regulation ask an entity to state how much a given vendor relationship is actually worth in expected loss terms, because that is not what DORA is built to produce. Article 18’s incident-classification criteria (clients affected, duration, economic impact) are qualitative fields for reporting an incident after it happens, not a forward-looking exposure figure.
Why the gap is more expensive to ignore this year
Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled from 15 percent to 30 percent year over year, the largest single-year jump the report has tracked in eighteen years of publication. IBM’s 2025 Cost of a Data Breach report puts supply chain compromise as the second most frequent initial attack vector at 15 percent, the second most costly at an average of 4.91 million dollars, and the slowest to contain at 267 days, ten percent longer than the 241-day average across all vectors. A vendor register tells a risk committee that a provider exists and has signed a contract. None of these three numbers are visible anywhere in that register.
What quantitative risk analysis adds on top of the register
Under a quantitative cyber risk management methodology, a DORA-compliant third-party inventory is not a competing deliverable, it is the raw material for one. The register becomes the asset and dependency list a quantitative model needs; the work that is still missing is turning that list into a Loss Event Frequency and Loss Magnitude distribution per critical relationship. Three adjustments matter more for third-party scenarios than for a direct-attack scenario: Contact Frequency should be pushed upward to reflect the vendor’s attack surface, not only the entity’s own; the vendor’s Resistance Strength is usually unknown and often weaker than the entity’s own control environment, since it sits outside the entity’s direct governance; and Loss Magnitude can multiply rather than simply add, because a vendor’s own secondary loss event becomes the entity’s primary loss event. The pattern behind the Change Healthcare and CDK Global incidents, a single upstream compromise producing Business Interruption at hundreds of downstream organizations simultaneously, is exactly this multiplication, and it is a structural amplification that a single-organization model will systematically undercount if the third-party pathway is not modeled as its own scenario.
The practical takeaway
Complying with DORA Chapter V and knowing what a specific vendor relationship is worth in expected annual loss are two different projects, built from the same underlying inventory. Most financial entities have only started the first one, because the Regulation only requires the first one. An ICT risk committee that wants to prioritize which critical provider gets the next round of due diligence, or which vendor relationship justifies paying for a stronger contractual exit clause, needs the second project: a P50 and P95 exposure range per critical relationship, calibrated the same way any other quantitative risk scenario would be, not a compliance status flag showing the register is complete.