--- title: "DORA Compliance: Evaluating and Managing ICT Third-Party Providers" date: 2026-02-24T13:30:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/dora-ict-drittanbieter" section: "Entries: Articles" --- ### What DORA Requires for ICT Third-Party Risk (Art. 28 to 44) [\#](#what-dora-requires-for-ict-third-party-risk-art-28-to-44 "What DORA Requires for ICT Third-Party Risk (Art. 28 to 44)") DORA establishes a binding framework for how EU financial entities must manage, monitor, and exit relationships with ICT third-party providers. The obligations are not aspirational guidelines; they are requirements that supervisory authorities audit. The framework covers four core areas: **1. ICT Third-Party Register (Art. 28)** Every financial entity must maintain a register of information on all ICT third-party service providers. The register must document the services provided, whether each provider supports critical or important functions, and the contractual arrangements in place. This register must be available to competent authorities on request. **2. Risk Assessment Before Contracting (Art. 28 and 29)** Before entering into any arrangement with an ICT third-party provider, firms must assess whether that provider supports a critical or important function, and weigh concentration risk. This classification drives the depth of due diligence, the contractual requirements, and ongoing monitoring obligations. **3. Contractual Requirements (Art. 30)** Contracts with ICT third-party providers supporting critical or important functions must include specific provisions. These are not optional; missing clauses are a compliance gap. **4. Exit Strategies (Art. 28(8))** Financial entities must maintain documented, tested exit strategies for ICT services supporting critical or important functions. The exit strategy must be realistic, meaning it must account for transition timelines, data portability, and operational continuity. --- ### Critical vs. Important: The Distinction That Matters [\#](#critical-vs-important-the-distinction-that-matters "Critical vs. Important: The Distinction That Matters") DORA distinguishes between two levels of provider relevance, with different consequences: - **Critical ICT third-party providers:** designated by the EU supervisory authorities (ESAs) under the Oversight Framework. These providers are subject to direct EU supervisory oversight and stricter monitoring requirements. - **Providers of critical or important functions:** assessed internally by the financial entity itself. These relationships carry the full Art. 30 contractual requirements, a mandatory exit strategy, and regular risk reviews. - **Other ICT providers:** support non-critical, non-important functions. They require a basic register entry and proportionate oversight. For backup and storage providers, the classification depends on the data processed and the function supported. If a provider stores data required for regulatory reporting, payment processing, or customer records, it almost certainly supports a critical or important function. The classification cannot be avoided by relabelling services. --- ### How to Build an ICT Third-Party Register [\#](#how-to-build-an-ict-third-party-register "How to Build an ICT Third-Party Register") Building a compliant register is a structured project, not a spreadsheet exercise. The following steps reflect what DORA Art. 28 requires in practice. #### Step 1: Inventory All ICT Third-Party Relationships [\#](#step-1-inventory-all-ict-third-party-relationships "Step 1: Inventory All ICT Third-Party Relationships") Start with procurement records, contract management systems, and shadow IT assessments. The register must be comprehensive; partial inventories create compliance gaps. #### Step 2: Map Services to Functions [\#](#step-2-map-services-to-functions "Step 2: Map Services to Functions") For each provider, document which internal business functions they support. Use your business impact analysis (BIA) or operational risk framework as a reference. If you do not have a BIA, building one is a prerequisite. #### Step 3: Classify Each Provider [\#](#step-3-classify-each-provider "Step 3: Classify Each Provider") Apply the critical/​important distinction. Document the rationale. The classification must be defensible to a supervisor; ​“we assumed it was not critical” is not a defensible rationale for a payment processing backup provider. #### Step 4: Document Contractual Status [\#](#step-4-document-contractual-status "Step 4: Document Contractual Status") For each provider, record whether existing contracts meet DORA Art. 30 requirements. Flag gaps for remediation. Set deadlines. #### Step 5: Assign Ownership [\#](#step-5-assign-ownership "Step 5: Assign Ownership") Each provider relationship requires an internal owner: a named function responsible for ongoing monitoring, annual risk reviews, and exit strategy maintenance. #### Step 6: Maintain and Update [\#](#step-6-maintain-and-update "Step 6: Maintain and Update") The register is a living document. New providers must be added before go-live. Exited providers must be archived with a record of the exit process. --- ### Contractual Requirements Under DORA Art. 30 [\#](#contractual-requirements-under-dora-art-30 "Contractual Requirements Under DORA Art. 30") Art. 30 sets out a mandatory minimum for contracts with providers of critical or important functions. The following elements must be present: - **Service description:** clear specification of the ICT services provided, including service levels and performance metrics - **Data locations:** where data is processed and stored, including sub-processors and their locations - **Accessibility and recoverability:** provisions ensuring data can be accessed and recovered, including in insolvency or service disruption scenarios - **Audit rights:** the financial entity (and competent authorities) must have the right to audit the ICT third-party provider, including on-site inspections - **Sub-contracting:** restrictions on sub-contracting, and notification requirements when sub-contractors change - **Security standards:** reference to applicable information security standards the provider must meet - **Incident notification:** obligation for the provider to report ICT incidents affecting the financial entity - **Termination rights:** circumstances under which the financial entity can terminate the contract, including regulatory-driven termination - **Exit provisions:** cooperation obligations during the exit phase, including data migration support and transition assistance Contracts that predate DORA and do not include these elements must be remediated. Supervisors examine contract portfolios. --- ### Exit Strategies as a DORA Requirement: Cloud Backup Concentration Risk [\#](#exit-strategies-as-a-dora-requirement-cloud-backup-concentration-risk "Exit Strategies as a DORA Requirement: Cloud Backup Concentration Risk") DORA Art. 28(8) requires financial entities to develop documented exit strategies for ICT services supporting critical or important functions. This is where cloud backup arrangements create structural compliance challenges. #### The Concentration Risk Problem [\#](#the-concentration-risk-problem "The Concentration Risk Problem") When a financial entity uses a major cloud provider for backup and archiving, several concentration risks emerge simultaneously: - **Vendor lock-in:** proprietary storage formats and APIs make migration technically complex and expensive - **Data portability:** extracting large volumes of archived data from cloud storage takes time, often weeks or months for multi-petabyte archives, which may conflict with the transition timelines a realistic exit strategy requires - **Geographic concentration:** many cloud services rely on a small number of hyperscaler platforms, creating geographic and provider concentration that DORA explicitly flags as a risk - **Pricing leverage:** during an exit, the provider has significant leverage; egress fees alone can make data extraction prohibitively expensive #### Why On-Premises Secondary Storage Reduces ICT Third-Party Risk [\#](#why-on-premises-secondary-storage-reduces-ict-third-party-risk "Why On-Premises Secondary Storage Reduces ICT Third-Party Risk") On-premises storage infrastructure operated by the financial entity is not an ICT third-party arrangement; it is an internal asset. This has direct consequences for DORA compliance: - No Art. 30 contractual requirements apply to internal infrastructure - No exit strategy is required for internal storage systems - Data location is fully under the entity’s control, with no sub-processor notification obligations - Audit rights are inherent: the entity audits itself - There is no concentration risk at the provider level This is not an argument against all third-party ICT services. It is a recognition that for backup and long-term archiving of critical data, on-premises hardware WORM (Silent Cubes) and air-gapped secondary storage (Silent Brick System) materially reduce the DORA compliance surface. --- ### Cloud Backup Provider vs. On-Premises: DORA Risk Assessment [\#](#cloud-backup-provider-vs-on-premises-dora-risk-assessment "Cloud Backup Provider vs. On-Premises: DORA Risk Assessment") How the two models compare against the DORA requirements: - **ICT third-party register entry:** cloud backup provider yes; on-premises no (internal asset) - **Art. 30 contract requirements:** cloud yes, must be remediated if missing; on-premises not applicable - **Exit strategy:** cloud yes, with documented and tested data extraction timelines; on-premises not applicable - **Audit rights:** cloud must be contractually secured, and providers may resist; on-premises full internal control - **Data location control:** cloud limited, depends on provider contracts and sub-processors; on-premises complete, EU jurisdiction - **Geographic concentration risk:** cloud high through hyperscaler dependency; on-premises low - **GDPR third-country transfer risk:** cloud present if the provider uses US-based sub-processors; on-premises none, data remains on-site - **Egress and exit costs:** cloud significant, can impede a realistic exit; on-premises not applicable - **Supervisory oversight trigger:** cloud potentially, if the provider is designated critical; on-premises not applicable --- ### Checklist for the Next DORA Audit [\#](#checklist-for-the-next-dora-audit "Checklist for the Next DORA Audit") Use this checklist to identify gaps before a supervisory review: **ICT Third-Party Register** - All ICT third-party providers inventoried, including shadow IT and sub-processors - Each provider classified: critical/​important function or other - Register available in a format that can be submitted to competent authorities - Register ownership assigned; update process documented **Contracts** - All contracts with critical/​important function providers reviewed against Art. 30 requirements - Gaps identified and remediation deadlines set - Audit rights secured, including on-site inspection rights - Sub-contracting restrictions and notification obligations in place - Termination and exit provisions included **Exit Strategies** - Exit strategy documented for each critical/​important ICT service - Exit timelines tested against data portability realities (especially for cloud archives) - Internal transition capability assessed - Exit strategy reviewed and updated annually **Concentration Risk** - Cloud provider concentration assessed at function level - Geographic concentration mapped - Mitigation measures in place for high-concentration arrangements **Ongoing Monitoring** - Annual risk review scheduled for all critical/​important function providers - Incident notification obligations in contracts, plus an internal process to act on notifications - Named internal owner for each provider relationship --- ### Further Resources [\#](#further-resources "Further Resources") → Data Sovereignty Guide (/en/blog/datensouveraenitaet-leitfaden/) → DORA Requirements for the Financial Sector (/en/blog/dora-anforderungen-finanzsektor/) → Avoiding Vendor Lock-In: Strategies for IT Decision-Makers (/en/blog/avoid-vendor-lock-in/) → The Cloud Egress Cost Trap (/en/blog/egress-kosten-cloud/) → Silent Cubes: Hardware WORM Archiving (/en/produkte/silent-cubes/) → Silent Brick System: Air Gap Backup (/en/produkte/silent-brick-system/) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### Business Continuity Management Business Continuity Management (BCM) is the organizational framework that ensures critical business processes can be maintained or restored within defined timeframes even during severe IT failures, cyber attacks or other crises. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/business-continuity-management) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### Data Sovereignty Data sovereignty describes an organization's complete control over its data: where it is stored, who can access it, which legal framework applies to it and whether it is available at any time without dependency on a single provider. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/data-sovereignty) ### Air Gap An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/air-gap) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr)