DORA's First Year of Data Is In. Third Parties Are Still the Weak Link.

Introduction

On June 3, 2026, the European Supervisory Authorities published their first annual overview of major ICT-related incidents under DORA. It covered 3,383 reported incidents from the regulation's first year in force. A third of them had cross-border impact. The primary drivers? System failures and third-party dependencies.

Nobody should be surprised. And yet, here we are.

The Grace Period Ended. The Data Confirmed It.

When DORA became enforceable in January 2025, regulators broadly treated the first year as a transition period. Supervisors reviewed frameworks, catalogued gaps, and gave institutions time to catch up. That era is over. National Competent Authorities are now conducting active enforcement reviews, and they are not interested in your policy documents.

The numbers make the shift stark. A 2024 dry-run exercise by the ESAs found that only 6.5% of nearly 1,000 firms across the EU successfully passed all 116 data quality checks on their Register of Information, DORA's mandatory inventory of ICT third-party contracts. Meanwhile, roughly half of regulated institutions were still working toward full compliance when the enforcement clock started.

This is not a documentation problem. It's an execution problem. And regulators are no longer pretending otherwise.

The Critical Provider List Changed the Stakes

In November 2025, the ESAs named names. For the first time, the European Supervisory Authorities published an official list of 19 designated Critical ICT Third-Party Providers – AWS, Microsoft Azure, Google Cloud, IBM, Orange, Bloomberg, and others – placing them under direct EU oversight via Joint Examination Teams. If your organization relies on any of them, your oversight obligations just got considerably more demanding.

This matters beyond the named providers themselves. The designation signals where supervisory focus is heading: concentration risk. The ESAs explicitly called out systemic reliance on a small number of cloud hyperscalers and infrastructure providers, and the interconnected dependencies that make diversification on paper irrelevant in practice.

Think about what concentration risk actually looks like in a real supply chain. One widely used cloud provider, one enterprise SaaS platform, one network infrastructure vendor shared across dozens or hundreds of your third parties simultaneously. A single incident doesn't just affect that vendor. It cascades. Black Kite's research across 136 verified breach events found that every single vendor breach now claims an average of 5.28 downstream named victims, the highest ever recorded. But named victims are only the visible surface. Behind them sits an estimated 26,000 shadow victims: companies impacted by the same cascades who were never legally required to disclose it.

That's what the ESAs are worried about. That's what your board should be asking about.

117 Days: That's How Long Your Vendors Stay Quiet

DORA requires a 4-hour disclosure window once an incident is classified as critical. The problem is the clock doesn't start until the victim decides the incident qualifies as "critical" or "major," terms DORA leaves deliberately undefined. In practice, organizations take roughly 10 days to detect an attack and then spend an average of 117 days investigating before disclosing anything to their customers. By the time your vendor tells you they were breached, the threat actor has been operating inside their environment, and possibly yours, for months.

Read that again.

This isn't a compliance gap. It's a fundamental flaw in the reactive, wait-to-be-notified model that most third-party risk programs are still built on. If your TPCRM program depends on vendors self-reporting in time for you to act, you don't have a program. You have a hope.

The 4-hour reporting window is meaningful only if you already know something happened. That requires continuous external monitoring of your third-party ecosystem, not annual questionnaires, not periodic reassessments, not spreadsheets with 200 rows marked "pending."

What DORA's Article 28 Actually Asks You to Prove

DORA's third-party ICT risk requirements under Article 28 are among the most demanding of any regulatory framework globally. Most organizations are still treating them like a checklist, and that's the wrong frame.

The regulation requires contractual guarantees covering security standards, audit rights, exit strategies, and business continuity obligations for critical third parties. It requires annual scenario testing exercises that include those third parties. It requires live maps of critical supplier dependencies across legal entities. It also requires you to understand your fourth and fifth-party exposure: your vendor's vendor, the infrastructure provider your vendor's SaaS platform runs on, the concentration risk buried three layers deep in your supply chain that nobody has mapped because nobody looked.

You can't questionnaire your way to Nth-party visibility. Sending an email to your vendor asking if their subprocessors were affected by a breach isn't due diligence. The triage model is obsolete. DORA codified what practitioners have known for years: external intelligence, continuously applied, is the only way to actually see your supply chain.

Attestations Are Done. Prove the Resilience.

The FCA said it plainly in March 2026: attestations are no longer sufficient.

Regulators across the EU and UK are asking a single question now: can you demonstrate that your critical services can absorb disruption and stay within defined tolerance limits? Not in theory. Under realistic stress conditions. With your third parties included in the test.

Try this diagnostic on your own team. If a critical vendor failed tomorrow, how long would it take you to detect it, contain the impact, and report within DORA's required window? Don't accept "we have a process" as the answer — push for actual detection timelines, actual escalation paths, actual data. If they can't produce specifics, you've found the gap.

Organizations performing well on operational resilience right now aren't spending more time on policy. They're investing in the intelligence infrastructure that lets them see their supply chain continuously, prioritize by actual exploitability rather than theoretical severity, and move fast when something breaks. That's a resilience posture, not a compliance posture, and the distinction is exactly what regulators are testing.

The 117-day problem is solvable. Waiting to be notified is not a strategy.

For more info on this topic, including how DORA and NIS2 compliance requirements map to real-time third-party intelligence, the DORA and NIS2 Decoded webinar with Black Kite, ServiceNow, and Sarity covers exactly that, including a live product walkthrough.