DORA Third-Party ICT Risk: Art. 28–30 Guide for 2026

In this article ↓

Short answer
DORA third-party ICT risk at a glance
Article 28: General principles
The non-delegation principle
Third-party ICT risk strategy
Register of Information
Pre-contracting risk assessment
Exit strategies
Annual reporting
Article 29: ICT concentration risk
What concentration risk means in DORA
What the pre-contracting concentration assessment must cover
Critical or important functions: the hinge concept
Classification criteria
Documentation of the classification
Article 30: Key contractual provisions
Minimum provisions for all ICT arrangements
Extended provisions for critical or important functions
Subcontracting chains
Contract gap analysis
Due diligence and ongoing monitoring
Pre-contracting due diligence
Ongoing monitoring
The oversight framework for critical ICT third-party service providers
How designation works
What designation means for financial entities
Proportionality in third-party ICT risk management
What supervisors check
Common mistakes
Mistake 1: Treating the Register of Information as a one-off filing
Mistake 2: Classifying critical functions by spend
Mistake 3: Leaving Article 30 contract gaps unmanaged
Mistake 4: Ignoring subcontracting one level down
Mistake 5: Exit plans that exist only as documents
Mistake 6: No management-body sight of the third-party risk picture
Related reading
Primary sources
Bottom line
FAQ
What does DORA Article 28 require for ICT third-party risk?
Does using a DORA-compliant cloud provider satisfy the financial entity's own DORA obligations?
Which ICT contracts must comply with Article 30 provisions?
What is ICT concentration risk under DORA Article 29?
Is exit planning mandatory for all ICT arrangements?
What must the DORA Register of Information contain?
How does the ESA oversight of critical ICT third-party service providers affect financial entities?
What should a DORA third-party ICT risk evidence pack contain for supervisory review?

Last reviewed: 1 June 2026

Key takeaways

DORA Articles 28–30 impose a structured third-party ICT risk management regime on all in-scope financial entities: strategy, register, due diligence, contractual provisions and exit planning.
Financial entities remain fully responsible for DORA compliance even when ICT services are provided by third parties — the provider's own compliance posture does not substitute for the financial entity's obligations.
The depth of contractual requirements escalates for arrangements that support a critical or important function, triggering the full Article 30 mandatory provisions.
Supervisors check whether the Register of Information is current, concentration risk has been assessed before contracting, and Article 30 clauses are present in critical-function contracts.

Short answer

DORA third-party ICT risk management requires EU financial entities to govern their dependence on external ICT providers in a structured, documented and reviewable way.

Under Chapter V of Regulation (EU) 2022/2554, the obligations rest on three core articles that have applied since 17 January 2025:

Article 28 — general principles: a third-party ICT risk strategy, the Register of Information, preliminary risk assessment before contracting, and exit strategies for critical arrangements.
Article 29 — ICT concentration risk: a mandatory assessment of single-provider and cross-sector concentration before entering new ICT arrangements.
Article 30 — key contractual provisions: mandatory contract terms for all ICT services, with a deeper set of requirements where the arrangement supports a critical or important function.

Financial entities cannot delegate their DORA obligations to a provider. Contracting with a cloud platform, a licensed SaaS vendor or a managed service does not transfer the entity's regulatory accountability. The financial entity must demonstrate its own governance, assessment and oversight of each material ICT arrangement.

This guide covers the full Articles 28–30 framework, what supervisors examine in practice, and how the broader oversight regime for critical ICT third-party service providers (Articles 31–44) connects to the financial entity's obligations.

DORA third-party ICT risk at a glance

Area	Obligation	Applies to
Strategy	Adopt and maintain a strategy on ICT third-party risk (Art. 28)	All in-scope financial entities
Register of Information	Maintain a structured inventory of all ICT third-party contractual arrangements (Art. 28)	All in-scope financial entities
Pre-contracting assessment	Identify and assess risks before entering any ICT arrangement (Art. 28)	All in-scope financial entities
Concentration risk	Assess single-provider and sector-level ICT concentration before contracting (Art. 29)	All in-scope financial entities
Annual reporting	Report to the competent authority on new ICT arrangements and categories of providers (Art. 28)	Financial entities other than microenterprises
Exit strategies	Maintain documented exit plans for critical or important function arrangements (Art. 28)	All in-scope financial entities
Minimum contractual provisions	All ICT contracts must include defined terms on service description, locations, termination, security and incident assistance (Art. 30)	All in-scope financial entities
Extended contractual provisions	Critical or important function contracts require additional clauses: audit rights, subcontracting controls, data return, exit assistance (Art. 30)	Where the arrangement supports a critical or important function

