GUIDE TO THE DORA REGULATION

What DORA covers and when it started to apply

DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, better known by the name its acronym comes from — the Digital Operational Resilience Act. Being a regulation, it applies directly: nothing is transposed into Czech law and the obligations follow from the European text itself. Czech law only designates the supervisory authority and sets out the administrative offences.

The subject matter is not banking law but ICT risk. Article 3(5) defines it as any reasonably identifiable circumstance in relation to the use of network and information systems which, if it materialises, may compromise their security and produce adverse effects. The structure follows from that: risk management, detection and reporting of incidents, testing, the supply chain, sharing of information on threats. In practice this is an information security management system with hard, enforceable reporting deadlines and a regulated supply chain.

There are two dates and they get mixed up. The regulation was published in the Official Journal on 27 December 2022 and, under Article 64, entered into force on the twentieth day following publication, that is on 16 January 2023. The same article then provides that it applies from 17 January 2025. Until that day the regulation existed and was in force, but created no enforceable obligations — the two years were a transition period for getting ready.

An editorial trap: on its DORA page the Czech National Bank writes that the regulation entered into force on 17 January 2025, and its news item from the same day is headlined "The DORA Regulation takes effect". This is not a contradiction in substance, only a shorthand for the date of application — with a regulation, entry into force and application are two different things, whereas Czech acts are commonly described as taking effect. If the date is ever disputed, what decides is the wording of Article 64, not the wording on a website.

Who is in scope, who is excluded and who gets a lighter framework

The scope is a closed list. Article 2(1) enumerates the entities under points (a) to (u). Points (a) to (t) are collectively called "financial entities" (Article 2(2)); point (u) covers ICT third-party service providers. That difference in status matters: a provider sits inside the scope of the regulation but is not a financial entity, so most obligations do not reach it directly — they reach it through the contract. The exception is critical providers, who are overseen by the European Supervisory Authorities (see below).

The simplified framework under Article 16 is not a general exemption "for small entities" — it is a named list. It covers small and non-interconnected investment firms, payment institutions exempted under Directive (EU) 2015/2366, institutions exempted under Directive 2013/36/EU in respect of which the Member State has not exercised the option in Article 2(4), electronic money institutions exempted under Directive 2009/110/EC and small institutions for occupational retirement provision. Articles 5 to 15 do not apply to them; instead, the second subparagraph of Article 16(1) imposes eight obligations covering the cyber security minimum (in the list below).

The simplified framework lightens the load elsewhere in the regulation too: entities referred to in Article 16(1) are not subject to threat-led penetration testing (Article 26(1)) and do not have to adopt a separate strategy on ICT third-party risk (Article 28(2)).

A microenterprise, however, is not a synonym for the simplified framework. Microenterprises are not excluded from scope — the regulation merely narrows the requirements for them in a few places, for example in the testing programme (Article 24 and Article 25(3)), in threat-led penetration testing (Article 26(1)) or in the exercise of audit rights at a provider (last subparagraph of Article 30(3)). Everything else applies.

• Eight obligations instead of Articles 5 to 15 (second subparagraph of Article 16(1)). A documented ICT risk management framework including protection of physical components, continuous monitoring of the security and functioning of systems, sound, resilient and up-to-date systems and tools, prompt identification of sources of ICT risk and of anomalies, identification of key dependencies on ICT providers, business continuity plans with backup and recovery measures, regular testing of those plans, and feeding the conclusions from tests and post-incident reviews back into risk assessment, including staff training.
• Alongside banks and insurers, the list of financial entities in Article 2(1) also captures a number of smaller players who would not normally count themselves as "the financial sector".
• credit institutions, payment institutions (including those exempted under Directive (EU) 2015/2366), account information service providers, electronic money institutions (including those exempted under Directive 2009/110/EC)
• investment firms, trading venues, data reporting service providers, central securities depositories, central counterparties, trade repositories, securitisation repositories
• managers of alternative investment funds and management companies
• insurance and reinsurance undertakings, insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries, institutions for occupational retirement provision
• crypto-asset service providers authorised under the Markets in Crypto-Assets Regulation and issuers of asset-referenced tokens
• credit rating agencies, crowdfunding service providers and administrators of critical benchmarks — Article 2(1), point (r), covers administrators of critical benchmarks only, not benchmark administrators in general

