DPIA template: team analytics (GDPR Art. 35) ​
Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.
Team analytics shows review and delivery metrics per repository, team or tenant, and LLM costs. The controller (the customer) decides whether a DPIA is required and carries it out. This template is prefilled with the product design; parts in angle brackets (<…>) are completed by the controller. The controller seeks the advice of its DPO (Art. 35(2)) and, where appropriate, the views of the people affected or their representatives (Art. 35(9)).
0. Is a DPIA required? ​
Probably, as a precaution. The metrics are computed from records of people's work (pull requests, reviews, issues). Even with aggregation, the system is objectively suitable for monitoring performance (BetrVG § 87(1) No. 6 makes co-determination necessary in Germany regardless of the DPIA outcome). The criteria "systematic monitoring" and "data of vulnerable data subjects (employees)" of WP248 rev.01 point towards a DPIA. The DPO decides.
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 | Help teams improve their review process and control LLM costs, using team-level aggregates |
| Not a purpose | Evaluating individual performance or behaviour; rankings; leaderboards |
| Metrics | Acted-on and dismissed rate of findings, comments per PR, silent-PR rate, findings, time to first review, time to merge, triage label acceptance, duplicate hits, assignment kept rate, fix-PR merge rate, LLM tokens, LLM cost, cache hit rate |
| Source data | findings, feedback_events, posted_comments, review_runs, pull_requests, issues, triage_runs, assignments, fix_runs, llm_calls (already stored for the core features) |
| Stored derivatives | analytics_daily: daily numerators and denominators per repository, metric and dimension. No per-person rows. No per-person activity table |
| Scopes | Repository (members with access), team of repositories and tenant (tenant administrators only), self view (only the person) |
| Retention | Follows the tenant's data retention setting |
| Recipients | Tenant members within their permissions; nothing is sent to model providers |
2. Necessity and proportionality (Art. 35(7)(b)) ​
| Question | Product facts | Controller assessment |
|---|---|---|
| Legal basis | Proposal: Art. 6(1)(f) (improving the development process), with a works agreement where required | <…> |
| Minimisation | Only aggregates are stored; populations for k-anonymity are computed at query time and never returned | <…> |
| k-anonymity | Every point (period × scope × dimension cell) of a people-based metric is suppressed when fewer than k distinct people contribute; k defaults to 5 and can only be raised (5–50) | <…> |
| Self view | Off by default; needs the tenant switch and the person's own opt-in; not available in works-council or team-only mode; tenant and instance administrators can never read another person's metrics | <…> |
| Exports | CSV export of aggregates only; suppressed values are never exported; no per-person export | <…> |
| Cost metrics | Not people-based; only for administrators; never split by person | <…> |
| Transparency | <employee information, transparency page> | <…> |
3. Risks (Art. 35(7)(c)) ​
| # | Risk | Source | Likelihood | Severity |
|---|---|---|---|---|
| A1 | Inference about one person from small groups | A team or period with few contributors | <…> | <…> |
| A2 | Differencing: comparing overlapping scopes (tenant minus team, team A minus team B) to isolate a person | Several scopes over the same data | <…> | <…> |
| A3 | Pressure on people through visible team metrics, or misuse for performance management | Organisational use | <…> | <…> |
| A4 | Self view used under pressure (employer asks people to opt in and show their numbers) | Social pressure | <…> | <…> |
| A5 | Data exposure through exports (CSV injection, uncontrolled spreadsheets) | Export | <…> | <…> |
4. Measures (Art. 35(7)(d)) ​
| Risk | Measures in the product | Evidence |
|---|---|---|
| A1 | Per-point and per-dimension-cell k-anonymity (k ≥ 5); responses never contain head counts; minimum granularity of one day | analytics.test.ts, analytics query tests |
| A2 | Tenant and team scopes require tenant:manage; per-point k in every scope; documented as a residual risk | threat model row AN1 |
| A3 | No person dimension, no rankings, no leaderboards; works-council mode forces team-level only | ADR-0014 |
| A4 | Self view is personal: only the person sees it; opt-in stored per person; disabled in works-council mode | Self-view tests |
| A5 | CSV escaping against formula injection; cache-control: no-store; only aggregates | threat model row AN2 |
Additional measures by the controller: <works agreement (template: ../betrvg/betriebsvereinbarung-anlage.md), purpose limitation in internal policy, k above 5 for small organisations>.
5. Residual risk and decision ​
| Item | Entry |
|---|---|
| Residual risk | <…> |
| Prior consultation (Art. 36) | <…> |
| DPO advice | <…> |
| Views of representatives | <…> |
| Decision: enabled scopes, k, self view | <…> |
| Review date | <…> |
Open points for the DPO / counsel ​
- Confirm the defaults: no per-person view for anyone but the person, k = 5, cost metrics exempt from k but administrator-only.
- Whether the self view should exist at all in employment contexts, given the risk of pressure (A4).
- Whether a DPIA is required for team-level analytics alone.