How to manage DORA third-party ICT risk using AI

Overview

You'll learn how to implement DORA's third-party ICT risk management requirements under Articles 28-30 using AI. This guide covers building and maintaining the ICT third-party provider register, conducting pre-contractual assessments, incorporating mandatory contract clauses, assessing concentration risk, developing exit strategies, and establishing ongoing monitoring, with specific ISMS Copilot prompts for generating each component.

Who this is for

This guide is for:

• Third-party risk managers and vendor management professionals at financial entities

• Procurement and legal teams responsible for ICT service provider contracts

• CISOs and CROs overseeing ICT supply chain risk

• Compliance officers ensuring third-party arrangements meet DORA requirements

• Consultants advising financial entities on DORA third-party risk management

• ICT third-party service providers seeking to understand their clients' obligations

Before you begin

You will need:

• An ISMS Copilot account (free trial available)

• Your ICT asset inventory from How to build a DORA ICT risk management framework using AI (identifies which assets depend on third-party providers)

• A list of your current ICT third-party providers and the services they supply

• Access to existing ICT service contracts for review

• Understanding of which ICT services support your critical or important functions

• Access to your legal, procurement, and vendor management teams

Understanding DORA's third-party ICT risk requirements

Article-by-article breakdown

DORA Chapter V, Section I (Articles 28-30) establishes the most comprehensive third-party ICT risk management regime in EU financial regulation:

Article

Title

Key requirements

Key deliverables

Art 28

General principles

Third-party ICT risk policy, register of all providers, pre-contractual assessment, ongoing monitoring, management body responsibility

Third-party ICT risk policy, provider register, assessment procedures

Art 29

Preliminary assessment of ICT concentration risk

Assess concentration risk before entering new arrangements, consider substitutability, data location, operational risks of concentration

Concentration risk assessment, dependency analysis

Art 30

Key contractual provisions

Mandatory contract clauses: SLAs, audit rights, data location, incident support, exit provisions, subcontracting controls

Contract clause library, contract review checklist, amendment templates

The scope of third-party ICT risk under DORA

DORA takes an expansive view of third-party ICT risk. The requirements apply to all ICT services obtained from third parties, not just outsourcing arrangements. This includes:

• Cloud services: IaaS, PaaS, SaaS providers (AWS, Azure, Google Cloud, Salesforce, etc.)

• Core system providers: Core banking, payment processing, trading platforms

• Managed services: Managed security (SOC), managed IT operations, managed network services

• Data services: Data analytics, market data providers, credit scoring services

• Communication services: SWIFT, payment networks, messaging platforms

• Software providers: Enterprise applications, security tools, regulatory technology

• Infrastructure providers: Data center colocation, network connectivity, CDN services

Step 1: Build your ICT third-party provider register (Article 28)

Creating the register

Article 28(3) requires financial entities to maintain and update a register of information in relation to all contractual arrangements for ICT services. This register must be made available to the competent authority upon request and reported annually through standardized templates.

1. Open your DORA workspace in ISMS Copilot

2. Generate the register template:

   "Create an ICT third-party provider register template that satisfies DORA Article 28(3) and the associated Regulatory Technical Standards. Include fields for: provider identification (legal name, LEI, jurisdiction, parent company), contract identification (contract reference, start date, renewal date, termination notice period), service description (ICT services provided, service category, delivery model), function supported (critical or important function: yes/no, business function name), data classification (types of data processed, data location including country and region, data transfer mechanisms), subcontracting (subcontractors used, subcontractor location, subcontracted service details), risk assessment summary (risk rating, last assessment date, key findings), contract compliance status (DORA mandatory clauses present: yes/partial/no), exit strategy status (exit plan developed: yes/no, last tested date), and last review date. Include guidance notes for each field and provide sample entries for common provider types (cloud, core banking, managed security)."

3. Populate the register systematically:

   "Help us identify and categorize all ICT third-party providers for our register. We are a [entity type] using the following ICT services: [list known services and providers]. For each provider, help us classify: whether they support critical or important functions, the data they process and its location, subcontracting arrangements we should investigate, risk rating based on service criticality and provider dependency, and contract review priority. Also identify categories of providers we may have overlooked: DNS providers, certificate authorities, payment processors, market data feeds, regulatory reporting tools, backup and DR providers, identity providers, and telecommunications carriers."

Register maintenance and reporting

The register is not a one-time exercise. Establish ongoing maintenance procedures:

"Create a procedure for maintaining and updating the ICT third-party provider register under DORA. Include: triggers for register updates (new contracts, contract changes, provider changes, subcontracting changes, risk reassessment), update responsibilities and workflow, quality assurance checks, annual comprehensive review process, reporting requirements to competent authority (annual submission per RTS format), management body reporting (summary of register status, risk concentrations, compliance gaps), and integration with procurement processes (register update as mandatory step in new ICT procurement). Provide an annual register review checklist."

Step 2: Conduct pre-contractual assessments (Article 28)

Due diligence framework

Before entering into or renewing any ICT service arrangement, DORA requires a thorough assessment of the provider and the arrangement. The depth of assessment should be proportionate to the criticality of the function being supported.

1. Generate the assessment framework:

   "Create a pre-contractual ICT third-party provider assessment framework for DORA Article 28. Include assessment areas: provider financial stability and viability, ICT security capabilities and certifications (ISO 27001, SOC 2, CSA STAR), incident management and notification capabilities, business continuity and disaster recovery capabilities, data protection and privacy compliance (GDPR alignment), subcontracting practices and transparency, regulatory compliance track record, geographic risk assessment (data location, jurisdiction, political stability), exit and transition support capabilities, and provider reputation and market position. For each area, provide: assessment questions, evidence to request, scoring criteria (adequate, needs improvement, inadequate), and red flags. Create two assessment depth levels: standard assessment (for non-critical services) and enhanced assessment (for services supporting critical or important functions). Provide an assessment report template."

2. Create a provider security assessment questionnaire:

   "Create a detailed ICT security assessment questionnaire for evaluating third-party ICT providers under DORA. Cover: governance and organization (security leadership, policies, certifications), access management (authentication, authorization, privileged access), data protection (encryption at rest and in transit, key management, data classification), network security (segmentation, monitoring, intrusion detection), incident management (detection capabilities, response procedures, notification timelines), business continuity (BCP/DRP, RTO/RPO capabilities, testing frequency), vulnerability management (scanning, patching, remediation timelines), change management (testing, approval, rollback), personnel security (background checks, training, awareness), physical security (data center security, environmental controls), and subcontracting and fourth-party risk. Include both yes/no and open-ended questions. Provide scoring guidance."

Assessing provider risks before engagement

Use ISMS Copilot to evaluate specific providers or provider types:

"We are considering [provider name/type] for [service description] supporting [critical/important/standard function]. Conduct a DORA-aligned pre-contractual risk assessment. Consider: provider's ability to meet DORA contract clause requirements (Article 30), data location and transfer implications, subcontracting transparency, incident notification capability alignment with our 4-hour DORA reporting deadline, auditability (right to audit, access to reports), exit feasibility (data portability, transition support, lock-in risks), concentration risk implications (do we already depend on this provider or its parent company for other critical services?), and regulatory considerations for our competent authority. Provide a risk-rated assessment with a recommendation on whether to proceed."

Step 3: Implement mandatory contract clauses (Article 30)

Understanding Article 30 requirements

Article 30 specifies mandatory elements that must be included in contracts for ICT services. The requirements are even more detailed for services supporting critical or important functions. This is often the most labor-intensive aspect of DORA third-party risk management.

1. Generate the contract clause library:

   "Create a comprehensive DORA Article 30 contract clause library for ICT service agreements. For each mandatory requirement, provide: the DORA article reference, a model contract clause (ready for legal review), explanatory notes, and negotiation guidance. Cover all Article 30 requirements: clear service description with quantitative and qualitative performance targets, data processing locations (including storage, processing, and backup locations) with prior notification of changes, data protection and confidentiality obligations, data availability, authenticity, integrity, and accessibility guarantees, service level agreements (SLAs) with measurable metrics, incident notification obligations (aligned with DORA reporting timelines, requiring provider notification within timeframes that support our 4-hour deadline), provider cooperation with competent authorities, audit rights (right to conduct audits and inspections, including on-site, or reliance on third-party certifications), termination provisions and adequate transition periods, participation in ICT security awareness training. For services supporting critical or important functions, add enhanced clauses for: full service description with clear functions and sub-functions, performance targets with associated penalties, business continuity and disaster recovery obligations and testing, reporting obligations (regular reporting on service performance, security, and material changes), exit assistance obligations (data return, transition support, migration assistance), subcontracting requirements (prior approval, flow-down of DORA clauses, right to object), and unrestricted right of the financial entity to monitor on an ongoing basis."

