Solvency II in the Cloud: What Insurers Must Architect Before They Migrate

Solvency II — Directive 2009/138/EC and its implementing measures under Commission Delegated Regulation (EU) 2015/35 — was designed before cloud computing was a primary delivery model for financial services infrastructure. The Pillar 2 governance requirements that create cloud architecture constraints were written for on-premises operations. EIOPA has since issued specific guidance (EIOPA-BoS-20-002, "Guidelines on Outsourcing to Cloud Service Providers"), but most insurers' cloud migration programmes are led by IT departments that haven't read it in conjunction with their regulatory affairs function.

EIOPA-BoS-20-002: What It Actually Requires

EIOPA's cloud outsourcing guidelines classify cloud IaaS, PaaS, and SaaS deployments as "outsourcing arrangements" under Solvency II Article 49. For material outsourcing arrangements — defined as those where a failure would materially impair the insurer's ability to comply with regulatory requirements — the requirements include: a written outsourcing agreement with specific provisions (Guideline 9), pre-outsourcing notification to the supervisory authority (Guideline 7), an exit strategy documented before migration begins (Guideline 14), and audit rights over the cloud provider (Guideline 13). AWS, Azure, and GCP all provide standard audit rights clauses and ISAE 3402/SOC 2 reports. The problem is that most cloud migration projects in insurance treat these as procurement checkboxes rather than as architectural inputs.

Pillar 2 ORSA and Data Quality

Solvency II Pillar 2 requires the Own Risk and Solvency Assessment (ORSA). Article 45 of the Solvency II Directive requires the ORSA to be based on reliable data. EIOPA's data quality guidelines require that data used in ORSA calculations have documented lineage, defined quality checks, and an audit trail of corrections. In a cloud architecture, this means: model execution environments must log inputs and outputs with sufficient detail to reproduce calculations; data quality checks must be automated and their results retained; and the lineage from source systems to ORSA model inputs must be machine-traceable, not manually documented.

The regulatory reporting chain creates an additional constraint. National Competent Authorities (NCAs) receive Solvency II QRT (Quantitative Reporting Templates) submissions that must be traceable to source data. In a cloud-native architecture, this means the reporting pipeline must maintain complete lineage from raw data through aggregation, calculation, and QRT generation. An Excel-based reporting layer that consumes cloud data and produces QRTs — common in legacy Solvency II implementations — is incompatible with the data quality requirements when the underlying data is cloud-native.

Architecture Requirements for Solvency II Cloud Compliance

1. Portable data formats: all actuarial model inputs and outputs in open formats (Parquet, CSV with schema documentation) stored in provider-agnostic object storage with WORM retention
2. Audit rights implementation: retain SOC 2 Type II reports from cloud providers; supplement with application-level audit logs that demonstrate Solvency II control effectiveness (provider SOC 2 does not map to Solvency II controls)
3. Exit strategy documentation: before migration, document the specific steps, timeline, and cost to migrate each workload to an alternative provider — this is a regulatory document, not an IT plan
4. ORSA model governance: document model conceptual soundness, validation methodology, and ongoing monitoring for every actuarial model deployed in cloud — map to EIOPA's model risk guidelines
5. NCA pre-notification: classify cloud migrations as material outsourcing and notify your NCA per Guideline 7 timelines (typically 30 days before migration)