Records of processing activities (GDPR Art. 30)

Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.

This template has two parts:

• Part A is the record the customer as controller keeps under Art. 30(1) for its use of CodeLotse (both editions).
• Part B is the record Quavon UG (haftungsbeschränkt) as processor keeps under Art. 30(2) for the hosted (Enterprise) edition.

Both are prefilled from the data inventory. Fields in angle brackets (<…>) are filled by the party that keeps the record. The exemption in Art. 30(5) for organisations with fewer than 250 employees is unlikely to apply, because the processing is not occasional; the DPO decides.

Part A — Controller record (customer)

A.1 Controller (Art. 30(1)(a))

Field	Value
Controller	<customer legal name and contact details>
Joint controller	<none, or name>
Representative (Art. 27)	<only if the controller is outside the EU>
Data protection officer	<name and contact details>
System	CodeLotse, <self-hosted / hosted by Quavon UG (haftungsbeschränkt)>, version <version>

A.2 Processing activities

Each row is one processing activity. Purposes (Art. 30(1)(b)), data subjects and data categories (Art. 30(1)(c)) and erasure periods (Art. 30(1)(f)) are prefilled with the product defaults. Legal bases are proposals; the DPO confirms them and documents balancing tests where Art. 6(1)(f) is used.

#	Activity	Purpose	Data subjects	Personal data	Source tables	Erasure (default)	Proposed legal basis
P1	Sign-in and access control	Authenticate users, decide permissions, end sessions	Users of the dashboard (employees, contractors)	Git host or identity-provider id, login, display name, host or issuer; session hashes; IdP group names; roles	users, auth_sessions, tenant_memberships, repo_memberships, oidc_role_mappings	Sessions ≤ 8 h, purged daily; users until removed; roles refreshed at sign-in	Art. 6(1)(b) or (f)
P2	Automated code review	Find defects and security issues in pull requests and publish review comments	Authors and reviewers of pull requests; people named in code	Login and id of PR authors, PR titles and descriptions, diffs, review findings, posted comments	pull_requests, pr_revisions, findings, posted_comments, people, webhook_deliveries	Tenant retention (default 90 days for derived data); webhook payloads 14 days	Art. 6(1)(f)
P3	Issue triage, replies and chat	Label issues, find duplicates, draft grounded replies, answer commands	Issue and comment authors	Logins, issue and comment text, labels, chat command log	issues, issue_comments, triage_runs, reply_drafts, chat_commands	Tenant retention; deleted with the issue or repository	Art. 6(1)(f)
P4	Issue to draft pull request, acceptance checks	Prepare draft fixes for issues and check acceptance criteria	The person who triggers a fix; issue authors	Trigger login, issue text excerpts, patches, test output tails	fix_runs, ac_checks, sandbox_runs	Tenant retention; sandbox snapshots ≤ 15 min	Art. 6(1)(f)
P5	Reviewer and assignee suggestions (if enabled)	Route reviews and issues to people who know the code	Repository members and collaborators	Selected people, explanation facts, per-path familiarity values, open assignment counts, opt-in availability (from/to only), privacy flags, reassignment feedback	assignments, expertise_cache, availability, availability_feeds, people, feedback_events	Assignment records 6 months; availability 30 days after the interval ends; feedback 6 months; shorter in works-council mode	Art. 6(1)(b) or (f); works agreement where required. DPIA: dpia-assignment.md
P6	Feedback learning	Learn which finding categories a repository acts on	Reviewers and PR authors (as actors of feedback)	Feedback outcome per finding, actor permission check (not stored per person)	feedback_events, suppression_rules, calibration_params	6 months for feedback events	Art. 6(1)(f)
P7	Team analytics (if used)	Show team-level review and delivery metrics and LLM costs	PR and issue authors (only in aggregates of at least k people)	Daily aggregates per repository; self view only for the person and only with their opt-in	analytics_daily, analytics_teams, analytics_team_repositories, budget_alerts	Follows tenant retention	Art. 6(1)(f); works agreement where required. DPIA: dpia-analytics.md
P8	Security and audit logging	Accountability, incident investigation, abuse prevention	Users and administrators	Actor login, action, target, IP address, time	audit_log, application logs	Audit log append-only; retention policy open (see review checklist); application logs operator-defined	Art. 6(1)(c) or (f)
P9	LLM usage accounting and optional prompt logs	Cost control and budgets; debugging model behaviour (opt-in)	People whose text appears in prompts	Usage records without prompts; prompt logs only when debug logging is on, redacted and encrypted	llm_calls, llm_prompt_logs	Usage per tenant retention; prompt logs ≤ 7 days	Art. 6(1)(f)
P10	Data subject requests	Answer access and erasure requests	Any person in the system	Export of the person's records; a hash of the subject in the audit entry	DSAR report	Report kept by the controller as needed for accountability	Art. 6(1)(c)

