Security

Counsel-review draft. Effective date pending. We have written this honestly: anything not stated here is not a control we currently run.

Foyercal handles calendar tokens, contact data, and the kind of small-but-sensitive operational signal that is uninteresting in isolation and serious at scale. This page describes the controls we run today, in plain language, with the specifics a security-aware buyer would expect to ask for. We are NOT SOC 2, ISO 27001, or HIPAA certified, and we say so explicitly here. We expect to pursue SOC 2 once revenue justifies the audit cost; we will publish the report through normal channels when the audit is complete.

Encryption in transit

All traffic to Foyercal runs over TLS 1.2 or higher. Older protocols are refused. HSTS is published at the apex domain so browsers that have visited us before refuse to downgrade. Certificates are managed by our hosting provider (Vercel) and renewed automatically with short validity windows.

Encryption at rest

The Postgres database is encrypted at rest by the storage layer (Supabase, with the database located in eu-west-3 / Paris). Sensitive credentials — OAuth refresh tokens for connected calendar providers, two-factor secrets, anything we treat as a credential — are wrapped in an additional application-layer envelope using AES-256-GCM with versioned keys (current version: ENCRYPTION_KEY_V1). Key versioning lets us rotate without re-encrypting historical rows in a single migration; old key versions remain available to decrypt until their data is rewritten on next access.

Authentication

You can sign in with Google OAuth, Microsoft OAuth, an email address and password, or a one-time magic link. Passwords are required to be at least twelve characters and to include letters, digits, and a symbol. Password hashes use bcrypt with a cost factor of twelve and a per-hash salt. We plan to upgrade to a memory-hard algorithm (argon2id or similar) before public launch; that work is on the roadmap.

Two-factor authentication using time-based one-time passwords (TOTP) is available on every account. When TOTP is enabled, the email/password flow is hard-blocked at the auth layer and sign-in must go through the TOTP-grant flow that requires both factors. Recovery codes are issued once and stored hashed; we cannot recover them for you. Magic-link grants are denied for TOTP-enabled users, as a defense-in-depth measure.

Sessions and rate limiting

Sessions are managed by Auth.js. The browser holds a signed JWT; the authoritative session record lives in Upstash Redis with a thirty-day rolling TTL. Every request validates the JWT against the Redis record so a server-side revocation (sign-out-all-devices, password change, account deletion) takes effect immediately, regardless of any cached JWT.

Authentication endpoints (sign in, sign up, password change, two-factor verification, magic-link consumption) are rate-limited per IP and per account. Repeated failures trigger exponential back-off and account-level audit log entries. Magic-link tokens are single-use, fifteen-minute-TTL JWTs denylisted in Redis on first use.

Audit logging

Every member action that changes state (invitations, role changes, billing actions, integration changes, calendar connections, booking edits, exports, support-access events) writes an audit log entry. Each entry records the actor, the time, the IP address, the action, and the parameters of the action. Audit logs are visible inside the app to organization admins and exportable in CSV and JSON. They are append-only at the application layer.

Audit logs are retained while the organization is active. We do not currently auto-expire audit entries; a maximum retention is on the roadmap.

Tenant isolation

Foyercal is multi-tenant. Every row in every table that holds customer data carries an organization identifier. Queries are scoped by organization at the application layer through a single guard function that every request must pass through. Cross-tenant reads and writes are rejected by that guard function and asserted in our test suite.

We do notcurrently enforce row-level security at the Postgres layer. Defense-in-depth at the database layer using Postgres RLS is on the roadmap; for now the boundary is enforced exclusively at the application layer. We are honest about this because it is a meaningful difference from a typical “we run RLS” claim.

Access control

Inside an organization, Foyercal supports role-based access: Founder, Founder Staff, Org Owner (rendered as “Admin” in the product), Org Admin, and Member, with custom roles on higher tiers. Members see only the calendars, bookings, and integrations they are assigned. Privileged actions (billing, member removal, integration revocation) are reserved for owners and admins by default.

The Founder role and Founder Staff role are configured through environment variables (FOUNDER_EMAILS and FOUNDER_STAFF_EMAILS) and cannot be elevated into from the UI. They permit cross-org support access via an explicit per-tenant opt-in and a magic-link confirmation. An in-app banner is visible whenever an operator has assumed support access. Hard-deny operations (transfer of ownership, account deletion, billing changes, decryption of OAuth tokens) are blocked under impersonation.

On the operations side, access to production infrastructure follows the principle of least privilege. Production database access is gated through Supabase’s administrative controls and limited to the founder team; every privileged session is logged by the provider.

Data minimization

We collect what we need and not more. Booker IP addresses are captured on confirmed bookings and on email-lead sign-ups, and are anonymized after the configured retention window (default: twelve months) by a daily cron at 03:00 UTC. We do not run third-party advertising trackers or cross-site analytics. We do not store the title, location, attendees, or body of personal calendar events; the calendar integration reads only free/busy time.

Backups and disaster recovery

Database backups are managed by Supabase under their default retention for our plan tier (currently seven days of point-in-time recovery). Backups are encrypted by the provider. We test restore against a non-production project on an ad-hoc cadence; a formal quarterly DR exercise is on the roadmap.

Vercel deployments are immutable; rollback to the previous green build is one-click. Static assets (uploaded brand logos, avatars) are stored in Vercel Blob and the underlying object store; their durability and retention follow the provider’s defaults.

Vulnerability management

Dependencies are tracked through GitHub’s native advisories. High and critical CVEs are triaged within one business day. Static analysis runs on every pull request; secret scanning runs on every push. Pull requests require a passing CI suite (855+ unit and integration tests at last count) before merge.

Incident response

We maintain a written incident response plan with named responders, severity definitions, and a communication template. On confirmed unauthorized access to customer personal data, we commit to notifying affected customers within seventy-two hours of confirmation, with the facts we have at that time and an undertaking to update as the investigation continues.

Routine outages (degraded performance, third-party provider problems, deployment incidents) are posted at foyercal.com/status.

Responsible disclosure

If you believe you have found a security issue in Foyercal, please tell us at support@foyercal.com with “security” in the subject line. Mail flagged that way is triaged out-of-band by the founder team rather than by general support. We will provision a dedicated security@ alias before public launch; until then, the support inbox is the right channel.

We commit to acknowledging your report within two business days, keeping you informed as we investigate, and crediting you publicly when a fix ships, unless you ask to remain anonymous. We ask in return that you give us a reasonable window to fix the issue before disclosing it, that you do not access or modify customer data beyond what is necessary to demonstrate the issue, and that you avoid degrading the service for other users while testing.

Out of scope for responsible disclosure: denial-of-service testing, social engineering of staff or customers, physical attacks against vendors, and anything that would expose us to lawful action by a regulator. A formal bug bounty program is on the roadmap.

Compliance posture

We are notSOC 2, ISO 27001, or HIPAA certified. We do not currently offer a Business Associate Agreement; do not use Foyercal in a workflow that involves Protected Health Information. We are GDPR-friendly: account holders can self-serve a data export and an Article 17 erasure request from inside the app, and we maintain a documented Data Processing Agreement available on request to paying customers. We accept the European Commission’s 2021 Standard Contractual Clauses for international transfers and the UK Addendum for UK transfers.

Effective date: pending counsel review. Draft prepared by the Foyercal team for legal review.