Structured under the four standard categories used in German-language data processing agreements: Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit, and Verfahren zur regelmäßigen Überprüfung.
A. Confidentiality (Vertraulichkeit)
A.1 Access control — persons
Flok holds no server hardware and operates no premises housing personal data. All processing runs on Vercel and Supabase infrastructure, and physical access control is inherited from those providers.
Authentication is passwordless throughout. Flok stores no passwords, and no password hash.
| Who | How they authenticate |
|---|---|
| Members (member portal) | Email one-time passcode only. Passkeys are deliberately not enabled on the member portal. |
| Club staff and admins | Email one-time passcode, or a WebAuthn passkey as an alternative. There is no password fallback, because there are no passwords. |
| Flok staff | The same passwordless mechanism, plus the tenant-access approval workflow in A.2. |
One-time passcodes are valid for 10 minutes and the account locks after 5 incorrect attempts. Session tokens are held in browser local storage with automatic refresh; no authentication cookie is set.
Session lifetime is the authentication provider's default. Passkeys are offered to staff but not currently mandatory, and there is no IP allow-listing.
A.2 Access control — data
Role-based permissions. Access within a club is governed by a database-driven permission model assigned per user per organisation. Client-side checks govern the user interface only; the enforced boundary is in the database.
Row-level security is the enforced tenancy boundary. Every table in the application schema has row-level security enabled — none without. The count is checked against the migration history rather than stated here, because it grows with every feature. Policies are expressed in terms of the accessing user's organisation membership and permissions, so a query issued with one club's session cannot return another club's rows regardless of what the client asks for.
Least privilege for Flok personnel. Flok staff cannot browse your data at will. Access to a specific organisation requires a support-access request carrying a stated reason, which you approve, is time-boxed (4 hours by default), can be revoked at any time, and expires automatically. Every request, decision, expiry and revocation is recorded.
A.3 Separation control
Flok is multi-tenant on shared infrastructure. Separation is logical, not physical, and is enforced at the database layer by the row-level security described in A.2 rather than by application code. Each record carries an organisation identifier; each policy constrains that column against the caller's verified membership.
A.4 Pseudonymisation and data minimisation
- Messages sent to the public support assistant have email addresses, phone numbers, IBANs and card-shaped numbers automatically stripped before storage. This is redaction, not anonymisation, and we describe it as such.
- The AI churn-risk feature sends only pseudonymous member identifiers plus three behavioural counts. No name, email address or other identifier leaves Flok for that feature.
- AI prompt and response text is not logged by default; capture is gated behind an off-by-default debugging setting.
- Error reports are sent without the monitoring SDK's personally-identifying data option enabled, and only from production builds.
A.5 Cardholder data — out of scope by design
No cardholder data touches Flok's infrastructure at any point. Payment is taken by full-redirect hosted checkout pages operated by Stripe or Payrexx on their own infrastructure. Flok renders no card-number field, no CVV field, and no payment iframe. After payment, Flok independently re-confirms the transaction against the provider's own API rather than trusting the redirect or the webhook payload. Clubs selling tickets through Flok therefore qualify for SAQ A. See how payments work.
B. Integrity (Integrität)
B.1 Transmission control
- TLS for all data in transit, across the application, the marketing site and all club-facing pages.
- A Content-Security-Policy restricts script, connection, frame and form-action origins to a named allowlist and upgrades insecure requests. It is currently deployed in report-only mode, so it reports violations rather than blocking them — we describe it as a monitoring measure, not an enforced control.
- Supporting headers: content-type sniffing disabled, a strict referrer policy, and a permissions policy restricting camera, microphone, geolocation and payment.
- Inbound webhooks are authenticated, not trusted. Email-provider webhooks are verified by HMAC signature with a five-minute replay window; Payrexx webhooks, which carry no signature, are never acted on directly, only after server-side re-verification against Payrexx's API.
- Encrypted database backups are GPG-encrypted before they leave the backup job, using a public key whose private half is held offline and never stored in CI.
B.2 Input control
Flok maintains an audit log recording, for each change: who, what action, on which record, when, and the values before and after. Entries are written by database triggers rather than only by application code, so a change made outside the normal interface path is still recorded.
The log is readable only by users holding the audit-log permission in that organisation, or by Flok staff under the approval workflow in A.2. There is no update or delete policy on the table, so entries cannot be altered or removed through the API.
Audit triggers cover member, event, invoice, ticket-order and registration records, and a parallel platform-level trigger records changes to platform configuration. They are not attached to every table in the schema.
B.3 Change control
- All schema changes ship as reviewed, version-controlled migrations.
- Application source is version-controlled with a linear main branch.
- An automated test suite and linter run over the codebase; performance and accessibility CI runs against the marketing pages on relevant changes.
- Third-party CI actions are pinned to commit hashes rather than floating tags in the job that handles the database dump.
C. Availability and resilience (Verfügbarkeit und Belastbarkeit)
C.1 Backup — two independent tiers
These are two separate systems, not one described twice. They are kept separate deliberately: one protects against losing history, the other against losing the last few hours.
| Tier 1 — long-retention archive | Tier 2 — fast recent restore | |
|---|---|---|
| Operated by | Flok, via its own CI pipeline | Supabase (Pro plan) |
| Frequency | Twice daily, 03:00 and 15:00 UTC | Daily, automatic |
| Retention | At least 60 days | 7 days |
| Stored where | A private object store at a different provider from the primary database, so one provider's failure does not take out both | The database provider's own infrastructure |
| Encryption | GPG-encrypted inside the job; private key held offline, never in CI | Provider-managed |
Restores are tested, not assumed: a restore script and runbook document a real, executed dry run, including issues found and fixed during it. Point-in-Time Recovery is a separate paid add-on and is not enabled; we make no PITR claim.
C.2 Redundancy and provider resilience
Flok operates no redundancy of its own; resilience is inherited from our infrastructure providers, who publish their own attestations:
- Vercel publishes SOC 2 Type 2, SOC 3, ISO/IEC 27001:2022, PCI DSS, HIPAA/HITECH as a Business Associate, GDPR, CCPA/CPRA, nFADP, TISAX, DSA, NIS 2 and DORA, and participates in the EU–US, Swiss–US and UK Data Privacy Frameworks — see its Trust Center.
- Supabase states it is SOC 2 Type 2 compliant, ISO 27001 certified and HIPAA compliant, and offers a DPA — see Supabase security.
These are our providers' certifications, not Flok's own. Flok holds no SOC 2, ISO 27001 or PCI DSS attestation of its own — see what Flok does not claim.
C.3 Data residency
- Member and club data: Zürich, Switzerland.
- Static assets and encrypted backups: Frankfurt, Germany.
- Transactional and newsletter email: Ireland, EU.
- One exception: the AI provider is reached over a global endpoint with no region pinning available. This is the only processing activity not confined to Switzerland or the EEA — see the AI Data Addendum.
C.4 Availability monitoring
A status-check job and a public status page; error and crash monitoring from production builds; and Content-Security-Policy violation reporting to a dedicated collector endpoint.
D. Procedures for regular review (Verfahren zur regelmäßigen Überprüfung)
D.1 Review and assessment
- A documented security audit has been carried out and its findings tracked to closure.
- Our PCI responsibility position is documented, versioned and published, with a machine-readable responsibility matrix and a generated PDF — see the shared responsibility matrix.
- The security page carries an explicit last-reviewed date that is updated whenever the page is substantively reviewed.
- Restore procedures are tested against real backups, not documented in theory.
D.2 Incident response
Breach notification obligations are contractual and are set out in section 8 of the DPA: 48 hours from awareness. Our security contact, security@getflok.app, is published with a 2 business day acknowledgement commitment for inbound vulnerability reports, together with a safe-harbour statement for good-faith research.
D.3 Order control
Sub-processors are engaged under written data processing agreements; the current list is maintained on our sub-processors page, and changes are notified in advance per section 9.3 of the DPA.