Key takeaways

• DORA’s Register of Information is not a vendor list. It is an operational dependency map with evidentiary weight.
• Classification of ICT services as critical or important must follow business impact, not contract value or cost category.
• Ongoing monitoring means a continuous evidence trail, not a once-a-year review.
• When a provider limits audit access, the absence of a formal documented response is a larger supervisory concern than the limitation itself.

A supervisory review of DORA compliance does not start with the register. It starts with a question: can your organization explain, with documentation, why a specific service is classified the way it is, what has been monitored since the last review, and what happened when something went wrong?

Most financial institutions that have built their ICT third-party register as a compliance artifact cannot answer that question cleanly. The fields are filled. The classifications exist. The annual review happened. But the logic behind the decisions, the evidence trail from ongoing monitoring, and the documented responses to provider issues are missing or incomplete.

DORA does not reward paperwork. It rewards demonstrated governance. Understanding what that means in practice, for the register, for classification, and for the annual review process, is what determines whether an organization is ready for scrutiny or merely looks ready on paper.

What the DORA ICT third-party register must contain

The Register of Information (RoI) required under DORA is not a procurement tool or a contact directory. Its regulatory function is to demonstrate that an organization understands its operational dependencies and the risks those dependencies generate.

The mandatory fields under DORA’s RTS and ITS for the Register of Information cover provider identification, description of services provided, indication of whether those services support critical or important functions, data and processing location, subcontractor details and outsourcing dependencies, key contractual terms including contract duration and exit conditions, and elements supporting exit strategy execution.

Beyond the mandatory field list, supervisors expect that register entries can be linked to contracts, risk assessments, due diligence outcomes, and evidence of ongoing monitoring. These connections are not explicitly enumerated in the RTS, but they are necessary to demonstrate effective ICT third-party risk management. An organization that can produce a complete register but cannot connect its entries to documented risk decisions has a governance gap, not a compliance gap.

Mature organizations extend the register further, adding data classification, concentration risk indicators, fourth-party dependencies, service-to-business-process mapping, and RTO/RPO requirements. These additions matter for resilience analysis and concentration risk management, particularly where multiple critical processes depend on a single provider, cloud region, or shared technology component.

The most common register failure is treating it as a procurement artifact, something maintained by vendor management teams for procurement purposes and presented to supervisors as DORA evidence. A well-maintained Register of Information should answer two questions at a glance: which services and providers support critical business processes, and what risks arise if those services are disrupted.

How to classify ICT services as critical or important under DORA

DORA requires CIF classification to follow operational impact, not contract value, spending category, or technical complexity. The governing question is whether a disruption or unavailability of the service could materially affect business continuity, customers, regulatory compliance, or the delivery of critical or important functions.

The outcome of classification drives significant downstream obligations, covering monitoring intensity, operational resilience testing requirements, contractual provisions on audit rights and SLA terms, business continuity planning, and the depth of exit strategy preparation.

Classification should assess the full operational context of a service, not the system in isolation. Provider substitutability, technology and integration dependencies, concentration risk contribution, tolerated downtime, customer and regulated service impact, regulatory obligation delivery capacity, and data location all factor into the assessment. DORA and the associated RTS place particular emphasis on cumulative impact: scenarios where the failure of one provider simultaneously affects multiple business processes or multiple entities within a group.

In practice, services supporting payments and core systems, trading and transaction processing, identity and access management, security monitoring, connectivity, and cloud infrastructure are frequently classified as critical or important. Many reach this classification not because of any single system’s importance, but because of the scale of operational dependencies that have accumulated around them. A public marketing site or local administrative tool would typically fall outside CIF classification, unless its unavailability affects regulated processes or critical operations.

Supervisors will examine not just the classification result, but the logic behind it, consistency across similar services, and the connection between classification and monitoring, resilience testing, and exit planning. Cross-functional assessment involving compliance, ICT risk, security, procurement, and business owners consistently produces more defensible outcomes than decisions made within a single function.

What ongoing DORA monitoring actually requires

