DORA RTS – regulatory technical standards

What the RTS are and why they matter

According to the European Banking Authority (EBA), the RTS are detailed rules designed by the European Supervisory Authorities (EBA, ESMA, and EIOPA) to clarify how financial entities must implement DORA. Each standard focuses on a specific area: ICT risk management, incident classification, third-party oversight, and resilience testing.

The RTS make DORA enforceable. Without them, firms would have too much interpretive freedom, and compliance would be inconsistent. The standards remove ambiguity and establish a baseline for what “good” looks like in operational resilience.

They are legally binding once adopted by the European Commission and published in the Official Journal of the EU. Financial entities are expected to align their governance, controls, and documentation directly with these standards.

Key RTS under DORA

The RTS are spread across multiple articles of the regulation. The most significant for banks and financial institutions include:

ICT Risk Management (Articles 15–16)

The RTS require financial entities to establish a documented ICT risk framework that covers governance, asset management, incident prevention, and recovery. This framework must be updated continuously and reviewed at least annually. It must also include a clear definition of roles and accountability across IT, operations, and compliance.

Incident Classification (Article 20)

Incidents must be classified based on quantitative and qualitative thresholds such as service downtime, data loss, and business impact. According to the European Commission’s consultation papers,  this standard is critical for harmonizing how firms report and manage disruptions across the EU.

Resilience Testing (Article 24)

The RTS clarify how advanced testing programs must be structured. They define independence, testing frequency, and the process for validating remediation results. This is directly connected to Article 24 requirements discussed in Partisia’s earlier blog on DORA testing. DORA checklist & Article 24 requirements for resilience

Third-Party Risk (Article 28)

Perhaps the most challenging RTS for institutions, Article 28 outlines how firms must classify, manage, and monitor ICT third-party providers. It also defines what constitutes a “critical or important function” and how to ensure exit strategies, audit rights, and shared responsibility models are embedded in contracts. CIF critical – understanding critical or important functions under DORA

According to the EBA’s regulatory policy documents,  this RTS directly aligns with prior EBA outsourcing guidelines but introduces stricter obligations and EU-level oversight for critical providers.

The difference between RTS and ITS

It is common to see both RTS and ITS mentioned in DORA. RTS are the binding regulatory requirements, while Implementing Technical Standards (ITS) describe how entities should report data to regulators. The ITS support the RTS by ensuring consistency in supervision and reporting.

For example, if the RTS require firms to classify incidents, the ITS specify how that classification must be submitted to authorities. Together, they form the operational rulebook regulators will use to evaluate compliance.

How financial institutions should approach RTS alignment

The RTS are not documents to be filed away. They are the checklist auditors and supervisors will use to assess compliance maturity. The practical approach should include:

1. Conduct a regulatory mapping exercise.
Identify which RTS apply to your business model. Not every institution faces identical requirements. A retail bank’s exposure will differ from that of an insurance firm or payment processor.

2. Update your risk management framework.
Align terminology and metrics with those used in the RTS. Replace internal definitions with regulatory ones where appropriate. Regulators will expect consistency.

3. Integrate RTS obligations into existing governance.
This includes updating ICT risk policies, third-party risk frameworks, and testing protocols. It should not be treated as an isolated compliance project.

4. Audit existing contracts.
The RTS on third-party management require firms to insert clauses that reflect DORA’s new rights and obligations, including access, audit, and termination terms. Contracts that do not meet these standards will need renegotiation.

5. Document everything.
Each RTS calls for demonstrable evidence. This means maintaining logs, minutes, risk registers, test reports, and board oversight documents.

Common challenges

The RTS introduce complexity in both interpretation and implementation. Some firms struggle to reconcile the RTS with existing national regulations, especially where legacy guidelines such as the EBA’s outsourcing framework already apply. Others face the practical challenge of scaling risk assessments across hundreds of third-party suppliers.

There is also concern around resource constraints. Independent testing and contract reviews require skilled personnel who understand both IT and regulatory risk. Many institutions are turning to consortium-based models to share knowledge and testing capabilities across entities.

The regulatory timeline adds further pressure. While the RTS are designed to be proportionate, smaller institutions often lack the compliance infrastructure to meet the technical documentation requirements on time.

“DORA’s technical standards are where the regulation becomes tangible. They remove the wiggle room that firms used to have under fragmented national rules. The EBA is not looking for box-ticking. It’s looking for evidence that institutions have operational resilience built into their systems, not around them.”
– Mark Medum Bundgaard, CPO, Partisia

This sentiment is widely shared across the industry. The RTS make it clear that resilience must be measurable, traceable, and consistently reported.

How RTS fit into the broader DORA framework

Each RTS corresponds to one of DORA’s five pillars. Together they create a holistic structure: ICT risk management defines control expectations, testing validates performance, incident classification supports transparency, and third-party oversight closes the loop.

Financial institutions that implement these standards effectively will not only meet DORA’s legal requirements but also strengthen their digital risk posture in a measurable way. Those that treat RTS compliance as an isolated exercise will find themselves caught off guard during supervisory inspections in 2025.

Partisia’s perspective

DORA’s RTS highlight the growing need for transparency, verification, and shared accountability across complex digital ecosystems. Compliance depends on accurate data exchange between financial entities, regulators, and third-party providers. Yet data sharing is often constrained by privacy and confidentiality obligations.

Partisia’s privacy-preserving data collaboration platform addresses this challenge directly. Through Multi-Party Computation (MPC), institutions can securely validate and exchange compliance data without revealing underlying sensitive information. This enables collaborative auditing, shared resilience testing, and independent validation that aligns with RTS expectations for independence and verification.

By combining secure computation with blockchain-based transparency, Partisia supports a model where compliance can be proven without exposing critical data. As RTS enforcement draws closer, this approach provides a practical, privacy-first method for meeting regulatory expectations and strengthening operational trust across the financial sector.

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.