Records of processing activities
Every kind of personal data Grail Atlas processes, what we use it for, the lawful basis we rely on, how long we keep it, and who (if anyone) we share it with. This is the full GDPR Art. 30 record, published voluntarily because transparency beats lawyer-speak.
If you want a copy of every record we hold on you specifically (or want it all deleted), use the privacy request form.
8 active activities
RP-ACCT-01Account management
v1 · effective 2026-05-22Create, authenticate, and maintain user accounts so the visitor can save a Grail List or saved searches across sessions.
- Lawful basis
- Art. 6(1)(b) — performance of a contract with the data subject
- Subjects
- registered visitors
- Data categories
- email · hashed password · display name · account preferences
- Sources
- the data subject directly via the signup form
- Retention
- While the account is active. 30 days post-deletion for cleanup; immediate on confirmed erasure request.
- Recipients
- Supabase — database + auth (US, EU-US DPF (SCC fallback))
- Vercel — hosting (request transit only) (US, EU-US DPF (SCC fallback))
- Security
- Salted scrypt password hashing; RLS deny-all-anon; TLS in transit; encryption at rest at the Supabase storage layer.
- Tables
RP-NL-01Newsletter (Grail Notebook)
v1 · effective 2026-05-22Deliver the Grail Notebook newsletter only to subscribers who have completed the double-opt-in confirmation.
- Lawful basis
- Art. 6(1)(a) — consent; Art. 7(1) demonstrability
- Subjects
- newsletter subscribers
- Data categories
- email · signup-page URL · IP address at confirm · confirmation timestamp
- Sources
- the data subject directly via the newsletter form
- Retention
- While subscribed. Proof-of-consent row (IP + timestamp) retained 24 months post-unsubscribe to defend against PECR / ePrivacy enforcement claims (typical limitation period 2-3 years; reviewed annually).
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- Email provider — transactional email (not yet selected) (TBD, TBD)
- Security
- RLS deny-all-anon; service-role-only writes; salted email hash for lookup.
- Tables
- newsletter_subscribers (email)
- Erasure rules
- newsletter_subscribers: defer 30d — Art. 17(3)(e) — proof-of-consent row retained 30 days post-request to defend against a possible "I never opted in" claim. The active subscription is suppressed immediately; the proof row is deleted at day 30.
RP-SS-01Saved searches + email alerts
v1 · effective 2026-05-22Persist the visitor’s saved-search constraints and dispatch alert digests they opted into.
- Lawful basis
- Art. 6(1)(b) — contract; Art. 6(1)(a) consent for alert emails
- Subjects
- registered visitors
- Data categories
- email · account id · saved search constraints · alert cadence · digest send history
- Sources
- the data subject directly
- Retention
- While the search is active. 90 days archive after the visitor deletes; immediate on confirmed erasure.
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- Email provider — digest delivery (not yet selected) (TBD, TBD)
- Security
- RLS per-account; per-account rate limit; query shape validated server-side; feed token hashed at rest.
- Tables
RP-GL-01Grail List
v1 · effective 2026-05-22Track the visitor’s shortlisted target watches and (optionally) owned pieces with acquired price/date for valuation.
- Lawful basis
- Art. 6(1)(b) — contract (opt-in feature)
- Subjects
- registered visitors who add Grail List entries
- Data categories
- email · account id · watch reference · condition · box/papers · acquired price · acquired date
- Sources
- the data subject directly
- Retention
- While the account is active; immediate on confirmed erasure.
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- Security
- RLS per-account; financial-status-adjacent fields encrypted at the storage layer.
- Tables
RP-REQ-01Catalog / brand suggestion submissions
v1 · effective 2026-05-22Accept the visitor’s request to add a watch or brand to the catalog; respond by email when the suggestion is acted on.
- Lawful basis
- Art. 6(1)(a) — consent (the submitter chooses to provide an email for follow-up)
- Subjects
- catalog-suggestion submitters
- Data categories
- contact_email (if provided) · submission text
- Sources
- the data subject directly via /request
- Retention
- 12 months from submission; immediate on confirmed erasure.
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- Security
- RLS deny-all-anon; honeypot + rate-limit on the form.
- Tables
- user_submissions (contact_email)
RP-CONS-01Cookie / tracking consent record
v1 · effective 2026-05-22Record the visitor’s consent choice so the banner does not re-prompt every visit, and so we can demonstrate consent under Art. 7(1).
- Lawful basis
- Art. 6(1)(c) — legal obligation (ePrivacy Art. 5(3) demonstrability + Art. 7(1))
- Subjects
- all visitors
- Data categories
- accepted categories · policy version · decision timestamp
- Sources
- the data subject’s banner interaction
- Retention
- 24 months from the most recent decision; mirrored Supabase row deleted on account deletion.
- Recipients
- (none — first-party cookie only for anonymous; Supabase mirror for logged-in) — - (-)
- Security
- First-party cookie; SameSite=Lax; Secure over HTTPS; mirror row RLS-protected.
- Tables
- consent_records (email_hash)
RP-AUDIT-01Privacy operations audit log
v1 · effective 2026-05-22Maintain a tamper-evident chain of every step of every DSAR + ROPA change so Art. 5(2) accountability is demonstrable.
- Lawful basis
- Art. 6(1)(c) — legal obligation (Art. 5(2) accountability)
- Subjects
- DSAR requesters · operator
- Data categories
- pseudonymised email hash · request metadata · IP hashes · event timestamps · hash chain
- Sources
- automated emission from privacy engine + ROPA change handler
- Retention
- 3 years minimum (Art. 82 actions limitation period); 6 years maximum. Daily salts are retained alongside the audit log for the same period so post-hoc verification remains possible.
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- External attestation log — hourly head-hash publication (global, public log)
- Security
- Append-only at three layers (app, row triggers, event trigger); hash chain; external hourly attestation.
- Tables
- privacy_audit_log (subject_email_hash)
- Erasure rules
- privacy_audit_log: Art. 17(3)(b) + (e) — retention necessary for compliance with a legal obligation (accountability) and defense of legal claims. Erasure does not apply to the audit log itself; the subject_email_hash is pseudonymised and not directly identifying.
RP-MIN-01Minor records remediation
v1 · effective 2026-05-22Erase records inadvertently created by under-18 visitors (or by their parents/guardians on their behalf) when discovered.
- Lawful basis
- Art. 6(1)(c) — legal obligation; Art. 17(1)(f) — erasure of unlawful processing
- Subjects
- under-18 visitors · parent/guardian on behalf
- Data categories
- (whatever was inadvertently collected — typically email + signup metadata)
- Sources
- parent/guardian or operator notification
- Retention
- Immediate on operator confirmation that the subject is under 18; no confirmation handshake required.
- Recipients
- Supabase — database (US, EU-US DPF (SCC fallback))
- Security
- Operator-initiated DSAR path; audit-chained.
Changes to this list are audit-chained — every addition, edit, or retirement appends an event to the privacy audit log. The chain’s current head is published hourly to an external attestations repo (so a service-role attacker can’t silently rewrite history). See privacy policy for the underlying commitments.