Security
How we protect your data.
Honest snapshot of where we are today, what's on the roadmap, and how to report a vulnerability if you find one. No marketing theatre — just facts and gaps.Last updated May 2, 2026
The stack
What runs in production.
Hosting & infrastructure
Application runs on Vercel; the Postgres database, authentication, realtime and file storage are Supabase, provisioned in AWS us-east-2 (Ohio). Both providers are SOC 2 + ISO 27001 audited. We don't run our own metal.
Authentication
Sign-in via Supabase Auth — email and password, or Google OAuth through the PKCE authorization-code flow (the iOS app adds Sign in with Apple, natively). Sessions are HTTPS-only, HttpOnly, SameSite cookies. Password hashing is delegated to Supabase Auth; we never see or store a password. SSO (Google Workspace) on the Business plan.
Authorization
Two independent layers. Every mutation runs through one tools layer that checks role (owner / admin / manager / employee) and scopes each query to your organization — there is no second code path that writes data. Underneath, Postgres row-level security is enabled deny-by-default on every table, so the database itself refuses requests that don't come from the application. A database trigger enables it on any table added later, so a new feature cannot ship unprotected by accident.
Data at rest + in transit
All data encrypted at rest (AES-256) and served over TLS. Backups are encrypted and rotated under Supabase's managed policy. Stripe handles payment data — we never see card numbers.
Audit log
Every mutation — create / move / delete shifts, member changes, schedule publishes, billing events — is appended to a Postgres audit log by the same layer that performs the change, so nothing can be written without being recorded. Each entry marks whether a person, a scheduled job, an API key or the AI acted. Retention scales with plan: 90 days on Starter / Core / Pro; 7 years on Business.
Abuse prevention
Rate limits on the public API surface: per IP, per integration key, and per calendar-feed token. Integration keys are org-owned, deny-by-default (each is scoped to an explicit list of allowed operations and capped by a role ceiling) and act as their creator, so offboarding a person revokes their keys. Outbound webhooks are signed and SSRF-gated.
Compliance
Where we stand.
We'd rather under-promise than print a badge we can't back. Here's the honest matrix:
| Framework | Status |
|---|---|
| SOC 2 Type I | Roadmap — targeting Q3 2026 |
| SOC 2 Type II | Roadmap — after Type I |
| GDPR / UK GDPR | Compliant — see privacy policy |
| CCPA | Compliant — see privacy policy |
| HIPAA BAA | Not applicable — Weekwright stores no PHI |
| PCI DSS | Out of scope — Stripe handles all card data |
Subprocessors
Who else touches your data.
Full subprocessor list with purpose and data scope is documented in our privacy policy. Summary: Google Cloud (hosting + database + auth), Vercel (application runtime), Stripe (billing), Anthropic (Claude API for AI features). No ad networks, no analytics brokers.
Incident response
If something goes wrong.
We disclose security incidents to affected customers within 72 hours of confirmed impact, in line with GDPR Article 33 and CCPA requirements. Notification goes by email to organization owners with the scope, root cause, and remediation steps.
We don't bury bad news. If a vulnerability landed in production we'll say so, what data was at risk, and what we changed to prevent recurrence.
Found a vulnerability?
Email security@weekwright.com with the details — repro steps, affected endpoint, suggested severity. We'll acknowledge within one business day, triage within five, and credit you publicly (with consent) once the fix ships. We don't run a paid bug bounty yet but we don't take research for granted.
Please don't test on real customer data. Use a test organization — we'll create one for security research on request.
Have a security or compliance question we missed?
The privacy policy covers data handling. For everything else, ask.