DORA is live, and every pillar assumes you can see your infrastructure

You cannot report an incident you can’t see the shape of.

The Digital Operational Resilience Act (DORA)  assumes you already have an accurate, current, classified picture of your Information and Communications Technology estate and the business functions it supports. Most organisations do not. That gap is where DORA programmes quietly fail, and it is an infrastructure gap before it is a compliance one.

This is not a future deadline you can plan around. Regulation (EU) 2022/2554, the Digital Operational Resilience Act, has applied directly across the EU since 17 January 2025, with no national transposition step to wait on. More than 22,000 financial entities are in scope EU-wide, plus the ICT third parties that serve them.

Most of these obligations live in the network and infrastructure layer. infrastructure teams own them whether or not their names appear on the compliance project plan. The programmes that succeed start with inventory and dependency mapping, then layer policy on top.

This piece follows the concrete moments DORA creates for your team: the incident-reporting clock, the annual Register submission, the business-function map, and the shift to continuous testing.

What is DORA Compliance? The Five Pillars Explained

DORA rests on five pillars: ICT risk management (Articles 5-16); ICT incident management, classification and reporting (Articles 17-23); digital operational resilience testing, including Threat-Led Penetration Testing(TLPT) at least every three years for entities designated significant (Articles 24-27, TLPT basis in Article 26); ICT third-party risk management, including the Register of Information (Articles 28-44); and voluntary information sharing (Article 45).

DORA covers banks, investment firms, payment and e-money institutions, insurers, crypto-asset service providers, fund managers, pension funds and rating agencies, among others. It also reaches the ICT third parties that serve them: cloud, colocation, connectivity and SD-WAN, managed security and SOC providers, and software vendors behind critical functions. Those third parties come into scope through contractual flow-down and, for the ones that matter most, an oversight regime run by a Lead Overseer EBA (European Banking Authority), EIOPA (European Insurance and Occupational Pensions Authority) or ESMA (European Securities and Markets Authority).

Two obligations define everything else. Article 8 requires you to identify, classify and document all ICT-supported business functions and ICT assets, and keep that record up to date. Article 28 requires a structured, continuously updated Register of Information on every ICT third-party arrangement, submitted to authorities annually and available for inspection.

Governance is explicit and personal: the management body is accountable for the ICT risk framework, and leaders do not get to delegate this away. Now to the moments where these pillars turn into pressure on your team.

DORA Incident Reporting Requirements: The 4h/72h/1 Month Clock

The reporting clock does not start at detection. It starts when an incident is classified as major. Classification itself must happen without undue delay, in practice within about 24 hours of becoming aware.

The cadence (Articles 17-19 plus the RTS) is what people shorthand as “4h / 72h / 1 month.” An initial notification is due within 4 hours of classifying the incident as major, and no later than 24 hours from detection. An intermediate report follows within 72 hours. A final report is due within one month of the intermediate report, with full root-cause analysis, impact including financial losses, remediation, and lessons learned.

Here is where it goes wrong for infra. If you spend the first three hours working out which business functions, customers and third parties are affected, you have no window left to report. Scope discovery is the tax that eats the clock. A dependency nobody documented, or a redundant path that had quietly stopped being redundant months ago, turns a scoped incident into a scramble against a four-hour deadline.

• Blast radius on demand (Articles 17-23): make “what does this asset touch” a query you can run in minutes, so the four-hour window is spent writing the report, not reconstructing the map.

DORA Register of Information: Avoid sending one that rots before you send it

Article 28 asks for something that sounds administrative and is really a data problem. You must maintain a structured, continuously updated Register of Information on all contractual arrangements with ICT third-party service providers, available for inspection and submitted annually.

The trap is treating the Register as a spreadsheet compiled once, ahead of the submission. It drifts within weeks. A provider changes, a service moves, or a contract renews, and the version you hand a regulator no longer matches reality. A spreadsheet that rots is not evidence.

• Turn the Register into live data (Article 28): model every ICT third-party arrangement, the provider, the service, the business function it supports, the contract and the exit strategy, so the Register stays queryable and current all year.
• See concentration risk before the regulator does (Article 28): once arrangements are modelled, surface which critical functions depend on which providers, and which providers sit behind several functions at once, so concentration and exit-strategy gaps show up as visible data ahead of any audit finding.

DORA Article 8: ICT Asset Classification Requirements: Traceable data

Article 8 requires you to identify, classify and document all ICT-supported business functions and ICT assets, and keep it up to date. “Kept up to date” is the hard part. A picture that is accurate at audit time and rotted by week three fails the standard by design.

