Sample DPIA — GDPR Article 35, employee wellness app

Nordvind Care AB, a Swedish employer of 1,200, plans a workplace-wellness app: activity tracking plus self-reported stress and sleep, a monthly wellbeing score visible to HR, and optional GP teleconsult booking, run by an EU-hosted vendor as processor. Is a DPIA required? Yes. The fetched Art. 35(3)(b) text makes a DPIA required for “processing on a large scale of special categories of data referred to in Article 9(1)”, and self-reported stress and sleep records scored monthly for a whole workforce are data concerning health (§3 walks both limbs of that determination, including the honest part: “large scale” is an analyst call, not a fetched threshold).

Headline risks: individual wellbeing scores reaching HR (DR-01) — the single design decision this DPIA reverses — consent that isn't freely given inside an employment relationship (DR-03), and processor re-use of the data beyond instructions (DR-04, held open pending the contract review). With the §4 mitigations applied, no register row keeps a high residual risk, so under the fetched Art. 36(1) test this DPIA does not trigger prior consultation of the supervisory authority — a conditional verdict, reasoned in §6.

4 of 7 register rows carry fetched citations. Two rows (DR-05, DR-06) matched no source row and ship as marked analyst drafts; one row (DR-04) rests partly on a provision (Art. 28) that was not fetched this run and is flagged unresolved. None of the three is papered over.