The exclusions in Article 2(3) have six points and one of them is easily dropped. The regulation does not apply to: (a) managers of alternative investment funds referred to in Article 3(2) of Directive 2011/61/EU, (b) insurance and reinsurance undertakings referred to in Article 4 of Directive 2009/138/EC, (c) institutions for occupational retirement provision operating pension schemes which together have no more than 15 members in total, (d) natural or legal persons exempted under Articles 2 and 3 of Directive 2014/65/EU, (e) insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries which are microenterprises or small or medium-sized enterprises, and (f) post office giro institutions referred to in Article 2(5), point 3, of Directive 2013/36/EU. On top of that, Article 2(4) allows a Member State to exclude from scope the entities listed in Article 2(5), points 4 to 23, of Directive 2013/36/EU.

The five areas DORA is made of

The regulation splits into five thematic blocks. Their order matches the way they build on one another in practice: first it has to be clear who decides and on what basis, then comes the ability to recognise and report an incident, then verifying that all of it works, and finally the supply chain, which in the financial sector is where most of the real risk exposure sits.

• ICT risk management (Chapter II, Articles 5–16). An internal governance and control framework, an ICT risk management framework, a business continuity policy and recovery plans, backups, lessons learned from incidents. Responsibility is assigned to a named body: under Article 5(2), point (a), the management body bears the ultimate responsibility for managing ICT risk, under point (g) it allocates and periodically reviews the budget for resilience, and under Article 5(4) it keeps its own training up to date. Entities other than microenterprises establish a role to monitor arrangements with ICT providers, or designate a member of senior management to do so (Article 5(3)).
• ICT-related incident management, classification and reporting (Chapter III, Articles 17–23). An incident management process with early warning indicators, records of all incidents and significant cyber threats, classification against common criteria and reporting of major incidents within precise deadlines.
• Digital operational resilience testing (Chapter IV, Articles 24–27). A testing programme as part of the risk management framework, yearly tests of systems supporting critical or important functions and, for entities identified for it, threat-led penetration testing.
• ICT third-party risk management (Chapter V, Articles 28–44). The register of information, mandatory contractual provisions, assessment of concentration risk, exit strategies and the oversight framework for critical ICT providers.
• Information sharing on cyber threats (Chapter VI, Article 45). Voluntary. Financial entities may exchange indicators of compromise, tactics, techniques and procedures and configuration tools within trusted communities, provided it happens under an arrangement that protects the sensitivity of the information. Participation in such an arrangement, however, has to be notified to the competent authority (Article 45(3)) — and failing to do so is a separate administrative offence in the Czech Republic.

The Czech version of the regulation uses the abbreviation "IKT" where practitioners say ICT. It is the same thing, but anyone searching the Czech official text has to type IKT — a query for ICT returns nothing there.

When an incident is major and the deadlines for reporting it

The duty to report major ICT-related incidents follows from Article 19, but the regulation itself does not say when an incident is major or what has to be sent by when. Classification is governed by Delegated Regulation (EU) 2024/1772, the deadlines by Delegated Regulation (EU) 2025/301. Without those two texts the reporting duty cannot be met.

Under Article 8(1) of Regulation 2024/1772 an incident is major where critical services are affected and, at the same time, at least one of two conditions is met: either the materiality threshold for the data losses criterion under Article 9(5), point (b), of that regulation is reached — that is, there has been successful malicious unauthorised access to network and information systems which may result in data losses — or two or more of the other materiality thresholds are reached. A single threshold met, malicious access aside, therefore does not lead to a report.

Article 5(1) of Regulation 2025/301 sets three deadlines. The initial notification as soon as possible, in any case within 4 hours of classifying the incident as major and no later than 24 hours after the entity became aware of it. The intermediate report no later than 72 hours after the initial notification, even where neither the status nor the handling has changed. The final report no later than one month after the intermediate report, or after the last updated intermediate report.

