Architecture Governance for DORA and NIS2: Decisions, Inventories and Dependencies

Architecture governance and regulatory documentation

An architecture diagram is quick to draw. Months later, the organisation still needs to say why a decision was made and who approved it. It also needs to know which applications support a critical service and how they depend on each other. Without those answers, audits stall and supervisory reviews become difficult.

Architecture governance is the set of forums, records and rules that keep the architecture accurate over time. It produces part of the documentation DORA and NIS2 expect: functions, ICT assets, their dependencies and the decisions that shaped them.

It does not make an entity compliant. The competent authority and auditors assess compliance against the entity’s organisational, contractual and security measures. An architecture repository helps document and evidence what is done; the work of the legal, risk and security functions remains in full.

The Architecture Review Board

The Architecture Review Board examines significant changes before they are committed: a new core application, a major integration, a new hosting model. It assesses them against adopted principles. Risk, security and resilience concerns are then handled while they are still cheap to fix.

A board lasts when it stays lightweight and regular: a clear review scope, few standing members, a cadence aligned with delivery. In ArchiLU, decision bodies are composed under your rules, each with its mandate. A body can have a single member, and one person can hold several profiles.

The ArchiLU Board has four views: To review, Questions, In rework and History. An architecture dossier can start from a request or be opened on its own. The Board puts questions to owners, reviews the answers, then decides with a reason or asks for rework and a new submission. The decision is recorded when it is taken.

Decision records

A decision record captures, for each significant choice, the context, the options considered, the decision taken and its rationale. It answers the hardest audit question, “why is it like this?”, without a search through inboxes and old slide decks.

In ArchiLU, the decision log keeps each decision with its body, its decision maker, its date, its outcome and its reason. For a submitted dossier, the version, the presentation and the trade-offs examined remain available. A recorded decision is not rewritten: another one replaces it, or the body withdraws it.

A decision’s consequences are recorded in principles, targets and affected elements; the next request finds those references. The auditor rereads each board decision with its reason. The audit trail is chained, verifiable and exportable by the administrator. Segregation of duties is on by default, and its removal is logged.

AI can prepare a decision or assess a waiver; only the members of the body decide.

Principles, rules and waivers

A principle states what is desirable, for example “prefer services hosted in the European Union for personal data”. A rule makes it verifiable. Attached to the applications and decisions they govern, principles and rules show where the architecture complies and where a documented waiver was accepted.

In ArchiLU, a principle is prepared in its case and applies once the board has adopted it. A later request is assessed against it: it follows the principle, justifies a waiver or proposes a change. Open waivers are among the findings of the exposure analysis. When a principle has an owner and its waivers stay visible, teams consult it while preparing their options.

The application and function inventory

DORA requires financial entities to identify, classify and adequately document their ICT supported business functions (Article 8). The obligation also covers the information assets and ICT assets supporting those functions, and their dependencies. The classification is reviewed at least yearly; inventories are updated periodically and at every major change.

The register of information in Article 28 of DORA is a different document. It covers contractual arrangements for ICT services provided by ICT third-party service providers. In ArchiLU, it is produced as a regulatory report from the same chain.

NIS2 lists asset management among the cybersecurity risk-management measures (Article 21). In both cases, the application inventory is the base. It stays current if it is the model architects, finance and risk already use. Rebuilt for each audit, it drifts back into the spreadsheet it replaced. In ArchiLU, applications and functions share one repository:

• Owner, criticality, lifecycle and supplier for each application.
• A function catalogue with DORA criticality, owner and the applications serving each function.
• Links from each application to its capabilities, processes, interfaces, technologies and contracts.
• Objects without an owner that stay visible, and a task sent every twelve months to each owner to confirm their objects.

ICT dependencies and exposure analysis

Knowing your applications is not enough. A resilience review asks what stops if a component, a provider or a data flow fails. DORA requires entities to map the links and interdependencies between assets, and to identify the processes that depend on ICT third-party service providers (Article 8).

In ArchiLU, the chain starts from a critical or important function. It follows linked processes and capabilities, the applications, then documented ICT services, providers and contracts. A missing link remains visible. The function record also shows the deployed instance, with its recovery time and acceptable loss, and the application’s exit plan.

The exposure analysis starts from a provider and traces it to the processes and critical or important functions that depend on it. It computes its findings: concentration, obsolescence, critical objects without an owner, open waivers. Each finding leads to a request, a risk or a board decision.

The resilience strategy required by DORA establishes the risk tolerance level for ICT risk and analyses the impact tolerance for ICT disruptions (Article 6). Before an arrangement supporting a critical or important function, the entity also assesses concentration risk (Articles 28 and 29). These assessments remain with the entity; the chain documents what they cover.

Where DORA and NIS2 fit

Regulation (EU) 2022/2554, known as DORA, has applied since 17 January 2025 to the financial entities listed in its Article 2. It covers ICT risk management, the reporting of major ICT-related incidents, resilience testing and ICT third-party risk. It also sets up an oversight framework for critical ICT third-party service providers.

Directive (EU) 2022/2555, known as NIS2, applies to essential and important entities in many sectors. Member States had until 17 October 2024 to transpose it. A financial entity may be identified as essential or important. DORA is then the sector-specific Union legal act for the purposes of Article 4 of NIS2 (Article 1(2) of DORA).

Both texts engage the management body. Under DORA, it defines, approves and oversees the ICT risk management framework and is responsible for its implementation (Article 5). Under NIS2, management bodies approve the cybersecurity risk-management measures, oversee their implementation and can be held liable (Article 20).

DORA also requires the resilience strategy to explain the ICT reference architecture and any changes needed to reach specific business objectives (Article 6(8)). In ArchiLU, each landscape carries the current state, the target and a dated roadmap. The gap gives each element its work package and due date.

A maintained inventory, mapped dependencies, reasoned decisions and an audit trail are the raw material for a resilience or supervisory review. The DORA and NIS2 checklist helps list the architecture documentation to produce.

BIAN for banking, and governance that lasts

A bank can also rely on an industry reference. BIAN, the Banking Industry Architecture Network, publishes reference models; its Service Landscape organises Service Domains. In ArchiLU, a sector model, BIAN for banking, loads through the workbook. Business owners then examine each mapping against their capabilities and applications.

Governance holds when it follows existing rhythms: budget cycles, contract renewals, transformation milestones. The board, decisions, principles and inventory connect to them, with no separate compliance project competing for the teams’ attention.

In ArchiLU, the DORA chain and the exposure analysis are part of the APM & Risk plan. Architecture dossiers and the board are part of the Enterprise Architecture plan, which also includes APM & Risk. The one-month trial runs on your own instance.