ARTICLES
DORA: the register is the exam
Firms prepare for DORA by buying tooling. The supervisor asks for a list — and the list is where it falls apart.
What is actually being asked for
DORA expects a register of information on every contractual arrangement for the use of ICT services: who the provider is, what function they support, whether that function is critical or important, where the data sits, and who they in turn depend on. It is maintained at entity level and it is reported.
None of that is a security control. It is bookkeeping — and it is the part almost nobody has, because it cuts across procurement, legal and IT, and no single one of those three owns it.
The clause nobody negotiated
DORA also expects contractual rights: audit and access, a defined exit, incident notification, and service levels for functions that matter. Most existing contracts were signed before any of that was required, and renewing them is slow work that has to start long before the auditor asks.
The uncomfortable case is the provider who will not agree. That is not a procurement problem to defer — under DORA it is a concentration risk you now have to document and decide about.
Where testing comes in, and where it does not
Threat-led penetration testing applies to the larger entities, not to everyone, and it is the part most vendors lead with because it is the part they sell. For most firms the binding work is the register and the contracts; the testing programme follows from knowing which functions are critical, and cannot sensibly be scoped before that.
If someone quotes you a DORA testing engagement before asking for your register, they are selling you the exam without the syllabus.