Security at SortedResearch

Last updated: 7 August 2026.

This page describes the technical and organizational measures that protect customer and participant data on SortedResearch, operated by The Future Mill LLC. It expands on Annex A of our Data Processing Agreement. Questions or reports: security@sortedresearch.com.

Infrastructure

SortedResearch runs on established cloud providers with mature security programs:

Application hosting: Vercel (US), serving all traffic over HTTPS.
Database and authentication: Supabase (managed Postgres, US).
Off-site backups: encrypted database backups stored with a separate provider (Cloudflare R2), deliberately independent of our primary database vendor.

We operate no physical servers. A full list of the vendors that touch personal data is on our Sub-processors page.

Encryption

In transit: all connections use TLS. HTTP Strict Transport Security (HSTS) is enforced with a two-year max-age including subdomains.
At rest: databases and backups are encrypted at rest by our infrastructure providers.
Passwords: researcher passwords are stored only as secure hashes by Supabase Auth. We never see or store a plain-text password. New passwords are checked against the Have I Been Pwned breached-password corpus before they are accepted.

Tenant isolation: enforced by the database, not just the application

Every customer's data carries an organization identifier, and Postgres Row-Level Security (RLS) policies make the database itself refuse cross-tenant reads and writes. Even if application code had a bug, the database would not return another customer's rows.

Organization roles (admin, editor, viewer) are enforced at the row level.
Participant-facing pages have zero direct database access: all participant reads and writes go through server routes with schema validation, and the anonymous database role has no table access at all.
Billing and entitlement fields (plan, account status) are protected by database triggers so that only the platform owner can change them, so a compromised or buggy client cannot upgrade itself.
An automated integrity check monitors that RLS remains enabled on every table.

Access control

Least privilege: internal access to production data is limited to what is needed to operate the Service, on a need-to-know basis.
Platform administration (the owner console) requires mandatory two-factor authentication (TOTP) at authenticator assurance level 2, and is invisible (returns "not found") to anyone else.
Break-glass recovery for the owner account is rate-limited, never bypasses MFA, and every use is logged.
Researcher accounts are authenticated via Supabase Auth with session cookies scoped by the same row-level security described above.

Application security

Security headers on every response: an enforcing Content-Security-Policy (default-src 'self', object-src 'none', frame-ancestors 'self', form-action 'self'), HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a locked-down Permissions-Policy. The CSP was shipped in report-only mode first, verified against every user flow, then promoted to enforcing.
Bot and abuse protection: Cloudflare Turnstile challenges on signup and participant entry, plus application-level rate limiting.
Input validation: participant and API inputs are validated with strict schemas server-side.
Webhooks (Stripe) are verified by cryptographic signature.
Scheduled jobs (backups, purges, health canaries) require a secret bearer token and fail closed.
Payment card data is handled entirely by Stripe; full card numbers never touch our systems.

Backups and disaster recovery

Hourly, independent backups: a scheduled job exports the full database (schema, data, and roles) every hour and stores it, compressed and encrypted, in a private bucket with a separate provider from our database vendor, so a problem with any single vendor account cannot take out both the database and its backups.
Backups are retained on a 30-day lifecycle.
We maintain a restore-verification script that loads a backup into a scratch database and confirms row counts.
Documented recovery targets: RPO ≤ 1 hour (at most one hour of data loss) and RTO of roughly 1–3 hours (time to restore service).

Monitoring and incident response

Public, live status page and a machine-readable health endpoint.
An internal system-status dashboard tracks backup freshness, error rates, AI spend, RLS integrity, and security configuration.
A weekly automated canary exercises the full stack and emails results.
We maintain an incident-response process for detecting, handling, and notifying security incidents. Customers are notified of personal data breaches affecting their data without undue delay, as committed in our DPA.

Secure development

Changes are version-controlled and reviewed before deployment.
The platform is built on a current, actively patched stack (Next.js, React, Postgres) with dependencies updated regularly.
Verification scripts exercise tenant isolation, authentication, quota, and payment flows against staging before release.

Certifications and roadmap

We are transparent about where our program stands today:

We do not yet hold SOC 2 or ISO 27001 certification.
An independent penetration test is planned as part of our commercial launch.
Single sign-on (SSO/SAML) for Enterprise customers is on the roadmap.

Our security commitments to customers are contractual. See the DPA (including Annex A) and SLA. Enterprise customers can request further security documentation at sales@sortedresearch.com.

Reporting a vulnerability

We welcome good-faith security research. See our Responsible disclosure policy, or write to security@sortedresearch.com.