Skip to content

Data protection

This page covers the technical and operational controls Fanzava applies to participant data: encryption, what we collect and don’t, how long we retain it, how it’s deleted, and what additional controls hub admins have.

LayerMechanism
In transitTLS 1.3 enforced for all connections. TLS 1.0 and 1.1 are not accepted. HSTS is preloaded.
At restAES-256 encryption for all stored data.
PasswordsHashed with Argon2id (memory-hard, OWASP-recommended). Never stored, transmitted, or logged in plaintext. Not reversible.
Session tokensSigned with RS256; signing keys rotated every 90 days with a 7-day overlap.
BackupsEncrypted with separate keys from production data, stored in a different security boundary.

For EU-region hubs, encryption keys are managed within the EU — see Data residency.

Fanzava operates on a principle of data minimisation. The following participant data is collected:

CategoryDataWhy
IdentityEmail address, display nameAuthentication and presentation
ProfileTimezone preference, avatar (optional), notification preferencesLocalisation and contact
ActivityTips, bracket picks, scores, leaderboard standingsThe product itself
EngagementLogin times, page views, feature usageAnalytics for hub admins
AcquisitionUTM parameters at signupMarketing attribution; anonymised after 90 days
AuditIP address (hashed), user agent (scrubbed)Security event correlation

Fanzava does not collect:

  • Real names beyond what participants choose to provide as their display name
  • Date of birth
  • Postal address (except where Enterprise customers require it for prize fulfilment, which is per-hub opt-in)
  • Phone numbers
  • Government identifiers
  • Biometric data
  • Health, religious, political, or other special-category data
  • Payment card details (handled by Stripe — see below)

Fanzava does not store payment card details. All payment processing is handled by Stripe, which is PCI DSS Level 1 certified. Fanzava receives only the Stripe customer ID, the billing email, and high-level subscription metadata — never the card number, CVV, or expiry. This keeps Fanzava out of PCI scope.

Different data categories have different retention policies:

DataDefault retentionConfigurable on Enterprise
Participant profile and credentialsLifetime of the participant’s hub membershipn/a
Tips and scoresIndefinitely (preserved for historical leaderboards)n/a
UTM acquisition data90 days, then anonymisedNo
Login history1 yearUp to 7 years
Analytics events2 yearsUp to 7 years
Audit logsSee Audit logsUp to 7 years
Email send logs1 yearUp to 7 years
Server access logs90 days, no PII includedNot customer-accessible

Hub admins can request data purges of inactive participants from Admin → Participants → Bulk actions → Purge inactive.

Right of erasure is implemented as a phased workflow rather than an instantaneous operation, to ensure clean removal across all systems while preserving the integrity of historical data the deleted participant has already affected.

The full workflow is documented on DPA & GDPR — Participant data deletion. In summary:

StageTiming
Logout (all sessions revoked)Immediate
Leaderboard removal (display anonymised)Within 24 hours
PII scrub from active databaseWithin 7 days
PII scrub from backupsWithin 30 days

After the 7-day PII scrub, the participant’s data cannot be re-identified, even by Fanzava engineering.

Hub admins can configure additional privacy controls beyond the defaults:

  • Email visibility — hide participant emails from group leaderboards and exports
  • Display name policy — require real names, allow nicknames, or allow pseudonyms
  • Data export restrictions — limit which admin roles can export participant data
  • Retention overrides Enterprise — configure custom retention periods for analytics, audit logs, and inactive participant data

Configure from Admin → Settings → Security → Privacy.

Fanzava’s sub-processors process specific categories of participant data on behalf of your hub. The current list is published at fanzava.com/legal/sub-processors with 30 days’ notice of any change. See DPA & GDPR for the contractual framework.

Was this page helpful?