This article is written for boards, executives, CISOs, and risk leaders, including US organizations that support EU financial entities. DORA is an EU regulation. Not every US business is directly in scope, so verify applicability with counsel before assuming anything.
Key Takeaways
- The management body owns ICT risk. Outsourcing does not transfer that accountability.
- A complete provider register tied to real dependencies is the foundation.
- Oversight should scale with criticality, from due diligence through monitoring.
- Concentration and exit risk need tested plans, not contract language alone.
- Board-ready evidence makes decisions defensible.
Understanding ICT Third-Party Risk and DORA Requirements
What ICT third-party risk means
ICT third-party risk is the risk created when an outside provider supports the technology, data, systems, or services behind your operations. Enterprise risk management covers the whole risk universe. Third-party risk management (TPRM) narrows to external providers and their dependencies.
Outsourcing moves the work, not the responsibility. Article 28 says financial entities using ICT services "shall, at all times, remain fully responsible" for DORA compliance, per the official regulation text.
Picture a payments provider that goes down for several hours. Your customers do not care whose servers failed. Your regulator will ask who owned the dependency.
What DORA changes
DORA is Regulation (EU) 2022/2554. It entered into force on January 16, 2023 and applies from January 17, 2025.
ESMA describes its aim as strengthening ICT security and keeping Europe's financial sector resilient through severe digital disruption. It ties ICT risk management to incident reporting, resilience testing, and third-party oversight.
Applicability checkpoint for US organizations
Keep three categories apart:
- Financial entities listed in Article 2, such as banks, insurers, and investment firms.
- ICT third-party service providers, which are defined separately and are not "financial entities."
- Designated critical ICT third-party providers (CTPPs), which face direct ESA oversight.
The ESAs designated 19 critical providers on November 18, 2025. Article 31(12) requires a designated CTPP established in a third country to set up an EU subsidiary within 12 months of designation. That is not a general subsidiary rule for every non-EU supplier.
For most US firms, the practical effect arrives through contracts: an EU financial entity customer pushes DORA terms down to you. Confirm your position with legal counsel.
The five-pillar framing
"Five pillars" is a convenient summary of Chapters II to VI, not an official statutory label:
- ICT risk management (Chapter II)
- ICT incident management and reporting (Chapter III)
- Digital operational resilience testing (Chapter IV)
- ICT third-party risk management (Chapter V)
- Information-sharing arrangements (Chapter VI)
Accountability and requirements at a glance
Under Article 5, the management body defines, approves, and oversees the ICT risk framework and is responsible for its implementation. It also approves and periodically reviews the third-party policy.
Execution is delegated across technology, security, procurement, legal, compliance, business owners, and internal audit. Without explicit decision rights and escalation thresholds, that delegation becomes diffusion.
The main third-party requirements to map against the current text and technical standards:
- Strategy and policy
- Pre-contract due diligence
- Register of contractual arrangements
- Baseline and enhanced contract terms (Article 30)
- Subcontracting and concentration oversight (Article 29)
- Termination and exit planning
The final technical standards matter here: RTS 2024/1773 (policy), ITS 2024/2956 (register), and RTS 2025/532 (subcontracting). Check each against its own adoption date, not DORA's application date.
5 Key Strategies for Managing ICT Third-Party Risk
1. Establish a clear ICT third-party risk strategy and policy
A DORA-aligned policy should define:
- Scope and provider criticality
- Risk appetite and ownership
- Approval requirements and exception handling
- Monitoring expectations and escalation thresholds
- Board reporting
Tie it to critical or important business services rather than treating every supplier the same. Article 4 proportionality adjusts the effort; it is not an exemption.
Make appetite measurable. Three thresholds work well: maximum downtime, maximum data-loss window, and maximum fraud loss per period. Give every exception an expiry date (60 or 90 days), a named owner, and a compensating control.
2. Build a reliable register and dependency map
The register should capture:
- Provider identity, service, and business owner
- Supported function and criticality
- Data handled and system dependencies
- Geographic and legal considerations
- Contract status and subcontractors
- Resilience evidence and exit readiness
A register is a living list, not a procurement export. Connect contract data to the real architecture.
Quality is a real problem. In the ESAs' 2024 dry run, only 6.5% of 947 registers passed all data-quality checks. Missing mandatory information drove 86% of the errors. Completeness is not compliance, but gaps like these are where scrutiny starts.
Look hard at:
- Fourth- and nth-party dependencies
- Shared cloud infrastructure
- Concentration across business units
- Mismatches between procurement records and operational reality
3. Embed risk-based due diligence into procurement and contracting
Before approval, evaluate:
- Security controls and resilience capability
- Incident history
- Financial and operational stability
- Regulatory posture and subcontracting model
- Data handling and recovery arrangements
Match the evidence to the tier. Mature vendors may offer SOC 2 Type II or ISO 27001. Higher-risk vendors should also show penetration-test summaries, incident-response evidence, and recovery-test results.
Then verify contract terms. Article 30 separates baseline provisions from enhanced ones for critical or important functions:
- Service levels and data locations
- Incident assistance, at no extra cost or a cost set in advance
- Audit, inspection, and access rights
- Subcontracting transparency
- Data return in an accessible format after insolvency or termination
- Termination and exit cooperation
Replace "reasonable time" with breach-notice windows in hours. Compliant wording is not operational evidence. Ask the vendor to show it works.
4. Monitor provider risk continuously and test resilience
Combine these inputs:
- Attestations and performance indicators
- Material changes and incidents
- Audit findings and remediation progress
- Contract reviews
Pick 8 to 12 metrics mapped to risk appetite, such as critical-vendor assurance, high-risk vendor gaps, and restore time in drills. Set your own thresholds from your appetite.
Include providers in incident response, disaster recovery, and continuity exercises. Feed results into remediation plans and management reporting.
Don't overstate testing duties. Threat-led penetration testing under Articles 26 to 27 applies to selected financial entities, at least every three years. It is not a universal supplier requirement.
5. Govern concentration risk and make exit strategies executable
Concentration appears as dependence on one provider, a small group, a shared platform, common subcontractors, or a service you cannot replace quickly. Typical examples are one cloud, one identity provider, or one managed service provider.
Assess substitutability, portability, transition resources, alternate providers, and in-house capability. Then ask the board's sharpest question: which vendor outage would stop revenue within 24 hours, and what is the workaround?
Exit plans need:
- Defined termination triggers
- Data and configuration retrieval
- Knowledge transfer and transition sequencing
- Contingency arrangements and a named owner
- Periodic testing
RTS 2024/1773 requires documented, periodically tested exit plans. A plan that has never been rehearsed is a document, not continuity.
Managing Third-Party Access and Evidence
Apply least-privilege controls to third-party identities
Access is where third-party risk turns into incidents. Controls to apply:
- Identity proofing and role-based access
- Least privilege and time-bound access
- Privileged access controls, with MFA on all privileged accounts
- Joiner-mover-leaver processes, especially offboarding
- Service-account governance and prompt removal when contracts end
RTS 2024/1774 supports this approach:
- Article 20: unique identification, including ICT-provider staff
- Article 21: least privilege and withdrawal of access
- Article 12: tamper-protected logging
Identity governance, privileged access management, and monitoring tools support evidence. They do not replace the wider third-party framework.
Create a single source of truth for compliance evidence
Link these records in one traceable model:
- Provider records and contracts
- Due diligence findings and access reviews
- Audit reports, incidents, and test results
- Remediation items, exceptions, and approvals
Each metric needs one system of record, one formula, one owner, and an update frequency. That cuts fragmented reporting and speeds audits, regulator requests, and executive decisions.
Connect access events and provider incidents to escalation
These events should trigger defined investigation paths:
- Anomalous access or excessive permissions
- Missed service obligations
- Provider incidents and material control failures
Name the provider owner, security, technology, legal, compliance, continuity, and executive roles in advance. Critical vendor outages, major breaches, and material control failures warrant immediate escalation, not the next quarterly meeting.
Practical Steps to Strengthen ICT Third-Party Risk Management
Perform a DORA-focused gap assessment
Assess each area against the current DORA text and applicable RTS/ITS, not a generic checklist:
- Governance and accountability
- Provider inventory and dependency mapping
- Criticality and due diligence
- Contracts and monitoring
- Incident response and testing
- Concentration, exit, and access
- Evidence quality
Rank gaps by business impact, regulatory significance, dependency criticality, and feasibility. Assign each an owner, target outcome, evidence requirement, and escalation route.
Build an executable 90-day implementation roadmap
Sequence the work in workstreams:
- Days 1 to 30: Set decision rights and scope. Validate the register. Disable stale vendor accounts.
- Days 31 to 60: Prioritize critical dependencies. Remediate contract and access gaps. Define monitoring indicators.
- Days 61 to 90: Test a high-impact continuity scenario. Package results for the board.
Tyson Martin's 90-day planning approach, with owners and measurable outcomes, is one practical governance model. Treat it as a structure for focus. It does not guarantee compliance.
Establish board-ready reporting and operating cadence
A useful dashboard shows:
- Change in overall posture since the last briefing
- Critical providers and unresolved high-impact issues
- Concentration exposure and incident trends
- Exit readiness, exceptions, and overdue remediation
- Decisions required
Write in plain English: trends and consequences, not technical volume. A heat map should be scannable in three minutes.
A KPMG 2026 survey of more than 70 institutions found digital-resilience reporting reaches boards quarterly at 51% and monthly at 19%. It covers broader resilience, not only third-party oversight.
Document who receives each report and how often. A workable rhythm is monthly management reporting and quarterly board or committee review. Escalate on critical vendor outages, new critical vendors, and major renewals.
Exercise, measure, and improve the program
Run scenarios with technology, business owners, suppliers, legal, communications, and senior leaders:
- Provider failure or prolonged outage
- Cyber incident at a provider
- Subcontractor disruption
- Access compromise
- A failed exit
Close each exercise with:
- Lessons learned and assigned remediation
- Revised thresholds
- Updated contracts or playbooks
- A decision on whether residual risk is within appetite
Optional executive support
Tyson Martin works with boards and executive teams as a board advisor or interim CISO. Engagements clarify decision rights, strengthen governance, improve executive reporting, and turn findings into an executable roadmap. This is advisory work. It is not legal advice or formal regulatory certification.
Conclusion
DORA third-party risk management is an operating capability built on visibility, accountable ownership, continuous monitoring, tested resilience, and credible evidence. A one-time questionnaire or contract review is not enough.
Boards should ask four questions:
- Can we name our critical dependencies?
- Can we explain our concentration exposure?
- Can we escalate a provider failure quickly?
- Can we keep essential services running if a supplier disappears?
Frequently Asked Questions
What are TPRM requirements?
DORA expects provider identification through a register, pre-contract risk assessment, contractual controls, ongoing monitoring, concentration management, incident readiness, and tested exit plans.
Who is primarily responsible for the ICT risk management framework?
The management body holds ultimate responsibility under Article 5. Security, technology, procurement, legal, risk, and business teams execute, but accountability stays at the top.
What is DORA in operational resilience?
DORA is the EU framework for digital operational resilience in financial services. It covers ICT risk governance, incident reporting, testing, third-party oversight, and information sharing.
What are the five pillars of the DORA regulation?
They are ICT risk management, ICT incident reporting, resilience testing, ICT third-party risk management, and information sharing. This is a common summary of Chapters II to VI, not an official label.
What is ICT risk management?
It is the process of identifying, assessing, treating, monitoring, and reporting risks to the security, integrity, availability, and resilience of ICT systems and services.
What is TPRM and why is it important?
TPRM manages risk from external providers, subcontractors, and shared infrastructure. Those dependencies can disrupt continuity, trigger compliance failures, expose data, and erode customer trust.