2. Create a contract review checklist:

   "Create a DORA Article 30 contract compliance review checklist for existing ICT service agreements. For each Article 30 requirement, provide: the requirement description, compliant/partial/non-compliant assessment, specific clause reference in the existing contract (if present), gap description (if partial or non-compliant), recommended amendment language, and priority (critical for services supporting critical/important functions, standard for others). The checklist should be usable by legal and procurement teams reviewing existing contracts systematically. Include a summary scoring mechanism to identify which contracts require immediate renegotiation."

Negotiation strategies

Use ISMS Copilot to prepare for contract negotiations:

"Create a DORA contract negotiation strategy for discussions with our [provider type, e.g., major cloud provider / core banking vendor / managed security provider]. Address common provider pushbacks: 'We cannot provide individual audit rights to every customer' (discuss reliance on SOC 2/ISO 27001 reports, pooled audits, and third-party certification per Article 30(3)), 'We cannot guarantee specific data locations' (DORA requirements, regulatory expectations, alternative approaches), 'Our standard SLAs are not negotiable' (minimum DORA requirements, escalation approaches), 'We do not accept unlimited liability' (proportionate approaches, cap negotiations), 'Our notification timelines are 24-48 hours' (need to support 4-hour DORA deadline, tiered notification approach). For each pushback, provide: the DORA legal requirement, alternative approaches that satisfy the regulation, compromise positions, and escalation strategies."

Step 4: Assess and manage concentration risk (Article 29)

Understanding ICT concentration risk

Article 29 requires financial entities to assess ICT concentration risk before entering into ICT service arrangements and on an ongoing basis. Concentration risk arises when over-dependence on a single provider (or small group of providers) creates systemic vulnerability.

1. Generate the concentration risk assessment framework:

   "Create an ICT concentration risk assessment framework for DORA Article 29. Include: definition and scope of ICT concentration risk, assessment methodology covering: single-provider dependency (how many critical functions depend on one provider), provider group dependency (parent company, subsidiary, and affiliated provider analysis), technology stack dependency (dependence on a single technology platform), geographic concentration (all critical services in one region or data center), substitutability assessment (ease of replacing each critical provider), supply chain concentration (multiple providers depending on the same fourth party), market concentration (limited alternative providers in a service category). For each dimension, provide: assessment criteria, measurement metrics, risk rating thresholds (low, medium, high, critical), and mitigation strategies. Create a concentration risk dashboard template for management body reporting."

2. Conduct a concentration risk analysis:

   "Based on our ICT third-party provider register, conduct a concentration risk analysis. Our providers include: [list key providers and services]. Analyze: which providers support multiple critical functions (single-provider concentration), whether any providers share parent companies or infrastructure (group concentration), geographic concentration of our critical ICT services, market availability of alternative providers for each critical service, potential systemic risk if our most critical provider experienced a major outage, and fourth-party dependencies (e.g., multiple providers using the same cloud platform). Rate concentration risk for each identified dependency and recommend mitigation actions."

Concentration risk mitigation

When concentration risks are identified, develop mitigation strategies:

"For each high or critical concentration risk identified in our assessment, develop mitigation strategies. Consider: multi-provider strategies (distributing critical services across multiple providers), multi-cloud or hybrid approaches, maintaining internal capabilities as fallback, contractual protections (enhanced SLAs, business continuity obligations, escrow arrangements), technology portability measures (avoiding proprietary lock-in, using portable formats and standards), geographic diversification of critical services, fourth-party risk management (ensuring providers have their own concentration risk mitigation), and gradual diversification roadmaps where immediate change is not feasible. For each mitigation strategy, provide: implementation steps, timeline estimate, cost considerations, residual risk after mitigation, and management body decision points."

Step 5: Develop exit strategies (Article 28)

Exit strategy requirements

