QUESTIONS ON THE DORA REGULATION

Both are right in their own way. Under Article 64, the regulation entered into force on 16 January 2023, but it applies only from 17 January 2025. The two years in between were a transition period: the text was in force, but it created no enforceable obligations.

So the date from which a supervisory authority can hold something against you is 17 January 2025. Note that the Czech National Bank describes that day as the date the regulation "became effective" — this is not a contradiction in substance, just loose wording; both dates and this editorial trap are unpicked in the guide.

The scope is a closed list, not a general definition — so all you have to do is find yourself in it. Article 2(1) enumerates entities under points (a) to (u); points (a) to (t) are "financial entities", point (u) covers ICT third-party service providers, which are not financial entities.

The list also contains players nobody counts as the financial sector: account information service providers, electronic money institutions, securitisation repositories, crowdfunding service providers and ancillary insurance intermediaries. The full list, including the trap in point (r), which covers only administrators of critical benchmarks, is in the guide.

Yes, they are in Article 2(3) and there are six of them. They tend to be quoted one point short, because the last one looks like a historical curiosity — post office giro institutions. The one most often missed is the exemption for institutions for occupational retirement provision operating pension schemes that together have no more than 15 members.

All six points and their links to the individual directives are set out in the guide. Beyond those exemptions, Article 2(4) also allows a member state to exclude further entities from the scope — whether the Czech Republic used that option is a question for Act No. 31/2025 Coll., not for the regulation.

Only if you are on the list. Article 16 is not a general exemption for small entities but a named list — it covers, among others, small and non-interconnected investment firms, exempted payment institutions and electronic money institutions, and small institutions for occupational retirement provision.

And "Articles 5 to 15 shall not apply" does not mean "we do not have to do anything": eight obligations apply in their place, from a documented ICT risk management framework to regular testing of recovery plans. The bonus is that you are not subject to threat-led penetration testing (Article 26(1)) or to the duty to adopt a separate strategy on ICT third-party risk (Article 28(2)).

The full list of eligible entities and all eight obligations are in the guide.

It is not. Microenterprises are not excluded from the scope, and the simplified framework under Article 16 does not apply to them on account of their size. The regulation narrows their obligations only in named places — the testing programme, threat-led penetration testing and the exercise of audit rights at a provider. Everything else applies in full.

The practical consequence: there is no "DORA lite" for a microenterprise. You have to go through the individual provisions and find where the narrowing genuinely applies to you. The specific articles concerned are in the guide.

The regulation itself does not say — the criteria are in Delegated Regulation (EU) 2024/1772. Under its Article 8(1), an incident is major where it has affected critical services and where either successful, malicious and unauthorised access with possible data loss has occurred, or two or more of the other materiality thresholds referred to in Article 9(1) to (6) are met.

There are six thresholds and they are set out in Article 9(1) to (6) of the same regulation — each paragraph is one threshold tied to one criterion from Articles 1 to 5 and 7. Within a paragraph it is enough to meet any one of the conditions listed, and the paragraph still counts only once:

• Clients, financial counterparts and transactions (paragraph 1) — more than 10 % of the clients of the affected service, or more than 100,000 clients in absolute numbers; more than 30 % of the financial counterparts affected; affected clients or counterparts identified as relevant; more than 10 % of the average daily number of transactions or of their average daily value. All of this is one threshold: exceeding 10 % of clients and 10 % of transactions at once still gives you one, not two.
• Duration and downtime (paragraph 3) — the incident lasts longer than 24 hours, or the downtime of ICT services supporting critical or important functions exceeds 2 hours.
• Costs and losses (paragraph 6) — they have exceeded, or are estimated to exceed, EUR 100,000.
• The remaining three — reputational impact (paragraph 2), impact in two or more member states (paragraph 4) and data losses (paragraph 5). Data losses include successful, malicious and unauthorised access under paragraph 5, point (b), to which Article 8 refers separately — that one is enough on its own.

Which leads to a non-obvious conclusion: one threshold met is not enough to trigger a report — with the exception of malicious access, which suffices alone. And because it is the paragraphs of Article 9 that are counted, not the individual conditions inside them, several conditions met within one paragraph still amount to a single threshold. Which paragraph of Article 9 holds which value, and how it ties back to Article 8, is unpicked in the guide.

