The essential internal controls for DORA compliance centre on ICT risk management, business continuity, incident classification and reporting, third-party oversight, and regular testing of digital operational resilience. These controls are not optional enhancements — they are explicitly required by the Digital Operational Resilience Act for all in-scope financial entities operating in the EU. The sections below unpack each dimension in detail, from what the regulation specifically mandates to where organisations most commonly fall short. If you have questions along the way, feel free to get in touch with us and we will be happy to help.

Which internal controls does DORA specifically mandate?

DORA mandates five core categories of internal controls: an ICT risk management framework, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements. Every in-scope financial entity must implement all five categories as an integrated system, not as isolated compliance activities.

Within the ICT risk management framework, organisations must maintain a continuously updated risk register, define protection and prevention measures, implement detection capabilities, and establish recovery and restoration procedures. The framework must be documented, reviewed at least annually, and approved by the management body.

Incident management requires a formal classification process that distinguishes between major and non-major ICT incidents, defined escalation paths, and structured reporting to competent authorities for major incidents within specific timeframes. Organisations must also track and review incidents to identify systemic weaknesses.

Digital operational resilience testing includes basic testing such as vulnerability assessments and scenario-based tests, as well as advanced threat-led penetration testing (TLPT) for the most significant entities. Testing must be conducted by independent parties and results must feed back into the risk management cycle.

Finally, information sharing controls require that organisations participate in trusted information-sharing arrangements about cyber threats, though this is the least prescriptive of the five categories. Across all of these, continuous governance is the common thread: DORA is designed as an ongoing operational obligation, not a point-in-time certification exercise.

How does ICT risk management under DORA differ from ISO 27001?

ICT risk management under DORA is operationally prescriptive and sector-specific, whereas ISO 27001 is a flexible, principles-based standard that organisations can tailor to their context. DORA mandates specific outputs, timelines, and governance structures for financial entities, while ISO 27001 defines a management system framework that organisations implement according to their own risk appetite and scope decisions.

The most significant structural difference is regulatory enforceability. DORA is EU law with direct supervisory oversight and the possibility of sanctions. ISO 27001 is a voluntary standard whose value comes from certification, not legal obligation. An organisation can hold ISO 27001 certification and still be non-compliant with DORA if it has not addressed DORA’s specific requirements around incident reporting timelines, TLPT obligations, or ICT third-party contractual requirements.

Another key distinction is scope and integration. ISO 27001 focuses primarily on information security and can be applied to any organisation or part of an organisation. DORA applies to the entire digital operational resilience posture of a financial entity, including operational continuity, outsourcing chains, and systemic risk. DORA also explicitly requires the management body to take personal accountability for the ICT risk framework, a governance requirement that goes beyond what ISO 27001 typically enforces in practice.

That said, ISO 27001 and DORA are complementary rather than competing. Organisations that have already built a mature ISO 27001 programme will find that many controls transfer directly. The gap work typically lies in DORA-specific areas: the incident classification taxonomy, the structured third-party register with contractual minimum clauses, and the testing programme requirements.

What role does the management body play in DORA internal controls?

Under DORA, the management body bears direct, non-delegable responsibility for the ICT risk management framework. Senior leadership must approve the framework, allocate sufficient budget and resources for its implementation, receive regular reporting on ICT risks, and take accountability for the organisation’s overall digital operational resilience posture. Governance sits at board level, not solely within IT or compliance functions.

This is one of DORA’s most important and frequently underestimated requirements. The regulation explicitly states that members of the management body must maintain sufficient knowledge and skills to understand and assess ICT risks. This means boards and executive teams cannot simply delegate oversight to a CISO or IT manager and consider their obligation fulfilled. They must be actively informed and demonstrably engaged.

What the management body must approve and monitor

The management body is required to approve the ICT risk management framework and any significant revisions to it. It must also approve the digital operational resilience strategy, the ICT business continuity policy, and the ICT response and recovery plans. Approval is not a rubber-stamp exercise: DORA expects evidence that leadership has reviewed and understood the material.

