The chapter has four articles and settles two questions: whether the Regulation applies to you, and to what extent. We kept all four, because the rest of the text is not worth reading without them. We do not reproduce the full list of the twenty-one categories of addressees in Article 2(1), nor all 65 definitions in Article 3 — we describe how they work and link to the official text, where both are complete.
What this page is and what it is not
The Regulation has 64 articles, this page covers 37 of them in a practical selection — not the full set. The articles left out either merely mandate the European Supervisory Authorities to issue technical standards, or govern the internal workings of the EU oversight structures, or amend other regulations; what was dropped from each chapter and why is stated in the Overview section at the start of every part. For the articles we do cover, we give the official heading, our own paraphrase of the subject matter and a separate CypherOn commentary on what it means in practice. We do not reproduce the text of the Regulation and this page is neither the official text nor a legal opinion — for a binding citation always open the English text on EUR-Lex, and there is a link at every article. One more trap: the English text says ICT where the official Czech translation says IKT. The headings here follow the English wording, so when you cross-check against the Czech text or a ČNB document you have to search for IKT, otherwise the query returns nothing. The "CypherOn commentary" blocks are our reading, not the text of the Regulation.
Žádný paragraf neodpovídá hledanému výrazu.
Chapter I
General provisions (Articles 1 to 4)
Defines the six areas the Regulation brings under one roof: ICT risk management, reporting of major ICT-related incidents, reporting of payment-related incidents by banks and payment institutions, digital operational resilience testing, sharing of information on cyber threats, and the management of ICT third-party risk. On top of that come the rules for contracts with ICT service providers and an oversight framework for the critical ones. Paragraph 2 provides that, in relation to financial entities identified as essential or important entities under the national transposition of NIS2, DORA is treated as a sector-specific act within the meaning of Article 4 of that Directive. Official text of Article 1
CypherOn commentary
Paragraph 2 is the sentence that keeps the financial sector out of the full reach of the Czech Cybersecurity Act — DORA is lex specialis to NIS2. It does not mean the Czech act can never touch you: what decides is which service you provide and in what role. The overlap between the two is covered in our guide. And because this is a regulation, it applies directly — waiting for a "Czech DORA" makes no sense, as Act No. 31/2025 Coll. only deals with supervision, powers and offences.
Paragraph 1 lists, in points (a) to (u), twenty-one categories of addressees — from credit institutions, payment institutions and electronic money institutions through investment firms, funds, insurance undertakings and intermediaries to market infrastructure, credit rating agencies and ICT third-party service providers. Paragraph 2 provides that the collective term financial entity covers points (a) to (t) only; an ICT third-party service provider under point (u) is not a financial entity. Paragraph 3 excludes six groups, among them small managers of alternative investment funds, small insurance intermediaries, and institutions for occupational retirement provision with no more than 15 members in total. Paragraph 4 allows a Member State to exclude certain institutions covered by Directive 2013/36/EU. Official text of Article 2
CypherOn commentary
Two misconceptions we meet most often. The first: "we are only a software supplier, DORA does not apply to us" — an ICT third-party service provider is within scope under point (u). Direct EU oversight reaches it only where it is designated as critical (Article 31), but the client passes the Article 30 obligations down in the contract, and refusing them means losing the deal. The second: "we are small, so we are out" — only the groups listed in paragraph 3 fall outside the scope, and being small is not enough on its own. A small entity is usually in the simplified regime under Article 16, which is not the same thing as being outside the Regulation. Before you start reading obligations, settle your role — that is what the scope part of the guide is for.
Contains 65 definitions. Four of them decide how far your obligations reach: critical or important function (a function the disruption of which would materially impair the financial performance of the entity or the soundness or continuity of its services and activities), major ICT-related incident (an incident with a high adverse impact on the systems that support those functions), microenterprise (a financial entity employing fewer than 10 persons with an annual turnover or balance sheet total not exceeding EUR 2 million, other than a trading venue, a central counterparty, a trade repository or a central securities depository) and ICT third-party service provider. Official text of Article 3
CypherOn commentary
Identifying your critical or important functions is the single most consequential decision of the whole project — the scope of the contractual requirements under Article 30(3), the scope of testing under Article 24(6), the content of the register of information and what you end up reporting all hang on it. Do it in writing and with reasons, because it is the first thing a supervisor asks about and the second thing a provider challenges when audit rights are negotiated. Note also that a microenterprise under DORA is not the same as an entity in the simplified regime under Article 16 — two different categories with different consequences, and they get mixed up regularly.
The rules of Chapter II apply in proportion to the size of the entity, its risk profile and the nature, scale and complexity of its services. In Chapters III and IV and in Chapter V, Section I, proportionality applies only where a specific provision expressly allows it. Competent authorities take the application of proportionality into account when they review the framework on the basis of the reports referred to in Article 6(5) and Article 16(2). Official text of Article 4
CypherOn commentary
Proportionality is not an exemption, it is a measure of depth. It does not excuse a missing document — it excuses its length. What works in practice is a single paragraph inside the ICT risk management framework that justifies the chosen level of detail against size and risk profile; without it, you only start arguing proportionality at the moment someone asks, and that is too late.
Chapter II · Art. 5 to 15
ICT risk management framework (Articles 5 to 15)
The core of the Regulation. The chapter has two sections — Section I is Article 5 alone, Section II runs from Article 6 to Article 16 — and we pull Article 16 out into a separate part below, because it addresses a different set of entities. Article 5 assigns responsibility to the management body, Article 6 establishes the ICT risk management framework and Articles 7 to 14 spell out its content in the order identification, protection, detection, response and recovery, backup, learning and communication. We cover Articles 5 to 14. We left out Article 15, because it is a mandate for the European Supervisory Authorities to issue a technical standard — the result is Delegated Regulation (EU) 2024/1774, which sets the individual measures out in far more detail than DORA itself and is the text projects actually work from. The provisions of this chapter do not apply to entities in the simplified regime under Article 16.
A financial entity has an internal governance and control framework for managing ICT risk. The management body defines, approves, oversees and is responsible for its arrangements — it bears the ultimate responsibility for managing ICT risk, approves the digital operational resilience strategy including the risk tolerance level, approves the ICT business continuity policy and the response and recovery plans, approves the ICT audit plans, allocates a budget to resilience and approves the strategy on the use of ICT third-party service providers. Entities other than microenterprises also set up a function to monitor third-party arrangements, or assign one member of senior management to do so. Members of the management body receive regular training in this area. Official text of Article 5
CypherOn commentary
This article is harder to satisfy than it looks, because it is satisfied by records, not by assertions. Minutes of the meeting at which the management body approved the ICT risk management framework, adopted the resilience strategy, set the risk tolerance level and allocated the budget, plus an attendance sheet from the board training — that is the entire evidence pack, and it costs one meeting a year. Without it you cannot show either the ultimate responsibility or the training. It is also the cheapest item in the whole project, so leaving it until the end is a classic sequencing mistake.
Requires a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system, including the protection of physical components and premises. Entities other than microenterprises assign the management and oversight of ICT risk to an independent control function and keep management, control and audit roles separate. The framework is reviewed at least once a year, after a major incident, and on the basis of findings from tests, audits or supervisory instructions; microenterprises review it periodically. The framework includes a digital operational resilience strategy with objectives, indicators, reference architecture and a communication strategy. Verification of compliance may be outsourced, but responsibility stays with the entity. Official text of Article 6
CypherOn commentary
If you run an ISMS certified to ISO/IEC 27001, a substantial part of the framework is already there — but not all of it. What is typically missing is the impact tolerance for ICT disruptions and the risk tolerance level for ICT risk (paragraph 8(b)), the evidence of the current resilience situation based on the number of major incidents reported and the effectiveness of preventive measures (point (f)), and the link to the testing programme under Chapter IV. The report on the review of the framework is submitted upon request, not automatically — which in practice means it has to exist before the authority asks for it. And watch the independence requirement for the control function: in smaller entities of around ten people this is the most common place where the three lines of defence model collapses, because one person runs operations and controls them.
Requires the ICT systems, protocols and tools in use to be up to date, reliable, proportionate to the scale of operations and sufficient in capacity to process data and transaction volumes — including when new technology is introduced. On top of that they must be technologically resilient enough to cope with peak demand under stressed market conditions or other adverse situations. Official text of Article 7
CypherOn commentary
A short article with an uncomfortable reach: a legacy system past end of support that cannot be updated breaches the "up to date" requirement no matter how well it is segmented off. The capacity requirement, in turn, is about behaviour at peak — if your performance tests only ever run against normal traffic, you have no evidence of coping with stressed conditions. Practical guidance: keep a lifecycle plan for key components and run capacity tests against peak load, not average load.
Requires you to identify, classify and document the ICT-supported business functions, information assets and ICT assets, their roles and interdependencies, and to review the classification at least once a year. Sources of risk are identified on a continuous basis and risk scenarios are reviewed at least yearly. Entities other than microenterprises perform a risk assessment after each major change to infrastructure or processes. This also covers records of configurations, interconnections and dependencies, including assets at remote sites, and documentation of the processes that depend on ICT third-party service providers. Official text of Article 8
CypherOn commentary
This is where projects are made or broken. Without a map of "business function → application → infrastructure → provider" you cannot identify critical or important functions, you cannot populate the register of information under Article 28(3), and you cannot scope your testing. It is also the most labour-intensive item, so it is the one most often postponed and then rushed to meet the reporting date. Advice from practice: build the inventory straight away in the shape the register of information under Implementing Regulation 2024/2956 expects — otherwise you will do the work twice.
Requires continuous monitoring and control of the security and functioning of ICT systems, and the deployment of policies, procedures, protocols and tools that ensure resilience, continuity and availability, in particular for systems supporting critical or important functions. The solutions have to protect data in transit, minimise the risk of corruption, loss and unauthorised access, and prevent flaws in data management. This includes a documented information security policy and the supporting controls for access, change and vulnerability management. Official text of Article 9
CypherOn commentary
DORA states this article in general terms, but Regulation 2024/1774 breaks it down into concrete requirements — from identity and privileged access management through cryptography and key management to change and vulnerability management. Work from the DORA text alone and you will get a list of missing policies from your auditor. Build to 2024/1774 and you have the structure the supervisor expects from the start. That is the single most useful thing we can say about Chapter II.
Requires mechanisms to detect anomalous activities, network performance issues and incidents promptly, including the identification of potential single points of failure, and to test those mechanisms regularly. Detection has to allow multiple layers of control, with defined alert thresholds and criteria that trigger the response procedures, including automatic alerting of the staff responsible. Sufficient resources and capabilities have to be dedicated to monitoring user activity and anomalies. Official text of Article 10
CypherOn commentary
Alert thresholds are not a technical detail — they are the clock that decides when your four-hour deadline for the initial notification starts running. If detection does not work at night and at weekends, the incident gets classified on Monday morning and proving that the report was on time becomes hard. Put in writing who picks up an alert at which time of day and how it escalates to the classification decision; otherwise the reporting process rests on whoever happens to be looking at the console.
Establishes a comprehensive ICT business continuity policy and the related response and recovery plans, which have to ensure continuity of critical or important functions, rapid containment of an incident, isolation measures, damage estimation and crisis communication. The plans are tested at least once a year; for entities other than microenterprises this includes cyber-attack scenarios and switch-over to backup capacity. Those entities also set up a crisis management function, and their response and recovery plans are subject to independent internal audit. A business impact analysis and records of disruptions are part of the same package. Official text of Article 11
CypherOn commentary
The most common finding here is not missing plans but plans never tested against the scenario that actually happens: restoring from backup gets tested, failing over to the secondary site during a ransomware event does not. The second frequent gap is the crisis management function — it tends to sit "with the head of IT", which during an incident means the same person handles technical recovery and the communication with the Czech National Bank and clients. Split the roles before you need them, and keep the record of the disruption as it unfolds: the final report under Regulation 2025/301 is built from it later, and reconstructing a timeline after the fact is expensive.
Requires a documented backup policy specifying the scope of the data covered and the minimum backup frequency based on the criticality and confidentiality of the information, together with restoration and recovery procedures and methods. Backup systems have to be capable of activation without jeopardising the security and integrity of data, and both backup and restoration are tested periodically. When restoring from your own systems, the environment used has to be physically and logically segregated from the source system. Central counterparties additionally have to recover all transactions as at the time of disruption. Official text of Article 12
CypherOn commentary
The requirement for a physically and logically segregated restore environment is the answer to ransomware, and in cloud architectures it tends to be met on paper only — a backup in the same tenant and under the same identities is not segregated. Verify three things: that restoration does not require signing in to a compromised directory, that backups cannot be deleted with operational permissions, and that you have actually attempted a restore rather than merely scheduled one. Evidence of a successful restore test is also the most persuasive attachment when you assess a provider under Article 30(3)(c).
Requires you to gather information on vulnerabilities, threats and incidents and to analyse their impact on resilience. After a major incident that disrupted core activities, a post-incident review examines the speed of response, the quality of forensic analysis, and the effectiveness of escalation and communication; entities other than microenterprises report the changes made to the authority upon request. Findings from testing and from real incidents feed into risk assessment and into training. Monitoring of technological developments and security awareness programmes for staff and management are part of the same article. Official text of Article 13
CypherOn commentary
The post-incident review is a cheap way to manufacture evidence that the framework works — and the only place where the Regulation explicitly asks you to assess the quality of forensic analysis. If you buy forensics in, secure the availability of that capacity contractually in advance; arranging it on the day of the incident costs you the first day and with it most of the traces. The output of the review belongs on the management body table, because under Article 6(5) it drives the review of the framework.
Requires crisis communication plans that allow responsible disclosure to clients, counterparties and, where relevant, the public, of at least major incidents and vulnerabilities. The communication strategy is set separately for staff and for external stakeholders, distinguishing between the people who handle the incident and the people who need to be informed. At least one person in the entity is responsible for public and media relations for these purposes. Official text of Article 14
CypherOn commentary
In practice the communication plan collides with two other obligations that run on their own clocks: informing clients under Article 19(3) where an incident affects their financial interests, and a possible personal data breach notification under the GDPR. Running three separate processes with three separate approvers is a reliable way to miss all of them. Prepare pre-approved message templates and a clear rule on who releases them — in a crisis you do not draft, you fill in the details.
Chapter II · Art. 16
Simplified regime for ICT risk management
The simplified regime replaces Articles 5 to 15 with eight obligations. It changes nothing else. Classification and reporting of incidents under Chapter III apply in full, and so does the management of ICT third-party risk under Articles 28 to 30 — with a single exception, the strategy on ICT third-party risk under Article 28(2), which these entities do not have to adopt. From testing, only advanced threat-led penetration testing under Article 26 is carved out; the general testing programme under Article 24 applies unless the entity is a microenterprise. The only thing we left out of this part is Article 16(3), a mandate for a technical standard — that standard is Regulation (EU) 2024/1774, whose Title II spells the simplified framework out.
Takes five groups outside Articles 5 to 15: small and non-interconnected investment firms, payment institutions exempted pursuant to Directive (EU) 2015/2366, institutions exempted pursuant to Directive 2013/36/EU in respect of which the Member State has not applied the option in Article 2(4), electronic money institutions exempted pursuant to Directive 2009/110/EC, and small institutions for occupational retirement provision. In their place it imposes eight obligations: a documented ICT risk management framework including protection of physical components, continuous monitoring of the security of systems, use of sound, resilient and updated tools, prompt identification of sources of risk and of anomalies, identification of key dependencies on ICT third-party service providers, business continuity plans with backup and recovery measures, regular testing of those plans and controls, and feeding the findings back into risk assessment and training. The framework is documented, reviewed periodically and revised after major incidents; the report on the review is submitted upon request. Official text of Article 16
CypherOn commentary
The most common misconception in the whole Regulation: a microenterprise is not on the list in Article 16(1). Being a microenterprise means relief inside Articles 5 to 15 (no independent control function, no internal audit of the framework, no crisis management function and no testing programme under Article 24), but the framework under Article 6 still applies to you. Conversely, an entity in the simplified regime may well be larger than a microenterprise, and Articles 5 to 15 do not apply to it at all. The second trap is the word "simplified" — the eight obligations in points (a) to (h) amount to a complete small security programme, and Regulation 2024/1774 breaks them down into specific policies. If you are unsure which group you belong to, your status under the sectoral directive decides, not your headcount; we can walk through it in the FAQ.
Chapter III
Incident management, classification and reporting (Articles 17 to 23)
This chapter applies to all financial entities, including those in the simplified regime, and it is the part where failure is most visible — a missed deadline carries a date. We cover Articles 17 to 20, 22 and 23. We left out Article 21, because it tasks the European Supervisory Authorities with preparing a report on the feasibility of a single EU hub for receiving reports; nothing follows from it today for the obligations of a financial entity. The deadlines and thresholds themselves are not in DORA — they sit in the standards that follow it, which we cite at Articles 18 and 20.
Requires a process to detect, manage and report incidents, and the recording of all incidents and significant cyber threats. The process has to include early warning indicators, procedures for logging, categorising and classifying incidents by priority and severity, allocation of roles for different scenarios, communication plans covering client information and internal escalation, and response procedures with secure restoration of services. Major incidents are reported to senior management and the management body is informed about them, including impacts and the measures taken. Official text of Article 17
CypherOn commentary
The duty to record all incidents, not just the major ones, is underrated. It is a practical insurance policy: without a record of ordinary incidents you cannot show why you did not classify a particular event as major, and that is exactly the question that comes after your first report. We recommend a mandatory field in the ticket holding the outcome of the assessment against the Article 18 criteria and the time the assessment was completed — the four-hour deadline runs from that moment.
Sets six criteria for assessing the impact of an incident: the number or relevance of clients and financial counterparts affected and the volume of transactions, including reputational impact; duration and service downtime; geographical spread; data losses; the criticality of the services affected; and economic impact. Cyber threats are classified as significant according to the criticality of the services at risk, who is affected, and how wide an area is involved. DORA does not set the thresholds for these criteria — it delegates them to a technical standard. Official text of Article 18
CypherOn commentary
The thresholds are in Delegated Regulation (EU) 2024/1772: under its Article 8(1) an incident is major where critical services under Article 6 are affected and, in addition, either there has been successful malicious and unauthorised access with possible data loss, or two or more of the other thresholds in Article 9(1) to (6) are met. The counting unit is the paragraph, not the condition inside it: more than 10 % of clients and at the same time more than 10 % of transactions is one threshold, because both sit in the same paragraph. This is the most common classification error and it goes wrong in both directions. Our page on classification and deadlines walks you through the criteria.
Art. 19
Reporting of major ICT-related incidents and voluntary notification of significant cyber threats
¶Requires major incidents to be reported to the competent authority in three steps: an initial notification, an intermediate report when the status or the handling of the incident changes materially, and a final report once the root cause analysis is complete and estimates have been replaced by actual figures. Significant cyber threats may be notified voluntarily. Where an incident affects the financial interests of clients, the entity informs them without undue delay. Reporting may be outsourced, but responsibility for meeting the obligation stays with the financial entity. The authority passes the information on — to the European Supervisory Authorities, the ECB, the NIS2 authorities and the resolution authorities. Official text of Article 19
CypherOn commentary
In the Czech Republic reports go to the Czech National Bank as a return in the SDAT system; without SDAT registration and an LEI code the report will not go out, which is something to sort out in advance rather than during an incident. The deadlines are in Regulation 2025/301: the initial notification within 4 hours of classifying the incident as major and no later than 24 hours from becoming aware of it; the intermediate report within 72 hours of the initial notification; the final report within one month. A deferral to the next working day exists, but it does not apply to the initial notification or the intermediate report for credit institutions, central counterparties, trading venue operators and other entities identified under NIS2 as essential or important — and the competent authority may switch it off for others as well. Our deadline calculator works out the actual dates.
Mandates the European Supervisory Authorities to develop technical standards setting the content of a major incident report, the content of a significant cyber threat notification and — the part that matters most in practice — the time limits for the initial notification and for each of the follow-up reports. The second standard creates standard forms, templates and procedures for submission. Official text of Article 20
CypherOn commentary
Anyone looking for the deadlines in DORA itself will not find them — this is where they are delegated. The result is two standards: Delegated Regulation (EU) 2025/301 for content and deadlines and Implementing Regulation (EU) 2025/302 for the forms and procedures. The practical consequence: your internal incident reporting procedure should reference those two standards, not Article 19 of DORA, because every deadline and every field of the return lives there.
The competent authority acknowledges receipt of the initial notification and of each report, and may provide the entity with proportionate feedback or general guidance, including anonymised information on similar threats, and discuss the remedies applied. Responsibility for handling the incident and its consequences does not shift to the authority. The European Supervisory Authorities report annually, in aggregated and anonymised form, on major incidents and issue warnings and statistics. Official text of Article 22
CypherOn commentary
The sentence about responsibility staying with the entity has practical content: an acknowledgement of receipt is not approval of your handling, and supervisory silence is not consent. When you receive guidance or a recommendation from the supervisor, file it with the incident and document what you did with it — it is the first thing that comes up at the next contact.
Extends the requirements of the whole of Chapter III, for credit institutions, payment institutions, account information service providers and electronic money institutions, to operational or security payment-related incidents, including major ones. Official text of Article 23
CypherOn commentary
For the payments sector this means the reporting regime does not depend on whether the cause was "cyber" — an operational outage of a payment service with no attacker in sight falls under the same rules. In practice it ends the old habit of routing cyber and operational events through two different channels to two different people; unifying the process is the cheapest measure available here.
Chapter IV
Digital operational resilience testing (Articles 24 to 27)
The chapter has two tiers. General testing under Articles 24 and 25 applies to all financial entities other than microenterprises, including those in the simplified regime. Advanced threat-led penetration testing under Articles 26 and 27 applies only to entities identified by the competent authority, and entities in the simplified regime as well as microenterprises are carved out of it. We cover all four articles; the only things left out are the paragraphs mandating technical standards, whose result we cite at Article 26.
Requires entities other than microenterprises to establish and maintain a testing programme as part of the ICT risk management framework, built on a risk-based approach. Tests are carried out by independent internal or external parties, and where they are run internally, conflicts of interest have to be ruled out. Issues found are prioritised, classified and remediated, and an internal methodology verifies that the remediation was complete. Systems and applications supporting critical or important functions are tested at least yearly. Official text of Article 24
CypherOn commentary
The yearly test under paragraph 6 is the obligation smaller entities miss most often, because it gets confused with the advanced testing under Article 26, which does not apply to them. Article 26 does not — Article 24 does. The second point is independence: letting your own developers test their own application is not enough, however good the test technically is. And mind the closing of the loop — without documented verification of remediation, a test is just a list of findings, which from a supervisory point of view is worse than no test at all, because you knew about the problem.
Lists the types of test the programme covers: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Central securities depositories and central counterparties carry out vulnerability assessments before any deployment of new or existing components supporting critical or important functions. Microenterprises test on the basis of risk and a strategic plan, having regard to their resources. Official text of Article 25
CypherOn commentary
The list is not a shopping list — it is a menu you choose from according to risk, and you have to be able to justify the choice. Source code review carries the qualifier "where feasible", so for bought-in software it is replaced by other assurances (provider test results, certifications, contractual warranties). A practical pointer you will not find in the text: schedule the tests so that their output lands in time for the annual review of the framework under Article 6(5) — otherwise the review has nothing to build on.
Entities identified by the competent authority carry out threat-led penetration testing at least every three years; the frequency may be adjusted according to the risk profile. The test runs on live production systems supporting selected critical or important functions and its scope is validated by the authority. Where ICT third-party service providers are within scope, the entity secures their participation; where there is a risk of impact on the provider's other customers, pooled testing by several financial entities can be arranged. Once completed, a summary of findings and remediation plans is submitted to the authority, which issues an attestation enabling mutual recognition of tests. An entity using internal testers has to use external testers for every third test; significant credit institutions use external testers exclusively. Official text of Article 26
CypherOn commentary
This is not an ordinary penetration test — it is a controlled red team exercise driven by threat intelligence scenarios, with the supervisor involved and a duration measured in months. In the Czech Republic the framework is TIBER-EU, which the Czech National Bank adopted in September 2024 and for which it issued the TIBER-CZ implementation guide in March 2025. The detail on testers and test phases is in Delegated Regulation (EU) 2025/1190. For entities that are not identified for TLPT there is still a useful pointer here: the yearly test under Article 24(6) should test your ability to detect and respond, not just produce output from a vulnerability scanner.
Testers may only be engaged where they are of the highest suitability and reputability, demonstrate expertise in threat intelligence, penetration testing and red team testing, hold certification from an accreditation body or adhere to formal codes of conduct or ethical frameworks, provide independent assurance of sound management of the risks associated with the testing, and carry professional indemnity insurance. Where internal testers are used, the competent authority has to approve their use, verify that resources are sufficient and that conflicts of interest are avoided, and the threat intelligence provider has to be external. The contract with the tester has to deal with the handling of the results. Official text of Article 27
CypherOn commentary
The requirements on testers are worth knowing even for entities outside TLPT — they are sensible selection criteria for any offensive testing engagement and can be lifted into a request for proposal unchanged. Two items are missing most often: professional indemnity insurance, and contractual treatment of what happens to the test results (where they are stored, who has access, when they are destroyed). A red team report is a manual for compromising you; treating it as an ordinary email attachment is a security incident of its own.
Chapter V · Section I
Managing of ICT third-party risk (Articles 28 to 30)
Three articles with the widest reach outside the financial sector — through contracts they land on every ICT provider. For a financial entity the whole section applies, including entities in the simplified regime, with a single exception: the strategy on ICT third-party risk under Article 28(2) does not have to be adopted by entities under Article 16(1) or by microenterprises. We cover all three articles. What is left out are the paragraphs mandating technical standards — their results (the register of information templates and the rules on subcontracting) are cited at the provisions they belong to.
Provides that the financial entity remains responsible for compliance at all times, even where a service is delivered by a provider. Entities other than microenterprises and other than entities in the simplified regime adopt a strategy on ICT third-party risk. All financial entities maintain a register of information on contractual arrangements for ICT services, distinguishing within it the arrangements supporting critical or important functions, report at least yearly to the authority on the number of new arrangements and the categories of providers, and inform the authority in advance of a planned arrangement covering a critical or important function. Before a contract is concluded, the risks including concentration risk have to be assessed, the provider and its security standards vetted, and conflicts of interest addressed. The article further lists the grounds on which it must be possible to terminate the contract, and for critical or important functions it requires tested exit strategies. Official text of Article 28
CypherOn commentary
The register of information is submitted to the Czech National Bank through the SDAT system, and its structure is set by Implementing Regulation (EU) 2024/2956 in fifteen templates. Two things kill a register most often: a missing LEI code (without it the return will not pass) and an unresolved rank in the supply chain — the direct provider is always rank 1, a subcontractor higher, and the standard sets no fixed number of layers. The exit strategy is the other underrated item: the Regulation wants it tested, not merely written, and a dry run of getting your data back from a provider is the only way to find out whether they hand it over in a usable format. There is a detailed walkthrough in the guide.
Before concluding a contract for a service supporting a critical or important function, you have to consider whether the provider is hard to substitute, or whether several such contracts are accumulating with one provider or with closely connected providers, and to weigh the benefits and costs of alternatives. Where the contract permits subcontracting, the benefits and risks of subcontracting are assessed, in particular where the subcontractor is established in a third country. For providers from third countries, insolvency law, compliance with Union data protection rules and enforceability of law are considered as well, and for long subcontracting chains, whether the entity and the authority are able to supervise the service at all. Official text of Article 29
CypherOn commentary
In practice concentration risk is not assessed at the level of the provider but at the level of the dependency: three different SaaS applications running at the same hyperscaler are one concentration, even with three separate contracts. Record indirect dependencies too (where the service physically runs), otherwise the assessment always comes out favourably. The elements to be identified and assessed for the subcontracting of critical functions are set out in Delegated Regulation (EU) 2025/532.
The rights and obligations of the parties have to be in writing, in a single document including the service level agreements. Paragraph 2 lists nine elements required in every contract for ICT services: a description of the functions and the conditions for subcontracting, the locations where services are provided and data processed together with a duty to notify changes, provisions on availability and data protection, rights of access to and return of data on insolvency or termination, service level descriptions, assistance during an incident at pre-agreed cost, cooperation with the authorities, termination rights with notice periods, and participation in training. Paragraph 3 adds six more for services supporting critical or important functions: precise quantitative service level targets, notification obligations of the provider, its own business continuity plans and security measures, participation in threat-led penetration testing, unrestricted rights of access, inspection and audit including on-site inspections, and an exit strategy with a transition period. The parties are to consider the use of standard contractual clauses developed by public authorities. Official text of Article 30
CypherOn commentary
This is the article behind the contract amendments landing on software houses from their banking clients — and it helps to know what cannot be struck out and what can. Audit rights and on-site inspections for critical functions (paragraph 3(e)) cannot go, and neither can the exit with a transition period. What is negotiable is the frequency and scope of audits, agreed in advance on a risk basis (Article 28(6)), the use of standard clauses instead of bespoke inventions (paragraph 4), and — where the financial entity is a microenterprise — having the audit rights exercised by an independent third party appointed by the provider (last subparagraph of paragraph 3). A point-by-point analysis from the provider side is in the guide.
Chapter V · Section II
Oversight of critical ICT providers (Articles 31 to 44)
This section introduces direct European oversight of providers that are not financial entities — historically a new thing. It concerns a narrow group: only providers designated by the European Supervisory Authorities become critical. We cover Articles 31, 33, 35, 42 and 43, that is designation, the tasks and powers of the Lead Overseer, the effect on financial entities, and fees. We left out Articles 32, 34, 36 to 41 and 44 — they govern the internal arrangements of the oversight framework (the Oversight Forum, coordination, requests for information, investigations, inspections, joint examination teams, international cooperation). No standalone obligation follows from them for the decisions of a financial entity or a provider.
The European Supervisory Authorities designate critical providers against four criteria: the systemic impact of a failure, the systemic importance of the financial entities served, the degree of reliance on the provider for critical or important functions, and its substitutability. A designated provider is assigned a Lead Overseer and has six weeks to submit a reasoned statement. Designation does not apply, among others, to intra-group providers or to those operating in a single Member State. The list of critical providers is published and updated yearly, and a provider may also request to be designated. A critical provider from a third country has to establish a subsidiary in the Union within 12 months of designation, otherwise its services cannot be used. Official text of Article 31
CypherOn commentary
The vast majority of providers will never be critical — the criteria are aimed at hyperscalers and large infrastructure providers serving the whole sector. The practical significance of the article lies elsewhere: your contract with a critical provider may change because of a decision you have no influence over, including the measure of last resort under Article 42(6). That is why an exit plan makes sense even where the provider looks unshakeable. The designation criteria are specified in Delegated Regulation (EU) 2024/1502.
The Lead Overseer is the main point of contact for a critical provider and assesses whether it has comprehensive rules and mechanisms in place to manage the ICT risk it may pose to financial entities. The assessment focuses on services supporting critical or important functions and is extended to the others where needed. It covers requirements on security, availability, continuity, scalability and quality of services, physical security including data centres, risk management processes, business continuity plans and testing. Official text of Article 33
CypherOn commentary
For a financial entity there is an indirect but useful consequence here: the assessment areas of the Lead Overseer make a good checklist for your own provider assessments. Asking a provider the same questions the supervisor asks (continuity, testing, physical security, subcontracting) gives you both comparable answers across providers and an argument for why you have to ask at all.
The Lead Overseer may request information and documentation, conduct general investigations and inspections, require remediation reports and issue recommendations — among other things on security requirements, on the contractual terms offered to financial entities, and on planned subcontracting. Where a provider fails to comply with the measures imposed, the Overseer decides on a periodic penalty payment after a period of at least 30 calendar days. The penalty is imposed on a daily basis until compliance is achieved, for a maximum of six months, and amounts to up to 1 % of the average daily worldwide turnover of the provider in the preceding business year. Penalties imposed are published. Official text of Article 35
CypherOn commentary
The periodic penalty payment is built as a means of compulsion, not as punishment for the past — it accrues daily for as long as non-compliance lasts. For a provider that is a material difference from a one-off fine, and in practice it means a dispute with the supervisor is worth resolving fast rather than well. Recommendations under point (d) are not binding as such; it is failing to follow them that triggers the follow-up measures under Article 42, and those land on the provider's customers.
A critical provider has 60 calendar days to state whether it will follow the recommendations or explain why not; an inadequate explanation or silence is published by the Lead Overseer, including the identity of the provider. National authorities inform the financial entities concerned about the risks arising from the recommendations, and the entities have to take them into account in their management of third-party risk. Where they do not, the authority alerts the entity and, as a measure of last resort, may decide that financial entities must temporarily suspend, in whole or in part, the use of the critical provider's services, or terminate the contracts. Before deciding, the authority weighs the severity of the breach and the risk to the continuity of the entity's business, and grants it a period to adjust contracts and trigger exit plans. Official text of Article 42
CypherOn commentary
This is the hardest instrument in the whole Regulation and it lands on the customer, not on the provider: it is the financial entity that gets told to stop using the service. It is also the best argument for treating the exit strategy under Article 28(8) as more than a formality — "the regulator has banned our current solution" is the only scenario in which the transition plan is triggered through no fault of yours and with no time to prepare. For critical or important functions, keep at least a rough estimate of the time and cost of migration; without it there is no basis for deciding anything when the measure of last resort arrives.
Critical providers are charged fees that fully cover the costs of the Lead Overseer in carrying out oversight, including the work of joint examination teams and the cost of independent experts. The fee is proportionate to the turnover of the provider and the detail is set by a delegated act. Official text of Article 43
CypherOn commentary
The practical impact is indirect but real: at critical providers, oversight fees and the cost of servicing that oversight feed into the price of services for the financial sector. When budgeting multi-year contracts with large providers, treat it as a factor pushing prices up. The method for calculating the fees is set out in Delegated Regulation (EU) 2024/1505.
Chapters VI to IX
Information sharing, supervision, penalties and application (Articles 45 to 64)
The closing part of the Regulation governs the sharing of threat information, the designation of competent authorities, their powers and penalties, and finally application. We cover Articles 45, 46, 50 and 64. We left out Articles 47 to 49 and 51 to 57 (cooperation between authorities, cross-sector exercises, exercise of the power to impose penalties, criminal penalties, publication of penalties, professional secrecy, data protection, delegated powers) and Articles 58 to 63, which are the review clause and amendments to other regulations. No standalone obligation follows from them for the day-to-day decisions of a financial entity; and anyone dealing with penalty proceedings needs the Czech Act No. 31/2025 Coll. anyway.
Allows financial entities to exchange threat information — indicators of compromise, tactics, techniques and procedures, alerts and configuration tools — where this improves their resilience, takes place within trusted communities, and is governed by arrangements that protect the sensitivity of the information shared, business secrets, personal data and competition rules. The arrangements set the conditions for participation, any involvement of public authorities and ICT providers, and the operational detail including the platforms used. The entity notifies the competent authority of its participation and of its withdrawal. Official text of Article 45
CypherOn commentary
Sharing is voluntary, but notifying your participation is not — and that is the part people forget. Before you join a sector community, check three things: how personal data inside indicators is handled, whether the rules of the community (typically the TLP protocol) map onto your internal classification scheme, and who is allowed to send information on your behalf. Without the third one, sooner or later the community receives more than you intended to send.
Determines which authority supervises compliance with the Regulation, by type of entity — for credit institutions the authority under Directive 2013/36/EU and, for significant banks, the ECB; for payment institutions and electronic money institutions the authority under Directive (EU) 2015/2366; for investment firms the authority under Directive (EU) 2019/2034, and similarly for the other sectors. Oversight of critical ICT providers is unaffected and belongs to the framework in Chapter V, Section II. Official text of Article 46
CypherOn commentary
In the Czech Republic the competent authority is the Czech National Bank; this follows from Act No. 31/2025 Coll. on the digitalisation of the financial market, which also sets out its powers and the related offences. In practice this means a single address for the register of information, incident reports and questions — with SDAT as the channel. How roles are divided between the ČNB and NÚKIB, the Czech cyber security agency, for entities caught by both regimes is described in their joint statement, which we summarise in the guide.
Competent authorities are to have supervisory, investigatory and sanctioning powers — access to documents and data, on-site inspections, summoning representatives of the entity, and the ability to require remedial measures. Member States lay down effective, proportionate and dissuasive administrative penalties and remedial measures, including an order to cease unlawful conduct and the temporary or permanent cessation of a given practice. Paragraph 5 contemplates that penalties and remedial measures may also be applied to members of the management body and other responsible individuals. Official text of Article 50
CypherOn commentary
DORA sets no specific fine amounts — the Member State does. In the Czech Republic that is Act No. 31/2025 Coll., which defines offences separately for financial entities and for providers; we go through the amounts and how they attach to individual obligations in the FAQ. For the board, paragraph 5 matters more: liability can land personally, which is worth knowing in advance when approving the framework and the budget under Article 5.
The Regulation entered into force on the twentieth day following its publication in the Official Journal, that is on 16 January 2023, and applies from 17 January 2025. It is binding in its entirety and directly applicable in all Member States. Official text of Article 64
CypherOn commentary
The two dates still get mixed up, even in sources otherwise worth citing: the Czech National Bank described 17 Jan 2025 as the date the Regulation "took effect", although under Article 64 it is the date of application. Substantively it changes nothing — since 17 Jan 2025 the obligations are enforceable and the two-year run-up is over. Anyone only starting now has no grace period: a register of information that does not exist or a missing reporting process are detectable immediately, without an on-site inspection.