Where the entity became aware of the incident earlier but only assessed it as major later, the 4 hours for the initial notification run from the classification (Article 5(2)). A postponement over weekends and public holidays does exist, but not for everyone — and this is where the costliest mistake is made, because the blanket version of the rule is, for a bank, a recipe for missing the deadline. The bullets below cover both: first the materiality thresholds, then the three variants of the postponement.

• Materiality thresholds under Article 9 of Regulation 2024/1772. More than 10 % of the clients of the affected service or more than 100,000 clients; more than 30 % of the financial counterparts affected; more than 10 % of the daily average number or value of transactions; clients or counterparts affected who are identified as relevant; reputational impact; a duration of more than 24 hours or downtime of ICT services supporting critical or important functions of more than 2 hours; impact in two or more Member States; data losses; costs and losses exceeding EUR 100,000.
• Variant A — the general rule (Article 5(4)). Where the deadline for the initial notification or for the intermediate or final report falls on a weekend day or a public holiday in the Member State of the reporting entity, the report may be submitted by noon of the following working day.
• Variant B — no postponement for the initial notification and the intermediate report (Article 5(5)). Paragraph 4 does not apply to the initial notification and the intermediate report of credit institutions, central counterparties, operators of trading venues and other financial entities that qualify as essential or important entities under Article 3 of Directive (EU) 2022/2555. For them the four-hour and the twenty-four-hour deadlines run on a Saturday night and on Christmas Eve as well. The postponement is left to them for the final report only.
• Extending variant B by a decision of the authority (Article 5(6)). The competent authority may switch the postponement off for further entities that are significant or have a systemic character at national or Union level. The decision is notified to the entity and applies only to incidents reported after the date of notification. The practical consequence: a bank must not build its procedure on the general rule, and nobody should assume that such a decision will never reach them.

In the Czech Republic, reports go to the Czech National Bank through the SDAT collection system, on the return for reporting a major incident; according to the ČNB the form is in English only. An entity that misses a deadline has to notify the authority under Article 5(3) of Regulation 2025/301 without undue delay, at the latest within the deadline concerned, and explain why. Where an incident has an impact on the financial interests of clients, the entity informs them without undue delay under Article 19(3) of DORA. Reporting may be outsourced under Article 19(5), but responsibility for fulfilling it stays with the financial entity — this can be treated as an ordinary incident management process, only with deadlines in hours rather than days and with the return prepared in advance; we set it up as part of the incident response plan, not as a separate compliance exercise.

Resilience testing and threat-led penetration testing

Testing is the area where DORA is closest to ordinary security practice. Under Article 24, financial entities other than microenterprises establish a testing programme as part of the ICT risk management framework, follow a risk-based approach and ensure that the tests are undertaken by independent parties, whether internal or external; for internal testing they have to allocate resources and avoid conflicts of interest in the design and the execution of the test. Article 24(6) then sets a hard minimum cadence: at least yearly, appropriate tests of all ICT systems and applications supporting critical or important functions.

What counts as testing is listed in Article 25 — the overview is in the bullets below. Central securities depositories and central counterparties additionally perform vulnerability assessments before any deployment or redeployment of applications and infrastructure components supporting critical or important functions (Article 25(2)).

The top tier is threat-led penetration testing (TLPT) under Article 26. It is carried out at least every three years, but it does not concern everyone — it applies to entities other than those referred to in Article 16(1) and other than microenterprises which are identified for it by the competent authority. The identification criteria are specified by Delegated Regulation (EU) 2025/1190: on one side the impact and systemic nature of the entity, on the other ICT risk factors — the complexity of the architecture, the dependence of critical functions on ICT systems, the number and type of arrangements with providers and the maturity of the ability to monitor the infrastructure and respond in time.

TLPT is not a bigger pentest. Under Article 26(2) it is carried out on live production systems actually used to support critical or important functions, the scope is validated by the competent authority and the defensive team is not told about the test. Where ICT providers fall within the scope, the entity secures their participation (Article 26(3)); where that would risk harming the provider's customers outside the scope of DORA, Article 26(4) allows pooled testing for several financial entities under the lead of one of them.

