The ICT third-party register: the DORA duty that even NIS2-ready firms are unprepared for
DORA has applied since January 2025 and demands more than good contracts: a complete register of all ICT services, linked to functions, criticality and exit plans. Why this goes beyond NIS2 supply-chain work, what a living register looks like, and why contracts alone are not enough.
Many firms have completed their NIS2 supply-chain work and assume DORA is covered too. That is an expensive mistake. For the financial sector, DORA requires a register of ICT third parties at a level of detail that NIS2 does not even ask for. The regulation has applied since 17 January 2025.
What DORA actually requires
At its core sits a register of all contractual arrangements for ICT services (Article 28). This register is more than a list of contracts. For each provider it captures which function it supports, whether that function is critical or important, which subcontractors sit behind it, and what an exit would look like. Add to that the reporting of major ICT incidents and digital operational resilience testing.
Why contracts alone are not a register
A folder full of contracts does not answer the question that counts in a crisis: what happens to our critical function if this provider fails? A register lives on the links between contract, provider, supported function, criticality, risk and exit plan. Only this chain makes concentration risk visible, for instance when three critical functions depend on a single provider. Without the chain you cannot see it and cannot act when it matters.
Why NIS2 work is not enough
NIS2 supply-chain security mainly asks: is the supplier secure? DORA additionally asks: what does this provider contribute to our critical functions, and how do we get out again? A different level of detail, a different reporting logic, and its own register obligation. Whoever has done NIS2 has a good basis but not yet the DORA register.
How isidaten implements this
In isidaten the building blocks of the register sit on one shared object base: providers and processors, contracts with type, status and deadlines, and the associated risks. Because everything hangs off the same object, the register emerges as a by-product of data you maintain anyway rather than a separate exercise. Incidents and deadlines reference the same providers. How this looks for DORA we show on the DORA solution page, or directly in a demo.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.