What the Digital Operational Resilience Act demands beyond documentation, and how to demonstrate executable continuity to regulators.
DORA's Article 11 addresses ICT business continuity management. Most compliance summaries stop at the documentation requirements — policies, plans, procedures. But the text goes further. Entities must ensure that critical functions remain operational or can be restored within defined timeframes.
This distinction matters enormously. A plan filed in a SharePoint folder that has never been executed is not continuity management — it is continuity theatre. DORA regulators, particularly those operating under the Joint Regulatory Technical Standards, are increasingly focused on the difference.
Many Finance and Operations teams have invested heavily in business continuity plans, BCPs, and recovery runbooks. The compliance team can produce a 200-page document on request. But when a major incident occurs — ransomware, cloud provider outage, key personnel unavailable — those documents cannot execute themselves.
Article 11 requires firms to identify critical functions, determine recovery time objectives, and ensure the organisation can actually meet them. This is not a documentation requirement. It is an operational readiness requirement.
DORA focuses on critical functions, not just IT systems. This means treasury payment execution, payroll runs, cash position reporting, and supplier settlement must each have a defined continuity path — independent of whether the ERP, TMS, or banking portal is available.
Recovery time objectives must be supported by actual working alternatives. A contingency that says “revert to manual processes” without defining those processes, who executes them, what data they need, and which controls apply — does not satisfy Article 11.
A common failure mode: staff cannot access the continuity procedures during an incident because those procedures are stored in the very system that is unavailable. Article 11 compliance requires that critical procedure access is itself resilient.
The technical standards under DORA require that firms can demonstrate, not merely assert, their continuity capability. Testing must go beyond tabletop exercises. Simulation-based testing — where teams actually work through critical processes under constrained conditions — produces the evidence regulators require.
For Finance functions, this means periodically running payment workflows, approval chains, and reporting processes as if primary systems were unavailable. Results — completion times, issues identified, corrective actions taken — must be logged.
Regulators asking about Article 11 compliance expect to see a coherent answer to a simple question: If your primary systems went down at 08:00 on a Monday, how would your Treasury team execute the day's critical payments?
The answer requires more than a policy. It requires an executable workflow, accessible data, defined roles, and evidence that the workflow has been tested and works. Organisations that can demonstrate this — with timestamped logs, tested procedures, and clear ownership — are materially better positioned in supervisory reviews.
Astran's AlwaysReady platform is designed specifically for this requirement: pre-built, tested continuity workflows for Finance and Treasury, accessible independent of production systems, with built-in simulation and evidence generation for regulatory purposes.