Step 1 — Confirm You Need a DPIA

For any deployment of PensionPortal.ai processing live member data, the answer is almost certainly yes. Document your reasoning using the EDPB WP248 criteria. Even if you are uncertain, conducting a DPIA when not strictly required carries no legal risk — failing to conduct one when required does.

The name of the scheme(s) to be onboarded

The categories of data to be processed

Which EDPB triggers apply

The DPO’s view (mandatory consultation — see Step 3)

Step 2 — Describe the Processing

Provide a systematic description of all processing activities. For PensionPortal.ai deployments, this includes:

IORP II governance and system of governance (S.I. 128/2021, Regulation 36)

Own Risk Assessment (ORA) preparation, documentation, and annual review

Investment governance and risk management

Pensions Authority reporting and supervisory engagement

Member benefit statement generation (S.I. 128/2021, Regulation 46)

Data strategy compliance and data quality management

Active, deferred, and pensioner members of the scheme

Spouses, civil partners, and dependant beneficiaries

Named trustees and Key Function Holders (KFHs)

Employer representatives and HR administrators

Scheme administrators and professional advisers

Identification data: Full name, PPS number, date of birth, address, contact details

Employment and pension data: Employment start/end dates, pensionable service, scheme membership dates, role/grade

Financial and benefit data: Salary history, contribution records (employee and employer), benefit entitlements, transfer values, AVC records

Governance data: Trustee declarations, KFH fitness and probity records, meeting minutes

Special categories (where applicable): Health data for ill-health retirement or death-in-service claims (Article 9 basis required — see compliance overview)

Data ingestion and validation from employer payroll systems

Member data quality dashboards and exception reporting

ORA workflow documentation and evidencing

Document management and version control

Regulatory reporting exports (Pensions Authority)

Benefit statement generation

Audit logging of all data access and modification events

Rights request handling (SAR, rectification, erasure)

Cloud-hosted application (see sub-processor register for infrastructure details)

API integrations with employer payroll and HR systems

Role-based access control separating trustee, employer, administrator, adviser, and member views

Data residency within EU/EEA (or SCCs in place for any international transfers)

Trustees: Data controllers — determine purposes and means of processing

PensionPortal.ai: Data processor — processes data on behalf of trustees under a Data Processing Agreement (DPA) per Article 28

Employer: Joint controller or separate controller depending on scheme structure — must be documented

Administrator, actuary, investment manager: Sub-processors of PensionPortal.ai or separate processors of the trustee — must be documented

Step 3 — Consultation

GDPR Article 35(2) requires the data controller to seek the advice of the DPO when carrying out a DPIA. For pension schemes, consultation should extend to:

DPO: Must be consulted and their advice documented. If the DPO disagrees with the DPIA conclusions, their dissenting view must be recorded.

Trustees: As data controllers, trustees should review and formally approve the DPIA

Scheme Administrator: The administrator handles much of the day-to-day data processing — their input on operational risks is essential

Data subjects (via trustee representatives): Article 35(9) requires controllers to seek the views of data subjects where appropriate. For pension schemes, this may be achieved through member-nominated trustee representatives or member consultative bodies

Step 4 — Assess Necessity and Proportionality

For each processing activity identified in Step 2, document:

Processing ActivityLegal BasisSupporting LegislationPensions Authority reportingArticle 6(1)(c) — Legal obligationS.I. 128/2021Benefit calculation and statementsArticle 6(1)(c) — Legal obligationPensions Act 1990 (as amended); S.I. 128/2021 Reg. 46ORA documentationArticle 6(1)(c) — Legal obligationS.I. 128/2021 Reg. 44Revenue/PAYE reportingArticle 6(1)(c) — Legal obligationTaxes Consolidation Act 1997Data quality monitoringArticle 6(1)(f) — Legitimate interestsTrustee duty to membersScheme governance analyticsArticle 6(1)(f) — Legitimate interestsTrustee fiduciary duty

Data Minimisation Review: Document that each data field collected is necessary for the stated purpose. Remove or anonymise fields that are not actively required. PensionPortal.ai’s field-level access controls support this — configure role profiles to display only the fields each role requires.

Retention Mapping: Confirm that retention periods are configured (see Data Retention and Deletion). Document the legal basis for each retention period and the process for deletion or anonymisation at end of retention.

Transparency Measures: Trustees must provide members with a privacy notice at the point of collection (Article 13) or as soon as practicable after collection (Article 14). Document what privacy notice is in place, when it was last updated, and how it is communicated to members.

Step 5 — Identify IORP II-Specific Risks

Step 6 — Define Mitigation Measures

For each risk identified in Step 5, document the controls in place:

RiskPrimary MitigationImplemented In Platform?Inaccurate member dataData quality validation engine; exception dashboards; field-level validation rules✅ YesUnauthorised accessFine-grained RBAC: trustee / employer / administrator / adviser / member role separation at database level✅ YesExcessive profilingAI outputs flagged as advisory; mandatory human review before any benefit decision; Article 22 documentation✅ YesInsecure transmissionTLS 1.2+ enforced for all API connections; API key authentication; integration documentation standards✅ YesInadequate loggingImmutable, append-only audit trail; structured log format; exportable for SAR responses✅ YesInternational transfersEU/EEA data residency default; SCCs in place where sub-processors operate outside EEA; transfer impact assessments documented✅ Yes

Documented Data Processing Agreement (DPA) with each processor per Article 28

Annual staff training on data protection obligations for all users with access to member data

Incident response procedure documented and tested

Breach notification protocol: trustees notified within 24 hours of awareness; DPC notification within 72 hours where required under Article 33

Step 7 — Conclude, Sign Off, and Plan Reviews

Residual Risk Assessment: After applying all mitigation measures, document the residual risk level for each identified risk. If any residual risk remains high, the DPO must assess whether prior consultation with the DPC is required under Article 36.

Formal Sign-Off: The completed DPIA must be:

Reviewed and formally approved by the trustee board (or trustee committee with delegated authority)

Reviewed by the DPO — with any dissenting views documented

Dated and version-controlled

Triggers for DPIA Review: A DPIA is a living document. It must be reviewed when:

A major new feature or processing activity is introduced to the platform

New data categories are added (e.g. health data for ill-health retirement workflows)

A new sub-processor is onboarded

The scheme structure changes materially (e.g. merger, wind-up)

A data breach or near-miss occurs

Relevant legislation or regulatory guidance changes

As part of the scheme’s annual ORA cycle (recommended)

Integration with ORA: The DPIA risk register should feed into the scheme’s Operational Risk Assessment under S.I. 128/2021, Regulation 44. Data protection risks are operational risks. Trustees should not treat them as a separate workstream.