Your customers’ data.
Treated like it’s ours.
The plain-English version of how we protect what you store with us. No compliance theatre. No “bank-grade security” without saying what that means. Here’s exactly what we do and where your data lives.
Questions procurement teams ask us, answered upfront.
If you’ve been sent to this page by a buyer’s IT team, these are the rows they’re scanning for first.
Built for isolation and speed.
TatvaCRM runs on a managed PostgreSQL cluster. Every customer workspace sits in its own isolated database schema — your contacts, deals and notes never share a table with another customer’s records. That isolation happens at the database level, not at the application level. If there’s ever a query bug on our end, it physically cannot return another tenant’s data.
Default region: Singapore. The default cluster sits in a Southeast Asia region that keeps round-trip time from major Indian cities consistently low (typically 60–90 ms). For most SMB and DSA workloads this is faster than self-hosting in India.
India data residency on Business tier. If your compliance team, an RBI-regulated customer, or your own NBFC/insurance policy requires data to stay inside India (Mumbai region), we provision a dedicated India-resident cluster on the Business tier. Schema isolation, encryption and backup posture are identical — only the geography changes.
Regulatory clarity. TatvaCRM is aligned with the Indian DPDP Act 2023 and follows GDPR-equivalent data protection standards. Cross-border transfer (where applicable) is documented in our Data Processing Addendum.
Honest about fit. If you need country-of-origin data residency from day one on the free tier, or you’re bound by a sector regulation we can’t meet, we’ll tell you upfront. Email us and we’ll walk you through the options — including cases where TatvaCRM isn’t the right fit.
Your data and theirs never meet.
Most multi-tenant SaaS products isolate customers with a tenant_id column — every row in every table carries a customer ID, and the application code is responsible for filtering by it. That approach is cheap. It’s also one missed WHERE clause away from leaking one customer’s data into another’s dashboard.
TatvaCRM uses schema-per-tenant isolation instead. When you sign up, we create a new PostgreSQL schema inside our Neon cluster — a completely separate set of tables, owned by a dedicated database role, with no ability to read from any other schema. Your contacts table and your neighbour’s contacts table are different physical objects.
Even a catastrophic application bug can’t return rows from the wrong tenant, because the connection the bug is running on doesn’t have permission to read them.
Each schema is a separate database role · no cross-schema reads
The boring stuff done properly.
No headline-grabbing security without the unglamorous basics behind it. Here’s what we actually do day to day.
Daily, retained 30 days
Full database snapshots every 24 hours, stored in a separate region. Point-in-time recovery to any moment in the last seven days. Backup restoration is a drill we run, not a plan we wrote down.
Least privilege, always
Only two engineers have production database access. All access is logged. Application code connects using per-tenant roles that can’t touch other tenants. No shared admin accounts. No long-lived database passwords.
Uptime & anomaly alerts
Continuous uptime monitoring from three geographies. Error rate alerts that page the on-call engineer. Anomalous query patterns flagged automatically — we notice slow leaks long before they become incidents.
Patched, not pinned
Automated weekly dependency scans. Critical security patches applied within 48 hours of disclosure. No “we’ll upgrade it next quarter” — old libraries are how breaches happen.
Who else touches your data.
We use a small set of vetted infrastructure providers for hosting, storage, email and CDN. The full list — with purpose, data category and region for each — is published on our sub-processors page and referenced in our DPA. We notify customers 30 days before adding or changing any provider.
Found a bug? We want to hear it.
If you’ve found a security issue in TatvaCRM — anything from a misconfigured header to something more serious — please tell us before you tell the world.
Email support@tatvacrm.com with “security” in the subject line. A human replies within one working day. We do not have a formal bug bounty programme yet, but we acknowledge every valid report publicly (with your permission) and we’ll work with you on a reasonable disclosure timeline.
We will not pursue legal action against researchers acting in good faith.
- Give us reasonable time to fix before disclosing publicly
- Don’t access or modify other customers’ data
- Don’t run DDoS or brute force tests against production
- Report one issue per email — easier to track
Need a DPA, security questionnaire, or a call with the founder?
We answer every security and compliance question within one working day.