DORA requires continuous monitoring of ICT third-party providers supporting critical or important functions. Periodic or annual reviews are not sufficient on their own.

The distinction that matters most is between passive document collection and active risk management. Supervisors expect a continuous evidence trail showing that the organization identified risks, analyzed them, responded to them, and made governance decisions based on them. Monitoring should cover SLA and KPI performance, security and operational incidents, vulnerabilities and cyber exposure, subcontracting changes, concentration risk evolution, and the provider’s operational resilience. It should also capture changes that shift a provider’s risk profile: new subcontractors, data relocation or jurisdictional change, ownership structure changes, significant cyber incidents, financial deterioration, and geopolitical developments.

In practice, maintaining this trail means keeping SLA and KPI trend reports, audit results and SOC 1 and SOC 2 reports, certifications, incident logs and remediation records, DR/BCP test outcomes, vulnerability assessments, access management reviews, and documentation of escalations, risk acceptance decisions, and follow-up actions.

The most common finding during supervisory reviews is an organization that has dashboards and reports but cannot demonstrate what actions were taken as a result. What supervisors look for is evidence of real governance: formal escalations, documented challenges to providers, agreed remediation plans, risk acceptance decisions, and updates to classification and exit strategy in response to identified risk changes.

Mature third-party monitoring functions operate as continuous risk management, not as a vendor review performed once a year.

What a DORA annual review must include

An annual ICT third-party review should be a documented, risk-based process. Its purpose is to confirm that the organization still understands its dependency profile, manages it effectively, and maintains adequate controls and operational resilience.

Minimum scope covers security incident history, SLA/KPI realization and trends, security control effectiveness, audit and assurance outcomes including SOC reports, subcontracting changes, provider financial condition, concentration risk, regulatory compliance status, and the effectiveness of BCP, DR, and exit strategy. The review should also reassess whether the service continues to support critical or important functions and whether the risk classification remains current.

Supervisors expect a full evidence trail: the current risk assessment, materials used in the analysis, evidence from ongoing monitoring, results from challenge sessions with the provider, governance decisions, formal risk acceptances, and agreed remediation plans. The ability to demonstrate not just data collection but active analysis and documented response is central to supervisory assessment.

Situations that create significant supervisory risk include identified material provider issues with no formal escalation, repeated SLA breaches with no remediation plan or risk acceptance decision, and growing operational dependency with no documented governance response. Each of these can be read as evidence of weak governance over ICT third-party risk.

DORA formalizes and reinforces expectations already present in prior outsourcing, operational resilience, and ICT risk management frameworks. Consistency across the Register of Information, contractual provisions, ongoing monitoring, CIF classification, and actual operational decisions is essential. Inconsistencies between these areas are a standard point of supervisory attention.

A mature annual review functions as a strategic reassessment of operational dependency, not as a compliance checklist.

When ICT providers refuse to provide audit evidence

DORA places significant weight on ensuring that organizations have appropriate access, audit, and monitoring rights for providers supporting critical or important functions. Contractual provisions should cover audit and inspection rights, incident and security issue reporting obligations, access to evidence of controls, transparency on subcontracting scope, and obligations to cooperate with regulators and supervisory authorities.

In practice, many global providers, particularly cloud and SaaS platforms, restrict individual audits or detailed security documentation disclosure. Organizations commonly rely on alternative assurance mechanisms such as SOC 1 and SOC 2 reports, ISO 27001 certifications, pooled audits, shared assessments, and hyperscaler compliance packages.

The operative question is not whether a provider holds a certification, but whether the available evidence adequately covers the organization’s risk profile. An ISO certificate or a generic compliance statement is rarely sufficient as the sole evidence of control effectiveness, particularly for services supporting critical or important functions.

Where a provider consistently limits transparency beyond the level the organization’s risk appetite can accept, DORA requires a formal assessment of the impact on ICT third-party risk. Available responses include implementing compensating controls, limiting the scope of service use, increasing monitoring intensity, obtaining formal risk acceptance from relevant governance bodies, renegotiating contractual terms, and initiating exit strategy and provider replacement planning.