How management accountability connects to continuous governance

DORA’s management body requirements reinforce the principle that governance must be a permanent organisational capability. When leadership is structurally embedded in the oversight cycle, ICT risk management becomes part of the organisation’s operating rhythm rather than a periodic compliance exercise. This is precisely the model that continuous governance frameworks are designed to support: keeping management informed, controls current, and accountability clear at all times.

How should third-party ICT providers be controlled under DORA?

DORA requires financial entities to maintain a complete, up-to-date register of all ICT third-party service providers, ensure that contracts with those providers include a defined set of mandatory clauses, conduct ongoing monitoring and risk assessments of the entire ICT supply chain, and implement exit strategies for critical or important functions. Third-party risk management must be systematic and continuous, not reactive.

The mandatory contractual requirements are among the most operationally demanding aspects of DORA third-party control. Contracts with ICT providers supporting critical or important functions must include, at minimum: a full description of services, service levels and their measurability, data location and security requirements, incident cooperation and reporting obligations, audit rights for the financial entity and its supervisors, and termination rights linked to regulatory requirements.

Many organisations discover during readiness assessments that their existing vendor contracts, particularly legacy agreements with large cloud providers or software vendors, do not meet these standards. Remediating contract language across a complex supplier base requires time, negotiation, and a structured programme of engagement.

For critical ICT third-party providers, DORA also introduces direct oversight by EU supervisory authorities. This does not remove the financial entity’s own obligations but adds a layer of regulatory scrutiny to the relationship. Financial entities must therefore be prepared to demonstrate their oversight activities, not merely assert that they exist.

A practical approach to third-party ICT control starts with a tiered classification of providers by criticality, followed by gap analysis of existing contracts, prioritised remediation of the highest-risk relationships, and integration of third-party risk into the ongoing ICT risk management cycle. Explore our governance services to understand how a structured, subscription-based model can support this kind of continuous third-party oversight.

What are the most common internal control gaps in DORA readiness assessments?

The most common internal control gaps identified in DORA readiness assessments are: incomplete or informal ICT risk registers, absent or untested business continuity and recovery plans, insufficient incident classification processes, non-compliant third-party contracts, and a lack of documented management body involvement in ICT governance. These gaps tend to cluster in organisations that have treated governance as a project rather than an ongoing function.

Risk register and documentation gaps

Many organisations have some form of risk register but it is either not ICT-specific, not regularly updated, or not formally owned by the management body. DORA requires the register to be comprehensive, current, and linked to protective and corrective measures. A risk register that was last reviewed eighteen months ago does not meet the standard of continuous governance that DORA expects.

Incident management process gaps

DORA’s incident classification criteria are specific and require organisations to assess incidents against thresholds covering criteria such as the number of clients affected, data losses, duration, and geographic spread. Many organisations lack a formal classification methodology and rely instead on informal judgement. This creates both under-reporting risk and the possibility of missing mandatory notification deadlines, which are measured in hours for initial alerts.

Third-party contract and oversight gaps

As noted above, legacy contracts are a persistent source of non-compliance. Beyond the contractual language itself, many organisations also lack a formal process for ongoing monitoring of third-party performance and risk posture. DORA expects documented evidence of monitoring activity, not just a signed contract.

Management body engagement gaps

Perhaps the most structurally significant gap is the absence of formal governance structures that bring ICT risk to the management body on a regular, documented basis. Where ICT governance sits entirely within IT or a second-line compliance function without structured board-level reporting, organisations cannot demonstrate the management accountability that DORA explicitly requires.

Addressing these gaps requires more than a one-time remediation project. It requires building governance into the organisation’s operational rhythm so that controls remain effective, documentation stays current, and leadership remains informed as the threat and regulatory landscape evolves. That is the difference between a compliance sprint and genuine, sustainable DORA readiness. Contact us to find out how we can help you build that foundation.

