How we protect your data
We treat security and compliance as engineering work, not paperwork. CardMetCare is DPDP-ready by architecture — multi-tenant from day one, runtime tenant-isolation probe in CI, audit log on every privileged action. Below is how CardMetCare is built — not what we plan to do.
Encryption
Data encrypted in transit (TLS 1.2+). At-rest encryption on the database volume. Backups encrypted with the same key custody.
Authentication
HttpOnly Secure cookies (SameSite=Lax). Account lockout on repeated failed attempts. Per-IP, per-username, AND per-tenant rate limiting via Bucket4j. Password complexity enforced at the API boundary.
Tenant isolation
Every clinical row carries a NOT NULL tenant_id with a foreign-key constraint. Service queries filter by the caller's tenant. A runtime cross-tenant probe asserts isolation against the live backend on every CI run — surfaces real regressions, not just intent.
Audit trail
Every privileged action — login, password change, billing activation, consent grant/withdraw, data correction/erasure, tenant verification decisions — emits a structured audit event. Audit log is append-only, admin-readable, and retained on a class-aware schedule (consent/ABDM events 10 years, security events 7 years, login events 2 years).
DPDP-ready architecture
Patient governance page exposes correction and erasure workflows directly to the data principal. Admin review queue handles incident triage. Audit retention enforces DPDP-aligned retention windows automatically. We use 'DPDP-ready' rather than 'DPDP-certified' until counsel confirms a stronger claim — honest framing matters.
Compliance-friendly
GST-compliant invoices on every paid charge. Indian data residency on request. Regular dependency vulnerability scans in CI. Security headers (CSP, X-Frame-Options, X-Content-Type-Options) enforced at the edge.
Reporting a vulnerability
If you believe you've found a security issue in CardMetCare, please write to security@cardmetcare.com. We acknowledge within 48 hours and respond with a remediation timeline within 5 business days. Please give us reasonable time to fix before any public disclosure.
What's not yet in production
Honest gap list:
- Live ABDM exchange — in sandbox; HFR ID + NABH + GSTIN captured at clinic signup, manual review until ABDM sandbox approval clears.
- SOC 2 Type II audit — planned post-Series A.
- Third-party penetration test — planned post-Series A.
- Multi-region failover — single-region today; multi-region planned with traffic SLOs.
- Offline write queue — patient app caches recent reads for offline viewing (snapshot strategy); writes still require connectivity until the full offline-write queue ships.
- Platform-admin / tenant-admin role split — currently a single ADMIN role; planned separation gates platform-wide views (all tenants, retention controls) from per-tenant administration.
We're transparent about this rather than vague. If any of these gaps matter for your engagement, ask — we'll tell you the timeline.
Trust, but verify
Want a deeper security review for your clinic or insurer engagement? Talk to us.