Product telemetry (opt-in, self-hosted only) contains no personal data and is not a processing activity of personal data; see toms.md and the data inventory.

A.3 Recipients (Art. 30(1)(d))

Recipient	Activities	Notes
Git host (for example GitHub)	P2, P3, P4, P5	Comments, labels, review requests and draft pull requests are published to the repository the data came from
Model provider configured by the tenant	P2–P5, P9	Only the provider and region the tenant configured; see subprocessors.md
Quavon UG (haftungsbeschränkt)	All, hosted edition only	As processor under the DPA
Identity provider configured for sign-in	P1	Receives the authentication request; returns identity and groups

A.4 Transfers to third countries (Art. 30(1)(e))

<List the model provider routes that process data outside the EEA, the country, and the safeguard (adequacy decision, for example the EU-US Data Privacy Framework where the provider is certified, or standard contractual clauses). Self-hosted models and EU-only routes involve no transfer.>

A.5 Technical and organisational measures (Art. 30(1)(g))

See toms.md.

Part B — Processor record (Quavon UG (haftungsbeschränkt), hosted edition)

B.1 Processor (Art. 30(2)(a))

Field	Value
Processor	Quavon UG (haftungsbeschränkt); address and register details in the imprint; contact@quavon.de
Data protection officer	<to be appointed or confirmed>
Controllers	One entry per customer tenant: <customer name, contact, DPA reference, tenant id>

B.2 Categories of processing per controller (Art. 30(2)(b))

For each customer tenant, Quavon UG (haftungsbeschränkt) carries out the activities P1–P9 of Part A that the customer enabled, on the customer's instructions as recorded in the DPA and in the tenant settings (enabled features, model routes, retention). Quavon UG (haftungsbeschränkt) carries out P10 only on the controller's request.

Category	Operations
Hosting and storage	Storing tenant data in Postgres and Valkey; backups <once backups exist>
Event processing	Receiving webhooks, running review, triage, reply, chat, fix and assignment jobs
Model calls	Sending prompts to the model route the tenant configured
Publishing	Writing comments, labels, review requests and draft pull requests to the tenant's Git host
Operations and support	Monitoring, incident handling, break-glass access with audit and customer approval; anonymous instance-wide operating statistics under DPA clause 3.5 (operator overview: user counts below 5 hidden, nothing per person or per controller, computed on request and not stored, every view audited)
Deletion	Retention jobs, deletion on request and at the end of the contract

B.3 Transfers (Art. 30(2)(c))

<Per tenant: the model route and its transfer safeguard, from the tenant settings. Hosting itself stays in the EU (see subprocessors.md).>

B.4 Technical and organisational measures (Art. 30(2)(d))

See toms.md and the ISO/IEC 27001 Annex A mapping.

Open points for the DPO / counsel

1. Legal basis for employee data per activity (Art. 6(1)(b) or (f), Art. 88 GDPR with § 26 BDSG after CJEU C-34/21).
2. Retention of the audit log and pseudonymisation on erasure requests.
3. Whether Art. 30(5) applies to any customer (unlikely).
4. Transfer safeguards per model provider route.