PulseCheck: the 'it's only aggregate' claim
Helio Systems runs a 1,800-person workforce across Germany, Poland and Ireland and licenses a wellness app called PulseCheck from an external vendor. Enrollment is voluntary and 214 employees have signed up. The app collects step counts, sleep duration, self-rated mood on a 1-5 scale and free-text journal entries. What HR actually sees is a dashboard of team averages, but the filter can be set to any team with three or more enrolled members, and the medical team can request individual records with the employee's written consent. The vendor keeps raw records for 24 months after the last sync, and its own product team uses the data to train a recommendation model. In March, a line manager asked HR for a colleague's journal entries following three weeks of sick leave. The DPO's position is that PulseCheck is 'aggregate reporting' and therefore outside the PIMS. The works council has asked for a written position before the next roll-out wave in April.
1. Is PulseCheck in scope of Helio's PIMS? Justify the boundary you would draw and name the evidence you would need.
Read the worked answer
It is in scope. The scope of a PIMS is set by the processing of PII, not by the format in which results are displayed.
- Aggregation is a presentation choice, not a legal status. A dashboard of averages still sits on top of identifiable records (employee ID, team, timestamps). The moment someone can filter to a team of three, the 'average' is a small-group statistic, and small groups are exactly where singling out works.
- Re-identification is trivially available inside Helio. HR knows team membership, the medical team can pull individual records, and the free-text journal is inherently identifying in content even without a name field.
- The vendor's model training is a separate purpose. Raw records retained for 24 months and reused for product development are a second processing operation with its own purpose, lawful basis and retention justification.
- The manager's request proves the risk is live, not theoretical.
Evidence to collect: the data model and retention configuration, the dashboard filter permissions, the vendor's training data pipeline, and the enrolment records showing consent language. The boundary to draw is 'all processing of employee wellness data by Helio and its vendor, including the analytics layer'. If Helio genuinely wanted part of this out of scope it would need documented, tested de-identification, which is not what a three-person filter provides.
2. The vendor argues that because it replaces employee names with tokens, the training data is anonymised. Assess that argument and explain what pseudonymisation does and does not achieve here.
Read the worked answer
Tokenisation removes the direct identifier and leaves everything else: team, site, dates, sleep pattern, mood trajectory, free text. That is pseudonymisation, and pseudonymised data remains PII under ISO/IEC 27701 because re-identification is possible using additional information that someone holds or can reasonably obtain.
What pseudonymisation does buy:
- It reduces casual exposure and supports minimisation, and it is a legitimate technical measure under the de-identification controls (Annex A, section 8.1) and under the privacy-by-design expectations for limiting processing.
- It lowers risk in lower-trust environments such as analytics sandboxes.
What it does not buy:
- It does not remove the data from PIMS scope or from the Annex A/B control set.
- It does not by itself make cross-purpose reuse lawful; purpose limitation still applies.
- It does not survive small populations. With 214 participants across a handful of teams, quasi-identifiers (site + team + date + step pattern) collapse the token quickly.
To claim anonymisation the vendor would need a documented re-identification risk assessment, suppression of rare records, a defined adversary model, and no ability to re-link to the source. Their own 24-month retention of the source records makes that claim impossible to sustain.
3. Who is controller and who is processor for the wellness data, and how does that change Helio's obligations? Address the manager's request.
Read the worked answer
Roles are decided per purpose, not per contract title.
- Helio is a PII controller for the wellness programme: it decides why the data is collected (wellbeing, absence management), which employees are invited, who can see what, and how long records are kept. It also decides the medical team's access.
- The vendor is a PII processor for the hosted app and dashboard: it acts on Helio's documented instructions. Annex B obligations apply - instruction-only processing, sub-processor control, assistance with PII principal requests and assessments, return or disposal at end of contract.
- The vendor is likely a controller for its own model training unless Helio's instructions and contract explicitly cover that purpose. Two controllers, two sets of obligations: Helio would need its own lawful basis for handing data over for product development, which is hard to justify for health-adjacent data.
The manager's request should be refused and routed, not quietly honoured. Individual journal entries should be released only through the medical/HR process the employees were told about, under a defined access rule, with the decision recorded. Two follow-ups matter more than the refusal itself: the employee notice must describe the analytics and training uses, and a privacy impact assessment should be done before the April roll-out, because this is large-scale processing of health data with a vulnerable population (employees in an unequal power relationship with the requester).