DORA and NIS2: What They Require for Third-Party ICT Monitoring

Two EU instruments now put third-party technology providers inside the compliance perimeter. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to EU financial entities since 17 January 2025. The NIS2 Directive, Directive (EU) 2022/2555, had a transposition deadline of 17 October 2024 and reaches a much wider set of essential and important entities across energy, transport, health, digital infrastructure, and public administration.

Neither one tells you to buy a monitoring tool. This is the first thing to get straight, because vendors in this space routinely imply otherwise. What DORA requires is a documented ICT risk management framework, a maintained register of contractual arrangements with ICT third-party providers, a concentration risk assessment before entering into arrangements for critical functions, and specific contractual terms including audit and access rights. What NIS2 requires includes supply chain security as one of its risk management measures, plus incident reporting on a fixed clock.

Availability monitoring produces evidence that supports several of those obligations. It does not satisfy any of them on its own. This article is for compliance leads, CISOs, and platform teams who need to know which articles apply, what artefacts an auditor will ask for, and where operational telemetry is genuinely useful versus where it is decoration. It is a practitioner's reading and not legal advice; confirm scope with counsel, because whether you are in scope at all is a legal question about your entity type.

Chapter V of DORA covers ICT third-party risk. Four articles carry most of the operational weight.

Article 28 sets the general principles. Financial entities must manage ICT third-party risk as an integral part of their ICT risk framework, and must maintain a register of information on all contractual arrangements with ICT third-party service providers. The register distinguishes arrangements supporting critical or important functions from the rest, and competent authorities can ask for it. In practice the register is the artefact everything else hangs off, and it is the one most teams underestimate: it is a living inventory, not a spreadsheet assembled the week before an audit.

Article 29 requires a preliminary assessment of ICT concentration risk before you enter into a contractual arrangement for a critical or important function. That includes looking at whether the provider is easily substitutable and whether you are contracting with a provider that already supports several of your other critical functions. Article 30 specifies what the contract itself must contain, including service level descriptions, notification obligations, and rights of access, inspection, and audit.

Articles 31 through 44 build an oversight regime for critical ICT third-party service providers designated by the European Supervisory Authorities. That designation happens above your head. Its practical effect for most entities is that some of your providers will be supervised directly, which changes what information becomes available about them and does not reduce your own obligations.

NIS2 approaches the same problem from a cybersecurity angle and catches a far broader population of organisations. Its risk management measures include supply chain security, covering the security of relationships with direct suppliers and service providers, and they require entities to account for vulnerabilities specific to each supplier.

The reporting clock is the part that surprises people. An entity must submit an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report within one month. Those deadlines run from awareness and not from resolution, which means detection latency directly consumes your reporting budget. If a supplier's degradation takes eleven hours to notice, you have spent nearly half the early-warning window before anyone starts writing.

This is where operational monitoring earns its place honestly. It does not make you compliant. It shortens time to awareness, and on a 24-hour clock that is a material difference. It also produces a timestamped record of when a third-party condition began and when you observed it, which is precisely the sort of thing you will be asked to reconstruct a month later for the final report.

Being precise about this is what separates a defensible compliance posture from a purchased one. Continuous availability data supports some obligations well and others not at all.

It supports ongoing monitoring of performance against agreed service levels, because you have an independent record instead of only the provider's own reporting. It supports incident timelines for NIS2 notifications. It supports the periodic review of whether an arrangement still performs as contracted. And it gives a concentration assessment something quantitative to sit on, since you can show which providers actually underpin which functions and how their incidents have correlated historically.

It does not establish that your contracts contain the Article 30 clauses. It does not constitute the register of information, which is about contractual arrangements and not uptime. It does not perform the pre-contract substitutability analysis. It does not demonstrate that you have an exit strategy or that you have tested it. Anyone selling availability monitoring as DORA compliance is describing a small slice of Chapter V and calling it the whole chapter.

The useful framing for a steering committee is that monitoring turns several of these obligations from assertions into measurements. Saying a provider met its service levels is a claim. Showing 90 days of independently recorded component status behind that claim is evidence, and the difference shows up the moment somebody challenges it. The mechanics of reporting that upward are in reliability reporting for executives.

The register defeats teams for a structural reason: procurement owns the contracts, engineering owns the dependencies, and the two lists disagree. Engineering is integrated with services nobody signed a contract for, and procurement holds contracts for services nobody has used in two years.

Start from the engineering side, because that list is the one that can be derived from evidence instead of memory. Enumerate every external service your systems call in production, then reconcile against the contract inventory. The gaps in both directions are the interesting output. A production dependency with no contract is a procurement finding. A contract with no production traffic is a cost finding and possibly an exit candidate.

Then classify. Each arrangement needs a decision about whether it supports a critical or important function, and that decision needs a rationale somebody will defend in twelve months. Tie each entry to the business capability it serves, so the register answers the question an auditor actually asks, which is what breaks if this provider stops. Mapping vendors to capabilities is the same exercise described in building a cloud dependency map.

Keep it current by attaching register review to an event that already happens. A new integration reaching production, a contract renewal, or a quarterly architecture review are all better triggers than an annual calendar reminder, which reliably produces a register that is accurate one day a year.

The most common failure is treating the register as a document instead of an inventory. Documents go stale silently. Inventories have owners, update triggers, and a way to detect drift.

The second is confusing the provider's SLA with the provider's behaviour. A contracted 99.9% is a commercial term with remedies attached. What the service actually delivered last quarter is a separate fact, and the two diverge more often than procurement expects, partly because of the maintenance exclusions covered in scheduled maintenance and SLA math.

The third is assessing concentration provider by provider. Article 29 asks about substitutability and about providers already supporting several of your critical functions, which is a portfolio question. Four vendors that each look independently fine can still share one cloud region, and that shared dependency is invisible if you assess them one at a time. The mechanics of that are in cloud concentration risk.

The fourth is assuming scope by industry rather than by legal test. NIS2 in particular reaches organisations that do not think of themselves as regulated infrastructure. Size thresholds and sector annexes decide this, and the transposing national law is what actually binds you, since a directive takes effect through member state implementation and those implementations differ.

Does DORA require continuous monitoring of third-party providers? Not in those words. It requires ongoing management of ICT third-party risk, monitoring of contractual arrangements, and a maintained register. Continuous availability monitoring is one reasonable way to evidence the performance-monitoring part. It is not named as a control and it does not cover the contractual or concentration obligations.

Does a status page aggregator make us DORA compliant? No, and be sceptical of anyone who says otherwise. It can produce independent evidence for service level performance and incident timelines, which is a genuine part of the picture. The register, the Article 30 contract clauses, the concentration assessment, and exit planning are all outside what any monitoring product can do.

We are not a financial entity. Does DORA apply? DORA applies to the categories of financial entities listed in Article 2, plus ICT third-party service providers to them. If you sell technology to EU financial entities you will feel DORA through your customers' contracts even when the regulation does not bind you directly, because they must obtain Article 30 terms from you.

How fast do we have to report under NIS2? An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. The clock starts at awareness, so detection speed is part of your compliance posture and not only an operational concern.

Does a third-party outage count as a reportable incident? It depends on the effect on your own service, not on whose infrastructure failed. If a supplier failure causes a significant disruption to the services you provide, the reporting obligation is yours. Outsourcing the component does not outsource the notification.

What evidence should we retain? Timestamped records of when each third-party condition started and when you detected it, the affected components, what you did, and what your customers experienced. Retain it for at least the period your national implementation requires, and structure it so a single incident can be reconstructed without reading a chat log.