Article 28: General principles

The non-delegation principle

Article 28 opens with the foundational rule: financial entities bear full responsibility for their DORA obligations regardless of how much ICT delivery is contracted to third parties.

This means a financial entity cannot rely on a provider's regulatory certification, security audit or compliance statement as a substitute for its own governance. The financial entity must conduct its own assessment, maintain its own register, hold its own contracts to the required standard and report independently to its competent authority.

Third-party ICT risk strategy

Financial entities must adopt a strategy on ICT third-party risk and review it regularly. The strategy should address:

the entity's overall approach to ICT third-party arrangements;
how criticality of ICT services and functions is assessed;
due diligence and monitoring standards;
requirements for contractual arrangements;
concentration risk thresholds and management;
exit planning requirements;
review and reporting cadence.

The strategy is not a one-off policy. It should be updated after material changes to the entity's ICT third-party landscape, including significant new arrangements, provider failures or changes in supervisory expectations.

Register of Information

Article 28 requires financial entities to maintain a Register of Information covering all contractual arrangements with ICT third-party service providers.

The register must connect:

the regulated entity;
the ICT third-party service provider;
the ICT service provided;
the business function supported;
critical or important function classification;
the governing contract;
subcontracting arrangements;
data and location information;
exit and continuity evidence.

The register must be kept current and made available to the competent authority on request. It is one of the most important DORA supervisory artefacts because it connects supplier relationships to operational dependency and contract status.

For a detailed implementation guide, see DORA Register of Information: 2026 Guide for ICT Third-Party Risk.

To work directly with the register structure, see the DORA Register of Information artefact.

Pre-contracting risk assessment

Before entering a new ICT arrangement, the financial entity must identify and assess all relevant risks associated with the ICT service. This covers:

whether the arrangement would support a critical or important function;
the provider's financial stability, security posture and service track record;
whether the service is easily substitutable if the arrangement were terminated;
whether contracting with this provider creates or increases ICT concentration risk;
what risks arise from the provider's subcontracting chain.

The assessment must be documented. If a supervisor or auditor later examines the arrangement, the pre-contracting decision trail — including the criteria applied and the approver — should be available.

Exit strategies

For ICT arrangements supporting critical or important functions, financial entities must maintain exit strategies that address:

how the ICT service can be migrated to an alternative provider or brought in-house;
what data return and deletion obligations apply under the contract;
what notice periods and transition assistance are contractually available;
what business continuity measures cover the transition period;
whether the exit path has been tested or validated.

Exit planning is not a theoretical document exercise. Supervisors and partner banks ask whether the financial entity can realistically exit a critical ICT arrangement without disrupting its regulated services. Contracts that do not give data-export rights or that lack transition assistance provisions undermine the exit strategy before it begins.

Annual reporting

Financial entities that are not microenterprises must report to their competent authority at least annually on: new ICT arrangements entered into during the year, categories of ICT third-party service providers, the types of contractual arrangements concluded, and the ICT services and functions being provided.

This reporting supports the competent authority's visibility of ICT dependency across the sector and may inform the European Supervisory Authorities' processes for designating critical ICT third-party service providers.

DORA third-party ICT risk programme behind schedule?

A 15-minute call with a CISO who has delivered DORA third-party risk for EU-licensed EMIs, PIs and CASPs — no pitch, just an honest view of where you stand.

Book a free 15-min call →

Article 29: ICT concentration risk

Article 29 requires financial entities to assess ICT concentration risk before signing new ICT arrangements.

What concentration risk means in DORA

Concentration risk in the DORA third-party ICT context arises from heavy dependence — at the entity level or across the sector — on a small number of ICT service providers for critical functions.

At the entity level, concentration risk includes:

reliance on a single ICT third-party service provider for multiple critical or important functions;
reliance on providers that are not easily substitutable within operationally acceptable timeframes;
reliance on intra-group entities for ICT services that support regulated operations.

At the sector level, systemic concentration arises when many financial entities depend on the same small group of ICT providers. This dimension is addressed separately through the ESA oversight framework for critical ICT third-party service providers (Articles 31–44) rather than through the financial entity's own assessment.

What the pre-contracting concentration assessment must cover

Before entering an arrangement, the financial entity must evaluate:

Concentration dimension	Assessment question
Substitutability	Could the ICT service be sourced from another provider within an operationally acceptable timeframe if needed?
Single-provider dependency	Does this arrangement increase concentration on a provider that already supports one or more critical functions?
Intra-group reliance	Is the provider an affiliated entity that could be affected by the same adverse event as the financial entity itself?
Exit complexity	Would terminating this arrangement be technically difficult, contractually constrained or operationally disruptive?
Cross-sector exposure	Is this provider already heavily used across the sector, creating systemic dependence at a level that supervisors have flagged?

The concentration assessment should be documented and linked to the Register of Information entry for the arrangement. It should be revisited after material changes to the entity's ICT provider portfolio.

Critical or important functions: the hinge concept

The classification of whether an ICT arrangement supports a critical or important function is the primary gateway to the deeper DORA obligations in Articles 28 and 30.

This classification determines:

whether the extended Article 30 contractual provisions apply;
the depth of pre-contracting due diligence required;
whether exit planning is explicitly mandatory;
the level of ongoing monitoring required;
what goes into board and supervisory reporting on ICT third-party risk.

Classification criteria

Factor	Questions to assess
Regulatory and operational impact	Would failure or disruption of this ICT service affect a regulated activity or customer-facing operation?
Recovery difficulty	Can the function be maintained or recovered within acceptable recovery objectives without this ICT service?
Data sensitivity	Does the ICT service process customer data, financial data, or data that is subject to regulatory requirements?
Substitutability	Is the provider and service reasonably replaceable within operational tolerances and without major transition risk?
Subcontracting chain	Does the provider use material subcontractors whose failure would propagate disruption to a critical service?

Do not classify by cost or contract value alone. A low-cost monitoring tool can support a critical fraud-detection workflow. A high-cost infrastructure provider may be operationally replaceable. The question is operational impact and substitutability, not expenditure.

Documentation of the classification

The criticality classification must be documented with rationale. If a supervisor challenges whether a function was correctly included or excluded, the financial entity must be able to show the criteria applied, the evidence considered and the decision-maker who approved the outcome. An undocumented classification — in either direction — creates a supervisory finding.

Article 30: Key contractual provisions

Minimum provisions for all ICT arrangements

Article 30 establishes minimum contractual provisions that all ICT arrangements must include, regardless of whether a critical or important function is supported. Every ICT contract should contain:

a clear description of the ICT services to be provided, including sub-services where relevant;
the locations where services will be provided and where data will be processed or stored;
provisions on data protection and information security;
rights for the financial entity to terminate the contract;
agreed service levels including performance metrics, reporting and escalation;
obligations on the part of the provider to cooperate with the financial entity in ICT incident management.

Extended provisions for critical or important functions

Where the arrangement supports a critical or important function, the contractual requirements go further. The contract must additionally include:

Contract area	What is required
Incident notification	Provider must notify the financial entity without undue delay of any ICT-related incidents that may affect the contracted services
Access and audit rights	Financial entity, its competent authority and other authorised parties must have the right to audit the provider and access relevant premises and systems
Security requirements	Specific ICT security standards the provider must meet, including what the financial entity can verify
Subcontracting controls	Conditions under which the provider may subcontract, including whether approval or notification is required for material changes
Data return and deletion	Provider must return data in a usable format and delete it on termination of the contract
Exit assistance	Provider must support the financial entity's transition or migration to an alternative arrangement
Business continuity	Provider must maintain continuity plans and cooperate in the financial entity's continuity and recovery processes
Termination rights	Financial entity must have the right to terminate without disproportionate penalties under defined conditions
Cooperation with authorities	Provider must cooperate with the financial entity's competent authority as required

Subcontracting chains

Where a provider subcontracts material parts of a critical ICT service, the financial entity must:

understand which subcontractors are involved and what each delivers;
assess whether subcontractor failure would affect the critical service;
ensure the contract grants rights to information about material subcontractor changes;
include material subcontractors in the concentration risk assessment;
capture subcontracting arrangements in the Register of Information.

DORA's subcontracting visibility requirement reaches one level beyond the direct provider relationship for critical ICT services. A financial entity that knows only its direct provider and not the material subcontractors supporting a critical function has incomplete third-party risk visibility.

