DORA's Third-Party Requirements Are More Demanding Than Most Compliance Teams Expected
The Digital Operational Resilience Act entered full application in January 2025. One year on, the requirements that financial entities are most struggling to operationalise are not the incident reporting timelines or the TLPT (Threat-Led Penetration Testing) requirements - they are the ICT third-party risk management provisions under Chapter V.
Article 28 requires financial entities to maintain a comprehensive register of all ICT third-party service providers, categorise them by risk, and conduct due diligence proportionate to that risk. Article 30 requires contractual protections, including provisions for monitoring, audit rights, and incident notification by the provider.
But the requirement that creates the most operational complexity is Article 29's mandate for a documented, ongoing 'ICT concentration risk' assessment - understanding and managing the systemic risk that arises when multiple critical functions depend on the same third-party provider.
For the institutions we work with, building a defensible, auditable third-party risk programme under DORA requires more than a register and some contracts. It requires verifiable evidence.
The ICT Third-Party Register: What It Must Contain
Article 28(3) requires financial entities to maintain a register of all contractual arrangements with ICT third-party service providers. The register must include:
- Service classification. Whether the provider supports critical or important functions (higher risk category) or non-critical functions.
- Due diligence documentation. Pre-contractual and ongoing due diligence performed, including security assessments, certifications reviewed, and findings.
- Contractual provisions. Evidence that contracts include the Article 30 mandatory provisions (audit rights, incident notification, termination rights, data security standards).
- Monitoring records. Ongoing performance and security monitoring results, not just point-in-time assessments.
- Concentration risk analysis. Which critical functions would be affected if this provider failed or suffered a significant incident.
The ESAs (European Supervisory Authorities) have issued RTS under DORA specifying the minimum content requirements for the register. Financial entities should ensure their register meets the RTS specifications, not just the base Article 28 text.
Our full guide to DORA compliance and defensible resilience covers the register requirements in the context of the full DORA framework.
The Integrity Evidence Gap in Third-Party Risk Management
The most common gap in DORA third-party risk programmes is not the initial due diligence - organisations have generally built those processes. The gap is ongoing monitoring with verifiable evidence.
Article 28(9) requires financial entities to 'continuously monitor' third-party service providers that support critical or important functions. In practice, this means more than reviewing quarterly security reports and checking certifications are still valid. Regulators will ask: how do you know the ICT services your critical functions depend on have maintained their security posture?
For ICT providers that process or store financial entity data, the answer that satisfies this requirement is cryptographic data integrity monitoring: continuous verification that the data assets flowing from the provider to the financial entity have not been tampered with in transit or at the source.
This is where the supply chain integrity approach intersects directly with DORA Article 28 obligations. Rather than relying on the provider's self-reported security posture, financial entities can independently verify data integrity at the point of consumption.
ROOTKey's DORA compliance tools include the third-party integrity monitoring capabilities needed to satisfy Article 28(9)'s continuous monitoring requirement. Start your DORA readiness assessment.
在邮箱中获取网络韧性洞见
关于数据完整性、合规与连续性的实用、可审计指南--发布即送达。