Legal and IT teams disagree on what DORA requires because the regulation deliberately bridges two worlds that rarely speak the same language. DORA’s text is written at a policy level, which means it uses terms that legal professionals interpret through a compliance and contractual lens, while IT professionals read the same words through an operational and technical one. The result is genuine ambiguity, not bad faith. Below, we unpack exactly where those interpretive gaps appear, why they persist, and what organisations can do to close them. If you want to talk through your specific situation, feel free to get in touch with us directly.

Where do legal and IT teams actually interpret DORA differently?

Legal and IT teams most commonly diverge on three areas: the definition of “critical or important functions,” the scope of ICT third-party risk obligations, and what constitutes an adequate incident response capability. Legal teams tend to read these terms as classification and documentation problems, while IT teams treat them as architectural and operational ones. Both readings are partially correct, which is precisely why the disagreement is so persistent.

Critical and important functions

DORA requires organisations to identify which functions are “critical or important” and then apply heightened standards to the ICT systems supporting them. Legal teams typically approach this as a scoping exercise: which business lines qualify, and how should that be documented for regulators? IT teams approach it differently. For them, the question is which systems, integrations, and vendors are in scope and therefore need hardened controls. These are not the same question, and organisations that treat them as such end up with documentation that does not reflect operational reality.

Third-party ICT risk

DORA’s third-party requirements are detailed and specific, covering contractual provisions, exit strategies, concentration risk, and ongoing monitoring. Legal teams focus on the contractual side: are the right clauses in place, are vendors classified correctly, and do agreements meet the regulatory minimum? IT teams focus on the technical side: can the vendor actually meet the SLAs those contracts promise, and do we have visibility into their infrastructure? When legal signs off on a contract and IT has never assessed the vendor’s actual security posture, the organisation is compliant on paper but exposed in practice.

Why does DORA use language that both sides can claim to own?

DORA uses principle-based language because it is a framework regulation, not a technical standard. It sets outcomes rather than prescribing methods, which gives organisations flexibility but also creates interpretive space. Words like “resilience,” “proportionality,” and “appropriate measures” are intentionally broad so they can apply across different sectors, sizes, and operating models. That breadth is a feature for regulators, but a source of friction inside organisations.

The practical consequence is that legal teams can read DORA’s language and conclude that a well-drafted policy document satisfies the requirement. IT teams can read the same language and conclude that the requirement demands a specific technical capability, such as automated failover or real-time threat detection. Neither team is wrong in isolation. The regulation genuinely accommodates both readings. What it does not accommodate is the two teams operating on those readings independently without ever reconciling them into a single, coherent position.

This is also why DORA is harder to implement than more prescriptive frameworks. A regulation that says “implement multi-factor authentication” leaves little room for debate. A regulation that says “ensure appropriate ICT security measures proportionate to your risk profile” requires judgment, and judgment requires alignment between the people making it.

What happens when legal and IT disagree during a DORA audit?

When legal and IT teams arrive at an audit with inconsistent interpretations, the organisation typically presents contradictory evidence. Legal produces documentation that describes one state of affairs; IT produces technical records that describe another. Auditors notice this quickly, and the inconsistency itself becomes a finding, regardless of whether the underlying controls are adequate.

The more serious consequence is that unresolved disagreement signals a governance problem, not just a communication one. Regulators assessing DORA compliance are not only checking whether controls exist. They are assessing whether the organisation has genuine operational resilience, which requires management to understand, own, and coordinate the organisation’s ICT risk posture. When legal and IT cannot agree on what is required, it suggests that no one has actually taken ownership of the full picture.

In practice, this creates two risks. The first is a direct regulatory finding. The second is that the disagreement reflects a real gap in the organisation’s resilience, one that could have operational consequences independent of any audit. Governance that exists only in documents but not in systems, or in systems but not in documented policy, is governance that will fail under pressure.

Who should own DORA interpretation inside an organisation?

DORA interpretation should be owned by a governance function that sits above both legal and IT, with the mandate to translate regulatory requirements into operational commitments. In practice, this is often the CISO, the Chief Risk Officer, or a dedicated compliance function, but the title matters less than the authority. The owner needs to be able to make binding decisions that legal will document and IT will implement.

The key principle here is that DORA is fundamentally a management responsibility. The regulation explicitly places accountability at the level of the management body, not with individual departments. This means the board and senior management are responsible for ensuring that their organisation’s ICT risk framework is coherent, proportionate, and operational. Legal and IT are both contributors to that framework, but neither owns it in isolation.

Organisations that assign DORA ownership to legal alone end up with policy-heavy programmes that lack operational grounding. Organisations that assign it to IT alone end up with technically sound controls that are not properly documented, governed, or connected to the broader risk picture. The most effective model is one where a cross-functional governance owner coordinates both, with clear role-based accountability for each domain. This is the foundation of continuous governance: not a one-time exercise, but an ongoing function that keeps legal and IT aligned as the regulatory environment and the organisation’s own systems evolve.

How can organisations align legal and IT on DORA requirements?

Organisations can align legal and IT on DORA by establishing a shared interpretation process, not just a shared document. This means bringing both functions together at the point where requirements are being translated into obligations, rather than having each team produce its own interpretation and then trying to reconcile them afterwards.