Contract gap analysis

Most EU fintechs have ICT contracts that predate DORA and were not drafted with Article 30 in mind. The practical task is a clause-by-clause gap tracker, prioritised by whether the arrangement supports a critical or important function.

Contract area	Gap status	Priority
Service description	Present / missing / insufficient	High — all arrangements
Security requirements	Present / missing / insufficient	High — all arrangements
Incident notification	Present / missing / insufficient	High — all arrangements
Termination rights	Present / missing / insufficient	Medium — all arrangements
Audit and access rights	Present / missing / insufficient	High — critical functions
Subcontracting controls	Present / missing / insufficient	High — critical functions
Data return and deletion	Present / missing / insufficient	High — critical functions
Exit and transition support	Present / missing / insufficient	High — critical functions
Cooperation with authorities	Present / missing / insufficient	High — critical functions

Remediation can be through contract renegotiation, amendment, addendum or a side letter depending on what the counterparty will agree. Gaps should be tracked with a documented owner and target remediation date. An unmanaged gap without rationale creates a harder supervisory finding than a tracked gap with a remediation plan.

DORA by competent authority

DORA applies as EU law, but day-to-day reporting, evidence and supervisory dialogue runs through your National Competent Authority (NCA). Pick the jurisdiction-specific guide that matches your authorisation:

Jurisdiction	DORA competent authority	Guide
Cyprus	CBC	Cyprus guide →
Denmark	Finanstilsynet	Denmark guide →
Estonia	Finantsinspektsioon	Estonia guide →
France	ACPR	France guide →
Germany	BaFin	Germany guide →
Ireland	Central Bank of Ireland	Ireland guide →
Italy	Banca d'Italia	Italy guide →
Latvia	Latvijas Banka	Latvia guide →
Lithuania	Lietuvos bankas	Lithuania guide →
Luxembourg	CSSF	Luxembourg guide →
Malta	MFSA	Malta guide →
Netherlands	DNB	Netherlands guide →
Poland	KNF	Poland guide →
Spain	Banco de España	Spain guide →
Sweden	Finansinspektionen	Sweden guide →

See the DORA National Competent Authorities selected-jurisdictions hub for the full directory and the difference between NCAs and the EU ESAs (EBA, ESMA, EIOPA).

Due diligence and ongoing monitoring

Pre-contracting due diligence

The preliminary assessment required before entering ICT arrangements should produce documented due diligence covering:

Due diligence area	What to assess
Financial stability	Provider financial health, ownership structure and group relationships
Security posture	Security certifications, recent audit reports, penetration test evidence and material incident history
Service capability	Track record of delivering this type of ICT service, relevant staffing and infrastructure
Subcontracting	Which subcontractors are material, what they deliver and how the provider manages them
Resilience	Business continuity and disaster recovery commitments, test evidence and recovery time capabilities
Data practices	Data location, segregation, access controls and encryption standards
Regulatory standing	Any recent regulatory action, supervisory findings or material audit issues involving the provider

The depth of due diligence should be proportionate to whether the arrangement supports a critical or important function. A critical-function provider warrants a deeper review — potentially including audit reports, independent certifications and direct engagement — than a non-critical service provider.

Ongoing monitoring

For critical ICT arrangements, due diligence is not limited to the pre-contracting stage. A monitoring programme should include:

regular review of security certifications, audit reports and incident notifications received from the provider;
periodic assessment of service continuity and recovery performance against contractual commitments;
reassessment of concentration risk at a defined cadence or after material changes to the entity's ICT provider portfolio;
review of subcontractor changes and their implications;
update of the Register of Information following material changes to the arrangement.

The frequency of monitoring should reflect the criticality of the ICT service and the risk profile of the arrangement.

The oversight framework for critical ICT third-party service providers

DORA Articles 31–44 establish a separate oversight regime for ICT third-party service providers that the Joint Committee of the European Supervisory Authorities (ESAs) designates as critical. This is distinct from — but connected to — the financial entity's own Articles 28–30 obligations.

How designation works

The ESAs may designate an ICT third-party service provider as critical based on factors including: the systemic impact a failure would have on financial entities and regulated services, substitutability of the provider, and the number and type of financial entities that use the provider for critical or important functions.

Designation leads to direct ESA oversight of the provider, led by a lead overseer among the three ESAs (EBA, ESMA or EIOPA), with powers to audit, inspect, request information and issue recommendations.

