RTS AND ITS SUPPLEMENTING DORA

What RTS and ITS are, and why there are twelve of them

Regulation (EU) 2022/2554 (DORA) has 64 articles and in a number of places it does not say exactly how an obligation is to be met — instead it empowers the European Supervisory Authorities to draft a technical standard and the Commission to adopt it. Those standards come in two forms. A regulatory technical standard (RTS) is adopted as a Commission delegated regulation and specifies the content of the obligation. An implementing technical standard (ITS) is adopted as a Commission implementing regulation and lays down uniform forms, templates and procedures.

The practical difference is smaller than it looks: in both cases the result is a regulation, binding in its entirety and directly applicable in all member states. They are not rewritten into Czech law and there is no Czech implementing decree for them — they apply as they stand, and every language version in the Official Journal is equally authentic.

The quickest way to recognise what a standard deals with is its preamble. Right at the beginning comes the phrase "having regard to Regulation … and in particular Article X thereof", and that article is the empowerment, that is the answer to the question which part of DORA the standard fleshes out. The overview below states it for every standard, because it is the only reliable guide — the titles are long and similar to one another.

As of 9 August 2026 twelve such acts exist. Ten of them are delegated regulations and two are implementing regulations (ITS) — 2024/2956 and 2025/302. Two of those ten, 2024/1502 and 2024/1505, are not RTS in the narrow sense: they are delegated acts the Commission adopts directly under DORA, not on the basis of a draft standard from the European Supervisory Authorities. Two standards stem from the same empowerment and one satisfies two empowerments at once, so the number of empowering provisions and the number of standards do not match.

• RTS = delegated regulation. It specifies the content of the obligation — what has to be assessed, what a policy has to contain, which conditions have to be met. Ten of the twelve acts take this form.
• ITS = implementing regulation. It lays down a uniform format — the templates for the register of information and the forms for incident reporting. There are two: 2024/2956 (register of information) and 2025/302 (incident reporting).
• The empowerment is in the preamble. The phrase "and in particular Article … thereof" tells you which part of DORA the standard fleshes out. Without it, titles this similar cannot be told apart.
• They apply directly. None of the standards is transposed into Czech law; Czech legislation covers only what the regulation leaves to member states, namely the designation of the supervisory authority and penalties.
• The date of publication is not the date of application. Most standards enter into force on the twentieth day following publication and set no separate date of application. The obligations themselves follow from DORA, which applies from 17 January 2025 (Article 64).
• Not every empowerment leads to a regulation. Article 11(11) of DORA requires the European Supervisory Authorities to draw up joint guidelines on the estimation of aggregated annual costs and losses caused by major incidents. Guidelines are not a regulation and therefore do not appear in this overview as a thirteenth standard.

To keep track of who has to do what, it helps to split the standards into three groups, which is also how this page is structured: what a financial entity has to manage internally (risk management, incidents, testing), what it has to settle with its providers (policy, register, subcontracting) and what concerns only the oversight of critical providers. Of the twelve standards, three touch ICT providers in practice.

ICT risk management: Regulation 2024/1774

Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 is the longest and most detailed of the twelve. It specifies ICT risk management tools, methods, processes and policies, and at the same time the simplified ICT risk management framework. It is unusual in satisfying two empowerments at once: the fourth subparagraph of Article 15 and the fourth subparagraph of Article 16(3) of DORA. A single act therefore covers both the full and the simplified regime.

Its structure mirrors the way risk management is divided in practice. After an opening article on the overall risk profile and complexity comes the part on the full framework, with chapters on ICT security policies and tools, on human resources and access control, on detection of and response to incidents, on ICT business continuity management and on the report reviewing the framework. The second part then covers the same topics for the simplified framework, in chapters of its own and with its own review report.

For practical use the important point is that this standard reads as a catalogue of requirements: its articles correspond to areas that are standard in security frameworks — asset management, encryption and key management, vulnerability and patch management, logging, network security, change management, physical security, identity management and access control, testing of business continuity plans. If you already run an information security management system, you are mostly dealing with the differences, not building on a greenfield site.

