ICT reference architecture: what DORA requires and how to build it

This page covers the full framework under Articles 5 to 15 of DORA, for example CRR credit institutions, insurance undertakings and fund management companies. Which framework applies to you is explained on the page DORA applicability. For institutions in the simplified framework under Article 16, a section further down shows what remains.

Where does DORA mention the ICT reference architecture?

In Article 6(8)(d). It is often attributed to Article 8, but the legal text uses the term only in this one place: the digital operational resilience strategy (DOR strategy) includes methods to address ICT risk and attain specific ICT objectives by “explaining the ICT reference architecture and any changes needed to reach specific business objectives”. The German version says the same. Delegated Regulation (EU) 2024/1774 (the RTS) does not use the term.

There is no definition. BaFin points out that the term is new in DORA and not defined in Article 3, so that the boundaries may be blurred. It considers the requirement comparable to the strategic development of the IT architecture under chapter 1.2(d) of the BAIT and VAIT (BaFin supervisory notice of 8 July 2024, section 1.1, in German). Because the reference architecture is part of the DOR strategy, the management body sets and approves it together with the strategy (Article 5(2)(d)). What else the DOR strategy must contain is shown on our page ICT risk management under DORA.

What does Article 8 DORA require?

Article 8 governs identification: functions, assets and dependencies are identified, classified, documented and kept in inventories. Information assets are collections of information, tangible or intangible, that are worth protecting. ICT assets are software or hardware assets in the network and information systems (Article 3(6) and (7)).

Articles 4 and 5 of the RTS add detail. The ICT asset management policy covers the lifecycle and prescribes the records to keep for each ICT asset (Article 4(2)(b)(i) to (ix), example below). The procedure under Article 5 sets the criteria for assessing the criticality of assets: the ICT risk of the supported functions and the impact of a loss of confidentiality, integrity and availability. Which functions are critical or important you decide using the method on our page Classifying critical or important functions.

How do the reference architecture and the inventories fit together?

The reference architecture is the target, the Article 8 inventories are the current state. Point (d) requires both to be considered together, because the DOR strategy has to explain the changes needed to reach business objectives. Those changes follow from comparing target and current state. We therefore work in three stages:

1. Target: architecture principles and structural models that set how ICT should be built. Independent of products, so that it does not age with every purchase.
2. Current state: the inventories under Article 8(6) with functions, assets, configuration, links and providers.
3. Changes: each gap becomes a measure with rationale, priority and owner. The DOR strategy explains the major ones.

DORA prescribes no method. BaFin describes DORA as standard-neutral, and the RTS only asks for leading practices and, where applicable, standards to be taken into account (RTS Article 2(2)(h)). We use terms from the TOGAF Standard of The Open Group as our method (TOGAF is a trademark of The Open Group): target architecture, baseline architecture and architecture principles. A TOGAF certification or a TOGAF project is not needed for this.

What belongs in an ICT reference architecture?

DORA does not set the content. Our professional recommendation is two levels in one document:

Architecture principles are lasting rules for planning, procurement and operations, each with name, statement and rationale. Examples are identity-based access instead of trust based on network position (often called “zero trust”), security as a design criterion from the start, several independent layers of protection, coupling of systems only through documented interfaces, and a defined operating model for cloud services. DORA prescribes none of these principles. They help, however, to meet the RTS requirements over time.

Structural models describe the build at conceptual and logical level, without products, versions or IP addresses. In the full framework several of them have an anchor in Delegated Regulation (EU) 2024/1774:

The network architecture and the network security design are to be reviewed once a year, periodically for microenterprises (RTS Article 13(i)). How privileged access is controlled technically is shown on our company page on privileged access under DORA.

Test for each statement: does it describe a lasting principle or pattern, independent of products? Then it belongs in the target. Does it describe a current state, a product or a configuration? Then it belongs in the inventory.

Example: reference architecture of Muster-Kreditbank AG

Fictitious example, not a client. Muster-Kreditbank AG is a CRR credit institution with 140 employees. Its core banking system is run by a data centre provider, workplaces and network by a managed service provider (MSP). Its reference architecture has this structure, each component mapped to the legal references and to the inventories:

One entry in the bank’s asset inventory holds the records from RTS Article 4(2)(b):

The recovery objectives match the BIA shown for the same bank on our page ICT risk management.

What applies in the simplified framework under Article 16?

A reference architecture is not an explicit requirement there. BaFin finds neither the requirement of Article 6(8)(d) nor the strategic development of the IT architecture under BAIT 1.2(d) in the simplified framework (supervisory notice of 21 August 2025, section 2.1, in German), and the yearly legacy assessment under Article 8(7) is not required (section 4.1). Identification remains: critical or important functions, the supporting information and ICT assets and their interdependencies must be identified, classified and documented (RTS Article 30(1)), as must the functions supported by providers and the key dependencies on ICT third-party service providers (RTS Article 30(2), Article 16(1)(e) DORA). BaFin does not require a CMDB for this (section 3.1). The other obligations are covered on the page Article 16 DORA.

Three typical gaps

How we help

We develop the target with you, compare it with your Article 8 inventories and derive the changes needed for the DOR strategy. If you first want to know where your framework stands as a whole, we start with the DORA gap analysis.