• vulnerability assessments and scans, open source analyses, network security assessments and gap analyses
• physical security reviews and questionnaires
• scanning software solutions and, where feasible, source code reviews
• scenario-based tests, compatibility testing, performance testing and end-to-end testing
• penetration testing

In the Czech Republic the framework is TIBER-EU, which the Czech National Bank joined in September 2024; in March 2025 it issued the TIBER-CZ Implementation Guide and it acts as the authority for threat-led penetration testing. For entities that are not identified for TLPT there is still a practical lesson in it: the yearly test under Article 24(6) should test the ability to detect and respond, not merely produce output from a vulnerability scanner.

The supply chain and the register of information — the financial entity view

The starting point is Article 28(1), point (a): a financial entity that buys ICT services remains fully responsible at all times for complying with every obligation under the regulation. Outsourcing does not transfer responsibility, it only moves the place where the risk arises. Entities other than those referred to in Article 16(1) and other than microenterprises also adopt and review a strategy on ICT third-party risk, which the management body reviews regularly (Article 28(2)).

Before entering into a contract, Article 28(4) requires the financial entity to assess whether the arrangement covers critical or important functions, whether the conditions for supervision are met, what risks the arrangement brings including a possible increase in concentration risk, to carry out due diligence on the provider and to assess conflicts of interest. Under Article 28(5) it may only contract with providers that comply with appropriate information security standards, and for critical or important functions it has to consider whether the provider applies the most up-to-date and highest quality standards.

Article 28(7) and (8) then require the ability to terminate the contract in listed situations and, for critical or important functions, a documented, tested and regularly reviewed exit strategy, including plans for transition to an alternative provider or back in-house.

The register of information under Article 28(3) is a complete record of all contractual arrangements on the use of ICT services, kept at entity level and at sub-consolidated and consolidated level, distinguishing the arrangements that support critical or important functions. It is not a one-off inventory: a reporting duty, a fixed format and, in the Czech Republic, an annual collection through the ČNB attach to it. The details are in the bullets below.

• Three duties tied to the register that are easily overlooked: at least yearly, to report to the competent authority the number of new arrangements, the categories of providers, the type of arrangements and the services and functions provided; on request, to make the whole register or parts of it available to the authority; and to inform the authority in good time about any planned arrangement concerning critical or important functions, or about a function having become critical or important.
• The format is set by Implementing Regulation (EU) 2024/2956. The templates are in Annex I — fifteen interlinked tables from B_01.01 to B_99.01, each with a fixed number of columns and any number of rows, where every combination of values is reported on a separate row. Annexes II to IV are the code lists the completion instructions refer to: activities by type of entity, the taxonomy of ICT services with identifiers S01 to S19, and how to report the value of total assets.
• Rank in the ICT service supply chain: a direct provider always has rank 1 and a subcontractor always higher, and under Article 2 of that regulation the rank is any natural number from 1 upwards — the standard sets no fixed number of tiers in the chain. Of the subcontractors, the ones to be reported are those effectively providing the ICT services supporting critical or important functions, or material parts of them (Article 3(2)). Legal persons are identified by a valid LEI code, or by the European Unique Identifier (EUID).
• In the Czech Republic the register is submitted to the Czech National Bank through the SDAT system. Instances of the return are generated automatically for the reporting entities and the ČNB sets the due date by a call — for the collection announced for 2026 the ČNB website gave 2 March 2026.
• The level at which the register is reported differs by type of entity. For credit institutions, the central securities depository, trading venues and insurance and reinsurance undertakings, the ČNB states that it is submitted at the highest level of consolidation in the EU; for payment institutions, small-scale payment service providers, electronic money institutions, investment firms, fund managers, management companies, insurance intermediaries and crowdfunding service providers, at individual level.
• Without an LEI code the return will not go through. The ČNB flags this separately — anyone without an LEI has to obtain one, otherwise the reporting duty cannot be met.
• The ČNB runs four DORA returns in SDAT. Besides the register of information, the major incident report and the significant cyber threat notification, there is also the report on security and operational risks (HLASRIZ01). It targets listed categories of entities — among others payment institutions and small-scale payment service providers, electronic money institutions and small-scale electronic money issuers, investment firms, fund managers and management companies, insurance intermediaries and crowdfunding service providers — and is submitted on the basis of a call from the ČNB, which also sets the date.