DORA does not require financial institutions to win negotiations with the largest global providers. It requires conscious, active, and documented risk management that reflects limited visibility or limited control rights. From a supervisory perspective, the absence of a formal assessment and response to such limitations is a greater concern than the limitation itself.

How the DORA register connects to the EU critical third-party framework

The organization-level ICT third-party register and the EU oversight framework for critical ICT third-party providers serve different but complementary functions. The organization’s register is an internal operational and risk management tool. Data reported across thousands of institutions enables European supervisory authorities to identify providers of systemic significance to the EU financial sector.

Register data reveals which providers, particularly cloud and hyperscale platforms, support critical or important functions across multiple institutions at scale. Selected providers may subsequently be designated as critical ICT third-party providers under the EU oversight framework. That designation does not transfer risk management responsibility to the regulator. Financial institutions remain responsible for provider monitoring, risk assessment, concentration risk management, continuity planning, and exit strategy regardless of designation status.

Organizations should mark such providers within their register and include them in concentration risk and operational dependency analysis, particularly where multiple critical processes depend on the same provider, cloud region, or shared technology component. A mature DORA register functions not only as a compliance instrument but as an operational dependency map and a foundation for assessing organizational resilience.

FAQ

What mandatory fields must a DORA ICT third-party register contain?

Under DORA’s RTS and ITS for the Register of Information, mandatory fields include provider identification, description of services provided, indication of whether those services support critical or important functions (CIF), data and processing location, subcontractor details and outsourcing dependencies, key contractual terms including contract duration and exit conditions, and elements supporting exit strategy execution. Beyond the mandatory list, supervisors expect entries to be linkable to risk assessments, due diligence outcomes, and ongoing monitoring evidence. A register that satisfies the field requirements but cannot support those connections does not demonstrate effective ICT third-party risk management.

How does DORA determine whether an ICT service is critical or important?

Classification under DORA follows operational impact, not contract value or technical complexity. A service is critical or important if its disruption could materially affect business continuity, customers, regulatory compliance, or the delivery of critical or important functions. The assessment must consider substitutability, integration dependencies, concentration risk, tolerated downtime, and cumulative impact across the group. DORA requires a documented, defensible methodology, not just a list of results. Supervisors will assess the logic, consistency across similar services, and the connection between classification and subsequent monitoring and exit planning.

What is the difference between what DORA requires for ongoing monitoring versus an annual review?

DORA requires continuous monitoring throughout the life of a CIF-supporting service. An annual review is a structured point-in-time reassessment within that ongoing process, not a substitute for it. Ongoing monitoring produces the evidence trail: SLA reports, incident logs, SOC results, audit outcomes, access management reviews, and documented governance decisions. The annual review reassesses whether the risk classification remains current, whether the service still supports critical or important functions, and whether concentration risk, contractual terms, and exit strategy are still adequate. Organizations that treat the annual review as their primary monitoring mechanism are not meeting the DORA standard.

Can a provider’s ISO 27001 certification satisfy DORA’s evidence requirements?

Not on its own. DORA requires that the available evidence adequately covers the organization’s risk profile for a specific service. An ISO 27001 certification or a generic compliance statement confirms a provider has a certified management system, but it does not demonstrate the effectiveness of specific controls relevant to the services that support critical or important functions. For CIF-supporting services, organizations should seek SOC 1 or SOC 2 reports, pooled audit outcomes, or shared assessments in addition to certifications, and formally assess whether the combination of available evidence is sufficient given the service’s risk profile.

What happens if a supervisory review finds that a provider refused audit access and the organization has no documented response?

From DORA’s supervisory perspective, the absence of a formal documented response to a provider’s limited cooperation is a larger concern than the limitation itself. DORA does not require organizations to secure full audit access from every global provider. It requires that organizations formally assess the impact of limited visibility on their ICT third-party risk, document that assessment, and take proportionate action: compensating controls, increased monitoring intensity, formal risk acceptance, contractual renegotiation, or initiation of exit strategy. An organization that accepted a provider’s refusal without any formal governance response has not demonstrated effective ICT third-party risk management under DORA.