The Click-Through Cloud Contract

Gaps by control area

• Supplier relationships: the information security requirements for the relationship were never determined, so they were never agreed. A click-through contract is evidence of that.
• Supplier agreements: nothing on breach notification timelines, audit or access rights, data return and deletion, sub-processor control, liability for data-protection failures, or security incident cooperation.
• ICT supply chain: three sub-processors in three countries with no visibility, no flow-down of requirements and no objection right. This is concentration and jurisdiction risk the insurer cannot even inventory.
• Monitoring, review and change management of supplier services: a public status page announcing changes 30 days ahead is notification, not joint change management. There are no service reviews and no security metrics.
• Cloud services: acquisition and use were assessed on availability and price; exit was never assessed, and on the evidence it is infeasible within the regulatory 12 months.
• Legal and regulatory requirements: the auditability obligation is not met, which is a compliance finding independent of the security risk.

Why the SOC 2 report does not close the gaps

• Scope: it covers the provider's own environment, not its sub-processors, which is exactly where the unassessed risk sits.
• Age: 19 months old, covering a period that has long passed, with no right to see current evidence.
• Fit: SOC 2 trust criteria are generic. They do not answer the insurer's specific questions about data residency, notification or exit.
• Enforceability: a report is an input to assurance, not a substitute for contractual rights. Without audit rights the insurer can only accept whatever it is given.

Conclusion

The arrangement is materially unassured against a regulatory requirement the insurer is directly exposed to.

Position: renewal is the leverage

Must-haves, in priority order:

1. Breach notification within 24-72 hours, with defined content and a named contact chain.
2. Audit rights - either direct right to audit or annual third-party assurance covering the provider and its sub-processors, with the insurer able to commission or attend.
3. A current sub-processor list, a right to object to new sub-processors, and flow-down of equivalent obligations.
4. Data return in an open, structured format plus certified deletion after termination, including backups and sub-processor copies.
5. Exit assistance for at least 12 months and a defined transition period, with costs stated.
6. A security addendum with defined controls, and liability for data-protection failures.

Fallback if the provider will not move

• Prioritise ruthlessly: breach notification, sub-processor transparency and exit are non-negotiable; availability credits are not a substitute for any of them.
• Add compensating controls: tokenise or minimise the data placed in the portal so a provider breach is less damaging, put the insurer's own web application firewall and egress monitoring in front, stream provider logs into the insurer's SIEM, and restrict which claims fields leave the estate.
• If the provider still refuses the non-negotiables, escalate as a formal risk acceptance to the accountable executive, stating the regulatory position and the notification consequences. Do not let procurement sign it as a commercial formality.

On the procurement argument

'Everyone uses them' describes concentration risk, not assurance. A market-leading provider is a larger target and a single point of failure across the sector. Popularity is not evidence that the control objective is met.

Timeline

Sixty days is enough to negotiate a rider. It is not enough to re-platform. Start exit planning in parallel regardless of the outcome, because the exit obligation exists whether or not the negotiation succeeds.

Contents

• Data inventory: what the provider holds, in which systems, including backups and sub-processor copies.
• Extraction: export in an open, documented format, at a defined frequency, encrypted in transit, with completeness and integrity verified by sampling rather than by trusting a row count.
• Deletion: certified deletion after return, covering backups and derived data, with a stated timescale.
• Service transition: parallel-run period, defined exit assistance, knowledge transfer, and export of configuration and workflow definitions.
• Dependencies: a list of everything that would break on exit, including integrations, identity federation and reporting.
• Contractual spine: exit clause, assistance obligations and costs, and obligations that survive termination such as confidentiality and deletion.
• Ownership: a named accountable owner and a place in the assurance calendar.

Making it real

• Test it. Run a partial extraction at least annually and record the result: how long it took, what was missing, what format problems appeared. An untested exit plan is not a control, it is an intention.
• Test early. Given a 12-month regulatory requirement and six years of data in a proprietary format, the first test must happen before the next renewal, not after the next incident.
• Use the result in negotiations. A documented, timed extraction attempt converts 'we would like an exit clause' into 'here is why we need one and what it must cover'.
• Consider escrow or export tooling where the format is proprietary and the provider cannot commit to open formats.

Judgement point

The exit plan's value is not that it exists at contract signature; it is that the organisation has proven it can execute it under time pressure. The regulator is asking a capability question, and capability is demonstrated by exercise, not by clause.