Regulatory

GDPR and Pension Data: An HR Team's Practical Guide

Occupational pension schemes involve sensitive personal and financial data at every step. This guide explains the GDPR obligations HR and pension admins must meet — and the common gaps found in practice.

Abstract visual representing GDPR data protection framework applied to pension administration

Why pension data is not ordinary HR data

GDPR applies to all personal data processing. But pension data has characteristics that make it a higher-risk category in practice:

  • It is necessarily processed over very long time horizons — decades, not months
  • It involves financial data about individuals that is sensitive even if it doesn't fall under GDPR's "special category" designation
  • It is processed by multiple parties — employer, pension provider, possibly payroll processor, HRIS vendor — creating a complex processor/controller chain
  • It crosses international borders when employees and pension providers are in different countries
  • Errors in pension data have direct financial consequences for employees, creating a high-impact downside to data quality failures

For HR teams managing pension obligations across multiple European countries, understanding the GDPR implications isn't optional. This article maps the key GDPR requirements as they apply specifically to pension data processing and the employer's role in that chain.

Legal bases for pension data processing

GDPR (Regulation 2016/679) requires every processing activity to have a lawful basis under Article 6. For pension data, two bases are most commonly relevant:

Article 6(1)(c): Legal obligation

Processing personal data to comply with a legal obligation. For auto-enrolment in the UK, bAV in Germany, and pension fund participation in the Netherlands, employers have statutory obligations to assess employee eligibility, calculate contributions, and report to pension providers. Processing employee personal data (salary, age, employment dates) for these purposes is processing to comply with a legal obligation.

This is the cleanest and most defensible basis for most core pension data processing: you are processing this data because the law requires you to.

Article 6(1)(b): Performance of a contract

Processing necessary for the performance of an employment contract. An employment contract that includes pension as a benefit requires the employer to process personal data to administer that benefit. This basis is relevant for pension contributions that go beyond the statutory minimum — an employer's voluntary enhanced contribution is a contractual benefit, and processing data to administer it is justified under this basis.

Note: Article 6(1)(a) (consent) is generally not appropriate as the primary basis for pension data processing, because consent must be freely given and withdrawable. An employee who "consents" to pension data processing as a condition of employment is not giving meaningful consent. Use the legal obligation or contract performance bases instead.

Special category data in pension processing

GDPR Article 9 creates stricter protections for "special category" personal data, including health data, disability information, and biometric data. Pension processing can intersect with special categories in several specific scenarios:

  • Disability and enhanced contributions: Some pension schemes provide for enhanced contributions or benefits for employees with disabilities. Processing disability-related information to determine eligibility for such enhancements requires an Article 9 basis in addition to an Article 6 basis. The most common basis is Article 9(2)(b): processing necessary for obligations and rights in the field of employment law.
  • Life cover and health assessment: Some bAV Direktversicherung products include disability insurance (Berufsunfähigkeitsversicherung) that requires a health declaration. The insurer — not the employer — typically collects this data, but the employer needs to ensure this processing is covered in its privacy documentation.
  • Dependant benefits: Death-in-service or survivor benefits require processing information about the employee's spouse, civil partner, or dependants. Processing data about third parties not in an employment relationship requires a separate justification and appropriate notice.

The processor/controller distinction in the pension supply chain

The GDPR controller/processor framework is particularly important for pension data, because multiple parties process the same data:

The employer as data controller

The employer determines the purposes and means of processing employee data for pension purposes — it decides what data to collect, for what purpose, and which providers to share it with. The employer is the data controller for pension-related processing.

The pension provider as data controller or processor

This is where the analysis gets nuanced. A pension fund or insurer that administers a pension scheme is typically a data controller in its own right — it processes member data to fulfil its own regulatory obligations (IORP II compliance, DNB reporting, annual benefit statements). This means the data relationship between employer and pension fund is typically controller-to-controller, not controller-to-processor.

The legal instrument governing this relationship is not a Data Processing Agreement (DPA) under Article 28 but rather an information-sharing agreement between two controllers, with appropriate privacy notices to employees covering both controllers' processing activities.

The HRIS vendor as data processor

The HRIS vendor (Workday, Personio, BambooHR, HiBob) processes employee data on behalf of the employer. This is a controller-to-processor relationship governed by a Data Processing Agreement under Article 28. The DPA should specify the purposes for which the HRIS vendor may process pension-related data (salary, employment dates, etc.) and the security and confidentiality obligations the vendor must meet.

The pension administration platform as data processor

