Security at Jeanus

Jeanus is a UK-operated B2B CRM. Customer data lives in encrypted Postgres in the EU. Every API call is filtered by tenant ID at the application layer and again by Row Level Security at the database layer, with a Playwright regression test that runs against the live deployment to catch leaks. We use industry-standard practices: TLS in transit, encryption at rest, role-based access, mandatory MFA for staff accounts, daily backups, and 72-hour breach notification. We are honest about what we have not yet done (formal pen test, SOC 2 audit) and we will earn those certifications when our first enterprise customer needs them.

• Database + authentication: Supabase (managed Postgres) in the UK (London, AWS eu-west-2). Primary project ID is fixed; failover and read replicas stay inside the UK / EU region.
• Application hosting: Vercel. Primary serverless functions run in lhr1 (London). Static assets are served from the global edge CDN.
• Transactional email: Resend (US-hosted; transmits recipient address + email body only).
• AI features: Anthropic Claude API (US). Prompts are request-only; Anthropic do not train on customer API traffic per their published policy.
• Billing: Stripe (EU/Ireland for European customers).

Full subprocessor detail, including DPAs, lives on the subprocessors page.

• In transit: TLS 1.2 or higher on every request to jeanus.app, with HTTPS enforced and HSTS set via Vercel.
• At rest: Supabase encrypts the database volume with AES-256. Daily backup snapshots are encrypted to the same standard.
• Secrets: API keys, the Supabase service role key, and the Anthropic key live as Vercel environment variables - not in the repo, not in client bundles.

Jeanus is multi-tenant. Every tenant's data is separated by three independent layers, so a bug in any one layer does not leak across tenants.

1. Application-level tenant filter. Every query that reads or writes user data resolves the current user's tenant_id from the session and applies .eq('tenant_id', tenantId) before the query runs. This is enforced through shared helpers (lib/current-rep.ts, lib/tenant-config.ts and per-domain libs) so individual route authors cannot accidentally skip it.
2. Database Row Level Security (RLS).Supabase RLS policies are enabled on every customer-data table. The policies bind the query to the current user's tenant via Supabase auth claims, so even if application code were to forget the filter, the database would still refuse to return another tenant's rows.
3. Automated regression test. A Playwright suite (tests/security/tenant-isolation.spec.ts) logs into the live deployment as each of our five demo tenants in turn, crawls every customer-facing page, and asserts that no leak tokens from any other tenant appear in the rendered HTML or the JSON the page consumed. The test runs against production and gates new releases.

• Passwords: managed by Supabase Auth. Bcrypt-hashed. Minimum 8 characters at signup.
• Multi-factor authentication (MFA): TOTP-based MFA is supported for all accounts and enrolment is available at /login/enroll-mfa. We require MFA on staff (admin) accounts and recommend it for all rep users.
• Session management: first-party HTTP-only cookies. Idle-timeout enforced by a client-side SessionExpiryGuard.
• Role-based access (inside a tenant): admin, manager, rep, viewer. Management-only pages are guarded by getStaffScope() server-side; they are not just hidden in the UI.
• Service-role access: the Supabase service role key (which bypasses RLS) is used only inside server-side API routes that need cross-row work and is never exposed to the browser. Service-role calls are logged.

• Supabase takes a daily encrypted backup of the database, retained for 30 days.
• Point-in-time recovery is available on the underlying Postgres instance for the retention window.
• We test restore-from-backup informally; a documented restore drill is on the roadmap before our first enterprise customer.

• Authenticated user actions inside the CRM (page navigations, mutations, sign-offs) are recorded in the activities table with actor, target, timestamp, and IP.
• Tenant admins can view their tenant's slice of the audit log. We can supply a fuller export on request as part of a data subject access request.
• The tenant-isolation regression test captures every cross-tenant attempt and fails the build if one renders. In production, queries that fall through to RLS-rejection are logged with the requesting user and the requested resource.

• If we detect or are notified of a personal-data breach that is likely to result in risk to your rights, we will notify affected customers within 72 hours of becoming aware, in line with UK GDPR Article 33.
• Notifications include the nature of the breach, the categories of data and approximate number of records, the likely consequences, and the steps we are taking.
• Our response playbook covers: isolate, assess scope, preserve evidence, notify, remediate, retrospect.
• Report a suspected vulnerability or breach to security@pixelandshovel.co.uk. We aim to acknowledge within one working day.

Every subprocessor we use publishes a Data Processing Agreement and a security overview. We only engage subprocessors who are operating to recognised industry standards (Vercel, Supabase, Anthropic, Stripe and Resend all hold one or more of SOC 2 Type II, ISO 27001, or equivalent independent attestations - check each vendor's live trust page for current scope).

See the subprocessors pagefor the current list and links to each vendor's DPA.

We have not yet commissioned a third-party penetration test or a formal SOC 2 / ISO 27001 audit. We are a small UK studio (Pixel & Shovel) and we plan to commission a pen test ahead of our first enterprise contract. We would rather tell you that honestly than claim a posture we have not earned.

If you need a pen test report or an audit attestation as part of your procurement process, talk to us and we will scope one against the contract value.

We welcome reports from independent researchers. Email security@pixelandshovel.co.uk with:

• The URL or component affected.
• Steps to reproduce.
• The impact you observed.
• Any proof-of-concept payload (keep it minimal; do not exfiltrate customer data).

We will acknowledge within one working day, keep you informed, and credit you in the fix notes if you would like. We do not run a paid bounty programme yet, but we treat researchers as collaborators, not adversaries.

Some of your security is in your hands:

• Use strong, unique passwords and turn on MFA for every user.
• Off-board leavers promptly - revoke their access in /settings/team.
• Don't share login credentials. Add a new user instead; unlimited users on every plan.
• Tell us at security@pixelandshovel.co.uk if you notice anything unusual.

We update this page when our practices change. Material changes are summarised in our release notes and announced to tenant admins by email.