Beating DORA's four-hour clock with a single 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

For the live demo, that returns: 47 services affected, 12,000 customers impacted, 320 in-flight transactions, tier-2 business function. The Article 19 notification template pre-populates from the same query. Two minutes elapsed since the incident notice.

The Article 28 due-diligence chain

The harder question — "did you onboard this vendor with adequate due diligence?" — is one procedure call:

CALL db.verifyAclChain('vendor:TradeNet')
YIELD entries, tampered
RETURN entries, tampered

The vendor's due-diligence chain shows the risk assessment from twelve months ago, signed by the head of ICT risk. The concentration analysis on file. The exit strategy documented. The continuous-monitoring active. Article 28 requirements, evidenced cryptographically.

The notification-order proof

You notify the regulator first, your customers second. The audit chain timestamps both. The supervisor can never claim later that you tipped off customers ahead of the regulator — the chain proves the order.

The numbers

A four-hour scramble that becomes a two-week post-mortem becomes a thirty-minute filing. Article 19 preliminary report ready within the window. Customer comms in ninety minutes. ECB review of your concentration analysis passes without comment. Your operational-resilience credibility — strengthened.

Live walkthrough on the DORA tab.