What role does a governance structure play in DORA compliance?

A governance structure is the foundation of DORA compliance. Without it, financial entities cannot demonstrate that ICT risk management is embedded into how the organisation actually operates, not just documented on paper. DORA explicitly requires that management bodies take ownership of ICT risk, which means governance is not optional; it is the mechanism through which compliance becomes real. The sections below unpack the specific governance questions that financial entities and their advisors are asking most in 2026.

If you are working through your DORA readiness right now and want to talk through what a governance structure looks like in practice, feel free to get in touch with us — we are happy to help without any obligation.

What specific governance elements does DORA require organisations to have?

DORA requires financial entities to have a clearly defined ICT risk management framework, an assigned management body with explicit accountability, documented roles and responsibilities for ICT risk, internal control functions, and a formal process for reviewing and updating governance arrangements. These are not aspirational; they are enforceable requirements under the regulation.

In practical terms, this means your organisation must be able to demonstrate:

A written ICT risk management framework approved at board or senior management level
Defined roles for who owns ICT risk, who monitors it, and who reports on it
Policies covering ICT security, business continuity, incident response, and third-party risk
An audit or review function that regularly assesses the effectiveness of controls
A clear escalation path from operational teams to the management body

What makes DORA distinct from earlier regulatory expectations is the emphasis on management body accountability. It is not enough for a CISO or IT department to own ICT risk in isolation. The regulation expects senior leadership to understand, approve, and actively oversee the framework. This is a governance requirement, not a technical one, and it is one of the most common gaps we see in organisations approaching DORA for the first time.

How does a governance structure map to DORA’s five pillars?

A governance structure provides the organisational scaffolding that makes each of DORA’s five pillars operational. The five pillars — ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk management, and information sharing — each require defined ownership, documented processes, and management oversight. Without a governance structure, these pillars remain isolated activities rather than a coherent system.

ICT risk management and incident management

These two pillars are the most governance-intensive. ICT risk management requires a framework that is actively maintained, not just written once. Incident management requires clear roles, escalation procedures, and reporting lines that are understood across the organisation before an incident occurs. Both demand that someone with authority is accountable — and that accountability must be built into the governance structure, not assumed.

Resilience testing and information sharing

Digital operational resilience testing, including Threat-Led Penetration Testing for in-scope entities, requires governance to schedule, resource, and act on findings. Information sharing arrangements require a governance decision about participation and a process for handling shared intelligence. Neither pillar can function on an ad hoc basis — both need a home within the governance structure to ensure they happen consistently and that results feed back into risk management decisions.

ICT third-party risk management, the fifth pillar, is covered in its own section below, given the depth it deserves.

Who is responsible for DORA governance within an organisation?

Under DORA, the management body holds ultimate responsibility for ICT risk governance. This includes approving the ICT risk management framework, allocating adequate resources, setting the risk appetite, and overseeing the implementation of the overall digital operational resilience strategy. Responsibility cannot be fully delegated to a technical function — senior leadership must be demonstrably involved.

In practice, responsibility is distributed across several roles:

Management body (board or equivalent): Approves the framework, owns accountability, receives regular reporting
Chief Information Security Officer or equivalent: Operationalises the framework, manages day-to-day ICT risk
Risk and compliance functions: Monitor adherence, identify gaps, support audit activities
Business line owners: Accountable for ICT risk within their domain, particularly for third-party dependencies
Internal audit: Provides independent assurance on the effectiveness of controls

One of the governance challenges DORA creates is ensuring that the management body has the knowledge and information it needs to exercise genuine oversight, not just rubber-stamp documents it does not fully understand. Building that capability at board level is a governance task in itself, and one that many organisations underestimate when they begin their DORA journey.

What’s the difference between a governance structure and a compliance project for DORA?

