ICT Architecture · DORA Art. 8
ICT Reference Architecture: what DORA requires – and what it means
DORA Art. 8 calls for an ICT reference architecture but does not define what that means. How classical IT architecture frameworks such as TOGAF provide orientation and what role the document plays within ICT risk management.
What is an ICT reference architecture?
DORA Art. 8 obliges financial entities to develop and maintain an ICT reference architecture. What this means in concrete terms is deliberately left open by the Regulation.
Orientation comes from TOGAF (The Open Group Architecture Framework), the world’s most widely used enterprise architecture standard. In TOGAF, two formally separate artefacts together describe the normative target state of an IT landscape:
Architecture Principles
Normative tenets that shape every architectural decision. They answer: by what rules do we decide? — e.g. Zero Trust, Security by Design, API-first.
Reference Architecture
Conceptual and logical structural models. They answer: how should the IT be structured? — e.g. three-tier application architecture, multi-stage firewall topology.
For an ICT reference architecture under DORA, both layers are pragmatically combined in a single document. Architecture principles without structural reference models are incomplete — and vice versa.
Layer 1: Architecture principles
in TOGAF: Architecture Principles
Architecture principles are normative tenets that apply on a durable basis and shape every planning, procurement and design decision. In TOGAF they are formulated with name, statement and rationale:
Zero Trust
No system and no user is granted implicit trust based on its network location. Every access is authenticated and authorised on an identity basis, regardless of origin and location.
Rationale: Perimeter-based security models do not provide effective protection against compromised internal systems or insider threats.
Security by Design
Security requirements are primary design criteria for every architecture and development decision — not a downstream add-on.
Rationale: Security measures integrated into the architecture from the start are more effective and significantly more cost-efficient than retrofitted corrections.
Cloud strategy
The reference architecture sets out bindingly which model is used to operate workloads — e.g. cloud-first as the default or cloud-by-policy with defined classification criteria.
Rationale: Strategic clarity about permissible operating models prevents uncontrolled sprawl and creates predictable governance for procurement and operations.
API-first
System integration occurs exclusively via documented, versioned APIs. Proprietary direct links and undocumented point-to-point couplings are not permitted.
Rationale: Uncontrolled system couplings create opaque dependencies, hinder risk analysis and jeopardise the auditability and third-party management requirements under DORA.
Defence in Depth
Security measures are implemented on multiple independent layers — network, application, identity, data. No single control mechanism is treated as sufficient.
Rationale: Layered controls significantly reduce the risk of a complete security failure caused by the failure of a single component.
Layer 2: Conceptual architecture models
in TOGAF: Reference Architecture
Architecture models describe the structural form of the IT landscape at conceptual and logical level — without reference to concrete products, systems or configurations. In TOGAF they deliberately operate above the physical architecture layer:
Three-tier application architecture
Presentation layer, business logic and data persistence are operated in physically or logically separated network zones. Direct connections between non-adjacent layers are not permitted; communication takes place exclusively via defined boundary points.
Multi-stage firewall architecture
The network perimeter is secured by at least two firewall stages: an outer firewall separates public networks from the DMZ; an inner firewall separates the DMZ from internal application and database zones. Direct connections from public networks into internal zones are not permitted.
Central identity and access model
All system accesses are managed via a central identity provider with uniform authentication standards. Privileged access takes place exclusively via a dedicated Privileged Access Management system; direct administrative system access without logging is not permitted.
Encrypted communication architecture
All data transmissions between system layers and all external connections are cryptographically secured. Unencrypted communication between system components is not permitted and requires an explicit, documented exception.
Redundancy and recovery model
The reference architecture defines resilience classes by system category — not the specific assignment of individual systems. Critical system categories require redundant operating models; the reference architecture sets out which categories belong to which classes.
Both layers together form the normative target state — the development plan of the IT. They describe how the IT should be, without prescribing which concrete systems or products are used. That concretisation is the task of the as-is inventory and the action plan.
The right level of abstraction: conceptual and logical — not physical
TOGAF distinguishes three architecture layers: conceptual, logical and physical. A reference architecture operates at the conceptual and logical layers. The physical layer — concrete systems, version states, IP addresses, configuration detail — does not belong in the reference architecture but in the as-is inventory.
This restriction is not a weakness of the document but a precondition for its normative force. A reference architecture phrased at the level of concrete products or configurations ages with every technology decision. A principle such as Zero Trust or a model such as the three-tier application architecture, on the other hand, retains its validity irrespective of the technologies in use.
The level of abstraction also creates the right governance anchoring: the reference architecture is the document approved by the management body. It makes strategic decisions — not operational ones. That is only possible if the document is phrased at a level where genuine strategic statements can be made.
Test question for classification: Does this statement describe a durable principle or pattern — independently of concrete products and configurations? Then it belongs in the reference architecture. Does it describe a current system state, a concrete product or a configuration? Then it belongs in the as-is inventory.
The three-stage model: reference architecture, as-is inventory, action plan
The reference architecture is the first link in a chain. The model corresponds to TOGAF’s principle of Target Architecture, Baseline Architecture and Architecture Roadmap — applied to DORA requirements:
TOGAF: Target Architecture → Baseline Architecture → Architecture Roadmap
Reference architecture – the normative target state
Architecture principles and conceptual structural models that bindingly set out how the IT should be structured. Abstract, durable and product-independent — the yardstick for all subsequent steps. Corresponds to the Target Architecture in TOGAF.
As-is inventory – the actual state
Documentation of the concrete IT landscape: existing systems, network topology, configurations, dependencies, third parties. Measured against the normative target state the gap emerges. Corresponds to the Baseline Architecture in TOGAF.
Action plan – the path to the target state
Each gap between reference architecture and as-is inventory generates a prioritised action. The action plan structures the implementation. Corresponds to the Architecture Roadmap in TOGAF.
ICT reference architecture under DORA Art. 8
The Digital Operational Resilience Act (DORA, EU 2022/2554) makes the ICT reference architecture a binding obligation for financial entities. Article 8 DORA requires financial entities to document and maintain such an architecture — as the basis of their ICT risk management framework.
Separately, Art. 8 DORA requires the complete ICT asset register: the as-is inventory with concrete systems, configurations and dependencies. Both requirements stand alongside each other — they are complementary but distinct documents with distinct functions.
Responsibility for the reference architecture lies with the management body under Art. 5 DORA. It approves the normative target state, is accountable for its currency and receives regular reports on deviations and progress under the action plan.
DORA requirements in the three-stage model
Reference architecture, as-is inventory and action plan – from one team
Blackfort Technology works with financial entities to develop the ICT reference architecture as the normative target state, runs the structured as-is inventory and derives the prioritised DORA action plan from it. Regulatory framing and technical delivery from a single engagement.
Frequently asked questions about the ICT reference architecture
What is an ICT reference architecture under DORA?
DORA Art. 8 requires an ICT reference architecture but does not define what is meant by the term. Orientation comes from TOGAF, the leading enterprise architecture standard: in TOGAF a reference architecture comprises both normative architecture principles (e.g. Zero Trust, Security by Design) and conceptual structural models (e.g. a three-tier application architecture or a multi-stage firewall model). For DORA purposes both layers are pragmatically combined in a single document.
What is the difference between Architecture Principles and Reference Architecture under TOGAF?
In TOGAF, Architecture Principles are normative tenets that shape every architectural decision – e.g. "Security by Design" or "API-first". They answer the question: by what rules do we decide? The Reference Architecture describes conceptual and logical structural models – e.g. a three-tier application architecture or a multi-stage firewall topology. It answers the question: how should the IT be structured? A complete ICT reference architecture contains both.
What is the difference between an ICT reference architecture and an as-is inventory?
The reference architecture is the normative target state – abstract, prescriptive, durable. The as-is inventory documents the actual current state – concrete, descriptive, continuously updated. In TOGAF terms this corresponds to the Target Architecture (target state) versus the Baseline Architecture (current state). Only the comparison of the two yields the gap from which the action plan is derived.
Why does the reference architecture remain at an abstract level?
The abstraction is not a weakness but the prerequisite for the document’s normative force. TOGAF distinguishes conceptual, logical and physical architecture layers. A reference architecture operates at the conceptual and logical layers – it describes patterns and principles, not concrete systems or configurations. A principle such as "Zero Trust" remains valid irrespective of the products in use. The physical layer and configuration detail belong in the as-is inventory.
Who is responsible for the reference architecture under DORA?
The management body of the financial entity carries personal responsibility for the ICT risk management framework under DORA Art. 5 – and therefore for the reference architecture as a strategic core document. It approves the normative target state and ensures that deviations are identified, assessed and addressed via an action plan.
TOGAF framing
The three-stage model
DORA framing
Related topics
Build the ICT reference architecture
We guide financial entities from the reference architecture through the as-is inventory to a prioritised action plan.
Request nowKontakt aufnehmen
Bereit für den nächsten Schritt?
Sprechen Sie mit uns über Ihre Sicherheitsanforderungen – konkret, ohne Verpflichtung und auf Augenhöhe.