The practical consequence for operations: classification has to be part of the incident management process and it has to be documented, because the decision "we are not reporting this" is equally a decision you must be able to defend.

Three of them, under Article 5(1) of Delegated Regulation (EU) 2025/301:

• Initial notification — within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it.
• Intermediate report — within 72 hours of the initial notification, even if neither the status nor the handling of the incident has changed.
• Final report — within one month of the intermediate report, or of the last updated one.

Not going to make it? Under Article 5(3) you have to tell the authority, within the deadline concerned at the latest, that you will miss it and give the reason — a missed deadline without notice is worse than a missed deadline with one. How the deadlines run when classification comes later, and the weekend regime, are covered in the guide.

It depends who you are — and the blanket version of the rule is a recipe for a bank to miss a deadline. The general rule is that a deadline falling on a weekend or a public holiday moves to noon of the following working day (Article 5(4) of Regulation 2025/301).

Except that for credit institutions, central counterparties, operators of trading venues and other entities qualifying as essential or important under NIS2, that extension does not apply to the initial notification and the intermediate report — the four-hour and 24-hour deadlines run for them on a Saturday night as well. And the competent authority can switch the extension off for other significant entities too, so nobody can count on it in advance. Both variants and the conditions for the authority decision are set out in the guide.

The operational consequence is concrete: if you are a bank, you need an on-call arrangement able to classify an incident and send the initial notification outside business hours. That is a matter for the incident response plan and for on-call availability, not for a compliance document — and that is how we approach it too.

In the Czech Republic you report to the Czech National Bank (ČNB), using the major incident return in its SDAT collection system — according to ČNB information the form is available in English only. The content of the reports and the procedures are set by Implementing Regulation (EU) 2025/302.

Two things that get overlooked: where the incident has an impact on the financial interests of clients, you have to inform them without undue delay (Article 19(3)) — that is a separate obligation alongside reporting to the authority. And while reporting can be outsourced under Article 19(5), responsibility for discharging it stays with you.

What is worth preparing in advance: registration in SDAT (without it you have no channel to report through), pre-filled static parts of the return, a contact matrix and written classification criteria. Which other DORA returns ČNB runs in SDAT, and who they concern, is summarised in the guide.

These are two different levels and they get confused. The testing programme under Article 24 is established by every financial entity other than a microenterprise: testing has to be carried out by independent parties, internal or external, and the minimum cadence is at least once a year for all ICT systems and applications supporting critical or important functions.

Threat-led penetration testing (TLPT) under Article 26 is carried out at least every three years, but only by entities identified for it by the competent authority; in the Czech Republic the framework is TIBER-EU and the TLPT authority is ČNB. It is not a bigger pentest — it runs on live production systems, on systems actually in use, and the defensive team does not know about it. What counts as testing and how entities are identified for TLPT is covered in the guide.

A pointer for entities that are not identified: the annual test under Article 24(6) is meant to test the ability to detect and respond, not to produce an export from a vulnerability scanner. A scanner finds the missing patch; it will not tell you whether anyone would have noticed it being exploited.

Because without the required provisions in the contract it is not allowed to buy the service from you. You are not a financial entity, so the regulation usually imposes no direct obligations on you — your obligations arise from the contract. The bank is not ticking a box of its own; it is securing what it needs to comply with Articles 28 and 30 and to keep its register of information.

Being small changes nothing about that: the definition of an ICT third-party service provider in Article 3, point (19) has no size threshold, and the definition of ICT services in point (21) is just as broad. A three-person software house delivering one microservice is an ICT provider in the same way a hyperscaler is — both definitions and their limits are covered in the guide.

The starting point of the whole relationship is Article 28(1)(a): the financial entity remains at all times fully responsible for compliance with its obligations under the regulation. Outsourcing does not transfer responsibility, it only moves the place where the risk arises — which is why a bank is so sensitive about its providers.