A compliance project is a time-limited effort to meet a regulatory deadline. A governance structure is the permanent organisational capability that keeps the organisation compliant over time. DORA does not end at a certification date — it requires continuous operational readiness, which only a governance structure can deliver. A project gets you to the line; a structure keeps you there.

This distinction matters more for DORA than for many other frameworks because the regulation is explicitly designed around continuous governance. Regulators expect financial entities to demonstrate ongoing resilience, not point-in-time compliance. An organisation that treats DORA as a project will find itself rebuilding the same work every time a review, audit, or incident exposes drift in its controls.

A governance structure, by contrast, embeds the required processes into how the organisation operates every day. Roles are defined and filled. Policies are reviewed on a schedule. Incidents are managed through a process that already exists. Third-party risks are assessed as contracts are renewed, not scrambled together before a regulatory inspection. The difference is the difference between reactive and proactive — and DORA’s supervisory expectations are firmly on the proactive side.

This is the core of what we do at Moatt: we help organisations build continuous governance as a permanent capability, so that DORA compliance is a natural output of how the organisation runs rather than a recurring emergency.

How does ICT third-party risk fit into a DORA governance structure?

ICT third-party risk management is one of DORA’s most operationally demanding pillars, and it must be embedded directly into the governance structure rather than treated as a procurement or IT function in isolation. DORA requires financial entities to maintain a register of all ICT third-party providers, conduct risk assessments, ensure contractual provisions meet regulatory standards, and apply enhanced oversight to Critical ICT Third-Party Providers designated by supervisory authorities.

Within a governance structure, ICT third-party risk needs:

A defined owner — typically a combination of risk, procurement, and business line leadership
A documented process for onboarding, monitoring, and offboarding ICT providers
A register that is actively maintained, not created once and forgotten
Contractual templates or checklists that reflect DORA’s specific requirements for ICT service agreements
Escalation criteria that trigger enhanced due diligence for high-concentration or critical dependencies

The governance challenge here is that third-party risk is inherently cross-functional. It touches legal, IT, risk, finance, and individual business units. Without a governance structure that assigns clear ownership and creates a shared process, each function manages its piece of the picture independently — and the organisation ends up with gaps, duplicated effort, and no consolidated view of its ICT dependency landscape. DORA’s supervisors will look for exactly that consolidated view.

When should a financial entity review its governance structure for DORA readiness?

A financial entity should review its governance structure for DORA readiness immediately if it has not done so since the regulation became applicable, and then on a regular, scheduled basis thereafter — at minimum annually, and whenever a significant change occurs. DORA is not a one-time assessment; it requires that governance arrangements remain fit for purpose as the organisation and its ICT environment evolve.

Triggers for an unscheduled governance review include:

A significant ICT-related incident or near-miss
A material change in the organisation’s ICT infrastructure or provider landscape
A merger, acquisition, or restructuring that affects ICT dependencies
New supervisory guidance or updates to DORA’s regulatory technical standards
A change in senior leadership with ICT risk responsibilities
Findings from an internal audit or external assessment

In 2026, many financial entities are discovering that their initial DORA implementation work was thorough at the time but has already begun to drift as business conditions have changed. Governance drift is a natural consequence of treating compliance as a project rather than a continuous capability. A scheduled review cadence — built into the governance structure itself — is the most effective way to catch drift before it becomes a supervisory finding.

If you want to assess where your governance structure stands today and what it would take to keep it aligned with DORA’s requirements over time, get in touch with us — we would be glad to walk through it with you.

Frequently Asked Questions

How do smaller financial entities with limited resources build a DORA-compliant governance structure without a large compliance team?

Smaller financial entities can start by applying the proportionality principle, which DORA explicitly acknowledges — the governance structure must be appropriate to the size, complexity, and risk profile of the organisation. In practice, this means a smaller entity may combine roles (for example, the CISO and risk function may sit with the same person) as long as accountability is clearly documented and the management body is still genuinely involved. The priority is to have the right processes and documented ownership in place, even if they are leaner than those of a large institution. Starting with a gap assessment against DORA's core governance requirements is the most efficient first step.

