DORA and NIS2 Turn Vendor Resilience Into an Operating Discipline

For most EU financial entities, the first quarter of 2026 ended with the same ritual it did in 2025: assembling the Digital Operational Resilience Act register of information, reconciling it against every ICT contract on file, and submitting it to a national competent authority before the March 31 deadline. For many, that submission is now filed and the project team has moved on to the next priority. That instinct — treat the register as a filing that's now complete — is exactly the gap regulators are starting to test for.

The register of information was never designed as an annual snapshot. It is a live account of every ICT third-party arrangement supporting a critical or important function — the provider, the function, its criticality, the full subcontracting chain behind it — that supervisors expect to reflect the current state of the business, not the state it was in on December 31 of the prior year. The 2026 submission cycle made this expectation explicit: several national authorities, including Luxembourg's CSSF and Belgium's FSMA, described this year's exercise as a "limited update" for entities with no material changes, which only works if an entity actually knows, continuously, whether anything material changed.

NIS2 is arriving at a similar inflection point from a different direction. The Directive's formal transposition deadline passed back in October 2024, but real enforcement has been uneven — as of late July 2026, 22 of the EU's 27 member states had national transposition laws in force, and the European Commission had referred four of the remaining stragglers to the Court of Justice of the European Union for failing to notify their laws at all. For essential and important entities in energy, transport, health, digital infrastructure, and manufacturing, the directive's supply-chain risk-management obligations are only now becoming something a national regulator can actually act on, rather than a requirement that existed on paper without a domestic enforcement mechanism behind it.

Put the two regimes side by side and a common thread emerges that has nothing to do with financial services or critical infrastructure specifically. Both DORA and NIS2 assume that an organization can, at any moment, produce an accurate, current, evidenced account of which third parties it depends on, how critical each dependency is, and what is being done to manage the risk they carry. That is a materially different capability than completing a questionnaire cycle or filing a register once a year — and it is the capability most third-party risk programs, even mature ones, have not yet built.

The Filing Is Done. The Discipline Isn't.

It's worth being precise about what the 2026 DORA register submission actually required, because the scope is often narrower — and the ongoing obligation broader — than teams assume once the deadline passes. In-scope financial entities had to submit data reflecting their contractual arrangements with ICT third-party service providers as of December 31, 2025, in a standardized xBRL-CSV format, to their national competent authority. For entities whose ICT third-party landscape had not materially changed since the prior year's submission, several regulators allowed a confirmation that the situation remained unchanged rather than a full resubmission.

That "limited update" option is where the discipline question actually lives. Confirming that nothing material changed is only a defensible statement if an organization has been tracking changes continuously throughout the year — new contracts signed, subcontractors swapped, criticality reclassifications triggered by a function's growing importance to the business. A register maintained as a once-a-year spreadsheet exercise cannot honestly support that confirmation; it can only support a guess dressed up as a compliance statement. Supervisors reviewing the 2026 cycle are reportedly using completeness, accuracy, and currency as their primary lenses — not just whether every arrangement is listed, but whether the subcontracting chains behind critical functions are traceable and whether the register reflects contract changes that happened months, not days, before the review.

This is the same underlying pattern Crest.Digital has described in the context of vendor questionnaires: a document that was accurate on the day it was completed quietly becomes less accurate with every month that passes, and nothing about the document itself signals when that has happened. A DORA register is a more formal, more heavily scrutinized version of the same problem — the stakes of an outdated entry are simply higher, because the audience reviewing it is a supervisor with the authority to ask hard questions about why a critical dependency wasn't documented.

What DORA and NIS2 Actually Require, Read Together

DORA requires in-scope financial entities to maintain a register of information covering every ICT third-party arrangement, classify which functions those arrangements support as critical or important, and — for the small subset of providers designated as critical at the EU level — participate in a dedicated oversight framework run directly by the European Supervisory Authorities. The register itself is the operational backbone of that framework: without an accurate, current register, neither the entity nor its supervisor can assess concentration risk, subcontracting exposure, or single points of failure across the financial system.

NIS2 approaches the same underlying problem from a wider angle. Rather than a formal register submitted to a regulator, it requires essential and important entities to manage supply-chain risk as an explicit component of their broader cybersecurity risk-management measures — assessing the security practices of direct suppliers, factoring a supplier's vulnerabilities and secure-development practices into procurement and contracting decisions, and maintaining ongoing oversight proportionate to how much that supplier's role could affect the entity's own resilience. Sector coverage is far broader than DORA's financial-services scope, spanning energy, transport, banking, health, digital infrastructure, public administration, and manufacturing, among others named in the Directive's annexes.

The two regimes differ in mechanism — a standardized register filed with a supervisor versus a risk-management obligation enforced through national law — but converge on the same expectation: an organization has to know, continuously and with evidence, which third parties it depends on for which functions, how critical each dependency is, and what could go wrong down the subcontracting chain behind the provider it actually contracted with. Neither regime is satisfied by an annual review that happens to be current on the day it's completed. Both assume ongoing maintenance is the baseline, not the enhancement.