Frequently Asked Questions

How long does it typically take to achieve full DORA compliance from a standing start?

The timeline varies significantly depending on the maturity of your existing ICT governance, but most organisations should expect a 12–24 month programme to address all five core categories comprehensively. Entities with a mature ISO 27001 or NIST framework in place may close the gap faster, but DORA-specific requirements — particularly third-party contract remediation and establishing board-level governance structures — consistently take longer than anticipated. Starting with a structured readiness assessment helps you prioritise effort and avoid spending time on controls that are already adequate.

Which financial entities are actually in scope for DORA, and are there any exemptions?

DORA applies to a broad range of financial entities operating in the EU, including banks, investment firms, insurance and reinsurance undertakings, payment institutions, crypto-asset service providers, and critical ICT third-party providers themselves, among others. Some proportionality provisions exist for smaller or less complex entities, meaning they may be subject to a simplified ICT risk management framework rather than the full requirements. However, proportionality does not mean exemption — even smaller in-scope entities must demonstrate meaningful compliance with the core obligations.

What happens if our organisation misses a major incident reporting deadline under DORA?

Missing a mandatory incident reporting deadline is a direct regulatory breach and can result in supervisory scrutiny, formal investigations, and financial sanctions imposed by your competent authority. DORA's initial alert requirement for major ICT incidents must be submitted within four hours of classification, with an intermediate report within 72 hours and a final report within one month — these are tight, operationally demanding windows. The most effective safeguard is a pre-built, rehearsed incident response process with clear ownership, pre-drafted notification templates, and direct lines to your regulatory contact, so that classification and reporting can proceed under pressure without delay.

How do we determine which of our ICT third-party providers support 'critical or important functions'?

DORA requires you to make this determination based on a structured risk assessment that considers factors such as the substitutability of the provider, the potential impact of a service disruption on your operations and clients, and the sensitivity of data processed. In practice, this means mapping your ICT supply chain against your critical business processes and assessing what would happen if each provider became unavailable or was compromised. Providers that underpin core banking, payment processing, client-facing services, or regulatory reporting functions will almost always qualify — and those relationships require the full suite of mandatory contractual clauses and ongoing monitoring.

Is threat-led penetration testing (TLPT) required for all in-scope organisations?

No — TLPT is an advanced testing requirement that applies only to the most significant financial entities, as determined by competent authorities based on criteria including systemic importance, scale, and risk profile. The majority of in-scope organisations will be required to conduct basic resilience testing, such as vulnerability assessments, scenario-based tests, and business continuity exercises, rather than full TLPT. That said, all organisations should build a testing programme that feeds results back into the risk management cycle, and those approaching the TLPT threshold should begin planning for it proactively rather than waiting for a supervisory notification.

Can we rely on our ICT providers' own compliance certifications to satisfy DORA's third-party oversight requirements?

No — DORA places the oversight obligation squarely on the financial entity, and a provider's ISO 27001 certificate or SOC 2 report does not substitute for your own documented monitoring and risk assessment activities. You may use third-party audit reports and certifications as inputs to your oversight programme, but you must maintain your own evidence of ongoing due diligence, including periodic risk reviews, performance monitoring against contractual SLAs, and documented follow-up on any identified weaknesses. Supervisors will expect to see your oversight records, not simply a folder of supplier certificates.

What is the most practical first step for an organisation that has not yet started its DORA compliance programme?

The most effective starting point is a structured gap assessment that maps your current ICT governance, incident management, testing, and third-party oversight practices against DORA's specific requirements across all five control categories. This gives you a clear, prioritised view of where your most significant exposures lie before you commit resources to remediation. From there, the highest-priority actions are typically formalising management body governance structures, updating the ICT risk register, and beginning the contract review process for critical third-party providers — as these areas carry the greatest regulatory and operational risk and take the longest to remediate.

Related Articles

Share

  • July 13, 2026