There is a dated interpretation from the ČNB on how far the register has to reach. In its answers from the webinar on DORA reporting of 27 March 2025, the ČNB said that the implementing standard assumes all ICT service providers, but that at that stage it would treat the inclusion of significant and critical providers — those whose services have a material impact on operational capability, security or continuity — as the minimum acceptable standard. That is a supervisor's interpretation for the first data collection, not the text of the standard — before filing, it is worth checking what the ČNB says about the current collection.

The part for providers: what Article 30 means when you are not a bank

The definition of a provider is deliberately broad and carries no size threshold. Article 3(19) defines an ICT third-party service provider as any "undertaking providing ICT services", and the service itself is defined just as broadly in Article 3(21): digital and data services provided through ICT systems on an ongoing basis to anyone inside or outside the organisation, including hardware as a service and its support through software or firmware updates. The only express carve-out is traditional analogue telephone services.

A three-person software shop supplying a bank with a single microservice is therefore an ICT provider in the same way a hyperscaler is. Direct obligations under the regulation usually do not arise for it. They arise from the contract, because the bank is not allowed to conclude one without the relevant provisions. That is why, since mid-2025, software houses, SaaS and managed service providers have been receiving contract addenda and long security questionnaires — the bank is not ticking a box of its own, it is securing the evidence it needs for Articles 28 and 30 and for the register of information.

Under Article 30(1) the rights and obligations have to be clearly allocated and set out in writing, and the full contract including the service level agreements should sit in a single document available in hard copy or in a downloadable, durable and accessible format. Article 30(2) then lists the minimum every ICT services contract has to contain, and Article 30(3) adds further provisions for the case where your service supports a critical or important function of the bank.

What a critical or important function is follows from Article 3(22) — in short, an activity whose disruption would materially impair the bank's financial performance, or its ability to keep its services and activities running, or its continuing compliance with the conditions of its authorisation. Whether your service is one of them is the bank's call — and in practice you can tell from how tough an addendum you receive.

• a clear and complete description of the functions and ICT services, stating whether subcontracting is permitted and under what conditions
• the locations — the specific regions or countries — where the service is provided and where data is processed and stored, plus the provider's duty to give advance notice of any planned change of those locations
• provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data
• ensuring access to, recovery and return of data in an easily accessible format in the event of insolvency, resolution, discontinuation of the provider's business or termination of the contract
• service level descriptions, including updates and revisions thereof
• the duty to provide assistance with an ICT incident at no additional cost, or at a cost determined ex-ante — the point most often underpriced when support is costed
• the duty to cooperate fully with the competent authorities and the resolution authorities
• termination rights and the related minimum notice periods
• the conditions for the provider to take part in ICT security awareness programmes and digital operational resilience training
• In addition, for critical or important functions (Article 30(3)), the following points apply.
• Full service level descriptions with precise quantitative and qualitative performance targets, so that the bank can monitor the service effectively and step in without delay when it is not met.
• A duty to report any development that could materially affect the provider's ability to deliver the service at the agreed level, plus notice periods.
• A duty to implement and test business contingency plans and to have ICT security measures, tools and policies in place providing an appropriate level of security.
• A duty to participate in and fully cooperate with threat-led penetration testing at the bank (Articles 26 and 27).
• Unrestricted rights of access, inspection and audit exercised by the bank, by a third party it appoints and by the competent authority, including taking copies of documentation on site. Under Article 30(3), point (e)(i), the effective exercise of those rights must not be impeded or limited by other contractual arrangements or by the provider's implementation policies — the familiar clause "audits only under our audit policy" does not survive here. On top of that there is a right to agree alternative assurance levels where the rights of other customers are affected, and a duty to cooperate during on-site inspections.
• An exit strategy with a mandatory adequate transition period, during which the provider keeps delivering the service so that the bank can move to another provider or take the function in-house.