• Who it applies to: financial entities. The full framework applies to entities outside the simplified regime, the second part of the standard to entities under Article 16(1) of DORA.
• What it means for providers: indirectly, quite a lot. Requirements on security, change management and continuity feed from this framework into security questionnaires and into the contractual provisions under Article 30(3)(c) of DORA.
• Where it is most often underestimated: the report reviewing the framework. The standard sets its format and content in separate articles for the full and for the simplified framework — it is not free text.
• Link to testing: the digital operational resilience testing programme under Article 24 of DORA is part of the risk management framework, not a separate discipline. Threat-led testing under Article 26 is then its most demanding part and is governed by a standard of its own.

The simplified framework is not the same thing as an exemption. The standard gives it a complete set of requirements of its own — governance and organisation, an information security policy, asset classification, access control, operations security, ICT security testing, project and change management, and business continuity plans including their testing. Smaller in scope, same logic.

Incidents: Regulations 2024/1772, 2025/301 and 2025/302

Incident reporting is covered by three standards, and it is worth knowing which one answers which question. Delegated Regulation (EU) 2024/1772 of 13 March 2024, adopted under the third subparagraph of Article 18(4) of DORA, answers "is it major?". It specifies the criteria for the classification of ICT-related incidents and cyber threats, sets out materiality thresholds and specifies the details of reports of major incidents.

The criteria are broken down in the individual articles into measurable quantities: clients, financial counterparts and transactions affected, reputational impact, duration of the incident and service downtime, geographical spread, data losses, criticality of the services affected and economic impact. They are followed by the articles on major incidents and on materiality thresholds, and separately by the high materiality thresholds for determining significant cyber threats.

Delegated Regulation (EU) 2025/301 of 23 October 2024, adopted under the third subparagraph of Article 20 of DORA, answers "what is sent and when". It sets the content of the initial notification and of the intermediate and final reports, the content of the voluntary notification of significant cyber threats, and the deadlines: the initial notification as soon as possible and in any event within four hours of classifying the incident as major, and no later than 24 hours from the moment the entity became aware of the incident; the intermediate report no later than 72 hours after the initial notification; the final report no later than one month after the intermediate report or after its last update.

Implementing Regulation (EU) 2025/302 of the same date, adopted under the fourth subparagraph of Article 20, answers "on what form and how". It contains the template for reporting major incidents and the procedures: submitting several reports at once, recurring incidents, the use of secure electronic channels, reclassification of an incident, notification that reporting has been outsourced, aggregated reporting and the notification of significant cyber threats.

• Who they apply to: financial entities. The report is submitted by the entity, not by the provider — the provider enters the process through the contractual obligations under Article 30 of DORA.
• The order in which they are used: first 2024/1772 (is the incident major?), then 2025/301 (what goes into the report and by when), then 2025/302 (on which form and through which channel).
• The weekend relief and its exception: where a deadline falls on a weekend or a public holiday, the report may be submitted by noon of the following working day at the latest — but for credit institutions, central counterparties, operators of trading venues and other entities considered essential or important under Directive (EU) 2022/2555, that relief does not apply to the initial notification and the intermediate report.
• Reclassification is anticipated. Where an entity does not classify an incident as major within 24 hours of detecting it and does so later, it submits the initial notification within four hours of that later classification.
• Outsourcing the reporting is possible, but it has to be notified — the implementing regulation has a separate article for it. Responsibility for discharging the obligation does not pass with it.
• What it means for providers: the deadlines in addenda are not arbitrary. The demand for reporting within hours exists because the customer is running a four-hour and a 24-hour deadline that it cannot meet without information from you.

The decision tree for classifying an incident and calculating the deadlines is covered separately in this category, on the page about incident classification and reporting deadlines. This overview only answers the question which act governs which part of the process.

Providers and contracts: Regulations 2024/1773, 2024/2956 and 2025/532

For ICT providers this trio is the most important part of the whole overview, because it is where most of what turns up in contract addenda and security questionnaires comes from.

Delegated Regulation (EU) 2024/1773 of 13 March 2024, adopted under the third subparagraph of Article 28(10) of DORA, specifies the detailed content of the policy on contractual arrangements on the use of ICT services supporting critical or important functions. It has eleven articles: governance arrangements, the main phases of the life cycle of contractual arrangements, ex ante risk assessment, due diligence, conflicts of interest, contractual clauses, monitoring of the arrangements and their termination. It is an internal policy of the financial entity — but it is precisely its article on contractual clauses that determines what the other side will want in the contract and by which methods it will verify that it holds.