DORA requires financial entities to have exit strategies for ICT services supporting critical or important functions. Exit strategies must ensure that terminating or transitioning away from a provider does not disrupt services, compromise data, or reduce regulatory compliance.

1. Generate exit strategy templates:

   "Create exit strategy templates for DORA Article 28 compliance, covering ICT services supporting critical or important functions. For each critical provider/service, the exit strategy should include: trigger events for exit (provider failure, contract breach, concentration risk, strategic change, regulatory requirement), transition planning (target state options: alternative provider, in-house, hybrid), transition timeline and milestones (realistic for the service complexity), data migration plan (data extraction, format conversion, validation, deletion from provider), knowledge transfer requirements (documentation, training, operational handover), parallel running period (minimum duration, acceptance criteria for transition), resource requirements (internal team, external support, budget), communication plan (clients, regulators, other stakeholders), testing and validation of alternative arrangements before full transition, contractual provisions supporting exit (transition assistance period, data return obligations), and risk assessment of the exit process itself (transition risks, mitigation measures). Create templates for common scenarios: cloud provider exit, core system replacement, and managed service transition."

2. Establish exit strategy testing:

   "Create procedures for testing exit strategies for critical ICT third-party providers. Include: testing frequency (at least annual review, testing key components), test types (tabletop review of exit plan, partial data extraction test, alternative provider proof of concept, full transition simulation), test scenarios (planned exit with cooperation, emergency exit with limited provider cooperation, provider insolvency scenario), success criteria for each test type, documentation and reporting of test results, management body reporting on exit strategy readiness, and remediation of identified gaps. Provide a test schedule aligned with our overall DORA resilience testing program."

Step 6: Establish ongoing monitoring (Article 28)

Continuous provider monitoring

DORA requires ongoing monitoring of ICT third-party providers, not just point-in-time assessments. The intensity of monitoring should be proportionate to the criticality of the service:

1. Generate the monitoring framework:

   "Create an ongoing ICT third-party provider monitoring framework for DORA Article 28. Include monitoring activities: SLA performance tracking (availability, response times, incident resolution, against contractual targets), security posture monitoring (certifications maintained, vulnerability disclosures, public breach notifications), financial stability monitoring (credit ratings, financial reports, market news, acquisition activity), incident notifications from providers (timeliness, completeness, alignment with DORA requirements), subcontracting changes (new subcontractors, subcontractor location changes), regulatory developments affecting the provider (enforcement actions, license changes, designation as critical provider), and material changes to service delivery (technology changes, data center migrations, personnel changes). For each monitoring activity, specify: frequency (continuous, monthly, quarterly, annual), data sources, responsible role, escalation criteria (when monitoring findings trigger reassessment or contract review), and documentation requirements. Create a monitoring dashboard template."

2. Define provider performance review procedures:

   "Create an ICT third-party provider performance review procedure for DORA compliance. Include: review frequency (quarterly for critical providers, semi-annual for important, annual for standard), review agenda template (SLA performance, security posture, incidents and notifications, subcontracting, material changes, compliance status), attendees (provider relationship manager, security, compliance), escalation procedures for underperformance (remediation requests, enhanced monitoring, management body notification, contract termination triggers), documentation requirements (review minutes, action items, provider commitments), and annual summary reporting for the management body and competent authority. Provide a provider performance review report template."

Subcontracting oversight

DORA requires oversight of subcontracting chains. Your monitoring must extend beyond your direct providers:

"Create a subcontracting oversight procedure for DORA compliance. Include: contractual requirements for subcontracting transparency (prior notification or approval, right to object), provider obligations to disclose subcontractors and their roles, assessment criteria for material subcontractors (same criteria as for the primary provider), monitoring of subcontracting chain changes, procedures when providers add new subcontractors (assessment, risk review, approval or objection), fourth-party risk assessment (subcontractors of subcontractors), flow-down of DORA-relevant contract requirements to subcontractors, and escalation procedures when subcontracting arrangements increase concentration risk. Provide a subcontracting register template and an assessment workflow."

Step 7: Governance and management body reporting

Third-party ICT risk policy

Article 28(2) requires a policy on the use of ICT services supporting critical or important functions. This policy must be approved by the management body:

