DORA checklist & Article 24 requirements for resilience
The Digital Operational Resilience Act (DORA) is no longer a distant compliance deadline. It becomes fully enforceable in January 2025, and Article 24 is one of the most tangible, practical sections of the entire regulation. It deals with how financial institutions prove their operational resilience through systematic testing — not policies, not statements, but repeatable, evidence-based exercises.
The logic is simple: regulators have seen too many firms describe their resilience in documentation that collapses when tested in practice. DORA changes that dynamic. Article 24 pushes financial entities to prove they can withstand disruptions by building a structured, risk-based testing program that covers their critical systems and third-party dependencies.
What Article 24 actually requires
According to the European Commission Article 24 mandates that all financial entities must establish a “digital operational resilience testing programme.” This testing must be proportionate to the entity’s size, business, and risk exposure - but the principle applies to everyone, from the largest bank to smaller regulated intermediaries.
The rule expects testing to move beyond simple penetration tests or continuity drills. Financial entities are required to conduct “advanced testing” for critical or important functions at least once a year. The testing must be independent, meaning it cannot be conducted by the same people who maintain or manage the systems being tested. CIF – understanding critical or important functions under DORA
In short: Article 24 wants firms to prove their defenses hold up under pressure, not just on paper.
Building a compliant DORA checklist
A practical DORA checklist helps convert the regulation’s broad wording into operational steps. These are the cornerstones that most institutions are working through now:
1. Define your scope.
Identify the ICT systems, applications, and data flows that support your critical or important functions (CIFs). Without this mapping, your testing plan will be incomplete.
2. Classify the functions correctly.
Tie your DORA testing requirements to the CIF definitions under Articles 28 and 30. This ensures the testing program is risk-based and aligned with business continuity priorities.
3. Establish testing frequency.
According to the European Banking Authority, critical systems must be tested annually, but additional event-driven tests are expected after material ICT changes or major incidents.
4. Ensure independence.
Internal testing teams often face conflicts of interest. Article 24 expects independent assurance, either through separate governance lines or certified third-party testers.
5. Record, report, and remediate.
Testing without documentation is meaningless. Every test must produce actionable reports, risk ratings, and evidence of remediation within reasonable timelines.
6. Link results to governance.
Boards and risk committees need visibility into resilience outcomes. Article 24 expects these findings to feed directly into the management body’s ICT risk oversight.
A good checklist isn’t just for auditors; it’s for operations. It creates a feedback loop where testing actually drives improvements, not bureaucracy.
Why this requirement matters
DORA’s testing requirement is the first time the EU has made resilience testing a legal obligation across the financial sector. It’s not a “best practice” suggestion — it’s regulatory law. The reasoning is pragmatic. Financial systems are now too interconnected, too digitized, and too dependent on shared technology providers to rely on assumptions. DORA RTS – regulatory technical standards
In recent years, operational disruptions — whether from cyberattacks, system failures, or vendor outages — have shown how fragile digital continuity can be. Regulators want proof that institutions can operate through disruption without jeopardizing consumers or markets. Article 24 gives them that proof.
The industry’s challenge: turning testing into insight
For many institutions, the real challenge is not running the tests — it’s making sense of the results. In complex environments with hybrid IT, cloud vendors, and outsourced data processors, even defining “independent testing” becomes complicated.
Some banks are adopting layered testing programs that combine automated penetration testing, red teaming, scenario-based simulation, and third-party audits. Others are leveraging risk-scoring models to prioritize which systems should be tested first.
Testing under Article 24 isn’t meant to be exhaustive — it’s meant to be intelligent. It should focus on systems whose failure would cause the most business or consumer harm.
What happens if you fail to comply
According to the European Commission’s enforcement guidance, failure to establish a compliant testing program can result in administrative penalties, restrictions on operations, and public sanctions.
Supervisory authorities in each Member State will assess readiness as part of broader DORA implementation. Firms that can’t demonstrate a structured testing process — supported by documented results and remediation — are likely to face regulatory intervention.
Beyond the regulatory risk, there’s reputational exposure. A single incident revealing weak resilience practices can erode trust faster than any fine.
“The difference between a compliant and a non-compliant firm under DORA will come down to evidence. Can you show that your tests were independent, meaningful, and acted upon? If not, you’re only simulating resilience.”
– Mark Medum Bundgaard, CPO, Partisia
This captures the spirit of DORA’s testing rule: it’s about proof of capability, not paperwork.
How DORA testing links to broader resilience goals
Article 24 doesn’t stand alone. It’s one of five core pillars of DORA, alongside ICT risk management, incident reporting, third-party risk, and information sharing. Testing is the mechanism that connects all of them. A robust testing framework verifies the adequacy of ICT risk controls, validates incident response readiness, and ensures that outsourced providers meet equivalent standards.
Firms that approach testing as a siloed task will struggle. Those that integrate it into their governance and vendor risk processes will gain both compliance and operational maturity.
Partisia’s perspective
Operational resilience depends on secure, verifiable collaboration across systems and partners. The complexity of testing critical or important functions often comes down to data access — who can share what information safely, without breaching privacy or compliance rules.
This is where Partisia’s privacy-preserving data collaboration technology becomes directly relevant. Using Multi-Party Computation, Partisia enables multiple parties to run computations on sensitive operational or testing data without exposing the raw data itself. That allows institutions to conduct cross-organisational resilience simulations, vendor risk assessments, and compliance validations in a privacy-safe way.
Instead of relying solely on self-reporting from vendors or third-party testers, financial institutions can use MPC-based methods to verify resilience results securely. This supports DORA’s intent: transparent, evidence-based assurance without compromising security or confidentiality.
For financial entities preparing for DORA Article 24, the goal should be resilience built on verifiable data — and privacy-preserving technologies like MPC provide the foundation for achieving it.
Start the conversation on secure data collaboration
Looking to explore how privacy-first technologies can strengthen your AML efforts and support compliance. Get in touch with our team to learn how Partisia’s platform can help you collaborate securely while staying fully compliant.