A pension administration platform that processes employee data on behalf of the employer — taking salary data in, calculating contributions, generating compliance reports — acts as a data processor. This relationship should be governed by a GDPR-compliant DPA specifying the nature and purpose of processing, data retention periods, security measures, and the processor's obligations regarding sub-processors.

Data subject rights in pension contexts

GDPR Articles 15–21 give data subjects (employees) a set of rights over their personal data. In the pension context:

Right of access (Article 15)

An employee can request a copy of all personal data held about them in connection with their pension. This includes contribution records, eligibility assessments, opt-out records, and any communications sent to pension providers on their behalf. Employers must be able to produce this data within one month of receiving a Subject Access Request (SAR).

For a company with manual pension records spread across multiple systems and spreadsheets, responding to a SAR can be genuinely difficult. A system of record for pension data that maintains a complete, exportable history significantly reduces the burden of SAR responses.

Right to rectification (Article 16)

If an employee believes their pension records are inaccurate, they have the right to request correction. Given that pension contributions are calculated from salary and employment data, an error in the underlying data has downstream effects on contributions. When an employee raises a rectification request, the employer must assess whether the pension provider's records also need correction.

Right to erasure (Article 17)

The right to erasure ("right to be forgotten") does not apply where processing is legally required. Pension contribution records that the employer must retain to meet TPR, BaFin, or Dutch pension regulator requirements cannot be erased at the employee's request. Employers should document this limitation explicitly in their privacy notices.

Right to data portability (Article 20)

For processing based on consent or contract performance, employees have the right to receive their data in a structured, commonly used, machine-readable format. This right is limited in scope for pension data, as much of it is processed on the basis of legal obligation (which is not covered by Article 20). However, employers should be aware of this right for any pension-related processing based on contract performance.

International data transfers in pension processing

For a UK company with a US-based HRIS vendor and European pension providers, pension data flows across multiple international boundaries:

  • UK employee data → US HRIS vendor: Post-Brexit, this is a UK-to-third-country transfer. An adequacy decision or UK International Data Transfer Agreement (IDTA) is required.
  • UK employee data → UK pension provider (NEST): Domestic transfer, no international transfer mechanism required.
  • German employee data → German Direktversicherung insurer: Domestic EU transfer.
  • German employee data → US HRIS vendor: EU-to-third-country transfer. Standard Contractual Clauses (SCCs) or adequacy mechanism required.

Employers must map all international data flows for pension data and ensure each transfer has an appropriate legal mechanism. This mapping should be documented in the employer's Records of Processing Activities (RoPA) under Article 30.

Practical checklist for HR teams

Documentation

  • Records of processing activities (RoPA) include pension data processing, listing each processor and controller in the chain
  • Privacy notices (employee privacy policy) describe pension data processing clearly, including the legal bases
  • Data Processing Agreements are in place with HRIS vendor and pension administration platform
  • Controller-to-controller information sharing agreements or privacy notices cover the pension fund/insurer relationship

Security

  • Pension data is encrypted in transit and at rest
  • Access to pension records is limited to personnel with a business need
  • Audit logs record access to pension data
  • Sub-processor chains for HRIS vendor and pension platform are documented

Retention

  • Pension contribution records are retained for the minimum period required by each jurisdiction's regulator (UK: six years from the end of the relevant tax year; Germany: generally ten years for payroll records; Netherlands: seven years for payroll records)
  • Records beyond the retention period are deleted or anonymised in accordance with documented retention schedules

Incident response

  • Personal data breaches involving pension data are notifiable to the relevant supervisory authority (ICO in the UK, BfDI in Germany, AP in the Netherlands) within 72 hours if they are likely to result in a risk to individuals
  • Affected employees must be notified if the breach is likely to result in a high risk to their rights and freedoms

A note on UK GDPR post-Brexit

Following Brexit, UK GDPR (the retained version of EU GDPR in UK law) applies in the UK. For employers with both UK and EU employees, UK GDPR and EU GDPR effectively run in parallel for the respective employee populations. The substantive requirements are very similar, though the supervisory authorities differ (ICO in the UK; national data protection authorities in EU member states). Employers must ensure their data processing documentation addresses both regimes where applicable.

Pensvyne processes pension data under a GDPR-compliant framework. A Data Processing Agreement is available to all customers. Employee data is hosted in AWS eu-west-1 (Ireland) and eu-central-1 (Frankfurt) to maintain EU data residency. UK data residency options are discussed during the onboarding process.

See Our Security Posture

Pensvyne is built with GDPR-compliant data architecture.

Data minimisation, purpose limitation, and documented retention schedules built in from day one.