DORA Technical Standards Explained

DORA sets the framework, and technical standards fill in much of the detail, and DORA itself applies from 17 January 2025. Regulatory technical standards and implementing technical standards, developed by the European Supervisory Authorities and adopted through the European legislative process, specify matters such as how incidents are classified and reported, what a register of ICT third-party information should contain, and how certain testing and oversight arrangements work. A firm that reads DORA alone, without the standards that apply to its activities, will have the shape of its duties but not the detail needed to carry them out.

The key practical point is timing. A standard applies on the date stated in that standard, which may differ from the date DORA itself starts to apply, so a compliance picture has to track standards individually rather than assuming that everything begins together. That staggered picture is one reason the timeline for DORA keeps moving after its application date.

The European Supervisory Authorities, the European Banking Authority, the European Insurance and Occupational Pensions Authority, and the European Securities and Markets Authority, develop draft technical standards within their respective areas, drawing on consultation and on the mandates in DORA itself. Drafts then go through adoption, with the European Commission adopting standards and the European Parliament and Council exercising scrutiny under the relevant procedures. The division of labour matters for a reader, because a banking, insurance, or securities lens may shape a particular standard, and because guidance and questions and answers from an authority can clarify how a standard is meant to be read. A firm should therefore note not only what a standard says, but which authority developed it and what accompanying material explains it.

In broad terms, regulatory technical standards specify substantive detail that DORA leaves open, such as criteria, methods, or content requirements, while implementing technical standards specify uniform formats, templates, and procedures for putting those requirements into practice. The distinction is useful when a firm is planning work: a regulatory standard may change what must be assessed or recorded, while an implementing standard may change the form in which information is reported or held. Both kinds carry legal weight once adopted and applicable, and both deserve the same tracking discipline. Guidance, by contrast, explains or clarifies without itself creating the same kind of binding detail, and confusing guidance with a standard is a common source of error.

DORA standards cover the practical machinery of the regime. Incident related standards deal with classification criteria and reporting templates, so that firms and authorities describe incidents in comparable terms. Register related standards deal with the information a firm keeps about its ICT third-party providers, so that its reliance can be inspected and understood. Other standards deal with matters such as subcontracting chains, testing arrangements, and oversight cooperation, each filling a gap that the framework regulation deliberately leaves to detailed rules. A reader does not need to memorise every standard to understand DORA, but a firm does need to identify which standards touch its services, its incident process, its testing programme, and its provider relationships, and to keep that identification current.

Tracking begins with a simple list, kept per service or per duty, of the standards that apply, their stated application dates, and the internal owner for each one. When a new standard is adopted or an existing one is amended, the list should trigger a review of the affected process, template, or register, rather than a general note that something has changed. The review should ask what has changed in substance, what has changed in form, and whether contracts, incident playbooks, or test plans need revision as a result. A list without owners and without a review trigger is a bibliography, not a tracking system, and it will quietly fall behind as the standards landscape develops.

A change in a standard can change a reporting template, a classification threshold in the sense of a criterion, a register field, or a testing expectation, and the firm needs to know which of its artefacts are affected. The change may require retraining for incident handlers, a revised register, an amended contract clause, or a redesigned test, depending on its content. The discipline is to treat a standard change like any other change to a service dependency: assess its impact, assign an owner, set a revision date, and record the decision. Firms that handle standard changes through a single central inbox, with no link to the services they affect, often discover the change only when a supervisor asks for a report in a new format.