Implementing Regulation (EU) 2024/2956 of 29 November 2024, adopted under the second subparagraph of Article 28(9), lays down the standard templates for the register of information. Seven articles and four annexes; Annex I contains fifteen interlinked templates, Annex II the licensed activities by type of entity, Annex III a closed code list of ICT service types with the codes S01 to S19 and Annex IV the instruction for reporting total assets. This is where most of the "administrative" questions put to providers come from: the legal entity identifier, the countries where the service is provided, the rank in the supply chain.

Delegated Regulation (EU) 2025/532 of 24 March 2025, adopted under the fourth subparagraph of Article 30(5), is the youngest of the three and the toughest in its effects. It has seven articles and specifies what a financial entity has to determine and assess when subcontracting ICT services supporting critical or important functions: the elements of proportionality including the length and complexity of the chain, application within a group, due diligence and risk assessment before the contract is concluded, the conditions that have to be in the contract, the regime for material changes to subcontracting arrangements and the grounds for terminating the contract.

• 2024/1773 — who it applies to: financial entities other than those in the simplified regime under Article 16(1) and other than microenterprises. It reaches providers indirectly but forcefully: it determines the verification methods, that is audits, joint audits, certifications and audit reports, and the conditions under which they may be used.
• 2024/2956 — who it applies to: all financial entities that keep a register of information. The provider reports nothing in it itself, but without its data the register cannot be assembled.
• 2025/532 — who it applies to: financial entities in contracts covering critical or important functions. For a provider it is the source of requirements to identify subcontractors, to pass audit rights and continuity requirements down into subcontracts, and to have material changes approved.
• The single most painful rule: unauthorised subcontracting of a critical or important function is, under 2025/532, a standalone ground for terminating the contract. The authorisation has to be explicit in the contract.
• Ultimate responsibility does not transfer. Relying on the assessments providers carry out on their own subcontractors does not limit the responsibility of the financial entity for complying with its obligations under DORA. That is why evidence is required, not declarations.
• Where you meet all three together in practice: in the contract addendum. An analysis of the individual provisions from the provider point of view is covered separately in this category, on the page about the Article 30 contract addendum.

The order in which these three standards hit a provider is usually the reverse of the order in which they came about: first arrives the questionnaire (input for the due diligence under 2024/1773), then the table of data for the register (2024/2956) and finally the addendum with the subcontracting provisions (2025/532). Knowing that in advance, you can prepare the material once and use it three times.

Threat-led penetration testing: Regulation 2025/1190

Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, adopted under the fourth subparagraph of Article 26(11) of DORA, governs threat-led penetration testing, known in practice as TLPT. It has seventeen articles and eight annexes setting out the content of the individual documents — the project charter, the scope specification document, the targeted threat intelligence report, the red team test plan and the red team test report, the blue team test report, the report summarising the findings under Article 26(6) of DORA and the attestation under Article 26(7).

The first thing to do is to tell TLPT apart from an ordinary penetration test. Under Article 3, point (17) of DORA it is a framework that mimics the tactics, techniques and procedures of real-life threat actors and delivers a controlled, bespoke, intelligence-led test of the critical live production systems of a financial entity. Under Article 26(2) the test is carried out on systems actually in live production use, covers several or all critical or important functions, and its scope is validated by the competent authorities.

The standard sets out which entities have to be tested — the criteria are split into impact-related and systemic factors (size, interconnectedness, importance and substitutability of the services, complexity of the business model) and ICT risk factors (risk profile, threat landscape, reliance of critical functions on ICT, complexity of the architecture, extent of services taken from third parties, results of supervisory reviews, maturity of continuity plans and of detection capabilities). Under Article 26(1) of DORA the test is carried out by identified entities at least every three years, and the competent authority may lower or raise that frequency according to the risk profile.

For planning, one figure matters most: under Article 11(5) the active red team testing phase lasts in any event at least twelve weeks, and its length is proportionate to the scope of the test and to the number of entities and providers involved. Any limited purple team testing, which may be moved to in exceptional circumstances with the prior approval of the TLPT authority, counts towards that minimum period.