Several practical steps make this work in practice:

  • Build a shared DORA taxonomy. Agree on definitions for the key terms in the regulation, particularly “critical or important functions,” “ICT third-party service providers,” and “significant ICT incidents.” Document these definitions in a way that both legal and IT can work from.
  • Map requirements to owners, not departments. Each DORA requirement should have a named owner who is accountable for both the policy position and the operational implementation. Ownership by a department tends to produce silo behaviour; ownership by a named individual with cross-functional authority tends to produce coordination.
  • Run joint reviews at regular intervals. DORA is not a static regulation, and organisations are not static either. Quarterly or semi-annual reviews where legal and IT assess the current state together prevent the drift that accumulates when teams work independently.
  • Use incidents as alignment opportunities. When an ICT incident occurs, the post-incident review is an ideal moment to test whether legal and IT are reading the situation the same way. Disagreements that surface in a post-incident context are easier to resolve than ones that surface during an audit.
  • Embed governance in operations, not just documentation. Continuous governance means that DORA compliance is maintained through live operational processes, not annual policy reviews. When governance is embedded in how the organisation actually runs, legal and IT are working from the same operational reality rather than from separate abstractions of it.

At Moatt, our governance services are built around exactly this kind of cross-domain alignment. We bring security, privacy, quality, and AI governance together into a single, integrated system, which means legal and IT are not interpreting requirements in parallel but contributing to a unified framework. Alignment is not a one-time workshop outcome; it is a structural feature of how governance is designed.

The organisations that handle DORA most effectively are those that treat it as a governance challenge rather than a legal one or a technical one. That framing makes the disagreement between legal and IT not a problem to be managed, but a signal that the governance structure needs to be strengthened. When both teams are contributing to a shared, management-owned framework, the interpretation question largely resolves itself, because there is a single authoritative position that both sides have helped to build. If you want to explore what that looks like for your organisation, plan a conversation with us and we will walk through it together.

Frequently Asked Questions

How do we know if our current DORA documentation actually reflects what our IT systems are doing in practice?

The most reliable way to test this is to run a structured walkthrough where IT traces a specific critical function — from the business process down through the supporting systems, integrations, and vendors — and then checks whether the legal documentation describes that same chain accurately. Gaps almost always appear at the vendor and integration layer, where contracts reference capabilities that have never been technically verified. If the two accounts do not match, you have a documentation-to-reality gap that needs to be closed before any regulatory engagement.

What is the biggest mistake organisations make when trying to get legal and IT aligned on DORA?

The most common mistake is treating alignment as a one-time output — typically a shared policy document or a single workshop — rather than as an ongoing structural process. Teams produce a reconciled interpretation, then drift apart again as systems change, vendors are onboarded, and the regulatory guidance evolves. Alignment that is not embedded in regular operational rhythms, such as joint incident reviews and periodic requirement mapping sessions, will degrade within months and leave the organisation exposed by the time the next audit arrives.

How should we classify a vendor that supports a function we have not yet formally designated as critical or important?

Until the formal classification is complete, the safest approach is to apply the same scrutiny you would to a confirmed critical vendor, particularly for contractual provisions and ongoing monitoring. DORA's proportionality principle does not protect organisations from risk that exists before classification is finalised — it only governs how controls are calibrated after the determination is made. Treat the classification exercise itself as time-sensitive, and document the interim position so that regulators can see the organisation is actively managing the ambiguity rather than ignoring it.

Can a small or mid-sized financial entity apply DORA's proportionality principle to reduce the scope of what legal and IT need to agree on?

Yes, but proportionality needs to be actively argued and documented rather than assumed. DORA explicitly allows organisations to calibrate their ICT risk management framework to their size, risk profile, and complexity, but that calibration must be a deliberate, reasoned decision — not a default. The proportionality argument should be developed jointly by legal and IT, because it requires both a regulatory justification (which legal owns) and an honest assessment of actual operational risk (which IT owns). A proportionality position that only one team has signed off on is unlikely to hold up under scrutiny.

What should we do if our ICT third-party contracts were signed before DORA came into force and do not include the required provisions?

DORA requires that existing contracts with critical or important ICT third-party providers are brought into compliance, and regulators expect organisations to have a remediation plan in place for legacy agreements. The practical starting point is a contract gap analysis against DORA's required provisions, prioritised by vendor criticality. Where renegotiation is not immediately possible, document the gap, the remediation timeline, and any compensating controls — this demonstrates active management of the issue, which is meaningfully better than silence in a regulatory context.

How do we handle a situation where IT identifies a resilience gap that legal believes is already covered by existing policy?

This is one of the most common and consequential misalignments, and it needs to be escalated to the governance owner — the CISO, CRO, or equivalent — rather than resolved bilaterally between the two teams. The governance owner's role is precisely to adjudicate these situations: determining whether the policy needs to be updated to reflect operational reality, whether IT needs to implement a control the policy already requires, or whether both need to change. Leaving the disagreement unresolved, or allowing one team to overrule the other without authority, is the scenario most likely to produce a finding during an audit.

How does DORA's digital operational resilience testing requirement translate into something both legal and IT can work from together?

DORA's testing requirements — including threat-led penetration testing for significant institutions — are an area where legal and IT need a genuinely shared framework rather than separate workstreams. Legal needs to understand what testing has been conducted, at what frequency, and against which systems in order to make accurate representations to regulators. IT needs to understand which systems are in scope, what the regulatory expectations are for test methodology, and how findings must be documented and remediated. The most effective approach is a joint testing calendar with agreed documentation standards, so that the outputs IT generates are already in a form that legal can use directly.

Related Articles

Share

  • June 1, 2026