Three areas are particularly important under DORA: governance, testable resilience, and ICT third-party risk management. These areas are connected. If the management body does not understand critical services, testing may be poorly prioritised. If third-party dependencies are hidden, recovery plans may not reflect operational reality.
From a governance perspective, responsibilities between technology, information security, risk, compliance, and business functions should be clear. The management body should monitor technology risk as part of enterprise and financial risk, not as an issue delegated entirely to the IT department. Important risk acceptances, open high-severity findings, and remediation plans should be documented and reported.
Testing should answer a practical question: when a critical service is disrupted, how will the organisation continue and recover within an acceptable timeframe? This goes beyond checking whether backups exist. Recovery time, data-loss tolerance, manual procedures, communication plans, and supplier support should be tested together.
Third-party risk requires both contractual and operational analysis. Service levels, incident notification, audit rights, subcontracting, data location, exit plans, and termination scenarios should be addressed clearly. Because DORA’s implementing acts provide further detail on compliance methods [3], contracts and control sets must be reviewed and kept current.
The true test of DORA is not whether an organisation can display a folder of documents during an audit. It is whether the organisation can continue critical services in a controlled manner during a serious disruption. DORA should therefore be managed as a learning system that connects technical controls to business impact.
# 4. NIS2