DORA Year Two: Why EU Financial Firms Need Real Network Visibility

When the Digital Operational Resilience Act (DORA) became enforceable across the EU in January 2025, financial institutions spent the year on paperwork: risk registers, updated vendor contracts, and incident escalation charts. That phase is over. In year two, regulators are asking a sharper question — not whether the documentation exists, but whether a security team can actually see an attack unfolding across its systems in time to act.

What DORA's second year actually tests

DORA's technical requirements go well beyond documentation. Article 9 obliges financial entities to continuously monitor and manage the security of their ICT systems. Article 10 requires them to detect anomalous activity quickly enough to trigger a response, with defined thresholds for when incident response kicks in. Article 19 puts a hard clock on reporting: initial notification as early as possible and no later than four hours after an incident is classified as major, with the fuller picture due within 24 hours of first becoming aware. Articles 28 through 30 extend the same scrutiny to third-party ICT providers — the processors, cloud platforms, and vendors a financial institution depends on.

Regulators are now checking whether institutions can meet these obligations in practice, not just describe them in a policy document.

Why the gap matters

Most organizations already maintain an asset inventory, configuration records, and endpoint logs. None of these, on their own, show how systems actually communicate with each other — especially across legacy infrastructure, unmanaged devices, and third-party integrations where standard telemetry is thin. That is precisely the blind spot attackers rely on: unusual internal traffic, command-and-control beaconing, and lateral movement often show up on the network well before an endpoint agent or a correlation rule flags them.

The same gap makes DORA's own clock harder to meet. A four-hour notification deadline leaves little room to manually piece together which systems were touched, whether a vendor's access pattern actually changed, or how far an intrusion spread. Those answers depend on having traffic evidence ready before an incident happens, not reconstructed under pressure afterward — which is also why the third-party risk articles matter in practice: a contract defines what a vendor is allowed to do, but only observed traffic shows what it is actually doing.

What to do about it

Map what "normal" communication looks like between critical systems, including vendor connections, before an incident forces you to reconstruct it against a four-hour deadline.
Extend monitoring to the segments endpoint agents don't reach: legacy appliances, unmanaged devices, OT/IoT, and the third-party integrations covered by Article 28-30 assessments.
Treat network-level monitoring as a complement to endpoint and identity logs, not a replacement — the value shows up when the three are correlated the moment an alert fires.
Run the DORA reporting timeline as a tabletop exercise, from "anomaly detected" to "four-hour notification drafted," and find out where evidence-gathering actually stalls today.
Treat vendor risk assessments as living documents: periodically confirm that a provider's real network behavior still matches what the contract describes, rather than revisiting it only at renewal.

DORA's first year proved institutions could build the governance. Its second year is proving whether that governance holds up against a live incident — and visibility, not paperwork, is what that comes down to.