The subcontracting-chain requirement deserves particular attention, because it's the piece most vendor risk programs still handle worst. A direct ICT provider can look low-risk in isolation while sitting on top of a subcontractor, cloud infrastructure layer, or downstream data processor that never appears in the primary contract. Crest.Digital has covered this fourth-party exposure separately — DORA and NIS2 both formalize what was already true operationally: the risk that matters often isn't the vendor an organization signed with, it's what's standing behind them.

Where a Static Register Fails

Three failure modes show up repeatedly once a register moves from a filing exercise to something a supervisor actually scrutinizes. The first is contract drift — a subcontractor changes, a service is renegotiated, or a function's criticality grows as the business comes to depend on it more, and none of those changes flow through to the register because no workflow requires it. The second is concentration blindness: a register can list every ICT provider individually and still fail to surface that five nominally different providers all route through the same cloud region or the same fourth-party subcontractor, which is precisely the kind of systemic dependency concentration-risk analysis is designed to catch and a static list is not built to reveal.

The third failure mode is the one that surfaces hardest during a supervisory review: an evidence gap. A register entry that states a provider's criticality classification without a documented rationale, or a subcontracting chain that was mapped once and never re-verified, reads to a supervisor as a compliance artifact rather than an operational reality. The same evidentiary bar Crest.Digital has covered for board-level risk reporting applies here — a register has to be able to show its work, not just state its conclusions.

None of these three failures require a new regulation to matter. They are the same gaps continuous monitoring was built to close in vendor risk programs generally, applied here to a specific, formally auditable register. What DORA and NIS2 change is not the underlying discipline required — it's the consequence of not having it, and the specificity of what a supervisor can now ask to see.

An 8-Point Framework for Continuous Vendor Resilience

Meeting the underlying expectation behind DORA and NIS2 doesn't require building a separate system for regulatory filing and a separate one for operational risk management. It requires one continuously maintained register that happens to satisfy both.

Points three and six are where most registers built for a single filing deadline fall shortest. Subcontracting chains are frequently mapped once, at onboarding, and never re-verified; concentration analysis is rarely run across the register as a whole because the register was built as a list of individual entries rather than a dataset meant to be analyzed. Both gaps have the same effect: the register can look complete on paper while missing exactly the systemic dependency a supervisor is most interested in.

Building the Discipline: A Six-Step Playbook

None of this requires discarding a register that already satisfied this year's filing. It requires wrapping that register in the ongoing maintenance workflow it was always implicitly expected to have.

The step organizations underinvest in most consistently is the fifth — wiring register updates into the contract lifecycle itself. A register that depends on someone remembering to update it after a contract event will always lag reality by weeks or months, and that lag is precisely what shows up as an "incomplete" or "stale" finding in a supervisory review, regardless of how thorough the original data collection was.

Where Agentic AI Fits — Keeping the Register Current at Scale

Tracing subcontracting chains across hundreds of ICT relationships, monitoring cyber posture continuously for every listed provider, and reconciling contract changes against register entries is not work a compliance or vendor-risk team can sustain manually once the register scales past a small provider population. This is exactly the kind of continuous, high-volume, evidence-heavy work agentic AI is suited to — applied here to keeping a regulatory register accurate between filing cycles rather than only at them.

AI-Assisted Register Maintenance and Change Detection

An agentic workflow can continuously watch for the events that should trigger a register update — a new contract, an amendment, a vendor's own re-attestation disclosing a subcontractor change — and flag the affected entry for review rather than waiting for the next scheduled audit of the register to surface the gap.

AI-Led Subcontracting Chain Discovery

Mapping the chain behind a direct provider — subcontractors, infrastructure layers, downstream processors — is largely a research and cross-referencing exercise at scale. An agentic layer can assemble a first-pass chain map from public filings, vendor disclosures, and product documentation, leaving a human reviewer to verify and finalize rather than build the map from nothing.

AI-Based Continuous Monitoring at Portfolio Scale

Once a provider is in the register, an agentic system can run continuous cyber-posture and adverse-media monitoring across the full population at once, correlating a detected signal to the specific register entry it affects and pre-assembling the evidence a reviewer needs — the same evidence-assembly discipline Crest.Digital has described for AI compliance programs, applied here to a DORA- or NIS2-scoped provider set.

Human-in-the-Loop on Every Determination

What the agentic layer does not do is decide whether a provider's criticality classification should change, whether a newly discovered subcontractor represents an acceptable risk, or how to weigh a concentration finding against a business dependency the organization can't easily replace. Those determinations stay with a named risk owner, informed by evidence the agent surfaced and kept current rather than replaced — the same accountability line Crest.Digital has argued belongs at the center of every agentic GRC workflow.

Programs that build this discipline stop treating the register as a project that resets every March and start treating it as infrastructure — something that's simply true on any given day, because it's maintained continuously rather than reconstructed under deadline pressure. That shift doesn't just satisfy a supervisor. It answers, honestly, the question every register is ultimately meant to answer: which third parties does this organization actually depend on right now, and what happens if one of them fails.

Frequently Asked Questions