The term the whole Regulation turns on
Regulation (EU) 2022/2554, known as DORA, binds the financial sector rather than industry at large. Banks, insurers, investment firms and payment institutions are all in scope; Article 2 carries the full list of categories that count as a financial entity. Every obligation in the Regulation traces back to one defined term. Article 3(1) defines digital operational resilience as the ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services provided by ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems it uses, and which support the continued provision of financial services and their quality, including throughout disruptions.
ICT is the EU's term for information and communications technology, so an ICT third-party service provider is simply an IT supplier under its regulatory name.
Three parts of that sentence carry the rest of the text.
- Build, assure and review. Resilience is not a property an entity simply has. It has to be evidenced, and re-examined on a cycle.
- Directly or indirectly. Capabilities bought in from a provider count as the entity's own. Contracting out the service does not contract out the resilience.
- Continued provision, and its quality, including throughout disruptions. The standard is not the absence of incidents; it is that the financial service keeps being delivered while one is running.
Because DORA is a Regulation, this definition is the operative legal standard in every Member State without any national transposition. An Irish fund manager, a Dutch payment institution and a Nordic insurer are measured against the same wording, in the same language it was drafted in.
Resilience is a wider question than security
Information security asks whether a system is protected against unauthorised access, manipulation and failure. Resilience asks what happens once that protection fails: whether the entity notices the incident, contains it, keeps its essential services running or restores them quickly, learns from it, and can demonstrate all of that afterwards.
That reaches past confidentiality, integrity and availability. It ties information security, business continuity and crisis management, third-party management and testing into a single outcome: the financial service stays deliverable.
How DORA turns the objective into obligations
The Regulation breaks the objective into five connected blocks of requirements.
| Building block | Chapter | The question it answers |
|---|---|---|
| ICT risk management | Chapter II | Do we know our risks, and do we steer them inside a documented framework? |
| Incident management, classification and reporting | Chapter III | Do we detect, classify and report incidents in an orderly way? |
| Digital operational resilience testing | Chapter IV | Do we test our assumptions instead of trusting them? |
| Management of ICT third-party risk | Chapter V | Do we control the dependencies we bought? |
| Cyber threat information sharing | Chapter VI | Do we learn from what happens to others? |
Five blocks or six areas? Both are right
Supervisory publications and advisory materials describe the same Regulation as both "five pillars" and "six areas". That is not a contradiction; it comes from counting two different parts of the Regulation.
Article 1(1)(a) lists six requirements that apply to financial entities: ICT risk management; reporting of major ICT-related incidents and, on a voluntary basis, of significant cyber threats; reporting of major operational or security payment-related incidents by certain financial entities; digital operational resilience testing; the sharing of information and intelligence on cyber threats and vulnerabilities; and measures for the sound management of ICT third-party risk.
The chapter structure folds the two reporting strands, points (ii) and (iii), together and so arrives at five. A third count appears when the third-party topic is split into its two sections: the general principles and contractual requirements of Chapter V, Section I on one side, the oversight framework for critical ICT third-party providers in Section II on the other. That also produces six.
| Way of counting | Comes to | Because |
|---|---|---|
| Chapters of the Regulation | five | the two reporting strands sit in one chapter |
| Article 1(1)(a) | six | the payment-related report is its own point there |
| Chapters with the third-party oversight framework counted separately | six | Chapter V, Sections I and II are run as distinct |
For your own work the number is beside the point. For reading somebody else's documents it is not: if a gap analysis is run against a list of five, check whether the payment-related report and the oversight framework are included in it or have fallen out.
The digital operational resilience strategy
Article 6(8) requires the ICT risk management framework to include a digital operational resilience strategy setting out how the framework is to be implemented. The Regulation lists what that strategy has to do: explain how the framework supports the business strategy and objectives; establish the risk tolerance level for ICT risk and analyse the impact tolerance for ICT disruptions; set clear information security objectives including key performance indicators and key risk metrics; explain the ICT reference architecture and any changes needed; outline the mechanisms for detecting incidents and preventing their impact; evidence the current resilience situation on the basis of the number of major ICT-related incidents reported and the effectiveness of preventive measures; implement resilience testing; and outline a communication strategy for ICT-related incidents.
The point most often skipped is impact tolerance. The Regulation asks not only how much risk the entity is prepared to carry, but how much disruption the delivery of the service can absorb before the answer stops being acceptable. Those are two different questions and they produce two different numbers.
The management body owns it
Under Article 5(2)(d) the management body bears the overall responsibility for setting and approving the strategy, including determining the appropriate risk tolerance level for ICT risk. On organisational structure the Regulation gets unusually specific: under Article 6(4), financial entities other than microenterprises have to assign responsibility for managing and overseeing ICT risk to a control function, ensure an appropriate level of independence for that function, and ensure appropriate segregation of ICT risk management, control and internal audit functions, expressly "in accordance with the three lines of defence model or an internal risk management and control model". A governance model that elsewhere counts as good practice is, for this scope, written into the text of the Regulation.
The management body also bears ultimate responsibility for managing ICT risk, approves the ICT business continuity policy and the ICT response and recovery plans, allocates the budget, and has to keep its own knowledge current through regular training. Digital operational resilience is expressly not a matter a board can leave with the IT function.
Proportionality
Under Article 4, financial entities implement the rules of Chapter II in accordance with the principle of proportionality, taking into account their size and overall risk profile and the nature, scale and complexity of their services, activities and operations. Application of Chapters III, IV and V, Section I is likewise proportionate, as specifically provided for in the rules of those Chapters. Competent authorities consider how the principle has been applied when they review the ICT risk management framework, which makes proportionality a reasoned design decision to be documented, not a discount to be claimed.
What evidence looks like
Because the definition includes reviewing, evidence is not an extra. The artefacts that carry it are the ones the Regulation requires anyway: the documented framework, reviewed at least once a year; the results of the testing programme; incident records including post-incident analysis; the register of information; and the reporting lines into the management body. An entity that produces these continuously has nothing to reconstruct when an inspection is announced.
How Rizzqo makes resilience evidenceable
Resilience is a state you can assert and must prove. In Rizzqo the proof comes out of execution: a critical function's coverage follows from the objects carrying it and from the requirements finalised against them. An object counts as fully covered only once every attached requirement has been closed as fulfilled or as not applicable; an answer marked fulfilled but still open continues to count as a gap.
For a supervisor the time axis matters at least as much as the current state. A daily snapshot freezes the values, so improvement can be shown as a trend rather than as an assurance given on the examination date.