Records of Processing Activities — GoDating
Article 30 GDPR record. Version 1.1 · 2026-05-05 · open Denmark beta scope.
| Field | Value |
|---|---|
| Controller | PX7 Digital |
| Controller address | Hyltebjerg Allé 43, 2720 Vanløse, Danmark |
| Controller contact | [email protected] |
| DPO | None appointed (size threshold not reached); contact above |
| Joint controllers | None |
| Representative in EU | Same as controller (DK-established) |
Processing activity 1 — Account creation + authentication
| Field | Value |
|---|---|
| Purpose | Identity establishment, access control, account recovery |
| Lawful basis | Article 6(1)(b) Contract |
| Data subjects | Individuals 18+ in Denmark who choose to create a GoDating account |
| Categories of personal data | Email, HMAC-SHA256 of email (for case-insensitive lookup), locale, role, account status, social-account linkage IDs (when used), email-confirmation tokens, magic-link session cookies |
| Categories of recipients | Internal: production Worker, admin operators with audit-logged access. External: Resend (email delivery only — magic-link payload, confirmation links, password-reset-equivalent) |
| International transfers | Resend may process email metadata in US infrastructure; SCCs in place |
| Retention | Account record: until deletion request + 30 d soft-delete grace, then hard-deleted. Magic-link tokens: ≤ 15 min. Sessions: ≤ 14 d sliding |
| Security measures | TLS in transit; D1 encryption at rest; sessions are httpOnly+Secure cookies signed via SESSION_SECRET; per-IP rate limit (5/h) on magic-link requests |
Processing activity 2 — Profile creation + presentation
| Field | Value |
|---|---|
| Purpose | Allow users to present themselves to other users for the purposes of mutual matching |
| Lawful basis | Article 6(1)(b) Contract; Article 9(2)(a) explicit consent for any special-category data revealed in photos or bio (consent captured per intake step in profile_consents) |
| Data subjects | Account holders who completed the profile-intake flow |
| Categories of personal data | Display name, date of birth, age-confirmed flag, area, postal code (4-digit), gender identity, "shown as", "interested in" (multi-value), relationship intention, free-text bio, prompt answers, up to 6 photos with SHA-256 + EXIF stripped |
| Categories of recipients | Other matched users (mutual-like only); admin operators reviewing reports; nobody else |
| International transfers | Same as activity 1 (Cloudflare D1 + R2 in EU regions where supported) |
| Retention | Same lifecycle as the account. Photo binaries in R2 grace-deleted 30 d after soft-delete. Vector embeddings in godating-prod-compat removed at hard-delete |
| Security measures | Pre-publication moderation of bio + photos; CSAM hash check before any photo is stored; NSFW classifier before publication; row-level access enforcement in worker |
Processing activity 3 — Discovery + matching
| Field | Value |
|---|---|
| Purpose | Generate a daily candidate pool for each user; detect mutual likes |
| Lawful basis | Article 6(1)(b) Contract |
| Data subjects | Active account holders |
| Categories of personal data | Profile attributes (per activity 2); behavioural action history; 128-dim vector representations derived from values_json + relationship_signals_json (stored in Cloudflare Vectorize) |
| Categories of recipients | Internal worker only; pool snapshots stored in Cloudflare KV |
| International transfers | Vectorize index in nearest available EU region |
| Retention | Pool snapshots: 7 d rolling. Vectors: refreshed every sweep cycle, deleted on account deletion |
| Security measures | Vector dimensions are non-invertible (FNV-1a hash bag + ordinal one-hot, L2-normalised); never exposed via public API; matching ranker behind feature flag |
Processing activity 4 — Communication between matched users
| Field | Value |
|---|---|
| Purpose | Enable text chat between mutually matched users; date-plan proposals |
| Lawful basis | Article 6(1)(b) Contract |
| Data subjects | Mutually matched account holders |
| Categories of personal data | Plain-text chat messages, per-message metadata (timestamps, read state), automated NSFW classifier scores stored as chat_safety_signals, date-plan content |
| Categories of recipients | The other party in the matched chat; admin operators only when a report is filed |
| International transfers | None beyond Cloudflare residency |
| Retention | Chat messages: 12 months rolling. Date plans: 12 months rolling. Safety signals: lifetime of the chat thread |
| Security measures | Server-side moderation classifier on every message; rate limits per user; reporting + blocking flow; mutual-match-only access control |
Processing activity 5 — Safety, moderation, abuse prevention
| Field | Value |
|---|---|
| Purpose | Compliance with the Digital Services Act + national law; protection of users from harassment, scam, CSAM |
| Lawful basis | Article 6(1)(c) Legal obligation (DSA Articles 14–18, CSAM-reporting national law); Article 6(1)(f) Legitimate interest in platform integrity, balanced against user rights — balancing test recorded in DPIA §3 |
| Data subjects | Reported users, reporters, all users (passively, via automated classifiers) |
| Categories of personal data | Reported content snapshots, reviewer decisions, admin audit trail, support notes, photo hashes for CSAM matching |
| Categories of recipients | Internal admin operators with audit-logged access; CSAM hits reported to NCMEC equivalent (DK: Red Barnet / National IT Investigation Centre) per CSAM runbook |
| International transfers | NCMEC referrals may transit US infrastructure under their regulated framework |
| Retention | 5 years (DSA evidence preservation + national criminal-evidence retention) |
| Security measures | Admin second-factor required (ADMIN_SECOND_FACTOR); admin actions written to immutable admin_audit_log; two-strike review for terminal account actions |
Processing activity 5a — Verification selfie review
| Field | Value |
|---|---|
| Purpose | Allow a user to request Level 1 photo verification and allow GoDating to determine whether a verified-profile badge may be granted |
| Lawful basis | Article 6(1)(b) Contract for the requested verification workflow; Article 9(2)(a) explicit consent for the verification selfie and any special-category traits visible in it |
| Data subjects | Account holders who actively request verification |
| Categories of personal data | One still verification selfie, randomly-prompted gesture context, selfie SHA-256, perceptual-hash similarity aids versus profile photos, reviewer decision, verification status history |
| Categories of recipients | Internal admin reviewers only; no third-party biometric provider is active at launch |
| International transfers | None beyond Cloudflare hosting under the main infrastructure DPA |
| Retention | Verification selfie deleted within 90 days of approve/reject/withdrawal; decision outcome retained for the life of the account; hash/similarity evidence retained only as long as the verification request row is retained |
| Security measures | Explicit consent gate before capture; R2 private storage; moderator-only access; no stored biometric template or face embedding on GoDating infrastructure; withdrawal path resets badge state |
Processing activity 6 — Notifications
| Field | Value |
|---|---|
| Purpose | Deliver transactional and opt-in updates |
| Lawful basis | Article 6(1)(b) for transactional (login, account confirmation); Article 6(1)(a) Consent for push + weekly recap |
| Data subjects | Account holders who opted in (where opt-in applies) |
| Categories of personal data | Push subscription endpoint + keys; recap preferences; per-delivery audit trail |
| Categories of recipients | Apple APNs / Google FCM when push is activated; Resend for transactional and recap email |
| International transfers | Apple, Google, Resend — all under DPA + SCC where required |
| Retention | Until unsubscribe; recap-delivery audit retained 90 d |
| Security measures | Granular per-channel toggles; one-click unsubscribe in every email; subscription endpoint rotation on revocation |
Processing activity 7 — Cross-handle profile import (Intus / GoToBe)
| Field | Value |
|---|---|
| Purpose | Allow users with an existing Intus or GoToBe account to import a starting profile shape |
| Lawful basis | Article 6(1)(a) Explicit consent (new intus_consents row required per import) |
| Data subjects | Users who initiate an import |
| Categories of personal data | The subset of Intus profile fields the user explicitly approves |
| Categories of recipients | Internal worker only; same controller umbrella (PX7 Digital owns Intus + GoDating) |
| International transfers | None |
| Retention | Tied to the corresponding intus_consents row; revocation in Intus propagates within 24 h |
| Security measures | Per-field consent UI; idempotent import; audit row in intus_imported_profiles |
Processing activity 8 — Operational telemetry
| Field | Value |
|---|---|
| Purpose | Detect application errors and performance regressions |
| Lawful basis | Article 6(1)(f) Legitimate interest (operating a stable service); user rights respected via aggregation + minimum data |
| Data subjects | All users (passively) |
| Categories of personal data | UserId (pseudonymous), route, error stack, browser UA. Cloudflare Web Analytics: cookieless, no per-user identifier |
| Categories of recipients | Internal Worker logs + D1 client_error_events; Cloudflare Analytics dashboard accessible to admin operators |
| International transfers | None beyond Cloudflare |
| Retention | 90 d rolling for client_error_events; Cloudflare Analytics retention per CF policy |
| Security measures | No identifying cookies; cookieless analytics; per-route sampling for high-volume errors |
Subprocessors (current)
| Subprocessor | Role | Location | Lawful basis for transfer | DPA |
|---|---|---|---|---|
| Cloudflare Inc. | Hosting (Worker), database (D1), object storage (R2), KV, Vectorize index, Web Analytics, Turnstile | EU regions where supported; otherwise SCC-protected | SCC + DPA | Active |
| Resend | Transactional + recap email delivery | EU + US (per region setting) | SCC + DPA | Active |
| Intus / GoToBe | Cross-handle profile import handshake | Same controller umbrella (PX7 Digital) | Internal | n/a |
| Apple APNs / Google FCM | Push notification fan-out (when activated) | US + EU | SCC + their respective DPAs | Pending push activation |
| External biometric provider not active at launch | Optional future liveness / identity-verification path | Provider and region will be published before activation | DPA and transfer basis required before activation | Not active |
The current published list is also at godating.app/legal/subprocessors. Any change is announced 30 d in advance via in-app banner + email to active users.
9. Document control
| Field | Value |
|---|---|
| Owner | Jørgen Larsen / PX7 Digital |
| Drafted by | HQ Dispatch agent (Claude) on 2026-05-04 |
| Effective | On publication at godating.app/legal/ropa |
| Next review | 2026-11-04 (6 months) OR on any change to subprocessors / data categories / retention |
| Version history | v1.1 — clarified current selfie-verification processing and future provider posture; v1.0 — initial draft, open Denmark beta |