GDPR & privacy
VisitorFlow processes personal data — visitor names, photos, signatures, ID scans, license numbers — on behalf of our customers. This page describes the controls in the product, the role we play under GDPR, and how to meet your data-protection obligations when you deploy VisitorFlow.
Roles
- Customer (you) = data controller. You decide what to collect, why, and for how long.
- VisitorFlow (us) = data processor. We execute your instructions and do not use visitor PII for any other purpose.
- Sub-processors = the vendors listed in our SOC 2 page. All bound by a DPA.
Data Processing Agreement
Our DPA is bundled into the standard MSA — no separate signature required. Standard Contractual Clauses (SCCs) are pre-signed for EEA → US transfers. EU customers can elect to keep visitor PII pinned to eu-central-1 on Professional and Enterprise plans.
Lawful basis
For most check-ins, lawful basis is legitimate interest (premises security) plus the visitor's freely given consent at the kiosk. We surface the controller's privacy notice on every flow:
- The privacy notice text is editable per tenant + per locale (
D-CFG-02). - Consent is recorded with the visit + the version of the notice they agreed to.
- NDAs are versioned; revoking a version does not retroactively affect signed copies.
Data subject rights (ARCO / DSR)
VisitorFlow ships a self-service portal for visitors at /portal on every customer's domain. Visitors authenticate with the email they used at check-in (magic link) and can:
- Access — see every visit, export PDF / JSON.
- Rectify — correct name / company / phone (we keep an audit row, the original is not deleted).
- Erase — request deletion. We anonymise the visit row (keeping aggregates for security analytics) and purge photos / IDs / signatures within 30 days.
- Object — opt out of biometric matching for future visits.
- Portability — JSON export of all their personal data.
DSRs the visitor cannot self-serve (e.g. anonymised aggregates, third-party challenges) are routed to the customer's data-protection officer via D-CFG-02 · Privacy & GDPR with a 30-day SLA.
Retention
Retention is configurable per data category and per location:
- Visit metadata: default 365 days, max 7 years (logistics / customs).
- Photos: default 90 days. Many sites set this to 7 days.
- ID document scans: default 30 days. Many sites set this to 0 (live-only).
- Signatures (for legal NDA): default 7 years (statute of limitations).
- Audit log: 7 years, immutable.
A nightly Inngest job purges anything past its retention window. Purge runs themselves are recorded in the audit log so the controller can prove the action took place.
Encryption
- TLS 1.3 in transit; HSTS preloaded.
- AES-256 at rest (Postgres + R2 storage).
- KMS-wrapped at the column level for the highest-stakes PII (driver licence number, driver licence image URL, visitor photo URL). See
packages/integrations/src/kms.ts. - Per-tenant KMS keys on Professional + Enterprise.
Cross-border transfers
Default region is us-east-1. EU data residency (eu-central-1) is available on Professional and Enterprise. Backups never leave the primary region.
Breach notification
We notify affected customers within 72 hours of confirming a personal-data breach, with an initial scope assessment and the GDPR Art. 33 fields you need for your own notice. You can subscribe to security-notices@visitorflow.com from D-CFG-02.
Children's data
VisitorFlow is not designed for under-16 visitors. If your premises receives minors (school groups, family-day events), enable the “redact name + show only initials on badge” toggle in the kiosk settings, and configure retention for photos to 0 days.
Cookie policy
The marketing site uses essential cookies (auth, CSRF) and product-analytics cookies (PostHog) gated behind a consent banner. The product itself does not set marketing cookies inside any customer-facing surface (kiosk, dashboard, portal).
Privacy questions: privacy@visitorflow.com. Security disclosures: security@visitorflow.com.