Article 30(2) sets the minimum for every contract on ICT services: a description of the functions and services including the conditions for subcontracting, the specific locations where the service is provided and data is processed, data protection, access to data and its return on termination or insolvency, service level descriptions, assistance during an incident, cooperation with authorities, notice periods and participation in training. The full list, and the tougher layer from paragraph 3, is in the guide.

None of it is unreasonable — but two items tend to be underestimated. The first is assistance during an ICT incident at no additional cost, or at a cost determined in advance: if it is not in your support price list, you have just given it away for free and without a cap. The second is the duty to give advance notice of a change of the locations where data is processed — which means you have to know where your subcontractors run and have a process for changing them.

The tougher provisions in Article 30(3) apply where your service supports a critical or important function of the bank — and the bank decides that, not you. They add precise performance targets, notification of any deterioration in the ability to provide the service, tested business continuity plans, participation in the bank tests, audit rights and an exit strategy with a transition period; the individual points are set out in the guide.

As for audit rights, their effective exercise must not be impeded or limited by other contractual arrangements or by your own implementation policies (Article 30(3)(e)(i)) — so the customary "audits only in accordance with our audit policy" clause will not get through.

Two things can be negotiated. Article 30(4) envisages the use of standard contractual clauses developed by public authorities, which is a legitimate argument against bespoke inventions in every addendum. And where the financial entity is a microenterprise, the last subparagraph of Article 30(3) allows you to agree that the audit is performed by an independent third party appointed by the provider.

They are not questionnaires for the sake of questionnaires. The bank uses them to comply with Article 28(4) and (5): before entering into a contract it has to assess the risks of the arrangement, including any increase in ICT concentration risk, carry out due diligence and verify that you meet appropriate information security standards. Everything it has to establish in the process is in the guide.

At the same time it needs structured data about you for the register of information — which is where the questions that look like pure paperwork come from: the LEI code, the exact countries of data processing, the list of subcontractors and their rank in the chain.

The approach that works: build one set of your own security documentation (scope of the service, architecture, controls, incident response plan, test results, list of subcontractors with countries) and answer questionnaires from it. Without that you answer every bank separately, and after a few dozen questionnaires you contradict yourself — and the next audit will find it. Building such a base is one of the things we do for providers; filling in other people's forms is not.

You do not keep the register of information — the financial entity does. The obligation in Article 28(3) falls on the bank; you are the party reported in it. Your role is to supply the right data: the LEI code (or the European Unique Identifier, EUID), the countries where the service is provided and data processed, a description of the service and a list of subcontractors with their rank in the chain, where the direct provider is always 1 and a subcontractor always higher. How the format under Implementing Regulation (EU) 2024/2956 is put together is shown in the guide.

On supervision: direct European oversight applies only to critical providers designated under Article 31, and they are not supervised by ČNB but by a Lead Overseer from among the European Supervisory Authorities (EBA, EIOPA or ESMA). The first list was published on 18 November 2025 and is updated annually; it contains providers with a pan-European footprint, not Czech software houses.

That does not mean you are invisible to ČNB, however. Under Section 19 of Act No. 31/2025 Coll., an ICT third-party service provider commits an administrative offence if it fails to give ČNB the cooperation required for supervision under Article 50(2) of the regulation. For a critical provider, failing to cooperate with the Lead Overseer is an offence as well.

Not entirely — and this is the most common misunderstanding at the boundary between the two. "Under DORA, not under the Cybersecurity Act" is a shortcut that holds only for part of the obligations. The mechanism sits in Article 4 of the NIS2 Directive: where a sector-specific Union act imposes at least equivalent requirements on cyber risk management and incident reporting, the provisions of the directive including supervision and enforcement do not apply — and under its Article 1(2) DORA is such an act.

It is not a blanket exclusion of the Act, though. The joint statement of ČNB and NÚKIB of 24 June 2026 names the obligations that stay with an entity under DORA — among them mandatory registration with NÚKIB and the state of cyber emergency regime — and adds the requirements where the Act is markedly stricter or more detailed than what DORA covers.

In practice: security measures and incident reporting you handle under DORA towards ČNB, the rest of the Act continues to apply to you; the line "we are outside the Cybersecurity Act" will not hold up in a conversation with NÚKIB. The full division between the two sets of rules is unpicked in the guide.