What designation means for financial entities

A financial entity using a designated critical ICT third-party service provider should:

monitor oversight outcomes published by the lead overseer, including any findings or recommendations directed at the provider;
understand how those findings may affect the provider's ability to deliver the contracted ICT service;
factor supervisory findings into its own ongoing risk assessment of the arrangement.

Designation does not reduce the financial entity's own obligations under Articles 28–30. The entity's Register of Information, contractual provisions, concentration assessment and exit planning requirements are unchanged regardless of whether the provider is subject to ESA oversight.

Proportionality in third-party ICT risk management

DORA allows financial entities to calibrate implementation depth to their size, risk profile, nature, scale and complexity of operations. Smaller or less complex entities can apply proportionality to their third-party ICT risk management without eliminating the obligation itself.

Obligation	Proportionality principle
Register of Information	All entities maintain a register; detail and monitoring depth scale with portfolio size and criticality
Pre-contracting due diligence	Depth scales with criticality; a small PI can rely on a proportionate supplier questionnaire rather than a full on-site audit
Contract review	All critical-function arrangements require Article 30 provisions; remediation timelines can reflect entity capacity
Concentration assessment	Assessment is required for all entities; documentation complexity scales with number and type of arrangements
Exit planning	Exit strategies for critical function arrangements are required; the complexity of the exit plan reflects the service
Ongoing monitoring	Monitoring programme required for critical arrangements; frequency and intensity scale with the risk profile

Proportionality changes the depth of implementation. It does not change the obligation to manage ICT third-party risk, maintain the register or include the required contractual provisions for critical services.

For a broader guide to DORA proportionality, see DORA Proportionality Principle: 2026 Guide for Smaller Financial Entities.

What supervisors check

In third-party ICT risk examinations, competent authorities consistently focus on the following areas:

Area	Common supervisory focus
Register of Information	Is the register complete, current and linked to the entity's critical functions and contracts? Are entries owned and recently reviewed?
Criticality classification	Are classifications documented with rationale? Have any critical-function arrangements been omitted without justification?
Concentration risk assessment	Has the entity assessed concentration before contracting? Are assessments documented and linked to register entries?
Article 30 contract provisions	Do critical-function contracts contain the required provisions? Are gaps tracked with remediation owners and dates?
Exit planning	Is there a realistic and documented exit path for each critical ICT arrangement? Has it been tested or validated?
Annual reporting	Has the entity reported on new ICT arrangements as required?
Subcontracting visibility	Does the entity know material subcontractors for critical services and their role in the delivery chain?
Ongoing monitoring	Is the entity receiving and reviewing security assurance, incident notifications and continuity evidence from critical providers?
Senior management oversight	Is there designated senior management ownership of third-party ICT risk? Is the management body receiving adequate reporting?

The Register of Information is typically the starting point. A supervisor can trace from the register to the criticality classification, to the contract provisions, to the concentration assessment, and then to board reporting on third-party ICT risk. Gaps at any of those links generate findings.

For jurisdiction-specific NCA contacts and reporting guidance, use the DORA National Competent Authorities selected-jurisdiction hub.

Common mistakes

Mistake 1: Treating the Register of Information as a one-off filing

The register must reflect current arrangements. Onboarding a new provider, modifying a critical service dependency or executing a material subcontracting change should all update the register within a reasonable time. A register that is accurate at the point of filing but not maintained operationally is a compliance gap within months.

Mistake 2: Classifying critical functions by spend

A low-cost SaaS tool supporting transaction monitoring can be a critical function dependency. A large infrastructure contract may be operationally replaceable. Contract value is not the classification criterion — operational impact, substitutability and data sensitivity are.

Mistake 3: Leaving Article 30 contract gaps unmanaged

Most pre-DORA contracts have gaps. Unidentified gaps are the highest risk. Identified gaps with a documented remediation plan — owner, target date, interim controls — are far more defensible in a supervisory review than gaps discovered during an examination.

Mistake 4: Ignoring subcontracting one level down

For critical ICT services, material subcontractors supporting the provider can create their own concentration and resilience risk. The register and due diligence should extend to material subcontractors, not only the direct provider relationship.

Mistake 5: Exit plans that exist only as documents

Supervisors ask whether the exit strategy is realistic. If the contract does not give rights to data export, or if the migration plan assumes capabilities that do not exist, the exit plan is not defensible. Exit plans should be validated against contractual rights, technical feasibility and operational resources.