"Create a Third-Party ICT Risk Management Policy for DORA Article 28(2). Include: policy purpose, scope, and applicability, management body responsibilities for third-party ICT risk oversight, risk appetite for third-party ICT services (acceptable concentration levels, geographic restrictions, provider standards), pre-contractual assessment requirements (triggering criteria, assessment depth by criticality), contractual standards and mandatory clauses, ongoing monitoring and review obligations, exit strategy and business continuity requirements, roles and responsibilities (third-party risk manager, CISO, legal, procurement, business owners), escalation and exception procedures, policy review and update frequency (at least annual), and integration with overall ICT risk management framework. Make it suitable for management body approval."

Management body reporting

Keep the management body informed about third-party ICT risk through structured reporting:

"Create a management body reporting package for third-party ICT risk under DORA. Include: provider register summary (total providers, providers supporting critical functions, new/terminated arrangements), concentration risk dashboard (key dependency metrics, changes from previous period), contract compliance status (percentage of contracts with full DORA Article 30 compliance, remediation progress), provider performance summary (SLA achievement rates, material incidents at providers, security posture changes), exit strategy readiness assessment, key risks and emerging issues (provider financial instability, regulatory actions, technology changes), and recommended management body decisions. Provide a quarterly reporting template and an annual comprehensive review template."

Step 8: Address cross-border and group considerations

Group-level third-party ICT risk management

If your entity is part of a financial services group, DORA third-party risk management must be coordinated at group level:

"Address group-level considerations for DORA third-party ICT risk management. Our entity is part of [group structure]. Help us: consolidate the provider register across group entities (identify shared providers, group-level concentration risks), coordinate contract negotiations for providers used by multiple group entities, align pre-contractual assessment standards across the group, share monitoring activities and findings, coordinate exit strategies where multiple entities depend on the same provider, and report group-level third-party ICT risk to the parent entity management body. Provide a group coordination framework."

Cross-border data location requirements

DORA Article 30 requires contracts to specify data processing locations. For cross-border arrangements, address the regulatory implications:

"Analyze data location and cross-border considerations for our ICT third-party arrangements under DORA Article 30. Our providers process data in [list countries/regions]. Assess: compliance with data location disclosure requirements, GDPR adequacy decisions and transfer mechanisms for non-EU data processing, regulatory restrictions on data processing locations for financial data in our jurisdiction, risks of data processing in jurisdictions with weaker legal protections, provider obligations to notify of data location changes, and contractual controls to maintain data location compliance. Provide recommendations for each provider/service where data location presents risk."

Next steps

You now have a comprehensive DORA third-party ICT risk management capability:

• Complete ICT third-party provider register with standardized data

• Pre-contractual assessment framework with provider security questionnaire

• Comprehensive contract clause library with Article 30 compliance checklist

• Concentration risk assessment framework and mitigation strategies

• Exit strategy templates and testing procedures

• Ongoing monitoring framework with performance review procedures

• Third-party ICT risk policy and management body reporting

This completes the five-part DORA implementation guide series. Review the complete series:

• How to get started with DORA implementation using AI -- Foundation: scope, governance, gap analysis, roadmap

• How to build a DORA ICT risk management framework using AI -- Pillar 1: Articles 6-16 framework, policies, controls

• How to implement DORA incident reporting using AI -- Pillar 2: Articles 17-23 classification, reporting, root cause analysis

• How to plan DORA resilience testing using AI -- Pillar 3: Articles 24-27 testing program, TLPT, remediation

• How to manage DORA third-party ICT risk using AI (this guide) -- Pillar 4: Articles 28-30 providers, contracts, concentration risk

For ready-to-use prompts covering every DORA article, see the DORA Compliance Prompt Library. For the complete regulatory overview, refer to the DORA Compliance Guide for Financial Entities.

Getting help

For additional support managing DORA third-party ICT risk:

• Ask ISMS Copilot: Use your DORA workspace to generate provider-specific assessments, contract clause analysis, and concentration risk reports

• Upload contracts: Get targeted Article 30 compliance analysis by uploading existing ICT service agreements for clause-by-clause review

• Negotiation preparation: Use ISMS Copilot to prepare position papers and alternative clause proposals before provider negotiations

• Validate outputs: Review all contract clauses with your legal team and verify assessment criteria against DORA Articles 28-30 and relevant Regulatory Technical Standards