Allin — GDPR status

The consent screen and consent audit trail are built and safe to ship, but none of it satisfies anything legally until it's actually protecting a real user. Being built isn't the same as being compliant.

GDPR Art. 28 requires a data processing agreement with anyone processing personal data on your behalf — this isn't optional or scaled by how sensitive the data is, every processor needs one. Highest urgency: Anthropic (handles real check-in/plan text, newest-confirmed processor, needs an active request not a click-through) and Supabase (holds every table directly). Amplitude/Customer.io/Meta/RevenueCat still need one each too, just lower urgency given what reaches them.

UK data controllers processing personal data must register with the ICO and pay the annual data protection fee, with narrow exemptions that don't apply here. This hasn't been checked yet — worth confirming directly in the ICO's own registry, since failing to register is itself a violation independent of anything else on this page.

Arts. 12–14 require accurate, transparent information about how data is used. The live policy on join-allin.com currently states things that aren't true (e.g. "we do not collect health data") while paid ads run. The corrected draft has existed for a while — publishing it is a Squarespace action only you or Isabel can do.

Art. 9(2)(a) requires explicit consent as the lawful basis for processing health-adjacent data (check-ins, reflections). The consent screen + audit trail cover the mechanism; both still need to actually ship to count.

Art. 5(1)(e) requires data be kept no longer than necessary for its purpose — meaning a defined retention period has to exist and be applied, not left open-ended. Not started; needs a decision on the actual period before it can be built.

Arts. 15/20 require providing someone their own data in a portable format on request. Not built yet.

The Terms state a 16+ requirement; nothing in the app asks or enforces it. The UK Children's Code applies to any service children are likely to reach, not just ones aimed at them — and paid ads mean the actual audience age isn't controlled. This is the one item here that's a real product/legal decision rather than a pure build — worth a lawyer's read given the mental-health-adjacent positioning.

Art. 25/32 name pseudonymization as an example of "appropriate technical measures," not an independent requirement by itself — but given the data involved, it's the difference between a privileged login seeing an identity vs. a random token. Stage 2/3 need a backup + verified backfill first, on a scheduled maintenance window, not urgent this week.

Same Art. 32 category as pseudonymization — an example measure, not mandated by name. Needs a real architecture decision (an edge function to keep the key outside the database) before any code gets written.

Internal access-control hygiene supporting the same Art. 32 security obligation — drafted, not applied, since it's an access-control decision rather than a bug fix.

This sits under ASA/consumer-protection rules, not GDPR — grouping it here before was misleading. Everything else on the claims register is sourced and safe; two claims need Isabel's exact wording call.