Choosing tools for DORA work
Software can organise registers, evidence and technical findings. Choose it around the decisions, data and responsibilities in your DORA programme.
The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.
Tools can make DORA work easier to maintain: contracts can be linked to functions, findings can receive owners and evidence can be retrieved for review. The useful question is which part of the programme needs support.
Start with the applicable obligations. A product shortlist made before that assessment risks buying features for the wrong scope.
Identify the records that need control
The ICT agreement register needs consistent identifiers and relationships. Incident records need timestamps, classification decisions and updates. Testing records need coverage, findings and verification.
A controlled spreadsheet may suit a small, stable dataset. A dedicated system may help when several people maintain interdependent records or changes are frequent. Evaluate access control, validation, history and export, not just the dashboard.
Use Finanstilsynet’s DORA resources to check the required outputs. A vendor’s claim to support DORA does not prove that its export matches the current submission format.
Connect technical evidence to its purpose
Asset and vulnerability tools can support identification and assessment. Detection platforms can provide incident evidence. Testing tools can contribute to the resilience programme.
Each input has limitations. An asset inventory can omit an unconnected environment; an alert may require validation; a successful scan does not demonstrate every resilience requirement. Record those limitations so the evidence is used accurately.
The testing article explains why automated testing and TLPT are not interchangeable.
Keep accountability visible
DORA places responsibility for ICT risk with the financial entity and its management body under the applicable rules. Software can support decisions about critical functions, supplier dependencies and incident classification. It does not transfer accountability to the tool vendor.
The same applies when tasks are outsourced. Agree who maintains the information, who reviews it and who authorises the result. A provider can assist with reporting while the entity remains responsible.
Evaluate an ordinary working day
Ask the proposed system to handle a supplier change, an overdue finding and an incident update using representative information. Can the right owner make the change, can another person review it, and can the firm retrieve the history?
Then check export and exit arrangements. The programme should remain understandable if the software or consulting provider changes. FM’s DORA advisory service can help define the requirements before a purchase decision.