• Who it applies to: financial entities identified for testing by the competent authority under Article 26(8) of DORA; under Article 26(1) of DORA the obligation does not apply to entities in the simplified regime under the first subparagraph of Article 16(1) or to microenterprises.
• What it means for providers: under Article 30(3)(d) of DORA, a contract covering a critical or important function has to include the obligation to participate in the testing and to cooperate in it fully. Participation is therefore not voluntary, and it is not half a day of assistance.
• Responsibility stays with the entity. Under Article 26(3) of DORA, where providers are involved the financial entity takes measures to ensure their participation and retains full responsibility for the test.
• Pooled testing is the answer for shared platforms. Under Article 26(4) of DORA, where there is a risk of an adverse impact on the quality or security of services delivered to customers falling outside the scope of DORA, several financial entities may agree in writing on pooled testing led by one of them; such a test counts as performed by all the participants.
• Internal testers only under conditions. The standard requires a policy for managing internal testers ensuring that the team has a lead member and at least two further members, and that all of them have been employed by the financial entity, or by an intra-group ICT service provider, for the preceding twelve months.
• One test in three has to be outsourced. Under Article 26(8) of DORA, an entity using internal testers has to contract an external tester for every third test; credit institutions classified as significant under Regulation (EU) No 1024/2013 may use external testers only.
• The threat intelligence provider has to be external in every case, including where the testing is done by internal testers (Article 27(2) of DORA). The requirements on testers — reputation, demonstrable expertise, certification or a code of conduct, independent assurance of risk management and professional indemnity insurance — are in Article 27(1).

Twelve weeks of active testing is a figure both sides do well to know. For the financial entity it is a planning constraint; for a provider inside the scope it is a capacity commitment that makes no sense to promise without thinking it through — which is why a contract addendum is better used to settle the conditions of participation than merely consent to it.

Oversight of critical providers: 2024/1502, 2024/1505, 2025/295 and 2025/420

The last group concerns neither an ordinary financial entity nor an ordinary provider. It governs the framework in which the European Supervisory Authorities designate ICT service providers as critical for the financial sector and exercise direct oversight over them.

Delegated Regulation (EU) 2024/1502 of 22 February 2024, adopted under Article 31(6) of DORA, specifies the criteria for designating critical providers. It has seven articles dealing with the approach to the assessment, the systemic impact of a failure on the stability, continuity or quality of the provision of financial services, the systemic character and importance of the services provided to financial entities, the criticality or importance of the functions supported, the degree of substitutability and the sources of information for the assessment. Under Article 31(7) of DORA no designation could take place before the Commission adopted this act.

Delegated Regulation (EU) 2025/295 of 24 October 2024 and (EU) 2025/420 of 16 December 2024 both stem from the second subparagraph of Article 41(2) of DORA and complement each other. The first harmonises the conditions for conducting oversight activities: the information in an application from a provider seeking voluntary designation as critical, the content and format of the information provided to the Lead Overseer, the information following a recommendation, and a separate template for providing information on subcontracting arrangements. The second specifies the criteria for determining the composition of the joint examination team, its establishment, the tasks of its members and the organisation of its work.

Delegated Regulation (EU) 2024/1505 of 22 February 2024, adopted under Article 43(2) of DORA, determines the amount of the oversight fees charged by the Lead Overseer to critical providers and the way in which those fees are paid — from the estimate of the expenditure of the authority, through the applicable turnover of the provider and the calculation of the fee, to the regime in the year of designation and for voluntary applications.

