Floynk logo

Security measures

Technical and organisational measures implemented by Floynk (DigitX B.V.) to protect customer data.

Probeer Gratis

Security measures

Effective date: 21 April 2026

This page describes the technical and organisational measures that DigitX B.V. (trading as Floynk) has in place to protect customer data. We aim to be precise rather than aspirational: what is listed here is what we actually do today. Where a control is delivered by one of our sub-processors, we say so — we do not claim someone else's certifications as our own.

1. Our security posture in one paragraph

Floynk is a small, focused team (currently one operator with production access). We keep our stack lean on purpose: fewer moving parts means a smaller attack surface. We rely on audited, certified providers for the components that must be enterprise-grade (Supabase for the database, Hetzner for compute, Stripe and Mollie for payments) and we harden the parts we run ourselves. We are aligned with the principles of ISO 27001 but we are not currently ISO 27001 certified. Our database provider, Supabase, holds SOC 2 Type II.

2. Hosting and infrastructure

  • Compute: Hetzner data centres in Falkenstein (FSN1) and Nuremberg (NBG1), Germany. Hetzner's facilities are ISO 27001 certified with biometric access, 24/7 surveillance, and redundant power/cooling. These are Hetzner's controls, not ours.
  • Primary database: Supabase Pro XXL on AWS eu-central-1 (Frankfurt). Managed PostgreSQL with SOC 2 Type II coverage, AES-256 encryption at rest, TLS 1.3 in transit, and point-in-time recovery.
  • Data residency: All customer data is stored and processed in Germany (Hetzner compute, Supabase in Frankfurt). The only exceptions are US-based sub-processors listed in our sub-processors page, all governed by Standard Contractual Clauses.
  • Deployment: Containerised services running on our own Hetzner hardware. Images are pulled from a private Docker Hub registry; images contain application code only — no secrets or environment variables are baked in.

3. Network and perimeter

  • Firewalls: Host-level firewalls on every server, with default-deny inbound rules.
  • CrowdSec: Collaborative intrusion-detection running on all public-facing hosts. Blocks known-malicious IPs at the edge using crowd-sourced threat intelligence.
  • Cloudflare Turnstile: CAPTCHA challenge on sign-up and other public forms to filter bots and scripted abuse. We do not use Cloudflare for DNS, CDN, or WAF.
  • TLS: All traffic, public and internal, is encrypted with TLS 1.3. HTTPS is enforced with HSTS on all Floynk domains.

4. Encryption

  • In transit: TLS 1.3 for all external and service-to-service traffic.
  • At rest: AES-256 encryption of the primary database, file storage, and backups (handled by Supabase and Hetzner).
  • Application-layer encryption: On top of at-rest encryption, API keys, marketplace credentials, and other sensitive fields are encrypted at the application layer before being written to the database. The decryption keys are held separately from the database so that a database copy on its own is not sufficient to recover these secrets.

5. Identity and access

  • Administrative access: Production access is restricted to a single person (the founder). No shared accounts, no ambient admin credentials.
  • Customer authentication: Delivered by Supabase Auth. Email-and-password with optional MFA (TOTP), Google sign-in, and CAPTCHA on sign-up. LinkedIn sign-in is planned and not yet enabled.
  • Multi-factor authentication: Enforced on every operator account for Supabase, Hetzner, Stripe, Mollie, Google Workspace, GitHub, Cloudflare, Docker Hub, Anthropic, and CloudAMQP.
  • Password storage: Customer passwords are never stored by Floynk directly; Supabase Auth stores them using bcrypt.
  • Session management: Short-lived access tokens with refresh; tokens revoked on password change or on demand.
  • Least privilege in the database: Row-Level Security policies on Supabase scope every query to the authenticated store(s). Customers cannot read each other's data by design.

6. Vulnerability management

  • OpenVAS: Regular authenticated and unauthenticated vulnerability scans against our public-facing infrastructure.
  • CrowdSec telemetry: Continuous detection of scanning and brute-force attempts.
  • Dependency monitoring: Automated dependency alerts (GitHub Dependabot) on the Django backend, Go services, Nuxt frontend, and marketing site.
  • Penetration testing: An independent third-party penetration test has been conducted; no critical findings remained open at close-out. We expect to repeat the exercise periodically.
  • Patching: Operating system and dependency updates are applied on a regular cadence; security-critical updates are applied as soon as is safely possible.