The infra reality is drift you already recognise: a duplicate IP nobody reconciled, a decommissioned circuit still marked “live” in the record, a shadow SaaS instance quietly running part of a payment function. Worse, the map of which ICT assets support which business function usually lives as tribal knowledge, not as evidenced, queryable data. Tribal knowledge does not survive an inspection or a 2am incident.

• Make critical business functions traceable (Article 8): map every ICT-supported business function to the assets, circuits and dependencies that serve it, end to end, so it becomes data you can query. This is the same map that makes the incident clock and the Register achievable.

DORA testing stops being a once-a-year event

Articles 24-27 require a digital operational resilience testing programme. Entities designated significant must also undergo Threat-Led Penetration Testing, a controlled attack simulation against live systems, at least every three years (the TLPT basis is Article 26). TLPT puts a real adversary against your production estate, which only holds up if your picture of that estate is accurate.

So teams rebuild a picture of intended versus actual state from memory and screenshots once a year, ahead of the audit. It is expensive, stale by the time it is compiled, and blind to everything that changed in between.

The shift worth naming is that compliance is running continuously. A picture that is true once a year, at audit time, no longer clears the bar DORA sets. Resilience has to be demonstrable at any moment, and the gap between intended and observed state is exactly what testing is meant to surface. This is where the whole discipline is heading, well beyond any single vendor.

• Replace the scramble with continuous evidence (Articles 24-27): detect drift between intended and observed state as it happens, a duplicate IP, a dropped redundancy, an unauthorised change no one logged, so control evidence accumulates continuously instead of being manufactured under deadline.

The thread running through every moment: a system of record

Look back at the four moments. The clock, the Register, the business-function map, and continuous testing are four faces of one requirement: a system of record for the ICT estate that underpins your business services. Each goes badly when the estate cannot be seen accurately.

For leaders, the first governance question is not “are we compliant” but “can we produce, on demand, the map that every one of these obligations assumes.” If the answer is no, that is the item to fund before any policy work. Management bodies are personally accountable for the ICT risk framework, so this sits with the board.

DORA leaves much of the administrative penalty regime to national authorities; the commonly cited headline is up to 2% of total annual worldwide turnover for financial entities. Critical ICT third parties under the oversight regime face periodic penalty payments up to 1% of average daily worldwide turnover, levied daily for up to six months. These are facts to plan against.

The practical order is the one this piece has followed: inventory and dependency mapping first, then the moments become manageable. The estate you can see is the one you can report on, test, and defend.

The capability that makes the moments manageable

Three capabilities carry the weight, and they are worth thinking about as needs before products. The first is a system of record: an authoritative, queryable model of the ICT estate covering assets, sites, services, dependencies, ownership and classification. This is what the NetBox Labs platform provides, and it answers the Article 8 inventory and the Article 28 Register. The second is continuous discovery: agent-based and agentless discovery that ingests live state and reconciles it against the intended model, feeding continuous identification and detection (Articles 9-12). The third is continuous assurance, so the picture is not just accurate today but provably accurate over time.

That third piece is where NetBox Validation comes in, currently in public preview. Validation checks your estate against policy before a change ships, and it does so offline, against your NetBox data and rendered configs, with no access to the live network and no device credentials. It runs three engines, and each one lines up with a DORA moment:

• Intent checks (Articles 8, 24-27): cross-object, fleet-wide checks over your source of truth for redundancy, addressing, topology and security, with checks such as no_duplicate_ips, redundant_power and min_bgp_sessions. This is the completeness and classification evidence Article 8 asks for, produced continuously.
• Graph analysis (Articles 17-23, 24-27): builds a dependency graph of the estate to compute blast radius, single points of failure and shared failure domains. A failure point that touches ten or more devices escalates to critical on its own, which is the scoping you want the moment the incident clock starts.
• Config analysis (Articles 24-27): offline analysis of rendered device configs for reachability, routing loops, BGP compatibility and ACL correctness, including a differential check that catches lost reachability or a dropped redundancy before a change merges.

Every run produces a compliance score and tracks it over 7, 30 and 90 days, with findings you can export through the API. That turns resilience evidence into something that accumulates on its own, instead of a report assembled the week before an audit. There is also a ready-made NIS2 / DORA policy pack of 21 rules that maps the regulation’s controls to concrete checks, so you start from a working baseline instead of an empty policy set.

The industry point matters more than the vendor one. The move is from periodic, document-based compliance to continuous, data-based assurance, with both NIS2 and DORA pushing that way. What counts is a model of your estate that stays true, and can prove it.