Skip to main content

Insurance data protection

The compliance pack for building insurance software under RAPID: when a DPIA fires, what processing records look like, where UK-client data may live, how long it is kept, and what the FCA and the Lloyd's market expect — summarised so engineers can act on it without reading the source regulation.

Draft — Compliance/DPO review pending

Drafted for engineering use; the DPO and Compliance must ratify the triggers, retention positions and residency rules before this is treated as authoritative.

When a DPIA is triggered​

A DPIA is a Definition-phase artefact, not an afterthought — if the answer to "does this touch personal data?" is yes or unsure, it starts at Definition, alongside the PFD:

  • Any new processing of personal data — a new product, feature or integration that stores, reads or transmits policyholder, claimant or employee data.
  • Special-category data — health data in claims files is the everyday insurance case; it triggers a DPIA automatically.
  • Large-scale processing or matching — book migrations, MTAs processed in bulk, combining datasets across sources.
  • Automated decision-making or profiling — anything that scores, ranks or decides about individuals, including "just a recommendation" that humans rubber-stamp.
  • Cross-border transfer — UK-client personal data becoming accessible to India delivery for the first time on a given product.
  • New AI processing of personal data — any use beyond the anonymised/synthetic defaults in the AI usage policy.

The Definition gate checks the DPIA question was asked; a product cannot pass it with "TBD" against personal data.

Records of processing​

  • Every product keeps a record of processing (UK GDPR Article 30): purposes, data categories, recipients, transfers, retention — maintained with the product's docs, not in a separate compliance silo.
  • The data model is the source of truth — personal-data fields are tagged in the schema (data-model governance), so the record of processing is generated and checked, not hand-maintained and stale.
  • Agent-readable — classification tags in the schema are what let agent guardrails and pipelines enforce the AI usage policy matrix mechanically.

Data residency: UK-client data, India delivery​

  • Default: data stays in the UK/UK-adequate storage — India delivery gets access, not copies. Remote access to UK-hosted systems is still a restricted transfer under UK GDPR and needs a valid mechanism.
  • Transfer mechanism — the UK IDTA or the UK Addendum to EU SCCs, plus a transfer risk assessment, covering the UK–India flow. One assessed mechanism reused across products, not renegotiated per feature.
  • Client contracts can be stricter — some insurance clients prohibit offshore access to policyholder data entirely; check the contract before granting India access to any client-confidential or regulated data.
  • No production data in development, either side — dev and test run on synthetic data (test data); residency questions mostly disappear when the data offshore teams touch is synthetic.
Pending

Legal to confirm the standing transfer mechanism and transfer risk assessment; Commercial to confirm which current client contracts restrict offshore access. Until then, treat offshore access to any client personal data as blocked by default.

Retention and erasure​

  • Retention is set per data category at Definition and recorded in the record of processing — insurance norms differ (policy records typically 6+ years post-expiry for claims exposure; claims involving injury far longer; marketing consent much shorter). No "keep forever by default".
  • Erasure must be buildable — the schema and architecture must support deletion/anonymisation per data subject without archaeology. This is a Definition-phase NFR, because retrofitting erasure is brutal.
  • Backups and logs count — retention rules cover them; provenance and audit trails retain event data, not personal data, wherever separable.

FCA and Lloyd's expectations — for engineers​

What the regulators expect, translated to build decisions:

  • Operational resilience — the FCA expects important business services to survive failures within stated impact tolerances: know your service's tolerance, design for it, evidence it (observability, runbooks).
  • Outsourcing and third parties (SYSC) — insurers must govern their suppliers, which is us: expect and support client audits — the provenance trail and client transparency pack are the answers we hand over.
  • Consumer Duty — systems must produce good customer outcomes and evidence of them: build the telemetry that shows outcomes, not just uptime (product telemetry).
  • Lloyd's minimum standards — for market-facing products, expect scrutiny on data quality, catastrophe-relevant data and reporting timeliness; ACORD data standards are the default for market message formats.
  • Auditability beats assertion — every one of these reduces, for an engineer, to: keep the evidence a by-product of the pipeline, so the answer to a regulator is a query, not a project.

Standards referenced: UK GDPR, ICO DPIA guidance, India DPDP Act, FCA Handbook (SYSC, Consumer Duty), Lloyd's minimum standards, ACORD.