GrailAtlasIndependent watch reliability, quality & value

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-22

Create, 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
  • Supabasedatabase + auth (US, EU-US DPF (SCC fallback))
  • Vercelhosting (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
  • accounts (email)

RP-NL-01Newsletter (Grail Notebook)

v1 · effective 2026-05-22

Deliver 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
  • Supabasedatabase (US, EU-US DPF (SCC fallback))
  • Email providertransactional 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-22

Persist 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
  • Supabasedatabase (US, EU-US DPF (SCC fallback))
  • Email providerdigest 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
  • saved_searches (email)

RP-GL-01Grail List

v1 · effective 2026-05-22

Track 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
  • Supabasedatabase (US, EU-US DPF (SCC fallback))
Security
RLS per-account; financial-status-adjacent fields encrypted at the storage layer.
Tables
  • grail_lists (email)

RP-REQ-01Catalog / brand suggestion submissions

v1 · effective 2026-05-22

Accept 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
  • Supabasedatabase (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-22

Record 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-22

Maintain 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
  • Supabasedatabase (US, EU-US DPF (SCC fallback))
  • External attestation loghourly 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-22

Erase 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
  • Supabasedatabase (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.

Records of processing activities — Grail Atlas