Your business data, handled like it's ours.
We're a small UK company, not a public cloud. We're also handling your phone, your inbox, and your booking calendar, so we take the security of that data as seriously as you do. Here's how, without the marketing fluff.
One round trip, four guardrails.
Every request from the app or a customer-facing channel travels the same path. Encrypted in flight, encrypted at rest, isolated per customer at the row level, written to a tamper-evident audit trail on the way out.
Customer input
Encrypted in flight
Workhand
Encrypted at rest
Supabase
Per-customer row isolation
Audit log
Tamper-evident chain
Customer input
Encrypted in flight
Workhand
Encrypted at rest
Supabase
Per-customer row isolation
Audit log
Tamper-evident chain
What we do, and what we don't claim to do.
Encryption at rest and in flight
Every customer credential (Gmail, Calendar, Twilio, Retell, Stripe) is encrypted with AES-256-GCM before it touches the database. Per-customer keys, derived from a master key Felix holds in 1Password. TLS 1.3 in transit. We've never had access to your plaintext passwords or tokens.
Least-privilege access by default
Postgres row-level security on every customer-scoped table. An operator can see what's queued; an operator can't decrypt your credentials. Customers can't read each other's anything. We have integration tests proving this, happy to share them on request.
UK GDPR aligned
We're a UK Ltd, your data sits in EEA Supabase, with US sub-processors under Standard Contractual Clauses for the model vendors. The full list of named vendors and the DPA are on the legal pages. DSAR requests handled within 30 days via the in-app form, full export within 7.
Synthetic monitoring + audit log
Every state change writes an immutable audit row (who, what, when, before, after). Every vendor has a health probe running every minute. Three failures in a row pages Felix on his mobile, and you can read the runbook for what happens next.
Backups + recovery
Daily point-in-time backups on a 7-day rolling retention. We've documented restore procedures in the runbooks. The only thing we can't restore for you is your encryption key, that's by design; if we had a copy, an attacker on our side could decrypt your stuff.
Incident response in writing
P0 (data breach) gets a customer-facing email within 4 hours and a status-page update within 30 min. P1 (auth/billing down) gets the same. We commit to honest comms during incidents, even when the cause is us.
Eight services, all under Article 28 contracts.
These are the third parties processing your data on our behalf. Full list with DPA status is on the sub-processors page. We notify you 30 days before adding any new one; you can object.
| Vendor | Purpose | Region |
|---|---|---|
| Supabase | Database + auth + storage | EEA |
| Vercel | App hosting | Global (SCCs) |
| Anthropic | Primary LLM | US (SCCs) |
| OpenAI | Fallback LLM | US (SCCs) |
| Retell | Voice agent runtime | US (SCCs) |
| Twilio | Voice + SMS | EEA via SCCs |
| Resend | Transactional email | EEA via SCCs |
| Stripe | Billing | Global (SCCs) |
We tell you, fast. Honestly.
You can check current state on the status page. If something feels wrong and we haven't flagged it, email felix@workhand.co.uk, he reads every one.
The formal versions.
Everything above, in the language a lawyer needs: