DORA Compliance in 2026: The Evidence NCAs Need to See

Since DORA entered into application in January 2025, the question is no longer whether you have an ICT risk management framework in place. The question is whether that framework operates as your policies say it does.

In 2026, NCAs — responsible for day-to-day supervision under DORA — will look beyond implementation plans and policy reviews. They will want your teams to demonstrate how the ICT risk framework is governed, how your organization identifies and records third-party dependencies, how incidents move through reporting workflows, and whether resilience testing covers the systems and providers that support critical or important functions.

This means, your compliance program must be traceable from management-body approval to operational control, supplier record, test result, and remediation decision.

When financial entities are unable to retrieve this data quickly, DORA compliance gaps become visible. A board-approved policy is not enough if your vendor inventory omits subcontractors supporting a critical or important function. An incident procedure is not enough if your team cannot show how it classified an event, who made the decision and whether it met the applicable notification and reporting deadlines.

This article examines four DORA compliance gaps likely to attract early supervisory attention in 2026: management-body accountability, Register of Information data quality, incident-reporting readiness, and ICT third-party oversight.

Management-body accountability: Approval is only the starting point

DORA’s Article 5 requires the management body to define, approve, oversee and remain responsible for the entity’s ICT risk management framework.

This means, your board, or equivalent management body, should be able to show when it approved the framework, which version it approved, who owns each material area of ICT risk and how it receives information about resilience issues. Evidence may include meeting agendas, board papers, minutes, approval records, risk reports, and action trackers.

Consider a payment institution that approved its ICT risk management policy in early 2025. Since then, it has moved a customer-facing application to a new cloud environment, changed its incident-response process and added a new provider supporting transaction monitoring. If the management body has not received an updated risk assessment, reviewed those dependencies or tracked the related remediation work, the original approval does not show that it is overseeing the framework now.

To ensure your entity’s DORA compliance, start with a simple question: Can your team connect each management-body decision to an owner, a control, a review date, and a documented outcome?

If the answer is no, the issue is not necessarily that your board has ignored ICT risk. More often, the governance record sits across committee packs, ticketing systems, policy repositories and supplier-management files. Under supervisory review, your team needs to assemble that record quickly and explain how the pieces connect.

DORA also requires management-body members to maintain sufficient knowledge and skills to understand and assess ICT risk and its impact on the entity. That makes training records relevant. A dated training session, attendance record and materials tailored to the entity’s risk profile are more useful than a generic statement that directors receive regular cyber updates.

Register of Information: Data quality becomes a control issue

The Register of Information, often shortened to RoI, is a structured record of contractual arrangements with ICT third-party service providers that financial entities must maintain and report to their competent authority. It shows where your ICT dependencies sit, which services support critical or important functions, and how concentration or subcontracting risk may affect operational resilience.

Procurement may hold the master contract, information security may maintain a separate vendor-risk record, and finance may record a different legal entity for invoicing. Although all the information may be available, none of these records alone provides a complete and accurate view of the entity’s ICT third-party arrangements under Article 28 of DORA.

Here, the first question is completeness. Have you captured every relevant ICT service arrangement, including cloud hosting, software-as-a-service platforms, managed security services, data providers, payment infrastructure and outsourced operational services with an ICT component?

The second is classification. Can your team explain which arrangements support a critical or important function and why? A service may be modest in spending terms but still be operationally material. Identity and access management, communications tooling, fraud detection, customer onboarding, market-data feeds and backup services can all create serious dependencies when they fail.

 The third question should be subcontracting. Your direct provider may rely on other companies to deliver the service. DORA’s third-party-risk framework requires financial entities to understand and manage those arrangements, particularly where they affect a critical or important function.

A practical review should test whether the register can answer five questions without manual reconciliation: What service do we receive? Which legal entity provides it? Which business function depends on it? Is that function critical? What subcontractors or downstream dependencies are relevant?

If the answer depends on one person’s institutional knowledge, the data is not ready.

Incident reporting: Show the decision trail

DORA requires financial entities to define, establish and implement an ICT-related incident management process. They must record ICT-related incidents and significant cyber threats, identify and document root causes, address them and report major ICT-related incidents to the relevant competent authority.

For every material incident, your team should be able to show when it detected the issue, who assessed the operational impact, how it applied the classification criteria, whether the event met the threshold for a major ICT-related incident, who approved the reporting decision and what follow-up actions resulted. The detailed reporting rules also require consistent information fields, including the date and time of detection for a major ICT-related incident.

This record matters even when an incident does not lead to an NCA notification. A supervisor may reasonably ask how your team concluded that an event fell below the reporting threshold. “The incident was resolved quickly” is not a classification rationale.

