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.2 or higher on every connection (TLS 1.3 where supported), with HSTS 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
DDoS protection at the edge. Strict security headers on every API response, including a Content Security Policy, X-Frame-Options DENY and a strict Referrer-Policy.
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
API keys, database credentials and signing secrets are kept in our hosting providers' encrypted secret stores and are never committed to source control. Webhook signatures are verified before processing.
Logging & Monitoring
Login attempts are recorded for forensic review. All admin actions are audit-logged with actor, target, timestamp and IP. Vault access events are surfaced to the affected user.
Backups & Recovery
Automated database backups. Application data and vault data live in separate databases and are backed up independently. Restores have been tested.

🔒 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. 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. Full table on the Security page.

📋 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
Planned
SOC 2 Type I and Type II are planned. The technical controls the audit evaluates are already in place.
GDPR
Aligned
Data minimization, right to access, right to erasure, breach notification, lawful basis for processing all in place.
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 →
Certification roadmap

We hold a CSA STAR Level 1 (Self-Assessment) listing. SOC 2 Type I and Type II are planned.

If you’re a diocese or district that requires formal third-party certification before deploying TSNC, reach out to lucas@thoushaltnotclick.com. We’ll walk you through our controls and what we can provide in the interim.

Last updated: October 12, 2026 · Questions? security@thoushaltnotclick.com