Mistake 6: No management-body sight of the third-party risk picture

If the management body is not receiving regular reporting on concentration risk, critical provider assessments, contract gap status and third-party incidents, the DORA governance requirement for management-body oversight of ICT third-party risk is not met — regardless of how well the technical team manages individual suppliers.

Primary sources

Bottom line

DORA third-party ICT risk management is not a supplier list or a procurement exercise.

Under Articles 28–30, financial entities must:

adopt a third-party ICT risk strategy and embed it in their ICT risk management framework;
maintain a current, complete Register of Information covering all ICT contractual arrangements;
assess concentration risk before contracting with any new ICT provider;
classify each arrangement by whether it supports a critical or important function;
ensure that critical-function contracts contain the Article 30 required provisions;
maintain realistic, documented and validated exit strategies for critical ICT arrangements;
conduct proportionate due diligence before contracting and ongoing monitoring of critical providers;
report on ICT third-party arrangements to the competent authority annually;
ensure the management body receives adequate reporting on third-party ICT risk.

Financial entities cannot delegate their DORA compliance obligations to the provider. Whatever the provider's regulatory standing, the financial entity holds full responsibility for its own governance, evidence and supervisory relationship.

FAQ

What does DORA Article 28 require for ICT third-party risk?

Article 28 requires financial entities to adopt a strategy on ICT third-party risk, maintain a Register of Information for all ICT contractual arrangements, conduct a risk assessment before entering new arrangements, assess ICT concentration risk, maintain exit strategies for critical or important function arrangements, and report annually to the competent authority on new ICT arrangements and provider categories.

Does using a DORA-compliant cloud provider satisfy the financial entity's own DORA obligations?

No. DORA is clear that financial entities remain fully responsible for their compliance regardless of whether ICT services are outsourced. A provider's security certifications or audit reports support the financial entity's due diligence but do not substitute for it. The financial entity must conduct its own assessment, maintain its own register and ensure its own contracts meet Article 30 requirements.

Which ICT contracts must comply with Article 30 provisions?

All ICT contractual arrangements must include the minimum provisions in Article 30. The extended provisions — covering audit rights, subcontracting controls, incident notification to the financial entity, data return and exit assistance — apply specifically where the arrangement supports a critical or important function. Classifying each arrangement before contracting determines which set of provisions applies.

What is ICT concentration risk under DORA Article 29?

Article 29 addresses the risk that arises when a financial entity — or the financial sector as a whole — depends heavily on a small number of ICT providers for critical or important functions. Before contracting, the entity must assess: how substitutable the provider is, whether concentration on this provider increases an existing dependency, and whether terminating the arrangement would be difficult or disruptive. The assessment must be documented.

Is exit planning mandatory for all ICT arrangements?

Exit planning is explicitly required for arrangements supporting critical or important functions. For other arrangements, practical exit and data-return considerations are a risk management good practice — particularly where the arrangement involves sensitive customer data or embedded operational dependencies. Supervisors focus most scrutiny on exit strategies for critical-function arrangements.

What must the DORA Register of Information contain?

The register must cover all ICT contractual arrangements and include: the regulated legal entity, the ICT third-party service provider, the ICT service, the business function supported, the critical or important function classification, contract details, subcontracting information, data and location details, and exit or resilience evidence. The exact technical format follows the applicable implementing technical standards and competent-authority guidance.

How does the ESA oversight of critical ICT third-party service providers affect financial entities?

The oversight framework in Articles 31–44 applies to ICT providers designated as critical by the ESAs — not directly to financial entities. If a financial entity uses a designated critical ICT provider, it should monitor oversight outcomes and any findings or recommendations directed at the provider, and factor these into its own ongoing risk assessment. The financial entity's obligations under Articles 28–30 are unchanged by the provider's designation status.

What should a DORA third-party ICT risk evidence pack contain for supervisory review?

A review-ready pack should include: the current Register of Information with data dictionary and owner list, documented criticality classifications with rationale, concentration risk assessments linked to register entries, pre-contracting due diligence records for critical providers, the Article 30 clause tracker and gap remediation log, exit strategies for critical ICT arrangements, ongoing monitoring records, annual reporting evidence, and management-body or risk-committee records showing oversight of third-party ICT risk.

DORA by competent authority

Andrey Gubarev

Related reading