GDPR for Health Insurance Brokers: Medical Underwriting Data, Claims History, and FCA Compliance
Health insurance brokers operate in the most sensitive corner of financial services data. You hold pre-existing condition disclosures, family medical histories, mental health records, and years of claims history — all of it special category data under GDPR Article 9. A single compliance failure can trigger ICO investigations, FCA enforcement action, and irreparable client trust damage simultaneously.
This guide covers the specific GDPR obligations that apply to health insurance brokers: the lawful bases for processing medical data, how to handle group scheme employer access, what happens at renewal, and the 10 mistakes that cost brokers the most.
Why Health Insurance Brokers Face the Highest GDPR Risk in Financial Services
Most financial services firms process financial data — account numbers, transaction histories, credit scores. That data warrants protection, but it sits in GDPR's standard category.
Health insurance brokers process something categorically different: Article 9 special category data. Pre-existing conditions, medication regimes, mental health diagnoses, family medical histories, and historical claims. This is the most protected class of personal data under GDPR, and it attracts the highest regulatory scrutiny.
The risk is compounded by the broker's structural position. You're not the insurer — you're the intermediary who collects sensitive medical information, shares it across your panel of insurers, stores it for FCA-mandated retention periods, and then wants to use it again at renewal. Every one of those stages creates distinct GDPR obligations.
Medical Underwriting Data as Special Category
Under GDPR Article 9(1), processing data about a person's physical or mental health requires explicit legal justification beyond the standard lawful bases. This covers everything health insurance brokers routinely collect:
- Pre-existing conditions: Any disclosed health condition, regardless of whether it affects the quote
- Medication data: Current and past prescriptions disclosed during the application
- Family medical history: Genetic predisposition information, often collected for critical illness cover
- BMI and lifestyle health data: Height, weight, smoking status collected as underwriting factors
- Disability status: Physical or cognitive impairments relevant to cover terms
The "special" designation isn't just semantic. Article 9 processing requires both a standard GDPR lawful basis (Article 6) and an additional Article 9 condition. For most health insurance brokers, the relevant Article 9 conditions are:
- Article 9(2)(a): Explicit consent — the data subject has given explicit consent for specified purposes
- Article 9(2)(b): Employment context — processing necessary for obligations in the field of employment and social security
- Article 9(2)(f): Legal claims — processing necessary for establishing, exercising, or defending legal claims
- Article 9(2)(g): Substantial public interest — with a basis in UK law
Legitimate interest — widely used across financial services — cannot provide the Article 9 condition. If your current privacy notice relies on legitimate interest for medical data, it's insufficient.
Claims History: The Most Sensitive Insurance Records
Claims history occupies a peculiar position in health insurance data. It's not collected at application — it accumulates over the policy lifetime. Each claim creates a record of what happened medically, when, with which provider, at what cost.
This data is sensitive for multiple reasons beyond the obvious. Claims patterns can reveal mental health treatment, addiction recovery, chronic conditions that developed post-inception, or family planning circumstances. A simple "physiotherapy claims" record reveals an injury; a pattern of physiotherapy claims reveals a chronic condition.
GDPR issues that specifically arise with claims history:
Retention vs. accuracy: Claims records from ten years ago may no longer accurately represent an individual's health. Keeping them indefinitely doesn't just raise retention questions — it risks profiling decisions based on outdated information, breaching the accuracy principle.
Use limitation: Claims history collected for claims management cannot be repurposed freely for underwriting at renewal. The ICO takes purpose limitation seriously; if data collected for one purpose (claims handling) is being used for another (renewal underwriting risk assessment), you need a separate lawful basis.
Right to erasure conflicts: Clients sometimes request deletion of claims records. This conflicts with retention obligations under FCA rules and the Limitation Act. You need a clear documented policy explaining why erasure cannot be honoured in these cases.
Lawful Bases for Health Data in Insurance
For health insurance brokers, the layered legal basis structure is:
For applications and quotes:
- Article 6(1)(b) — performance of a contract (the insurance contract)
- Article 9(2)(a) — explicit consent, or
- Article 9(2)(f) — legal claims and defending legal proceedings
The explicit consent route is the cleanest, but requires granular, specific consent — not buried in terms and conditions.
For claims processing:
- Article 6(1)(b) — contract performance
- Article 9(2)(f) — establishing/exercising legal claims (the claims process itself)
For FCA-mandated record-keeping:
- Article 6(1)(c) — legal obligation
- Article 9(2)(b) — employment or social security law obligations (for group schemes)
For marketing and renewal:
- Article 6(1)(a) — consent (cannot rely on contract for renewal marketing)
- Article 9(2)(a) — explicit consent required for using health data in renewal communications
Document each processing activity against these bases in your Records of Processing Activities. The ICO expects to see ROPA entries that separately address the Article 9 condition — not just a generic "legitimate interest" entry.
Group Health Scheme Administration: Employer Access to Employee Medical Data
Group health schemes create a genuinely complex data relationship. The employer is funding the scheme. The employees are the data subjects. The broker is arranging cover. The insurer is underwriting it. HR software may be administering it.
The critical GDPR question: what can the employer see?
The default position should be that employers see nothing about individual employees' health data or claims. The benefit of a group scheme is that it's group-rated — the employer gets aggregate statistics, not individual records. An employer who can see that Employee X claimed for psychiatric treatment has received special category data they have no right to hold.
In practice, brokers often facilitate data flows that allow employer HR teams more access than they should have. Common problems:
- Eligibility lists: Acceptable — employers confirm who is on the scheme
- Claims reports with names: Not acceptable without explicit individual consent
- "Utilisation reports" showing condition categories: Borderline — depends on whether individuals are identifiable
- Premium increase justifications citing specific claims: Unacceptable
For group schemes, brokers should establish clear data sharing agreements with employer clients that explicitly limit what health data the employer can access. The broker's role is to facilitate cover, not to create a mechanism for employers to gain insight into employee medical history.
FCA Suitability Requirements and GDPR Retention Conflicts
FCA COBS rules require health insurance brokers to maintain suitability records demonstrating that the cover recommended was appropriate for the client. These records include the health information on which the recommendation was based.
FCA retention minimums for insurance intermediaries: at least three years from the date of advice for most records, extending to indefinite retention for some categories where legal proceedings remain possible.
GDPR's storage limitation principle requires keeping data only as long as necessary. These two frameworks pull in opposite directions.
The resolution is documented and proportionate retention schedules:
- Identify each category of health data you hold
- Identify the regulatory retention minimum for each category
- Set a retention period that satisfies regulatory minimums without excess
- Document the legal basis for the retention period (Article 6(1)(c) — legal obligation)
- Implement deletion processes at the retention period end
"Indefinite retention because we might need it" is not acceptable. "Seven years from policy end to satisfy FCA requirements, then deletion" is. The key is that the retention period is defined, documented, and actually implemented — not aspirational.
Pre-Populated Quote Forms and Data Accuracy Obligations
Many health insurance brokers pre-populate renewal quote forms with data from the previous application. This creates efficiency — but it creates GDPR accuracy problems.
The accuracy principle requires that personal data is accurate and, where necessary, kept up to date. For health data, this is significant: a pre-existing condition disclosed five years ago may have resolved, worsened, or the treatment may have changed.
Pre-populating forms without prompting the client to review and confirm the data means you may be processing inaccurate health data. Worse, that inaccurate data is being transmitted to insurers as the basis for quotes, potentially affecting the cover terms and premium offered.
Best practice: When using pre-populated health data for renewal quotes, include a clear prompt requiring the client to review, confirm, or update every health disclosure before submission. Record the date of confirmation. This satisfies the accuracy principle and creates an audit trail.
Insurer Panel Data Sharing
Health insurance brokers typically approach multiple insurers to find the best terms for a client. This involves sharing the client's medical underwriting data with several insurers simultaneously or sequentially.
Under GDPR, each insurer who receives the data becomes a controller for that data. The broker is disclosing special category data to multiple third parties. This requires:
Explicit client authorisation: Your privacy notice and consent process must clearly state that health data will be shared with multiple insurers on your panel for the purpose of obtaining quotes. Generic "we may share with third parties" language is insufficient for special category data.
Named or described insurers: Clients should be able to understand who their data is going to. If your panel is fixed, name them. If it varies, describe the panel criteria and provide a mechanism to find out which insurers were approached.
Data sharing agreements: You should have written agreements with each insurer on your panel covering how they will handle the health data you share, their retention obligations, and what happens if they decline to quote.
Declined insurer deletion: When an insurer declines to quote, they should delete the health data they received. Your data sharing agreements should require this, and you should have mechanisms to confirm it happened.
Renewal Marketing Using Health Data: The Consent Dilemma
At renewal, brokers face a specific problem: they want to use health data collected at inception to facilitate a renewal recommendation or quote. But the consent obtained at inception was for the original insurance transaction — not for ongoing marketing.
The ICO's position on using previously collected data for marketing is clear: you need a separate marketing consent lawful basis. Soft opt-in — which permits marketing to existing customers under PECR — does not apply to Article 9 special category data. You cannot rely on soft opt-in to send health-data-informed renewal communications.
What this means in practice:
- At inception, obtain explicit consent for renewal-related processing of health data as a distinct consent item
- Make clear that the health data disclosed will be used at renewal to assess whether the same or different cover remains appropriate
- Provide a genuine opt-out that doesn't affect the current policy
- Honour opt-outs — if a client refuses renewal marketing consent, you cannot use their health data to proactively generate renewal quotes
This is an area where many health insurance brokers are currently non-compliant. The consent obtained at inception typically covers arranging the original policy, not the ongoing commercial relationship.
Data Subject Rights for Medical Underwriting Records
Clients have the full range of GDPR rights in relation to their health insurance data. Several of these create specific challenges:
Subject Access Requests (SARs): A client can request all data you hold about them, including their health disclosures, insurer communications, and claims records. Your SAR response process needs to cover all the systems where this data lives — not just your main CRM.
Right to Erasure: As discussed, this often conflicts with FCA retention obligations. You can refuse erasure where legal obligation requires retention, but you must document this refusal and inform the client of their right to complain to the ICO.
Right to Rectification: If a client believes their health data is inaccurate, they can require you to correct it. For historical records that were accurate at the time of collection, you should add a note confirming the correction request rather than altering the original record.
Right to Object: Clients can object to processing based on legitimate interest. For health data — which cannot use legitimate interest as the Article 9 condition — this right has limited practical scope, but you still need a process for handling such requests.
Portability: For data processed by automated means under consent, clients can request their data in a machine-readable format. Health application data processed on consent qualifies.
Mental Health Disclosures and Their Special Sensitivity
Mental health data deserves specific attention beyond its Article 9 special category status. Historically, mental health disclosures in insurance applications resulted in significant adverse underwriting decisions — exclusions, premium loadings, or outright declines. The FCA has been scrutinising this area.
GDPR obligations specific to mental health data:
Minimisation: Only collect mental health data that is genuinely necessary for underwriting. Fishing expeditions — asking about any "mental health history" without specific relevance — likely violate the data minimisation principle.
Purpose limitation: Mental health data collected for underwriting purposes cannot be used for anything else — not internal risk profiling, not commercial analysis, not product development.
Processor obligations: If you use third-party mental health assessment tools or screening services, these processors must have Data Processing Agreements that include the specific protections required for special category data.
Staff training: Everyone who handles mental health disclosures should understand both the sensitivity of the data and the legal framework. Inadequate staff training has been cited in ICO enforcement actions.
International Health Cover and Cross-Border Data Transfers
International health insurance and expatriate cover creates cross-border data transfer issues. When you share a UK client's medical data with an insurer's underwriting team based outside the UK, or with an assistance provider in a third country, that's a restricted transfer under UK GDPR.
Since the UK's departure from the EU, UK-to-EU transfers are covered by the UK-EU adequacy decision. UK-to-US transfers now rely on the UK-US data bridge (the UK Extension to the EU-US DPF). Other third country transfers require UK-approved Standard Contractual Clauses or an Article 46 safeguard.
For health insurance brokers with international clients or insurer panels:
- Map where medical underwriting data flows — including temporary processing locations
- Identify which countries are adequacy-approved and which aren't
- Ensure appropriate transfer mechanisms are in place before sharing health data internationally
- Include transfer mechanism details in your privacy notice
Aggregators as Joint Controllers
When health insurance quotes are generated through aggregator platforms — Compare the Market, GoCompare, Confused.com and similar — the aggregator is not merely a referral source. They are processing the health data the client entered on their platform and sharing it with you.
Under GDPR, this makes the aggregator and the broker joint controllers for the data at the point of sharing. Joint controller relationships require a written arrangement under Article 26 that determines respective responsibilities for:
- Fulfilling data subject rights
- Providing privacy information to data subjects
- Handling data breaches
- Retention and deletion
Many brokers receive leads from aggregators without having the required Article 26 arrangements in place. The aggregator's terms of business may address this — but standard broker T&Cs often don't.
Review your aggregator relationships. If you don't have documented joint controller arrangements, you have a compliance gap.
10 Common GDPR Mistakes Health Insurance Brokers Make
Using legitimate interest as the Article 9 condition: Legitimate interest cannot serve as the Article 9 basis for special category data. Explicit consent or another qualifying condition is required.
Relying on generic consent for health data: Consent for special category data must be explicit and specific. Buried health data consent in terms of business is not valid.
Sharing individual claims data with employer clients: Employers administering group schemes should receive aggregated data only. Individual health and claims data should not be shared without specific individual consent.
Pre-populating renewal forms without data accuracy checks: Reusing inception health data at renewal without prompting review violates the accuracy principle.
No data sharing agreements with insurer panel members: Every insurer receiving health data from you should have a written agreement covering their data handling obligations.
Inadequate privacy notices for health data: Privacy notices must identify the Article 9 condition, name the categories of health data collected, and explain cross-insurer sharing.
No documented retention schedule: "We keep data until we don't need it" is not a retention policy. Define retention periods for each data category against the regulatory basis for retention.
Handling SARs through general customer service: SARs for health data require a structured process. Ad hoc responses risk incomplete disclosure or inadvertent additional breaches.
Aggregator leads without joint controller arrangements: Receiving health data leads from aggregators without Article 26 arrangements in place creates regulatory exposure for both parties.
Renewal marketing without specific health data consent: Using health data to generate proactive renewal quotes or marketing without separate renewal consent likely breaches both GDPR and PECR.
Start with a Website Audit
Before tackling the full data governance stack, audit what your website is already doing. Most health insurance broker websites run quote forms, analytics tools, and live chat widgets that collect visitor data — often with consent banners that don't meet GDPR requirements.
A free website scan will show you which cookies and trackers are firing, whether your consent mechanism is correctly configured, and what data is being transmitted to third parties before you've even had a client conversation.
Scan your website free at app.custodia-privacy.com/scan →
Last updated: March 2026. This guide covers UK GDPR (the UK General Data Protection Regulation as incorporated by the Data Protection Act 2018), PECR, and FCA regulatory requirements as they apply to health insurance intermediaries regulated by the Financial Conduct Authority.
Top comments (0)