DORA Chapters at a Glance

DORA is organised into chapters that each handle a different part of digital operational resilience, and the regulation applies from 17 January 2025. ICT risk management sets the foundation, incident reporting deals with disruption when it happens, testing checks whether recovery would work, third-party risk deals with reliance on outside providers, and information sharing deals with learning across the sector, while supervision and oversight run across the whole. Read separately, each chapter looks like a self contained topic. Read together around a single service, they describe a loop: understand risk, detect and report trouble, prove recovery, manage reliance, and learn.

An asset management illustration helps, and it is only an illustration. A trading and valuation service depends on market data, a portfolio system, and a custodian link. Risk management asks what could break that chain, incident reporting asks how a break would be recognised and communicated, testing asks whether valuation could be restored, third-party risk asks what the data and custody providers owe, and information sharing asks what the wider sector could learn.

The ICT risk management chapter asks a financial entity to build and maintain a framework for identifying, protecting, detecting, responding to, and recovering from ICT risk, with governance, policies, and controls that fit the firm's risk profile. In service terms, the chapter is about knowing the service, knowing what it depends on, and knowing what would hurt it. It includes the familiar disciplines of access control, network security, data protection, and incident response planning, but its centre of gravity is the service view: a control matters because it protects a particular service, a particular data set, or a particular recovery path. A risk register that lists generic threats without tying them to services will struggle to guide decisions during a disruption.

The incident chapter deals with ICT-related incidents, including how they are classified, how they are reported to a competent authority, and how they are followed up. The practical heart of the chapter is classification: not every glitch is an incident of the kind DORA is concerned with, and a firm needs criteria that let staff distinguish routine trouble from a disruption that affects a service, its customers, or its data. Once classified, an incident needs a clear reporting path, a record of decisions and times, and a follow-up that feeds back into risk management and testing. A reporting process that produces a form but no learning has missed the chapter's purpose, because the next incident will meet the same weaknesses.

The testing chapter asks for a programme of digital operational resilience testing, proportionate to risk, that checks whether ICT systems, controls, and recovery arrangements work as intended. Testing ranges from routine checks and scenario exercises to more advanced threat-led penetration testing, known as TLPT, for entities and services where the risk picture calls for it. The value of testing lies less in a pass mark and more in what it reveals: a recovery step that depends on a person who is unavailable, a backup that cannot be restored in the order needed, or a provider whose role was misunderstood. Test findings should travel back into the risk framework and into incident plans, closing the loop that the chapter structure implies.

The third-party risk chapter addresses reliance on ICT third-party providers, including due diligence, contractual terms, ongoing monitoring, and exit planning, together with a register of information about provider relationships. Its logic is straightforward: a firm remains responsible for its service even when a provider operates part of it, so the firm needs rights and information that let it understand, oversee, and if necessary leave a relationship. The information sharing chapter, by contrast, allows financial entities to share cyber threat information and intelligence within trusted arrangements, under conditions that protect confidentiality and comply with applicable law. Sharing is voluntary in design, and its purpose is collective learning: a threat seen by one firm may soon be seen by others.

A useful way to use the map is to pick one service and walk it through every chapter in turn, asking at each step what changes for that service. What risk does the chapter reveal, what incident would it surface, what test would prove recovery, what provider does it depend on, and what lesson could be shared? If a chapter produces no answer for that service, the gap may be a missing control, a missing provider record, or simply a service that was mapped too thinly. Supervision sits over the whole walk, since competent authorities look for evidence that the chapters connect in practice, not merely that each chapter has a document of its own. That service walk is the bridge between this overview and the detailed guides in the cluster.