Trust Center

Our complete security posture, compliance status, and the controls we have in place to protect your data. We update this page when our posture changes.

🛡️ Security Architecture

Encryption at Rest
AES-256-GCM for all encrypted vault data. Database storage uses Supabase's underlying AES-256 encryption. Vault data is segregated to a dedicated database, isolated from application data.
Encryption in Transit
TLS 1.3 enforced for all connections (Vercel, Railway, Supabase). HSTS header with 180-day max-age set on all responses.
Key Derivation
Argon2id (RFC 9106) — memory-hard, GPU-resistant. Three tunable presets per user (Fast/Balanced/Maximum). No fallback to PBKDF2.
Zero-Knowledge Vault
Master passwords are never transmitted to or stored on our servers. Vault keys derive client-side; we only see ciphertext. We cannot read your passwords even if compelled.
Envelope Integrity
HMAC-SHA256 over every vault envelope, with domain-separated keys. Server-side tampering of vault metadata, KDF parameters, or escrow wraps is detectable on next unlock.
Recovery Escrow
RSA-OAEP-4096 keypairs generated client-side. Org admins hold the private key on their devices; we hold only the public half. Recovery requires the admin's PEM file.

🔧 Operational Security

Authentication
Bcrypt password hashing. TOTP 2FA available; mandatory for vault access. Persistent failed-login tracking with progressive lockout. JWT bearer tokens with rotation on master password change.
Multi-Admin Vault Recovery
When a platform admin or enterprise admin initiates vault recovery, an independent admin from the target organization must co-sign before the recovery proceeds. No single elevated account can unilaterally extract another organization's plaintext passwords. Co-approval decisions are permanently audit-logged and surfaced to the affected user.
Web Application Firewall
Vercel's built-in DDoS protection. Helmet middleware on the API with strict CSP, X-Frame-Options DENY, and Referrer-Policy strict-origin.
Input Sanitization
Server-side XSS sanitization on all user-supplied content rendered in emails. URL allowlists for outbound calls. DNS rebinding mitigation on URL-fetching endpoints.
Secrets Management
All API keys, database credentials, and signing secrets are stored in Railway environment variables. Never committed to source control. Webhook signatures verified before processing.
Logging & Monitoring
Login attempts persisted to Postgres for forensic review. All admin actions audit-logged with actor, target, timestamp, and IP. Vault access events surfaced to the affected user.
Backup — and What We Won't Claim About Restore
Our managed database provider takes automated backups. Vault data and application data live in separate database projects, so each is backed up independently. We are not claiming a proven restore: we have run no restore drill and publish no RPO or RTO, and we removed the 'point-in-time recovery available' line that used to sit here rather than leave a capability advertised that we have never exercised. Our one tested recovery control is code rollback, which does not undo a database change. See the Security page.

🔒 Privacy & Data Handling

  • Data minimization. We collect only what's needed for the service to function. Email content for AI analysis is opt-in per email and not retained.
  • No data sales. We do not sell or share customer data with third parties for advertising or marketing.
  • Extension permissions, stated up front. The browser extension requests access to all websites — Chrome presents this as “read and change all your data on all websites”. It is needed because the QR-code scanner, AI-image check, breach warning on login forms, password autofill and the optional Content Filter have to be able to run on an arbitrary page. Those general-web features are user-initiated or feature-gated; we do not build, keep or sell a record of where anyone browses. Permission-by-permission breakdown on the Security page.
  • Recovery covenant. Organizations enabling vault recovery sign a contractual covenant restricting use to documented continuity reasons. Misuse constitutes breach of contract.
  • User-visible audit. Every recovery event surfaces to the affected user via in-app notification AND personal email with full context.
  • Right to be forgotten. Account deletion requests honored within 30 days. Encrypted vault data destroyed; audit logs retained per legal requirements.
  • Subprocessors. Parties that process personal data on our behalf: Supabase (database), Hetzner (Mobile Coverage mail relay), Resend (email), Stripe (billing), Twilio (SMS verification codes), Anthropic (AI analysis, opt-in per email, plus the support chat on this site), Google and Microsoft (SSO sign-in), Google Safe Browsing (URL reputation), EmailRep and IPQualityScore (sender/URL reputation), HIBP (breach checking), Tremendous (referral payouts), PostHog (product analytics — cookieless, anonymous, no signed-in student sessions). No subprocessor receives plaintext vault data. Public-registry and threat-feed lookups that receive only a bare domain name or link URL — RDAP/WHOIS, PhishDestroy, abuse.ch — are not subprocessors and are listed under threat intelligence on the Security page instead. Full table there.

📋 Compliance Status

CSA STAR Registry (Level 1)
Listed
Publicly listed via a CAIQ v4 self-assessment mapped to 197 Cloud Controls Matrix controls across 17 domains. View our listing →
SOC 2 Type II
Planned
Targeted for early 2027. Will pursue once we reach scale where the certification is required by enterprise customers.
GDPR
Aligned
Data minimization, right to access, right to erasure, breach notification, lawful basis for processing all in place. We are not currently registered with a supervisory authority.
FERPA
Compatible
No student PII is required. Schools using us with student email accounts retain control of all data. We act as a service provider under FERPA's school official exception.
CIPA
Compatible
Cybersecurity awareness training is one of the components K–12 schools may use to satisfy Children's Internet Protection Act requirements.
HIPAA
Not Covered
ThouShaltNotClick is not designed for processing protected health information. Healthcare organizations should not store PHI in our vault.
Continuous Vulnerability Scanning
Active
Monthly authenticated scans plus continuous emerging-threat monitoring of all public-facing infrastructure via Intruder.io. High-severity findings triaged within 24 hours.

🚨 Incident Response

If you discover a security issue, please email security@thoushaltnotclick.com. We'll acknowledge within 24 hours.

Notification policy. If we determine that a security incident has affected customer data, we'll notify affected customers within 72 hours of confirmation, with a written description of what happened, what data was affected, what we've done in response, and what you should do.

Status page. Live availability and incident history at thoushaltnotclick.com/status.

Past incidents. None to date. We maintain an immutable incident record on the status page; a clean record is meaningful only if we'd actually disclose if anything happened.

📚 Documentation

Security Architecture →Privacy Policy →Terms of Service →Status Page →
What we’re NOT certified for (yet):

We hold a CSA STAR Level 1 (Self-Assessment) listing but do not yet hold SOC 2 Type II, ISO 27001, or other third-party-audited certifications. We’re a small focused team building toward those — and we believe the strongest signal of trust is being explicit about what we have and don’t have, rather than claiming compliance we haven’t earned.

If you’re a diocese or district that requires formal third-party certification before deploying TSNC, reach out to lucas@thoushaltnotclick.com. We’ll discuss timing for SOC 2 and what other accommodations we can make in the interim.

Last updated: April 26, 2026 · Questions? security@thoushaltnotclick.com