DORA's four-hour initial notification: tracing affected services with a query

The Digital Operational Resilience Act came into force in January 2025. For every EU financial firm, Article 19 sets the most punishing clock in regulatory operations: a major ICT-related incident at a critical third party triggers a four-hour preliminary notification window to the competent authority. The clock starts when you confirm the incident — and the authority expects a real report, not a placeholder.

What does a real Article 19 report need? Which of your services were affected. Which of your customers are impacted. The expected business consequence. A reference to the third-party vendor and your due-diligence record. In most EU financial stacks, producing this in four hours is impossible. Reconstructing service dependencies on three hundred ICT third parties takes a day under pressure. Mapping customer impact takes another. Showing the vendor due-diligence chain takes another.

The fine for late notification is up to one percent of annual revenue per day. The reputational cost is worse — DORA-supervised firms are expected to handle this, and failing to handle it suggests broader operational deficiency.

Why this is so hard in most stacks

Three things have to be true at the moment of incident:

1. Vendor → service dependency. You have to know, instantly, which of your internal services depend on the affected vendor.
2. Service → customer impact. You have to map services to the customers using them, with the in-flight transaction count.
3. Vendor due-diligence record. You have to produce Article 28 evidence — the risk assessment, the concentration analysis, the exit strategy — for the affected vendor, signed and dated.

If those three things live in a CMDB, an analytics warehouse, and a GRC tool respectively, you cannot answer them in four hours. If they live in one graph, you can.

The blast-radius query

MATCH (v:Vendor)<-[:DEPENDS_ON]-(s:Service)<-[:USES]-(c:Customer)
WHERE v.name = 'TradeNet'
OPTIONAL MATCH (c)-[:HAS_INFLIGHT]->(t:Transaction)
OPTIONAL MATCH (s)-[:CRITICALITY]->(crit:Tier)
RETURN count(DISTINCT s) AS services,
       count(DISTINCT c) AS customers,
       count(DISTINCT t) AS inflight,
       crit.tier

In the illustrative walkthrough, that returns 47 services affected, 12,000 customers impacted, 320 in-flight transactions, and a tier-2 business function. You can use the same results to fill in the Article 19 notification.

The Article 28 due-diligence chain

The harder question — "did you onboard this vendor with adequate due diligence?" — is answered by the records written during onboarding. If the risk assessment, concentration analysis, exit strategy and monitoring records are stored as nodes linked to the vendor, one query returns them (the relationship name is fictional):

MATCH (v:Vendor {name: 'TradeNet'})-[:HAS_DUE_DILIGENCE]->(d)
RETURN d

db.history on each record lists when it was written. GET /graphs/{name}/audit/verify re-hashes the graph’s write history and returns clean or the first broken record. The check covers the whole graph and has no date window. The history log is not signed or anchored outside the server, so the check does not detect a rewrite of the whole log, or removal of the most recent records, by someone with write access to the server.

The notification-order record

You notify the regulator first, your customers second. If each notification is written to the graph when it is sent, the recorded times show the order, and the history check reports whether the hash chain that includes those records is intact.

The numbers

The figures in this post and in the walkthrough are illustrative.

Illustrative walkthrough on the DORA tab.