Two things that can be negotiated. First, Article 30(4) expects the parties to consider using standard contractual clauses developed by public authorities — a legitimate argument against bespoke invention in every addendum. Second, where the financial entity is a microenterprise, the last subparagraph of Article 30(3) allows the parties to agree that the rights of access, inspection and audit are exercised by an independent third party appointed by the provider. The elements a financial entity has to determine and assess when subcontracting ICT services that support critical or important functions are specified by Delegated Regulation (EU) 2025/532 — in practice this means a provider has to know who sits underneath it and be able to evidence it.

Overlap with the Czech Cybersecurity Act

The most frequent question at the boundary of the two rulebooks is whether a bank is under DORA or under Act No. 264/2025 Coll. The answer "under DORA, not under the Cybersecurity Act" is a shorthand that only partly holds.

The mechanism sits in Article 4 of the NIS2 Directive: where sector-specific Union legal acts require essential or important entities to adopt cyber security risk-management measures or to notify significant incidents, and the effect of those requirements is at least equivalent, the corresponding provisions of the directive — including those on supervision and enforcement — do not apply to those entities. DORA is precisely such a sectoral act.

In the Czech implementation it looks like this. The financial market is one of the sectors under the Cybersecurity Act, and Decree No. 408/2025 Coll. defines the regulated services within it — the activity of a credit institution, the operation of a trading venue and the activity of a central counterparty (required by the directive) and, going beyond the directive, the activity of a payment institution and the activity of an electronic money institution.

In the explanatory memorandum to the decree, NÚKIB explains that in matters of security measures, incident reporting and the exercise of supervision these entities will fall under the DORA regime and that only the remaining provisions of the Cybersecurity Act will apply to them, in particular the national instruments. Both authorities confirmed that reading in a joint statement of the ČNB and NÚKIB of 24 June 2026: the DORA requirements on cyber risk management and incident reporting generally take precedence, but this is not a blanket disapplication of the Act. What specifically remains of it is in the bullets below.

• For a financial entity: security measures and incident reporting are handled under DORA towards the ČNB. The Act still applies where DORA does not regulate the area equivalently — the joint statement names mandatory registration of the entity with NÚKIB and the state of cyber emergency expressly, and the national instruments stay in place on top of that, countermeasures above all. Requirements that are markedly stricter or more detailed in the Act or in another NIS2-based rule than what DORA covers may be added as well. So "we are outside the Cybersecurity Act" is an imprecise statement.
• Who supervises: the ČNB remains the main supervisory authority for the financial sector. For specific activities where equivalent regulation is missing — the statement mentions trust services — supplementary supervision by the relevant authority applies, that is by the Digital and Information Agency or by NÚKIB. The authorities also envisage joint inspections and sharing of their results, so information does travel between them.
• For providers: not being directly under DORA does not mean being unregulated. In the sector of digital infrastructure and services, Decree No. 408/2025 Coll. lists among the regulated services the provision of cloud computing services, data centre services, managed services and managed security services. A provider that meets the significance test complies with the Cybersecurity Act in its own right and at the same time with the banks' contractual requirements under Article 30 of DORA — two legal bases, one set of security measures, two sets of evidence.

A practical view: running the dual regime as two projects does not pay off. The measures are largely the same in both rulebooks; what differs is the reporting, the supervisory authority and the format of the evidence — so one risk assessment and one set of measures can be built and the differences covered by mapping. That is how we do it for providers serving regulated clients in several sectors at once.

Who supervises and what is at stake

The Czech adaptation consists of two acts of 22 January 2025, published on 14 February 2025 and both effective from 15 February 2025: Act No. 31/2025 Coll. on the implementation of European Union legislation in the area of financial market digitalisation (the Financial Market Digitalisation Act) and Act No. 32/2025 Coll., amending certain acts in connection with that implementation and with sustainable finance.

