Security
01Security posture
Findry is a small, opinionated product. The security posture reflects that: we don't over-engineer, but we don't cut corners on the things that matter. Your workspace content — hypotheses, bets, outcomes, and everything you write — is encrypted at rest and in transit, access-controlled at the row level, and never used to train models. This page describes how.
We are a pre-Series-A product. We won't pretend to have the security programme of a hundred-person company. What we do have: sensible defaults from day one, a hosted stack (Vercel + Supabase) that handles the heavy lifting, and a commitment to transparency about what we have and what we don't yet.
02Infrastructure
Hosting
The application runs on Vercel (compute) and Supabase (database, auth, storage). Both are SOC 2 Type II certified. We inherit their physical security, network isolation, and availability guarantees.
Regions
EU workspaces are stored and processed in the EU (Frankfurt). US workspaces default to us-east-1. You choose your region at workspace creation; it cannot be changed after the fact because data never moves cross-region.
Network
All inbound traffic is TLS-terminated at the edge. The database is not publicly reachable — the application server communicates with it over a private network via Supabase's connection pooler. No database port is exposed to the internet.
03Encryption
- In transit. TLS 1.3 minimum, enforced at the CDN layer. HTTP requests are redirected to HTTPS; HSTS is set with a one-year max-age.
- At rest.AES-256 via Supabase's managed encryption. Applies to all workspace content, integration tokens, and uploaded attachments.
- Backups. Supabase automated daily backups are encrypted with the same key material. Rolling 30-day retention. Deletion from production propagates to backups within 35 days.
- Integration tokens. OAuth tokens for connected tools (PostHog, Linear, Slack, etc.) are stored encrypted and never exposed in API responses. They are used server-side only.
04Authentication & access
Sign-in
Findry uses passwordless magic-link email and Google OAuth. There are no passwords to leak. Magic links expire after 15 minutes and are single-use.
Sessions
Sessions are stored in Supabase Auth, rotated on each use, and expire after 7 days of inactivity. Signing out from one device invalidates that session only; a “sign out everywhere” option revokes all sessions.
Row-level security
Every table in the Findry database has Supabase Row Level Security enabled. A query from workspace A cannot return rows belonging to workspace B at the database level — not just the application level. Multi-tenancy isolation is enforced in the data layer.
Internal access
Paulo (the sole employee) has read access to the database for debugging purposes. He does not have write access to production data outside of normal application flows. Direct database writes for support purposes require a logged reason. This policy will be formalised into a proper access-log requirement as the team grows.
Pulse share links
Pulse shares are protected by a hashed passcode embedded in the URL. The passcode is not stored in plaintext. Anyone with the link can view the share; there is no additional login. Treat Pulse share links like you would a shared Google Doc with link-based access.
05Application security
- Input sanitisation. All user content is sanitised before storage and escaped on render. We use parameterised queries throughout; there are no raw SQL string concatenations.
- CSP. A Content Security Policy header is set on all responses, blocking inline script injection and restricting third-party resource origins.
- CSRF. State-changing requests require authentication tokens that are not accessible to cross-origin pages.
- Dependency scanning.
pnpm auditruns in CI on every pull request. High and critical advisories block the merge. - Secrets management. All secrets live in Vercel environment variables, not in the repository. The repository is private. There are no hardcoded credentials anywhere in the codebase.
06Monitoring & incidents
Error monitoring
Runtime errors are captured by Sentry with PII scrubbing enabled. Error events do not contain workspace content — only stack traces and anonymised context. Paulo is paged for severity P0/P1 events.
Availability
Uptime is monitored via Vercel's built-in checks plus an external synthetic monitor. A public status page is on the roadmap for post-launch.
Incident response
In the event of a confirmed breach or data exposure, affected workspaces will be notified within 72 hours — meeting the GDPR notification window. The notification will describe what was exposed, how, and what steps were taken. We will not send vague “we take your security seriously” notices.
07Compliance roadmap
- SOC 2 Type II. In scope for the Enterprise tier. We are collecting audit evidence from day one, targeting a formal audit in Q1 2027.
- GDPR. Implemented: data minimisation, lawful basis documentation, subject-access requests in-app, 72-hour breach window. Pending: Data Processing Agreement template for enterprise customers.
- CCPA. Implemented: no data sale, opt-out of telemetry, right to delete in-app.
- Penetration testing. External pen tests scheduled quarterly beginning Q3 2026 (first test at public launch).
If your organisation requires a specific compliance artefact that isn't listed here, write to security@findry.io. We'll tell you honestly whether we have it or when we expect to.
08Responsible disclosure
If you discover a security vulnerability in Findry, please report it to security@findry.io before disclosing it publicly. We will:
- Acknowledge your report within one business day.
- Confirm whether we can reproduce the issue within five business days.
- Keep you informed as we work on a fix.
- Credit you in the release notes if you'd like.
We do not currently operate a bug bounty programme. We will not take legal action against good-faith security researchers.
This security page is a working draft. It reflects our actual practices as of the date above. A reviewed version will ship before public launch.