Consider a cloud outage that disrupts customer access for 45 minutes. Operations may view it as a contained service interruption. Compliance may need to assess whether it affected critical or important functions, customers, transactions, data integrity or the entity’s reputation. Technology may still be determining the root cause. A defensible process captures these assessments, the evidence used and the decisions made at each stage.

The same discipline applies after the event.

DORA requires firms to ensure that root causes are identified, documented and addressed to prevent recurrence. If the post-incident review identifies a control weakness, the record should show the remediation owner, target date, testing approach and closure decision.

This is where incident management connects back to management-body oversight. Significant incidents, recurring weaknesses and overdue corrective actions should appear in the reporting your management body receives. Otherwise, the entity may have operational data without evidence of effective governance.

ICT Third-Party Oversight: Test the Services You Actually Depend On

While the Register of Information shows what ICT services and providers your entity depends on, third-party oversight shows whether you have assessed, contracted for and monitored those dependencies well enough to manage disruption.

DORA requires financial entities to manage ICT third-party risk as part of the ICT risk management framework. For services supporting a critical or important function, it includes assessing the provider before contracting, documenting the arrangement, setting contractual requirements and monitoring the risk throughout the relationship.

A contract may name a cloud provider as the direct supplier for a critical or important function. However, keeping that service available may also depend on identity and access management, data storage, content delivery, backup, monitoring and API infrastructure, some of which may be provided by subcontractors or separate third parties. If a supplier review assesses only the company named in the contract, it can miss the underlying services whose failure would interrupt the critical or important function.

To know the real picture, start with the function, not the vendor.

Ask which customer, trading, payment, onboarding, reporting or internal control function the service supports. Then identify the systems, providers and subcontractors required to keep that function available, secure and recoverable. That is the dependency map your risk assessment, Register of Information, contracts and testing plan should share.

DORA also expects financial entities to consider concentration risk. If several critical or important functions rely on one provider, one region, one technology stack or one small group of subcontractors, a single disruption can affect multiple business processes at once. The issue is not whether using a large provider creates automatic noncompliance. The issue is whether your entity understands the exposure and has documented controls for it.

For critical or important functions, those controls should include contractual provisions on service levels, access and audit rights, security requirements, incident cooperation, subcontracting conditions, data handling, termination rights and exit arrangements. The contract is not the entire control. It is the point at which your operational expectations become enforceable.

Then test the assumptions behind it.

If a provider becomes unavailable, can your team continue the affected critical or important functions? Can it restore data, move workloads, activate a manual fallback or obtain the information needed to notify customers and regulators? Your resilience-testing program should test these questions against the systems and providers that support the actual service—not only the applications your organization owns directly.

DORA requires financial entities other than microenterprises to conduct appropriate testing at least annually on ICT systems and applications that support critical or important functions. The testing program must identify weaknesses and drive corrective action.

The evidence should show more than that a test took place. It should show the scenario, the services and third parties in scope, the result, the control gaps identified, the remediation owner and the date the entity verified closure.

A third-party-risk file is complete when your entity can show that it understands the dependency, has tested the relevant failure scenario and can act on the result.

What to prepare now

The goal is not to create a separate DORA evidence repository for every policy, contract and test. It is to make the existing record retrievable, current and connected.

Start with four evidence packs aligned to the gaps above:

Management-body governance: Framework approval, meeting minutes, ICT risk reporting, decisions, action tracking and director training records.

Register of Information: Complete supplier data, service descriptions, criticality assessments, legal-entity details, contracts and subcontracting information.

Incident management: Incident logs, classification assessments, escalation records, report submissions where applicable, root-cause analyses and remediation tracking.

ICT third-party risk oversight: Due-diligence records, criticality and concentration-risk assessments, contracts, subcontracting information, ongoing monitoring, exit plans and supplier-related remediation records.

Then run a retrieval exercise. Give the responsible teams a realistic internal deadline and ask them to produce the record for one critical or important function, one recent ICT incident and one significant supplier relationship.

Do not grade the exercise on whether every document exists. Grade it on whether someone outside the process can follow the chain from management-body oversight to operational control and corrective action.

That is the practical standard emerging under DORA. An entity that can explain its decisions, show its records, and close its findings is in a much stronger position than an entity with an extensive policy library and no clear evidence of operation.

DORA’s requirements are technical. The content explaining them should be equally precise.

NexLayer Content helps RegTech and finance-adjacent SaaS teams turn complex regulatory developments into credible thought leadership, search-led articles and buyer education for technical audiences.