Under Section 9 of Act No. 31/2025 Coll., the competent authority under DORA is the Czech National Bank. It supervises every person subject to obligations or prohibitions under the regulation (Section 10), may impose remedial measures (Section 11) and may exercise the powers under Article 50(2), points (a) to (c), and Article 50(4), points (b) or (c), of DORA (Section 12). Compliance is enforced through coercive fines: up to CZK 5,000,000 individually and up to CZK 20,000,000 in aggregate (Section 14).

One group of providers does not fall under the ČNB. Under Article 31, the European Supervisory Authorities (EBA, EIOPA and ESMA) designate, through the Joint Committee, the ICT third-party service providers that are critical for financial entities, and appoint a Lead Overseer for each of them from among their own ranks. The criteria are in Article 31(2) and are specified by Delegated Regulation (EU) 2024/1502: the systemic impact of a large-scale outage, the systemic character of the dependent financial entities, the degree of reliance for critical or important functions and substitutability.

The inputs for designation come from the registers of information — which is why the register is collected in a structured form every year. The list is published and updated yearly under Article 31(9), and the first one came out on 18 November 2025; a provider not on it may apply for designation itself under Article 31(11). For Czech software houses this is a scenario out of reach — designation targets providers operating across Europe. The penalties for breaching DORA are then set not by the regulation but by the Member State; in the Czech Republic they are in Sections 18 and 19 of Act No. 31/2025 Coll. and are graded by what was breached:

• Up to CZK 50,000,000 for a financial entity failing to meet the obligations concerning the ICT risk management framework (Article 6), the ICT business continuity policy (Article 11), the duty to report major incidents (Article 19), digital resilience testing (Chapter IV) and ICT third-party risk management (Chapter V, Section I).
• Up to CZK 20,000,000 for failing to meet the other ICT risk management obligations (Articles 5, 7 to 10, 12 to 14 and 16), the incident management process (Article 17), the classification of incidents and threats (Article 18), and for breaching an obligation imposed by a decision under Article 42(6).
• Up to CZK 10,000,000 for failing to notify participation in an information-sharing arrangement (Article 45(3)) and for failing to cooperate with the ČNB in supervision under Article 50(2).
• Providers (Section 19): an ICT third-party service provider commits an administrative offence by failing to give the ČNB the cooperation it requires in supervision under Article 50(2) — a fine of up to CZK 10,000,000. For a critical provider, failing to cooperate with the Lead Overseer under Article 37(4), Article 38(4) or Article 39(6) is an offence as well, with a fine of up to CZK 20,000,000. For all of these offences the decision may also be published.
• Critical ICT providers are not supervised by the ČNB. The Lead Overseer is appointed under Article 31(1), point (b), by the European Supervisory Authorities and is one of them — EBA, EIOPA or ESMA, depending on where the largest share of the assets of the dependent financial entities sits. The instrument is a periodic penalty payment of up to 1 % of the average daily worldwide turnover, imposed daily for a maximum of six months (Article 35(6) to (8)).
• Two consequences of designation with no parallel elsewhere in European law. A third-country provider has to establish a subsidiary in the Union within 12 months under Article 31(12), otherwise its services may not be used, and it pays for its own oversight — the fees are set by Regulation (EU) 2024/1505.

Management responsibility is not framed in DORA as a sanction but as an assigned role: Article 5(2), point (a), puts the ultimate responsibility for managing ICT risk on the management body, and Article 5(4) requires its members to keep up to date through regular training in this area. Article 50(5) further expects Member States to give authorities the power to apply administrative penalties and remedial measures to members of the management body and to other individuals responsible under national law. Minutes of the meeting at which management approved the ICT risk management framework and allocated its budget are therefore a record worth having.

Dates and deadlines that can be evidenced

The timeline carries only dates with a traceable source. The rolling deadlines are at the bottom, because they have no single date — they run from an event, not from the calendar.

Official sources

This guide is informative and is not a legal opinion. Every statement about a date or an obligation above comes from one of these sources — for the binding wording, always go to them.