• Who it applies to: providers designated as critical, and the oversight authorities. For Czech software houses and providers operating nationally this is a scenario well out of reach.
• Who is excluded from designation: under Article 31(8) of DORA, financial entities providing ICT services to other financial entities, providers subject to oversight frameworks under Article 127(2) of the Treaty on the Functioning of the EU, intra-group ICT service providers and providers supplying services in one member state only to entities operating in that state alone.
• Voluntary designation is possible. Under Article 31(11) of DORA a provider not on the list may request designation itself; Regulation (EU) 2025/295 sets out what that request has to contain.
• Where the input comes from: the registers of information. Under Article 31(10) of DORA competent authorities transmit the reports under the third subparagraph of Article 28(3) annually and in aggregated form to the Oversight Forum, which assesses the dependence of financial entities on providers.
• Subcontracting shows up here too. Regulation (EU) 2025/295 contains a separate template for information on subcontracting arrangements — the same problem that Regulation (EU) 2025/532 handles for ordinary contracts is handled at the oversight level by a form.
• Oversight is paid for. The fees under Regulation (EU) 2024/1505 are borne by the critical provider, not by the financial entities that use its services.

The practical significance of this group for everyone else is indirect: designating a provider as critical changes the regime in which its operations are supervised and shapes the information financial entities receive about it. The obligations of a financial entity towards such a provider do not change, though — the contract under Article 30 continues to apply.

How to work with this overview and what is deliberately missing from it

Twelve standards look like a lot, but nobody is subject to all of them. A financial entity outside the simplified regime works mainly with Regulation 2024/1774 internally, with the incident trio in day-to-day operations, with the provider trio when purchasing, and with the testing standard if it has been identified for testing. An entity in the simplified regime has a smaller scope, but not a zero one. An ICT provider meets three of them in practice: 2024/1773 through questionnaires, 2024/2956 through the data for the register and 2025/532 through the subcontracting provisions.

When reading a particular standard it pays to start at the end of the preamble, that is with the empowering article, and only then move on to the text. The empowerment tells you which question the standard answers, and thereby whether it is relevant to you. The second useful habit is not to rely on the title: the titles are long, they contain the same phrases and telling them apart from memory is practically impossible. The number and the year are more reliable.

Two things are deliberately missing from this overview. The first is the joint guidelines of the European Supervisory Authorities. Article 11(11) of DORA does not require a technical standard but joint guidelines on the estimation of aggregated annual costs and losses caused by major incidents, which entities other than microenterprises report to competent authorities upon request under Article 11(10). Guidelines have a different legal status from a regulation and do not belong among the accompanying standards.

The second is the Czech adaptation. DORA and the accompanying standards apply directly; what is left to member states is the designation of the competent authority and penalties. So do not look for those in the technical standards but in Czech legislation — the guide to the regulation in this category will get you oriented.

• Financial entity under the full regime: 2024/1774 internally, 2024/1772, 2025/301 and 2025/302 for incidents, 2024/1773, 2024/2956 and 2025/532 with providers, 2025/1190 once identified for testing.
• Entity in the simplified regime: the part of standard 2024/1774 devoted to the simplified framework, plus the incident trio; the policy on contractual arrangements under 2024/1773 does not apply to entities under Article 16(1) of DORA or to microenterprises.
• ICT provider: 2024/1773 (where the questionnaires and verification methods come from), 2024/2956 (what data about you the customer needs) and 2025/532 (what will be in the contract about subcontracting). The rest is for orientation.
• Critical provider: 2024/1502, 2025/295, 2025/420 and 2024/1505; the other standards reach it through contracts in the same way as anyone else.
• Check that it is current. This overview is a snapshot as of 9 August 2026. Accompanying standards may be added or amended; the most reliable check is the list of related documents for Regulation (EU) 2022/2554 on EUR-Lex.
• Do not confuse them with NIS2. The technical standards under DORA are directly applicable EU regulations. The implementing rules under the Czech Cybersecurity Act are Czech decrees with a different scope and a different addressee — the overlap of the two regimes is covered in a separate section of the guide.

One practical note on dates. For most standards it holds that they enter into force on the twentieth day following publication and set no separate date of application — but the obligation itself comes from DORA, which applies from 17 January 2025. The fact that a standard appeared later than that date therefore does not mean the obligation is postponed; it means that until the standard was issued, the obligation was met directly under the text of the regulation.

When the individual standards were published

Dates of publication in the Official Journal. The order shows how the framework was filled in — and why, in the first year DORA applied, some areas had to be handled directly under the text of the regulation, before a technical standard existed for them.

Official sources

The numbers, titles and empowering articles on this page are taken from the wording of the individual acts in the Official Journal, as of 9 August 2026. The links lead to the full text on EUR-Lex.