Data Protection Impact Assessment
A Data Protection Impact Assessment (DPIA) under GDPR Art. 35 is required when processing is likely to result in a high risk to people's rights and freedoms — typically large-scale automated profiling, systematic monitoring, or large-scale processing of special-category data. This page records why a full DPIA is not yet triggered at v1, the v1 data-flow assessment that supports that conclusion, and the precise point at which a full DPIA becomes required.
v1 scope and conclusion
At v1, proof. is a personal cookbook tool. It stores and versions content the user writes, rendering and exporting it on their request. There is no automated profiling, no behavioural tracking, no special-category data processed by design, and — importantly — no language model or autonomous agent that processes the user's recipe content. Processing is confined to providing the service the user explicitly asked for.
On that basis, the Art. 35 high-risk threshold is not met at v1, and a full DPIA is not triggered. The assessment below documents the v1 data flows so the conclusion is auditable, and the trigger condition is stated so a DPIA is started before — not after — the threshold is crossed.
v1 data-flow assessment
The data flows present at v1, with their controls:
- Account and authentication — email and display name, session cookie. Stored per-user; access gated by session. Minimal identity data, contractually necessary.
- Recipe content, cook logs, outcomes, media — user-authored content, isolated per user. Not shared with any third party unless the user publishes a recipe link themselves. Exportable and deletable by the user.
- Feedback to GitHub — the one external flow that carries a user identifier. The issue body carries an opaque synthetic account identifier only; email and display name are excluded. Screenshots are stored separately and referenced by opaque key. The data-minimised design keeps this a low-risk flow.
- Crash telemetry — sanitised server-side (emails, tokens, and session identifiers stripped) before it is logged. Not linked to user identity beyond the sanitised payload.
- Waitlist email — single email address, consent-based, auto-purged after rejection or expiry.
Identified residual risks at v1 are limited and mitigated: data minimisation on the GitHub boundary, sanitisation on telemetry, per-user isolation of content, self-serve export and erasure, and a single essential cookie with no third-party tracking. None rises to the Art. 35 high-risk threshold.
When a full DPIA becomes required (Phase 2 trigger)
A full DPIA must be completed before the Phase 2 agent pathway ships. That pathway introduces a language-model integration that processes the user's recipe content on the cook's behalf — for example, to suggest a variation or summarise changes. At that point recipe content is sent to a model provider acting as a processor, which changes the risk profile:
- A new sub-processor (the model provider) receives user content.
- Automated processing of user content is introduced, where v1 had none.
- The legal basis, retention by the provider, and transparency to the user must all be re-assessed.
The DPIA for that pathway will document the model provider as a sub-processor, the data sent and its retention, the legal basis for the processing, the user-facing disclosure, and the controls (opt-in, scope limits, and the read-versus-write distinction). This page is updated to a full DPIA at that time. No such processing exists at v1; nothing on this page describes a feature that is not yet built.
Contact
Data-protection questions: privacy@proofcook.com. No Data Protection Officer is appointed; for a solo project of this scope none is required.