Concentration risk in a single-cloud insurance stack with an undisclosed fourth party
Rheinland Versicherung is a non-life insurer with 1.1 million policyholders. Its claims platform, policy administration, and customer portal all run on one hyperscaler in a single EU region. The insurer also buys three SaaS products from vendors hosted on the same hyperscaler, and one of those vendors subcontracts data enrichment to a fourth party outside the EU. The master cloud contract gives Rheinland 99.9% availability, but audit rights are limited to 'security certifications on request', subcontracting changes require no notice, and there is no exit plan. The provider is not designated critical by any supervisor. The CIO says 'we are not dependent because we could move to another cloud in six months', but no migration test has been done. The board asks whether DORA requires action and what contract changes are needed before renewal in 90 days.
1. Assess the concentration risk and third-party dependency. Is the CIO's six-month migration claim sufficient?
Read the worked answer
No. Concentration risk is not limited to providers designated critical by a supervisor. It arises where a financial entity relies on one provider or a small number of providers for services that are difficult to substitute. Here the claims platform, policy administration and portal all run on one hyperscaler in one region; three SaaS vendors are hosted on the same provider; and a fourth party outside the EU processes data enrichment. That creates correlated failure and subcontracting risk. The 99.9% availability commitment does not address exit or concentration.
The six-month migration claim is an assertion, not evidence. DORA expectations include a documented exit strategy, data portability, tested migration or fallback, and an assessment of substitutability. Without a migration test, skills plan and cost estimate, the board cannot rely on it. I would require a concentration risk assessment, a tested exit plan for the most critical services, and contractual rights to support exit. The provider not being designated critical reduces supervisory oversight but does not remove the insurer's own due diligence and contractual obligations.
2. Identify the contractual provisions that must be present in the cloud and SaaS agreements under DORA, and how to handle the fourth-party subcontractor.
Read the worked answer
Contracts should cover: a clear description of services and supported critical functions; service levels and remedies; security and data protection; data location and access; incident notification and cooperation; audit and access rights, including on-site where appropriate; business continuity and disaster recovery; subcontracting notification or approval; termination and exit assistance; data return and deletion; and cooperation with competent authorities. The current 'certifications on request' audit clause and no-notice subcontracting are inadequate for material arrangements.
For the fourth party, require flow-down of security, incident, audit and data-protection obligations; notice of changes; inclusion in the register of information; due diligence; and an exit path that does not depend on the fourth party's cooperation. If the provider will not accept these terms, assess compensating controls and escalate to the board as a risk acceptance. The renewal in 90 days is the leverage point: negotiate before signature, not after an incident.
3. What should go into the register of information for this setup, and why is the register not just an IT inventory?
Read the worked answer
The register should record each contractual arrangement with an ICT third-party provider, including the provider's identity and location, the services and critical functions supported, the data involved, subcontracting chains, the country of data processing, contract and renewal dates, criticality, exit options and any supervisory designations. For Rheinland, it must show the hyperscaler, the three SaaS providers, and the fourth-party data enricher as linked arrangements.
It is not just an IT inventory because it captures contractual, risk and dependency information that supports concentration analysis, exit planning and supervisory requests. An inventory lists servers and applications; the register explains who provides what, under which contract, with which subcontractors, and how the insurer could exit. It should be maintained by the third-party risk function with legal and procurement input, reconciled to the contract database, and reviewed when arrangements change. That is how the board can see the dependency in one place.