# GDPR & Works-Council Annex

**Companion to the Session Records Policy template · hxframework.org/policy · CC BY 4.0**
**This is a template and a discussion aid, not legal advice. Data-protection law is jurisdiction-specific; review with counsel and your DPO.**

---

## 1 · Why this annex exists

Session records are work product, but they contain personal data: the author's writing, their working patterns, sometimes their mistakes. In the EU (and anywhere with works councils or similar bodies), collecting them is a consultation topic on day one. This annex gives you the structure for that conversation — and the design decisions that make it a short one.

## 2 · The design decisions that do the heavy lifting

These are properties of a faithful CARE implementation. Confirm each with your vendor or your own build before relying on it in a filing:

1. **Purpose limitation, structural.** Experience signals never feed performance, compensation, or employment decisions (the purpose boundary). This is the single most important line for both GDPR purpose-limitation analysis and works-council concerns about *Leistungs- und Verhaltenskontrolle* (performance and behavior monitoring).
2. **Data minimization by aggregation.** Nobody above the author sees raw sessions; upward views are aggregates with a minimum group size of five. Individual-level processing is limited to custody (storage) and the author's own use.
3. **Transparency, in-product.** The charter is displayed where measurement happens; the access log gives every person the list of accesses to data that includes them — a standing, self-serve answer to "who has seen my data?"
4. **A hard collection boundary.** The repository connection defines scope. Personal projects, personal accounts, and personal devices are out of scope by construction, not by promise.
5. **Revocable, scoped sharing.** Team-level visibility requires the author's explicit, revocable, logged approval — scoped to a named team, never "the organization."

## 3 · Lawful basis (discussion aid)

Most organizations will analyze custody and aggregate analysis under **legitimate interests** (Art. 6(1)(f)): the record is work product, processing is limited, individual-level visibility is architecturally constrained, and a balancing test is materially helped by points 1–5 above. **Consent** (Art. 6(1)(a)) is the natural basis for the sharing consent specifically — it is explicit, granular, revocable, and logged, which is exactly what consent must be. Employment-context consent is treated skeptically in the EU; the design helps because refusing to share carries no consequence: aggregates and custody don't depend on it.

Document the analysis in a DPIA (below) rather than reasoning from this page.

## 4 · DPIA checklist

- [ ] Processing description: what a session record contains; where it is stored; retention schedule.
- [ ] Scope boundary: how the repository connection is enforced; what never enters collection.
- [ ] Purpose statement and the purpose boundary; how the boundary is enforced technically.
- [ ] Visibility matrix: author / named team (consent) / aggregates k≥5 / no one.
- [ ] The access log: who can read it, what it records.
- [ ] Data-subject rights mapping (Section 5).
- [ ] Aggregate-only mode assessment (Section 6) if a works council requests it.
- [ ] Vendor/sub-processor list and transfer analysis, if hosted.

## 5 · Data-subject rights mapping

- **Access (Art. 15):** the author can read their own sessions in full; the access log covers "who else has seen data including me."
- **Rectification (Art. 16):** rarely relevant to verbatim records; contextual notes are the usual remedy.
- **Erasure (Art. 17):** balanced against the record's status as a business record. The policy position: personal-scope material is never collected; work-product records are retained under the documented schedule, with erasure honored where the law requires it and the aggregate contributions retained.
- **Portability (Art. 20):** exports in a documented, machine-readable format — see PSF, the Portable Session Format (hxframework.org/psf).
- **Objection (Art. 21):** sharing is opt-in already; objections to custody/aggregation are handled through the documented process, with the DPIA's balancing analysis as the reference.

## 6 · Works-council mode: aggregate-at-ingest

Where a works council requires it, a faithful implementation can run in **aggregate-only mode**: individual-level records are processed transiently for aggregation and coaching, and no raw-session browsing surface exists for anyone but the author. Put this on the table early — offering it unprompted is the strongest trust signal available.

## 7 · Talking points for the first meeting

1. "The record is kept like source code — and read like a census, not like a camera."
2. "No number about an individual is shown to anyone but that individual."
3. "Nothing here touches performance, pay, or employment — by architecture, and in writing."
4. "Every person can see who accessed data that includes them, at any time."
5. "Sharing is opt-in, team-scoped, revocable, and logged — and declining costs nothing."

---

*Published under CC BY 4.0 as part of the HX policy kit (hxframework.org/policy).*