Under the joint statement of 24 June 2026, primarily ČNB. If you carry out specific activities for which no equivalent regime exists — the statement gives trust services as an example — supplementary supervision by the relevant authority is added, for instance by the Digital and Information Agency or NÚKIB, over the implementation of those specific requirements. Such an inspection may also examine the part of the DORA security framework that the activity in question directly affects.

The two authorities have further agreed to cooperate in proportion to the intensity of their own supervision, including joint inspections and sharing of results. So count on information travelling between them. How supervision is divided and what remains from the Act is summarised in the guide.

Quite possibly, and it happens more often than expected. Not being under DORA directly does not make you unregulated: in the digital infrastructure and services sector, Decree No. 408/2025 Coll. designates cloud computing, data centre services, managed services and managed security services, among others, as regulated services. If you meet the significance criterion, you become a regulated entity under Act No. 264/2025 Coll. and comply in your own right — alongside whatever the banks require of you in contracts under Article 30 of DORA.

Two legal titles do not mean two projects, though: the measures are largely identical in both sets of rules, what differs is reporting, the supervisory authority and the format of the evidence, so you can build one risk assessment and cover the differences by mapping. The overlap between the two regimes is unpicked in the guide; for the Act itself there is a guide to the Cybersecurity Act and an impact calculator.

The Czech adaptation consists of Act No. 31/2025 Coll. on the digitalisation of the financial market and the accompanying Act No. 32/2025 Coll., both in force since 15 February 2025. Under Section 9, the competent authority under DORA is the Czech National Bank: it supervises every person on whom obligations or prohibitions under the regulation fall, imposes remedial measures and enforces them by coercive fines.

A coercive fine under Section 14 is not a penalty for an offence — it is used to enforce a remedial measure or an obligation already imposed, and it is imposed step by step. A single coercive fine may not exceed CZK 5,000,000, and the aggregate may not exceed CZK 20,000,000. Fines for administrative offences under Sections 18 and 19 run separately alongside.

Watch one exception: critical ICT service providers are not supervised by ČNB. Their Lead Overseer is appointed under Article 31(1)(b) by the European Supervisory Authorities and is one of them — EBA, EIOPA or ESMA, depending on where the largest share of assets of the dependent financial entities lies. The individual powers of ČNB and the mechanism for designating critical providers are described in the guide.

The regulation itself does not set the level of penalties — Article 50 requires member states to provide for effective, proportionate and dissuasive administrative penalties and remedial measures. The specific amounts are therefore national; in the Czech Republic they are in the offences part of Act No. 31/2025 Coll. (Section 18 et seq.) and are graduated by what was breached:

• Up to CZK 50,000,000 — the ICT risk management framework, the business continuity policy, reporting of major incidents, resilience testing and third-party risk management.
• Up to CZK 20,000,000 — other obligations in ICT risk management and in the incident management process and classification.
• Up to CZK 10,000,000 — failure to notify participation in an information-sharing arrangement and failure to cooperate with ČNB in supervision.
• Providers (Section 19): up to CZK 10,000,000 for failing to cooperate with ČNB; for a critical provider up to CZK 20,000,000, including towards the Lead Overseer. Publication of the decision may be imposed as well.

For critical providers the Lead Overseer has a tool of its own: periodic penalty payments of up to 1 % of average daily worldwide turnover, imposed on a daily basis until compliance is achieved, for no longer than six months (Article 35(6) to (8)).

Which specific articles fall under which band is set out in the guide; the exact wording of the offences and of the amounts is in Act No. 31/2025 Coll. in the e-Sbírka.

DORA treats this not as a penalty but as an assigned role: under Article 5(2)(a) the management body bears the ultimate responsibility for managing ICT risk, allocates the budget for it and, under Article 5(4), regularly takes training in the area itself. On top of that, Article 50(5) expects member states to give authorities the power to apply penalties and remedial measures to members of the management body as well.

The practical consequence is simple and cheap: minutes of a meeting at which management approved the ICT risk management framework, adopted the digital operational resilience strategy and allocated a budget to it, plus evidence that members of management were trained. Without that, compliance with Article 5 is an assertion, not evidence. How this connects to supervision and penalties is in the guide.