Security summary

The short version: we hold very little, on purpose.

How it's built

One application on Cloudflare Workers, with the database and the cache in the same platform. There are no servers of ours to patch and no open ports.
TLS 1.2 or better, everywhere, with strict transport security.
A strict content security policy with no inline script, checked automatically on every change. Third-party origins are named one at a time and only on the pages that need them.
Two domains. The one people respond on serves nothing else at all, which is what stops a shared link ever reaching an account page.

A link we email, always. It expires and works once. People may also add a password (at least 12 characters, stored as a slow keyed hash), two-step verification, a passkey, Google or Discord. None of them is required, and none is stored in a form a copy of our database could use to sign in.
Session tokens are hashed at rest and scoped to one domain.
API keys are hashed, shown once, scoped, rate limited and revocable.
Credentials we hold on somebody's behalf, such as a calendar connection or a chat bot, are encrypted with a key that can be rotated, and thrown away the moment the connection is removed.

Names, and email addresses where somebody chose to give one.
What somebody said about when they're free.
Busy intervals from connected calendars: a start and an end and nothing else, so no title, location or guest list. There is a test that feeds a calendar full of titles through and asserts none of them survives.
No payment details. Paddle is the merchant of record and no card number ever touches us.
No tracking, no advertising, no third-party analytics on any page anybody shares.

A breach register, and notification to affected people and to the regulator within 72 hours of us knowing.
Report a vulnerability to support@whenabouts.me. We'll acknowledge within two working days. We won't threaten anybody who tells us about a problem in good faith.

The three things a questionnaire always asks about.

Assurance. Our security rests on the architecture above and on a test suite that runs on every change, which anyone can verify against what these pages say. Tell us which certification your process requires and we'll tell you where we stand on it today.
Testing. The application is tested continuously by its own suite, and we arrange an independent penetration test where a buyer's process calls for one.
Sign-in. A link we email, on every plan, and optionally a password, two-step verification, a passkey, Google or Discord. If your organization runs on SAML or SCIM, talk to us and we'll tell you exactly where that stands.