Security practices statement · SPDI Rule 8 · Last reviewed 14 July 2026

How we protect health data.

ClinicOps holds medical records, so we treat every patient record as sensitive personal data. This page describes the security controls we have actually built and deployed today — stated factually, without certification claims we don't hold and without describing planned work as already live. Published in support of Rule 8 of the IT (SPDI) Rules, 2011 (reasonable security practices and procedures).

Technical controls

What protects the data

🔐

Encryption at rest

Prescription content and selected clinical-encounter fields get field-level application encryption (AES-256-GCM) wherever a deployment's encryption key is configured.

🗂️

Document storage

Patient-uploaded reports, scans and photos are held on access-controlled server storage, scoped to the owning clinic. They are not individually encrypted by the application today.

🔒

Encryption in transit

All traffic between your browser or WhatsApp and our servers travels over TLS (HTTPS). There is no unencrypted access path.

🏥

Per-clinic isolation

Every clinic is a separate tenant, enforced with PostgreSQL row-level security at the database layer. A startup check refuses to run the application at all if the database role it connects as could bypass that isolation.

📜

Audit logging

Sensitive reads, writes and data exports are written to an append-only audit trail — who did what, when and from where. The application's database role cannot alter or delete audit rows, even with direct SQL access.

🔑

Sessions & access control

Staff sign in to opaque, individually revocable sessions (12-hour lifetime) carried in an HttpOnly cookie — not a long-lived bearer token. Logins are rate-limited with lockout, and staff can enable TOTP two-factor authentication.

🛡️

Capability-based authorization

Every action is checked against the acting user's specific capabilities and record scope, not just their role. A supervised "break glass" path for emergency access is itself logged to the audit trail.

🧾

Immutable clinical records

Once a prescription or clinical encounter is finalized, that version is immutable and carries a SHA-256 integrity hash, so any tampering with the stored record can be detected.

🇮🇳

India hosting & backups

Application and database run in India, with a startup check that enforces this data residency. Encrypted database backups run daily and are also retained in India.

Process controls

How we operate

Incident response per the CERT-In Directions, 2022: we maintain an internal security-incident register with a 6-hour reporting workflow to CERT-In for reportable incidents, a written response runbook, and synchronised system clocks (NTP).
Durable event handling: inbound WhatsApp and payment webhook events are persisted to a durable inbox before they are processed, so a crash, retry or duplicate delivery cannot silently lose or double-process an event.
Log retention: system logs are retained for 180 days within India, per CERT-In requirements.
Least privilege: the application connects to the database as a restricted role; destructive operations on records like audit logs and incident registers are revoked at the database level.
No PHI in logs: application logs are redacted by design — no phone numbers, tokens or patient names.
Documented programme: we maintain a written internal security policy and audit document, reviewed as the product changes.

Honesty section

What we don't claim

Certifications: we align our controls with ISO/IEC 27001 practices and are pursuing certification; we do not currently hold an ISO 27001 certificate, and our security reviews to date are internal. Encryption scope: field-level application encryption today covers prescription content and selected clinical-encounter fields when configured — it does not cover every clinical note field or uploaded document; those rely on access-controlled server storage and the isolation/audit controls above. ABDM: integration is on our roadmap; we make no ABDM certification or empanelment claims today. We will update this page as controls change or formal audits/certifications complete.

Found something?

Reporting a vulnerability

If you believe you've found a security issue in ClinicOps, email support@logicues.com with details. We acknowledge reports promptly, won't take action against good-faith research, and will credit you if you'd like once the issue is fixed.