Privacy Notices — Inventory & Consistency Check

1. Purpose

GDPR Art. 13/14 and revDSG Art. 19 require a privacy notice at the point personal data is collected, covering a defined minimum content set (§3). This document does two things: it inventories where a notice should exist across Stratify's touchpoints (§2), and it states this document's actual job — confirming consistency between whatever notice is currently live and the real processing map already documented in `dsgvo-data-flow.md` — rather than asserting what any live notice currently says.

This document does not verify live notice content. The codebase does not contain the marketing site's or sign-up flow's actual privacy-notice copy in a form this ISMS effort can read and assess — that content lives in whatever CMS or static page serves the public site, outside this repo's scope, and asserting its content from the codebase alone would be fabrication. Every content judgment below is marked as an open verification task for Antonios/Toby, not a finding.

2. Touchpoint inventory — where a notice should exist

3. Minimum required content (Art. 13/14 checklist)

Any live notice covering the touchpoints in §2 should be checked against this checklist — this is the standard the consistency check in §4 applies, not a claim about what's currently live:

• [ ] Identity and contact details of the controller — wait, what. Advisory, per the confirmed

controller-of-record determination in facts.md/PLAN.md §2

• [ ] Contact details of the DPO — [email protected]
• [ ] Purposes of the processing and the legal basis for each (should match

dsgvo-data-flow.md §3 — e.g. Art. 6(1)(b) for account/mandate data, Art. 6(1)(a) for free-tier newsletter consent)

• [ ] Legitimate interests pursued, where Art. 6(1)(f) is the basis (PostHog/Sentry, referral

cookie, per §3)

• [ ] Recipients or categories of recipients — should reflect the real sub-processor list in

register/suppliers.yaml / facts.md, not a stale vendor list (see PRIV-08 §5's correction note re: Resend → AWS SES)

• [ ] Third-country transfers and safeguards, where applicable — should reflect PRIV-08, including

the push-notification vendors it newly assesses

• [ ] Retention period, or the criteria used to determine it — should reflect PRIV-11
• [ ] The existence of data subject rights (access, rectification, erasure, restriction,

portability, objection) and how to exercise them — should reflect PRIV-09, including the honest self-service gap stated there (§4 of that document)

• [ ] The right to lodge a complaint with a supervisory authority — for GDPR, the relevant EEA

supervisory authority for the subject; for revDSG, the EDÖB

• [ ] Whether provision of the data is a statutory or contractual requirement, and the consequences

of not providing it (relevant mainly for account sign-up and partner onboarding)

• [ ] Existence of automated decision-making, if any — per PRIV-09/PRIV-07, currently not

applicable, but the notice should say so rather than being silent on it

4. Consistency-check job

Once the live notice content for each §2 touchpoint is available (an Antonios/Toby manual pull, not something this document does), the check this document performs is: does the live notice's description of purposes, recipients, retention, and rights match what `dsgvo-data-flow.md`, PRIV-08, PRIV-09, and PRIV-11 actually say Stratify does? A mismatch in either direction is worth flagging — a notice that promises less than the operational reality is a transparency gap; a notice that promises more (e.g., claiming self-service erasure that doesn't exist yet) is a false representation that should be corrected in the notice, not treated as an aspirational target.

5. Open verification tasks

1. Pull the current live privacy-notice text from the marketing site, sign-up flow, and partner

application flow — none of this is available from the codebase.

1. Confirm whether a careers/candidate touchpoint exists at all; if so, check whether it has any

notice.

1. Run the Art. 13/14 checklist (§3) against each live notice found.
2. Correct any mismatch found — either the notice or the operational document (dsgvo-data-flow.md

or the relevant PRIV-* document), whichever is inaccurate.

1. Record the outcome of steps 1–4 as a dated entry once completed; this document should not be

marked approved until at least one full pass of this check has been done.

6. Review

This document cannot be marked approved until the open verification tasks in §5 have been run at least once. Once approved, reviewed annually alongside the other Tier 3 privacy documents, and immediately whenever a new touchpoint collecting personal data is added to the product.