Architecture Governance for DORA & NIS2: A Practical Guide

Governance operating model

Governance should be designed as a service that improves decision quality and speed, not as a review ritual.

A mature model combines clear decision rights, risk-tiered review depth, and transparent outcome tracking.

• Create risk tiers with explicit approval authorities
• Standardize decision records with rationale and trade-offs
• Track exceptions with expiration dates and remediation plans

Governance is what makes architecture defensible

Most teams can draw a diagram. Far fewer can prove, months later, why a decision was made, who approved it, which applications support a critical service, and how those applications depend on each other. That gap is where audits stall and where regulatory reviews get uncomfortable.

Architecture governance closes the gap. It is the set of forums, records and rules that keep your architecture honest over time — and, as a useful side effect, it produces the documentation and evidence that frameworks like DORA and NIS2 expect. This guide walks through the moving parts and where each regulation fits.

A disclaimer up front, because it matters: nothing here makes you legally compliant. DORA and NIS2 compliance is determined by regulators and auditors against your organisational, contractual and security measures. A governance practice and a tool help you document and evidence what you do; they do not replace legal, risk and security work.

The Architecture Review Board (ARB)

The ARB is the decision forum. Significant changes — a new core application, a major integration, a move to a new hosting model — are reviewed against agreed architecture principles before they are committed. The point is not bureaucracy; it is to catch risk, security and resilience concerns while they are still cheap to fix.

An ARB only earns its keep when it is lightweight and consistent: a clear scope for what needs review, a small standing membership, and a cadence that fits delivery rhythms rather than blocking them. Archilu supports this with structured review and approval workflows so that what the board decides is captured at the moment of decision, not reconstructed afterwards.

Decision records: the architecture trail

A decision record captures, for each significant choice, the context, the options considered, the decision taken and the rationale. Done well, it answers the single hardest audit question — "why is it like this?" — without a scramble through inboxes and old slide decks.

In Archilu, decisions are first-class objects linked to the applications, capabilities and policies they affect. That linkage is what turns a list of decisions into a navigable trail: an auditor can move from a critical business service to the applications that support it, to the decisions that shaped them, in a few clicks.

Policies and principles as living constraints

Principles state what good looks like ("prefer EU-hosted services for personal data"); policies turn principles into testable rules. The value comes from connecting them to the model: when a policy is attached to the applications and decisions it governs, you can see where you comply and where you have accepted, documented exceptions.

This is also where governance becomes proactive rather than punitive. A policy with a clear owner and a visible exception list is a tool teams use to make better choices, not a checklist someone enforces after the fact.

The application register

The application register — the registre des applications — is the backbone. It is the authoritative inventory of the applications supporting your business services, each with an owner, a criticality rating, hosting details and a lifecycle status. Regulators in finance and across NIS2's essential and important sectors expect you to know which ICT assets underpin your critical functions; the register is how you answer that.

The decisive design choice is that the register should be the same model your architects, finance and risk teams already use — not a parallel artefact rebuilt for each audit. When the register is live, it stays current as applications are added, retired or change owners, instead of drifting back into the spreadsheet it replaced.

• Owner, criticality and lifecycle status for every application
• Hosting and data-residency attributes for residency questions
• Links to the business services and capabilities each application supports
• Maintained continuously, not rebuilt per audit

ICT dependency mapping

Knowing your applications is necessary but not sufficient. Resilience reviews ask a harder question: if a given component, provider or data flow fails, which critical services are affected? Answering that requires mapped dependencies — between applications, between applications and the third parties that host or feed them, and between applications and the business services on top.

Archilu treats these dependencies as part of the model, so impact analysis is a query rather than a workshop. Mapping ICT dependencies is also the practical foundation for the impact-tolerance and concentration-risk thinking that frameworks like DORA push organisations toward — again, as documentation and analysis, not as a compliance verdict.

Where DORA and NIS2 actually fit

DORA (the EU Digital Operational Resilience Act) targets the ICT resilience of financial entities and their critical providers; NIS2 broadens cybersecurity obligations across essential and important sectors. Both lean heavily on the same underlying facts: you must know your ICT assets, your dependencies and your critical functions, and you must be able to show your governance.

Architecture governance produces exactly those facts. A maintained register, mapped dependencies, recorded decisions and an audit trail are the raw material a resilience or supervisory review draws on. But — and this is the disclaimer restated deliberately — DORA and NIS2 compliance is a legal determination made by your regulator and auditors against organisational, contractual and security controls. Archilu is an evidence and documentation aid, not a guarantee of compliance. Pair it with your legal, risk and security functions; the linked DORA & NIS2 architecture checklist is a starting point for the architecture-side documentation.

BIAN for banking, and making governance stick

Banks face an extra dimension: a shared reference model helps governance scale. BIAN (the Banking Industry Architecture Network) provides a standard service-domain landscape for banking, maintained by the BIAN association. Aligning your capability and application model to a BIAN-style reference makes the register easier to reason about across teams and against the way supervisors think about banking functions.

Whatever your sector, governance only holds if it lives where the work happens. The pattern that works is to connect the ARB, decision records, policies and the register to your existing rhythms — budget cycles, vendor renewals, transformation milestones — rather than running a separate compliance project that competes for attention. Start from where you are: Archilu's free EA maturity assessment scores ten dimensions, including governance, and returns a prioritised plan in about ten minutes, and the linked governance tool guide and DORA & NIS2 checklist turn these principles into concrete next steps.

Governance KPIs

A governance model is credible only if it produces faster and better decisions over time.

• Review-to-decision SLA by risk tier
• Exception backlog aging trend
• Rework rate after architecture decision
• Cross-domain dependency risk trend

Common mistakes

Governance fails when it is heavy on control but weak on decision clarity.

• Reviewing low-risk changes with full committee overhead
• No explicit decision rights by risk category
• No expiration date on architecture exceptions
• No measurable quality indicators in governance forums

Practical checklist

This baseline keeps governance useful without creating delivery drag.

• Define risk tiers and matching decision rights
• Create standard review templates and acceptance criteria
• Set SLA for architecture decisions by risk level
• Track exceptions, aging, and closure outcomes monthly