Security

This page describes how Foyer protects venue and guest data.

Hosting and infrastructure

Foyer runs entirely on Cloudflare's edge network (Workers and Durable Objects). There are no servers of our own to patch or expose — the application runs in Cloudflare's sandboxed runtime, behind Cloudflare's DDoS protection and web application firewall.

Each customer account is its own isolated database. There is no shared, multi-tenant data store: one company's reports, accounts, and settings live in a database that no other company's requests can reach, and every request is routed to its own account before any data is read.

Encryption

In transit: all traffic is served over HTTPS with TLS. This includes the guest report form, the staff dashboard, and every API call.

At rest: all stored data is encrypted at rest on Cloudflare's infrastructure.

In the application: passwords are hashed with bcrypt and are never stored, logged, or emailed in plain text. Push notifications are end-to-end encrypted to each device using the Web Push standard (RFC 8291), so notification content is unreadable to the push relays that carry it.

Access control

Access is role-based and enforced on the server, not just hidden in the interface. Head-office admins, location managers, and maintenance staff each get their own scope: a location manager sees only their own site, a maintenance account sees only the areas it has been granted, and every API route re-checks the caller's role and scope before answering. Additional permissions (such as letting a manager work the review queue) are narrow, individual grants rather than role upgrades.

Account admins can review who has access at any time on the Active users page, see each account's sign-in history, and download the full sign-in log. Support access to a customer's account is read-only — support sessions cannot take actions on cases.

Authentication

Passwords are strength-checked at creation and hashed with bcrypt. Accounts created by an admin start with a temporary password that must be replaced at first sign-in. Sign-in attempts are rate-limited.

Two-factor authentication is supported with authenticator apps (TOTP) and passkeys, including Face ID and Touch ID on supported devices. Sessions are server-side, expire after 7 days, and can be reviewed and revoked individually from Settings.

Data retention and deletion

Your data is retained for as long as the subscription is active. Account admins can export their complete data from Settings at any time — the export is a full copy, not a summary.

When a customer leaves, deletion is scheduled with an explicit, name-confirmed request and completes within 30 days, removing reports, photographs, accounts, and settings. Data-subject requests (access, correction, erasure) are handled together with the customer, who remains the controller of their staff's and guests' data, within one month of the request.

Backups and disaster recovery

Stored data is durably replicated by Cloudflare as part of its Durable Objects storage. Independently of that, account admins can take complete backups from Settings whenever they choose, and those backups can be restored. The export and restore paths are exercised by our automated test suite on every release, so a restore is a tested operation rather than a hopeful one.

Monitoring and logging

The service watches itself from both sides:

• Outside in: independent uptime checks probe the application — including the guest QR scan path end to end — from multiple regions, and alert on failure.
• Inside out: the application sweeps every account's health every 5 minutes and sends a heartbeat to our monitoring provider; if the heartbeat goes silent, an alert fires within about 15 minutes even if everything else looks fine (a dead-man's switch, so a failure that can't report itself still gets reported).

Inside the application, every action on a report — validation, release, notes, resolution, AI decisions — is recorded in that case's history under the name of whoever (or whatever) did it, and sign-ins are logged per account.

Payments

Subscription payments are processed by Stripe. We never see or store full card numbers.

Guest anonymity

Guest reports are anonymous by design — guests are not asked to create an account or provide their name or contact details.

Subprocessors

Foyer processes data on behalf of its customers, and engages the following subprocessors. Because each account is isolated, no subprocessor ever receives a cross-customer dataset — each email, text, or AI call carries only the single report or question that occasioned it.

Switching off your AI assistant keeps your data away from the AI provider entirely.

Compliance

We maintain an internal security control register mapped to the SOC 2 Trust Services Criteria, with written policies covering incident response, breach notification, data-subject requests, and subprocessor management. We do not currently hold a third-party certification and won't claim one here until an independent auditor has issued it.

Under GDPR, Foyer acts as a processor for its customers. Our outbound email is authenticated with SPF, DKIM, and DMARC.

Incident response

Incidents are detected by the monitoring described above and by reports from customers and staff. Every incident has a named lead who owns it from triage through fix and communication; availability incidents are reported as they happen.

If a security incident involves personal data, we notify affected customers within 24 hours of becoming aware, with the facts then known, and follow up within 72 hours with the fuller picture — categories of data involved, likely consequences, and measures taken — so customers can meet their own notification obligations. Every incident ends with a written review.

Report a vulnerability

Email Security@foyerops.com with details of the issue. We aim to acknowledge reports promptly and will keep you updated while we investigate.