The fetched Art. 35(7) sets the minimum content of this document: “(a) a systematic description of the envisaged processing operations and the purposes of the processing […]”, “(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes”, “(c) an assessment of the risks to the rights and freedoms of data subjects […]”, and “(d) the measures envisaged to address the risks […]” (each quoted to its first clause; the full points continue in the linked text). This section covers (a) and (b); §4 and §5 cover (c) and (d).

Show the text form

[Employee (1 of 1,200)]
      |  activity + self-reported stress/sleep     <- explicit consent, Art. 9(2)(a)
[Wellness app backend]   (processor: app vendor, EU-hosted)
      |  writes
[(Special-category store -- activity, stress, sleep; health data, Art. 9(1))]
      |  pseudonymised records
[Wellbeing scoring]      (monthly score per employee)
      |--> monthly score, personal feedback        -> back to the employee only
      |--> aggregated cohort scores ONLY           -> [HR wellbeing dashboard] (controller)
[GP teleconsult booking] (opt-in; booking metadata kept out of HR-visible data)

• DSData subjects — 1,200 employees. Enrolment is optional. The app collects activity data plus self-reported stress and sleep, and computes a monthly wellbeing score.
• CController — Nordvind Care AB (employer). Determines purposes and means. After the §2 redesign, HR receives aggregated cohort scores only, never individual scores.
• PProcessor — the app vendor (EU-hosted). Runs ingestion, storage, and scoring on documented instructions. The special-category store sits on the vendor's side.
• GGP teleconsult service (opt-in). Receives booking requests only from employees who opt in. Whether it acts as a separate controller for the consultation itself is recorded as an open scoping question (analyst note), not settled here.

Necessity & proportionality — three purposes, three calls. Each verdict below is an analyst call: Art. 35(7)(b) requires the test, but the fetched text does not decide it for any given system. Senior review confirms or corrects these on a paid engagement.

The fetched Art. 35(1) sets the general test: “Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.” Art. 35(3) then names cases where a DPIA “shall in particular be required”, including “(b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10”. Two limbs to establish:

Special categories. The fetched Art. 9(1) prohibits, absent an exception, processing of personal data including “data concerning health”. Classifying self-reported stress and sleep records — collected to compute a wellbeing score — as data concerning health is an interpretive step (analyst call), but a short one: the data exists to describe the employee's health state. A fetched CJEU row points the same way for the employment context: ECLI:EU:C:2023:1022, whose case metadata reads “special categories of data – Data concerning health – Assessment of an employee's working capacity – Health insurance medical service processing data”. Only the case metadata was fetched in this run — a paid engagement retrieves and reads the decision itself before relying on its reasoning.

Large scale. The fetched text sets no numeric threshold, so this is an analyst determination: 1,200 data subjects, continuous activity collection, systematic monthly scoring, the entire workforce of the controller — we conclude large scale. If a reviewer rejected that call, the Art. 35(1) general test would still point the same way for health data processed inside an employment power asymmetry (also an analyst call). Supervisory guidance (the WP248 criteria) is the standard screening method here, but no fetched row carried it in this run, so it is named as analyst method and not relied on.

Swedish angle. The Swedish corpus returned the Swedish-language GDPR text, served with EUR-Lex source links (the regulation applies directly and is not an SFS statute): Art. 35(4) — “Tillsynsmyndigheten ska upprätta och offentliggöra en förteckning över det slags behandlingsverksamheter som omfattas av kravet på en konsekvensbedömning avseende dataskydd i enlighet med punkt 1” — and Art. 57(1)(k) (“Upprätta och föra en förteckning när det gäller kravet på en konsekvensbedömning avseende dataskydd enligt artikel 35.4”), which together ground that IMY, the Swedish supervisory authority, must maintain a published list of processing operations requiring a DPIA. The list itself was not fetched in this run — checking this processing against IMY's current list is recorded as an open verification step for the paid engagement, not assumed.

Lawful basis for the health data. Of the Art. 9(2) exceptions fetched, the candidate is “(a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes”. The occupational-medicine exception “(h) … preventive or occupational medicine, for the assessment of the working capacity of the employee …” does not fit (analyst call): an HR-visible wellbeing dashboard is not occupational medicine delivered under the professional-secrecy conditions of Art. 9(3). That leaves explicit consent — and consent inside an employment relationship carries a freely-given problem this DPIA treats as a risk in its own right (DR-03); the imbalance doctrine itself was not fetched this run and is marked as an analyst premise.

One row per risk to the rights and freedoms of the employees (Art. 35(7)(c)) — not risks to Nordvind. Severity, likelihood, and residual ratings are analyst-assigned and would be confirmed or corrected in senior review.

Linked citations are rows the gateway returned during this run, with source URL, publisher, and license preserved. The one unlinked identifier (GDPR Art. 28 on DR-04) is a named candidate that was not fetched — the row is flagged, not dressed up. Rows with no matching source say so instead of carrying an invented reference.

The fetched Art. 32(1) requires that “the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk”, naming: “(a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” Applied here (Art. 35(7)(d) measures; each mapping is an analyst assignment):

• Art. 32(1)(a). Encryption in transit and at rest for the special-category store; wellbeing-scoring records pseudonymised so the scoring path never handles named employees (DR-02).
• Art. 32(1)(b). Access to individual records restricted to the employee and the processor's operational need — no HR path to individual data exists in the redesigned architecture (DR-01, DR-07).
• Art. 32(1)(c). Vendor backup and restore for the wellbeing store, tested, so employees' data survives a technical incident intact.
• Art. 32(1)(d). Scheduled testing of the measures above, with the minimum-cohort-size suppression (DR-05) included in the test scope.
• Art. 32(4). “The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law” — the fetched anchor for keeping the vendor instruction-bound (DR-04), pending the Art. 28 contract review flagged in §4.

Art. 32(2), also fetched, directs the risk weighing to “accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed” — the lens used for DR-02's rating.

The fetched Art. 36(1) reads: “The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.” The operative question is therefore whether high risk remains once the controller's mitigations are counted — the residual-risk reading. (That reading is standard supervisory practice, but the guidance stating it was not fetched this run, so the interpretive step is marked as analyst method.)

Applied to the §4 register: every high initial risk (DR-01, DR-02, DR-03, DR-04, DR-07) is reduced to a medium residual by measures Nordvind can actually take — chiefly the aggregated-only HR view, the consent design, and the Art. 32 measures in §5. No row ends at a high residual. Verdict: prior consultation under Art. 36(1) is not required (analyst call). Two honest conditions attach: DR-04's residual is provisional until the processor-contract review closes, and the ratings themselves are unreviewed sample assignments — if senior review raised any residual back to high, the verdict flips and the Art. 36(2) machinery follows (“the supervisory authority shall, within period of up to eight weeks of receipt of the request for consultation, provide written advice to the controller”, extendable by six weeks — quoted as fetched).

If consultation were triggered, the fetched Art. 36(3) already lists what Nordvind would hand over — responsibilities of controller and processors, purposes and means, safeguards, DPO contact details, and “the data protection impact assessment provided for in Article 35”: this document. Either way, Art. 35(11) applies going forward: “Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations” — DR-07's function-creep trigger is wired to exactly that duty.

• Structure per Art. 35(7). Sections 2–5 map one-to-one onto the fetched minimum content (a)–(d); §6 runs the Art. 36 gate on the outcome.
• Sources fetched through the Ansvar gateway. GDPR Articles 9, 32, 35, and 36 as full-text lookups; an EU-wide search on the DPIA trigger; a Swedish-corpus search (riksdagen-published GDPR text); a CJEU case-law row; and an authority-guidance search. Every quote in this document is verbatim from a fetched row, with source URL, publisher, and license preserved. Nothing is cited from model recall.
• Refusal discipline — guidance. The authority-guidance search for prior-consultation material returned four rows, all off-topic for this processing (AI Act prohibited-practices guidelines, the GPAI Code of Practice, and two vehicle-type-approval documents under UN R155/R156). No authority-guidance citation is carried in this document; the gap is recorded rather than filled.
• Refusal discipline — searches. From the EU-wide search, three of six rows were discarded as off-topic (Reg (EU) 2019/1020 recital 52 on market surveillance, Reg (EU) 167/2013 Art. 7 on tractor approval, REACH Art. 14), and one further row — EDPB connected-vehicles guidance carrying an Art. 9 explicit-consent fragment — was excluded as off-domain; Art. 9(2)(a) is cited from the fetched article text directly instead. From the Swedish search, two of five rows are used (Art. 35(4) and Art. 57(1)(k)); three were excluded as off-topic (Prop. 2022/23:131 on welfare technology in elderly care, SFS 1973:1084 on land survey, Prop. 2022/23:41 on tax-agency data analysis).
• Marked analyst judgment. The large-scale determination, the health-data classification, the necessity table, all severity/likelihood/residual ratings, the Art. 9(2)(h) exclusion, and the residual-risk reading of Art. 36(1) are analyst calls, marked in place. The WP248 screening criteria were not fetched and are not relied on.
• What a paid engagement adds. Your real processing records and a scoping call; verification against IMY's published DPIA list; the Art. 28 processor-contract review that closes DR-04; DPO advice per Art. 35(2) and, where appropriate, the views of data subjects per Art. 35(9); and a named senior reviewer who confirms or corrects every call before it ships.

Senior review:   [shown for format — fictional sample, nothing to certify]
Reviewer:        [named reviewer — CIPP/E / data-protection lead]
Date:            [—]

A paid engagement ships only after the named reviewer has validated every call and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine.

Want this for a real processing operation?

Download the blank DPIA template (free XLSX) →