DPIA template: reviewer and assignee suggestions (GDPR Art. 35) ​
Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.
The controller (the customer that enables assignment) carries out the data protection impact assessment. This template is prefilled with the product facts from ADR-0014 and the legal assessment input. The controller completes the parts in angle brackets (<…>) and records its own conclusions. The controller must seek the advice of its DPO (Art. 35(2)) and, where appropriate, the views of the people affected or their representatives (Art. 35(9)), for example the works council.
0. Is a DPIA required? ​
Likely yes. The processing evaluates personal aspects of employees (familiarity with code derived from their work history) to allocate work, which meets several criteria of the EDPB-endorsed guidelines WP248 rev.01 (evaluation or scoring, systematic monitoring, vulnerable data subjects — employees, innovative technology) and the German DSK list of processing operations that always require a DPIA (No. 8 and No. 11). Art. 35(3)(a) may also apply if suggestions have similarly significant effects. The DPO confirms.
1. Description of the processing (Art. 35(7)(a)) ​
| Item | Content |
|---|---|
| Controller | <customer> |
| Processor | Hosted edition: Quavon UG (haftungsbeschränkt) under the DPA. Self-hosted: none |
| Purpose | Suggest (mode suggest) or request (mode apply) reviewers for pull requests and assignees for issues, based on code ownership, recent work on the affected files, current open assignments and declared availability, to route work to people who know the code and to spread knowledge |
| Not a purpose (prohibited uses) | Evaluating performance or behaviour; decisions on hiring, pay, promotion, termination or appraisal |
| Legitimate interest (if Art. 6(1)(f)) | <efficient and knowledge-spreading code review; balancing test> |
| Data subjects | Repository members and collaborators who can be requested as reviewers or assignees |
| Inputs (closed allowlist) | CODEOWNERS entries; time-decayed commits, blame and reviews on the affected files; who fixed similar issues; current count of open assignments and review requests; availability intervals (opt-in, from/to only); opt-out and privacy flags |
| Excluded inputs | Speed, volume or quality per person; acceptance rates; personal traits; calendar contents; per-person learned parameters (full list: assessment §2) |
| Outputs | Up to count suggested people per subject, each with fixed-template explanation facts; in apply mode the review request or assignment at the Git host |
| Storage and retention | assignments 6 months; expertise_cache recomputed, not historised; availability 30 days after the interval ends; feedback_events 6 months; shorter in works-council mode |
| Recipients | Repository members (comment in suggest mode, if enabled); Git host; the configured model provider only if a model is used for similar-issue search |
| Technology | Weighted scoring with human-set weights; per-repository weight learning (bounded) from reassignments |
| Modes and gates | off (default), shadow, suggest, apply. apply needs the instance legal sign-off, a per-repository opt-in by a tenant admin and, in works-council mode, an attestation that permits it. Without sign-off the feature runs in shadow only |
2. Necessity and proportionality (Art. 35(7)(b)) ​
| Question | Product facts | Controller assessment |
|---|---|---|
| Legal basis | Proposal: Art. 6(1)(b) (organising work under the employment contract) and/or (f); for employees Art. 88 GDPR with § 26 BDSG or a works agreement (§ 26(4) BDSG). After CJEU C-34/21, § 26(1) sentence 1 BDSG may not suffice on its own | <…> |
| Purpose limitation | Prohibited uses stated in the instructions for use; no export of per-person data; configuration changes audited | <…> |
| Data minimisation | Closed input allowlist; per-path cache without per-person totals; availability from/to only; only selected people stored | <…> |
| Accuracy | Explanation facts are factual statements from the inputs; humans can change every assignment | <…> |
| Storage limitation | Retention defaults above; daily retention job | <…> |
| Transparency (Arts. 13, 14) | Transparency page readable by every tenant member; labelled comment; information text for employees to be prepared by the controller | <…> |
| Rights | Export and deletion per person (quavon dsar); individual opt-out without reason (Art. 21); explanation of each suggestion | <…> |
| Processors and transfers | See subprocessors.md | <…> |
3. Risks to the rights and freedoms of data subjects (Art. 35(7)(c)) ​
Likelihood and severity are assessed by the controller (low / medium / high).
| # | Risk | Source of risk | Likelihood | Severity |
|---|---|---|---|---|
| R1 | Suggestions are used or perceived as performance evaluation | Per-person familiarity values; anchoring | <…> | <…> |
| R2 | Unfair distribution of work or learning opportunities | Ranking favours those who already know the code | <…> | <…> |
| R3 | Automated allocation without effective human control (Art. 22) | apply mode | <…> | <…> |
| R4 | Monitoring of behaviour or availability | Activity history, availability intervals | <…> | <…> |
| R5 | Disclosure of sensitive data (absence reasons, health) | Calendar feeds | <…> | <…> |
| R6 | Repurposing for HR decisions | Customer use outside the intended purpose | <…> | <…> |
| R7 | Excessive retention | Assignment records and feedback | <…> | <…> |
| R8 | People cannot object or do not know about the processing | Lack of information | <…> | <…> |
4. Measures to address the risks (Art. 35(7)(d)) ​
| Risk | Measures in the product | Evidence |
|---|---|---|
| R1 | No per-person scores in any API or comment; no rankings of other candidates; explanation facts only from fixed templates; team-level-only switch | explain tests, privacy tests |
| R2 | Knowledge-spreading pairing ("suggested together with … to spread knowledge"); workload factor; per-repository weights visible in the UI | select tests |
| R3 | suggest is the default once enabled; apply only after legal sign-off and per-repository opt-in; humans can always change assignments; reassignment never lowers future suggestions | assignment-flow.int.test.ts |
| R4 | Availability is opt-in; GitHub "Busy" read only for people who opted in; no historised activity | availability tests |
| R5 | ICS reduced to from/to of out-of-office events at import; no titles, attendees or reasons | ics.test.ts |
| R6 | Prohibited uses in instructions for use; no per-person export; audit of configuration changes | ADR-0014 |
| R7 | Retention defaults and daily job; shorter in works-council mode | maintenance.int.test.ts |
| R8 | Transparency page; individual opt-out; works-council mode on by default for German tenants | assignment.md |
Additional measures by the controller: <employee information, works agreement (template: ../betrvg/betriebsvereinbarung-anlage.md), training of maintainers, review interval>.
5. Residual risk and decision ​
| Item | Entry |
|---|---|
| Residual risk | <low / medium / high> |
| Prior consultation of the supervisory authority needed (Art. 36)? | <yes / no, reason> |
| DPO advice (Art. 35(2)) | <summary, date> |
| Views of data subjects or representatives (Art. 35(9)) | <summary, date> |
| Decision and permitted modes | <off / shadow / suggest / apply> |
| Review date | <at least yearly and on every change of inputs or modes> |
Open points for the DPO / counsel ​
Questions Q1–Q14 of the legal assessment input, in particular Q3 (profiling), Q6 (Art. 22), Q7 (legal basis) and Q8 (division of DPIA work between provider and deployer).