Security

Every customer's data is scoped by Postgres Row-Level Security, enforced at the database layer — not only in application code. A bug in our application logic cannot, on its own, leak one customer's data to another.

Submitted numbers are hashed (SHA-256) for logging; raw numbers exist only transiently in a short-lived cache. See our Privacy Policy for the full explanation.

TLS is enforced on every connection to our API and dashboard. There is no plaintext HTTP path.

API keys are stored as salted hashes, never in plaintext. The raw key is shown to you exactly once, at creation.

Access to production customer data is limited to the personnel who need it to operate the Service, on a least-privilege basis. Administrative actions are logged to an audit trail.

We maintain an internal incident response process for suspected security incidents. Where an incident affects your data, we commit to notifying you without undue delay after confirming the incident, consistent with our obligations under the DPDP Act and the IT Act's Reasonable Security Practices Rules.

If you believe you've found a security vulnerability in FILTER, please report it to security@usefilter.io before disclosing it publicly. We will acknowledge reports and work with you on a reasonable disclosure timeline.

Customer data is backed up by our infrastructure providers as part of their managed database offerings. We are formalizing our own documented business continuity plan alongside our broader compliance roadmap below.

We are not SOC 2 or ISO 27001 certified today, and we'd rather say that plainly than leave it ambiguous. What we do have: audit logging on administrative actions, and infrastructure built on Vercel, Supabase, and Upstash, each of which independently maintains SOC 2 Type II compliance — we inherit the security posture of that infrastructure layer. We consider formal certification a Year 2+ decision, triggered by a customer's actual requirement rather than a calendar date, and we'll update this page when that changes.