What are the most common governance mistakes financial entities make when implementing DORA for the first time?

The most common mistake is treating governance documentation as the end goal — producing a polished ICT risk management framework that sits on a shelf but is not embedded into day-to-day operations. A close second is failing to build genuine board-level capability, leaving senior leadership approving documents they do not fully understand, which regulators can quickly identify during supervisory reviews. Organisations also frequently underestimate the cross-functional coordination required, particularly for third-party risk, leading to siloed ownership and an incomplete picture of ICT dependencies. Building in a regular review cadence from day one — rather than bolting it on later — prevents much of this drift.

How should a management body demonstrate 'active oversight' of ICT risk to satisfy DORA's expectations?

Active oversight means the management body receives regular, structured reporting on ICT risk — not just incident notifications, but forward-looking risk indicators, third-party exposure summaries, and updates on resilience testing outcomes. Board members or equivalent senior leaders should be able to evidence their engagement through meeting minutes, approved policy records, and documented decisions on risk appetite. Regulators will look for a clear audit trail showing that the management body asked questions, challenged assumptions, and made informed decisions — not simply that they received information. Investing in board-level ICT risk training or briefings is a practical and increasingly common step to support this.

Can an organisation use an existing enterprise risk management framework as the basis for its DORA governance structure, or does it need to build something entirely new?

An existing enterprise risk management framework is a strong foundation and should absolutely be leveraged rather than replaced. DORA's governance requirements are largely consistent with sound risk management principles, so organisations with mature ERM frameworks typically need to extend and formalise what they already have — adding ICT-specific policies, clarifying management body accountability for digital operational resilience, and ensuring third-party risk processes meet DORA's specific contractual and oversight requirements. The key is to map existing controls against DORA's requirements systematically and identify the gaps, rather than assuming alignment or starting from scratch.

What does a DORA governance review actually involve, and how long does it typically take?

A DORA governance review typically involves assessing the current ICT risk management framework against the regulation's requirements, evaluating whether roles and accountabilities are clearly defined and operationally active, reviewing key policies for completeness and currency, and testing whether escalation and reporting processes function as documented. For a mid-sized financial entity, a focused review can be completed in four to eight weeks, depending on the maturity of existing documentation and the availability of key stakeholders. The output should be a prioritised gap register with recommended remediation actions, not just a compliance checklist — the goal is to identify what needs to change in practice, not just on paper.

How does DORA's governance framework interact with other regulatory requirements like NIS2 or the EBA ICT Risk Guidelines?

DORA takes precedence over sector-specific ICT risk requirements for financial entities within its scope, but it broadly aligns with the principles in the EBA ICT and Security Risk Guidelines, meaning organisations that have implemented those guidelines are well-positioned. NIS2 applies to a broader set of entities and has some overlapping requirements around incident reporting and third-party risk, but DORA is more prescriptive and operationally detailed for financial services specifically. Where overlap exists, organisations should design their governance structure to satisfy the most demanding requirement, which is typically DORA, and document how that single framework addresses obligations under each applicable regulation — avoiding the inefficiency of running parallel compliance programmes.

What evidence should a financial entity be preparing now in case of a supervisory review or inspection focused on DORA governance?

Supervisors will typically look for documented evidence that governance is live and operational, not just theoretically in place. This includes board and committee minutes showing ICT risk was discussed and acted upon, a current and maintained ICT third-party provider register, records of completed resilience tests and the actions taken on findings, up-to-date ICT risk policies with version histories and approval signatures, and documented incident logs with evidence of the escalation process being followed. Organisations should also be able to produce their ICT risk appetite statement and show how it has been applied to real decisions. The strongest evidence is a consistent, dated paper trail that shows governance happening continuously — not a bundle of documents assembled in response to an inspection notice.

Navigation