7. Application security

  • Secure SDLC: Code is reviewed before merge. Secrets are managed outside of source control.
  • Static analysis: Linters and type checkers run in CI for Python, Go, and TypeScript/Vue.
  • CSRF, XSS, SQL injection: Protections via Django's built-in defences (CSRF tokens, ORM-parameterised queries, template auto-escaping) and Nuxt's default output escaping. User input is validated at application boundaries.
  • Rate limiting: On authentication endpoints and public APIs, with stricter limits for anonymous traffic.
  • CAPTCHA: Cloudflare Turnstile on sign-up, password reset, and other abuse-prone forms.

8. Monitoring and logging

  • Error tracking: Sentry captures exceptions and performance anomalies across backend, frontend, and Go services. Sentry scrubbing rules strip request bodies and sensitive headers before data leaves our servers.
  • Product analytics: PostHog EU (Frankfurt) tracks feature usage and funnels behind cookie consent.
  • Infrastructure monitoring: Hetzner and Supabase operational dashboards for uptime, resource usage, and query performance.
  • Log retention: Server and application logs are retained for the period needed to operate the service and meet security/debugging needs; access is restricted to authorised personnel.

9. Backups and recovery

We run three independent backup layers so that no single failure — in us or a provider — results in data loss:

  1. Supabase point-in-time recovery (PITR) — continuous, typically sub-minute granularity on managed PostgreSQL.
  2. Hetzner server and volume snapshots — periodic snapshots of the compute layer.
  3. Weekly offline pg_dump — a full logical database dump taken weekly, stored encrypted in Hetzner Object Storage in Germany, separate from the live database.

Restore procedures have been tested. Because we use managed PostgreSQL with PITR, our realistic Recovery Point Objective is well under one hour; our Recovery Time Objective depends on the scope of the incident and is something we work to minimise through automation.

10. AI services and personal data

Floynk uses Anthropic's Claude API for AI-assisted product features. We do not use any other AI vendor. Before any prompt leaves our backend, we apply strict input scrubbing:

  • Removed: names, email addresses, phone numbers, street names, and city.
  • Allowed for geography context only: postal code, house number, country.

We do not fine-tune models with customer data and we do not permit Anthropic to use our prompts for training (opt-out / Zero Data Retention enabled where available). This scrubbing is enforced server-side, not client-side.

11. Incident response

  • Detection: CrowdSec, Sentry, Supabase and Hetzner alerting, and operational dashboards feed a single on-call inbox monitored by the founder.
  • Containment: Compromised credentials are rotated immediately; affected components are isolated via firewall rules or taken out of service.
  • Notification: In the event of a personal data breach, we will notify affected customers without undue delay and within 72 hours of becoming aware, as required by GDPR Article 33. We will also notify the Dutch Autoriteit Persoonsgegevens where the breach is likely to result in risk to individuals' rights and freedoms.
  • Post-incident: We conduct a written root-cause review and track corrective actions.

12. People and operations

  • Team size: Floynk is operated by a single founder with production access. Employee count and access scope are kept deliberately minimal.
  • Confidentiality: Any contractor or future employee with access to customer data is bound by a written confidentiality agreement before access is granted.
  • Training: Given the team size, security awareness is maintained continuously rather than through formal annual training programmes.
  • Device hygiene: Operator devices run full-disk encryption, require MFA, and are kept current on OS and security updates.

13. Sub-processors and vendor management

See our full, current list of sub-processors at /sub-processors. Every sub-processor that processes personal data on our behalf is bound by a Data Processing Agreement. Where sub-processors are outside the EEA, transfers are governed by Standard Contractual Clauses with a Transfer Impact Assessment on file.

14. What we do not (yet) have

In the spirit of honesty, here is what we want customers to know we do not currently have:

  • We are not ISO 27001 certified (we follow its principles).
  • We are not SOC 2 certified as a company (our database provider Supabase is).
  • We do not operate a 24/7 staffed Security Operations Centre.
  • We do not currently have a formal bug-bounty programme (vulnerability reports are welcome — see "Reporting" below).

If any of these are dealbreakers for your organisation, please reach out — we are happy to discuss what compensating assurances we can provide.

15. Reporting a vulnerability

If you believe you have found a security vulnerability in Floynk, please email security@floynk.com. Please give us a reasonable opportunity to investigate and remediate before any public disclosure. We will acknowledge your report promptly and keep you informed of progress.

16. Contact

DigitX B.V. (trading as Floynk) Jonkerbosplein 52, 6534 AB Nijmegen, the Netherlands KvK 82240264

Last updated: 21 April 2026.