Under DORA, financial entities have to assess ICT third-party providers before contracting, monitor them during the relationship and keep a register of information on every arrangement. A provider's SOC 2 report is useful evidence for that assessment and monitoring: it gives independent assurance on security controls, and often on availability and confidentiality, over a defined period. It does not replace what DORA requires on its own terms, including the contractual provisions in Article 30, the audit and access rights for services that support critical or important functions, exit planning and the register itself. Use the report as one input to the risk assessment, record what it covers and what it does not, and follow up on the gaps.
DORA has applied since 17 January 2025, and its ICT third-party risk chapter changed how banks, insurers, investment firms and other financial entities treat their technology providers. Most of those providers already have a SOC 2 report, and the obvious question is how much of DORA's work it can do.
What DORA asks of financial entities
- A strategy and policy for ICT third-party risk, with management responsibility for it.
- A risk assessment before entering an arrangement, including concentration risk.
- Monitoring of the provider throughout the arrangement.
- Contracts that contain the provisions Article 30 requires, with more for services that support critical or important functions.
- Exit strategies for services that support critical or important functions.
- A register of information on every ICT arrangement, in the format the implementing technical standards set.
The DORA framework page covers the regulation as a whole.
Where a SOC 2 report helps
| DORA activity | What the SOC 2 report contributes |
|---|---|
| Pre-contract risk assessment | Independent assurance on the provider's security controls, and availability or confidentiality where in scope |
| Ongoing monitoring | A new report each period, exceptions over time, and bridge letters between reports |
| Subcontracting chain | The list of subservice organizations and how each is treated in the report |
| Your own controls | The complementary user entity controls the provider assumes you operate |
What a SOC 2 report cannot replace
- The contractual provisions DORA requires, including service descriptions, data locations, incident assistance and termination rights.
- Audit, access and inspection rights for services that support critical or important functions.
- Exit plans and the ability to transfer or bring the service back in-house.
- Participation in your resilience testing where the regulation requires it.
- The register of information, which you maintain yourself.
A report also covers a past period and the scope the provider chose. If the service you rely on is not in scope, or the criteria you need are missing, the report does not cover that risk.
Reviewing the report for DORA purposes
Start with the general checks: type, period, opinion, scope, exceptions, complementary controls and subservice organizations. The vendor SOC 2 review checklist sets them out. Then add the DORA questions: does the service support a critical or important function, where is the data processed, which subcontractors support the service, and does anything in the report change your concentration risk assessment?
Recording it with the register
Record the review against the arrangement it relates to, so the risk assessment, the monitoring evidence and the register of information describe the same provider and service. When a new report arrives, review it again and update the record. The third-party risk management solution shows how Noru builds the register from the vendor register and keeps reviews next to it.