Security & Trust
Encrypted. India-resident. Audit-logged.
When you handle MLC paperwork and lakhs of patient records, trust is the product. Here are the four things that matter.
Four pillars
Defence in depth, not in slides.
No buzzwords. The technical detail your CISO or DPO will actually ask for.
Encryption
AES-256 + TLS 1.3
Every PHI column encrypted at rest with rotating keys. End-to-end TLS 1.3 in transit. A stolen disk image or a packet capture is ciphertext, not patient data.
Tenant isolation
Row-Level Security
PostgreSQL RLS enforces hospital tenancy at the database — not the application. A misconfigured query physically cannot return another hospital's rows.
DPDP 2023
India data residency
All patient data lives in Mumbai (ap-south-1) and Hyderabad AWS regions. No replication outside India. DPDP Act 2023 compliant by architecture.
WORM audit log
Tamper-evident audit
Every read, write, export and login is hash-chained into an append-only ledger. The MLC court order trail is reproducible six years later, byte-for-byte.
Compliance
The badges that matter in India.
DPDP Act 2023
India data protection — by architecture, not policy
ISO 27001:2022
Information security management — audited annually
NABH-ready
Documentation, traceability and quality indicators built in
ABDM / NHA
ABDM Health ID linking + NHA-aligned consent artefacts
CERT-In aligned
Quarterly third-party penetration tests
Daily backups
Automated daily encrypted backups · 30-day retention · cross-AZ replication
Our promises to you
What we will do, in writing.
Customer notice within 1 hour of detecting any incident affecting your data
Formal DPDP Section 8(6) disclosure within 72 hours if PHI is impacted
Full data export in FHIR R4 / CSV / PDF-A within 7 days of contract end
Quarterly pen-test reports & SBOM available under NDA to enterprise prospects
Compliance matrix
Standard by standard, where MyEMR stands.
We are honest about the difference between "ready" (the platform satisfies the controls) and "certified" (the certificate is in our hands). Both are tracked below.
Standard
Status
Region
What it covers
DPDP Act 2023
Compliant
India
Decomposed consent, India data residency, breach reporting workflow, DPO function, patient export & deletion API.
NABH Digital Health Standards
Ready
India
All 12 NABH digital readiness checkpoints satisfied at the platform level. Hospital certification is the hospital's process.
ISO 27001:2022
Ready (audit Q3 2026)
Global
Information security management system controls implemented. External audit scheduled for Q3 2026.
ISO 27701
Roadmap (2027)
Global
Privacy information management extension to 27001. Tracked as roadmap item once 27001 is closed.
SOC 2 Type II
Not pursued
US
We are an India-first product; we do not pursue a US-centric audit we cannot enforce in India. Re-evaluated annually.
HIPAA technical safeguards
Architecturally aligned
US
Audit log, RLS, encryption, access control align with HIPAA technical safeguards. No US BAA is signed; HIPAA is a US statute.
ABDM (Ayushman Bharat Digital Mission)
HIP-compliant
India
Registered Health Information Provider. ABHA-linked records, consent manager interoperability, FHIR R4 exchange.
CERT-In incident reporting
Aware
India
Incident reporting playbook aligned with CERT-In's 6-hour reporting requirement for in-scope incidents.
GST e-invoicing
Compliant
India
Outbound invoices include IRN/QR per CBIC schema. Reverse charge and B2B/B2C splits handled in the billing module.
GDPR
Not in scope
EU
We do not market to or store data of EU data subjects. If a customer's edge case requires GDPR posture, it's a custom scope.
Encryption, end to end
What "encrypted" actually means in MyEMR.
"We use AES-256" is the cheapest sentence in healthcare marketing. The interesting questions are about key management, rotation cadence, scope of coverage and the threat model the encryption protects against. Here's what we do, line by line.
256
AES bits at rest
1.3
TLS minimum in transit
90d
Key rotation cadence
100%
PHI columns covered
At rest — every PHI column, not the whole disk
We don't rely solely on disk-level encryption (which doesn't help against a misbehaving database client). Sensitive columns — name, phone, address, diagnoses, clinical notes — are encrypted at the application layer with AWS KMS-managed keys. A read query against a leaked database without the KMS key returns ciphertext.
Key rotation every 90 days
Data Encryption Keys are rotated automatically on a 90-day schedule, with envelope encryption so old ciphertext remains readable. Master keys are managed by AWS KMS; key access is logged in CloudTrail and reviewed quarterly.
In transit — TLS 1.3, HSTS, no fallback
TLS 1.3 only between the browser/app and our edge; TLS 1.2 with strong ciphers between internal services. HSTS preloaded. We don't accept HTTP, even for redirects. No SSLv3, no TLS 1.0/1.1.
Patient and staff passwords
Argon2id with per-user salt and tuned memory/iteration cost. Passwords are never stored or logged in plaintext, including in error traces. Password reset uses single-use tokens with 15-minute expiry.
Document storage
Patient documents, reports and prescriptions in S3 are encrypted with SSE-KMS using per-tenant KMS keys. A leaked S3 bucket policy without KMS access doesn't expose document content. Pre-signed URLs are short-lived (5 minutes default).
Field-level decryption only on demand
Encrypted columns are decrypted in the application only when the request has a legitimate purpose (authenticated user + role check + audit log entry). Bulk decryption (e.g. an analytics job) requires explicit ops approval and is logged separately.
What encryption doesn't protect against
Encryption does not stop an authenticated user with the right role from seeing data they shouldn't — that's what row-level security and audit logs are for. We are explicit about this in our threat model so nobody confuses encryption with access control.
Backup & disaster recovery
The hospital does not stop. Neither does the data.
RTO and RPO targets are real numbers in our SLA, not marketing aspirations. We test the restore quarterly — because backups you have not restored are not backups.
RPO ≤ 5 minutes
Point-in-time recovery via continuous WAL streaming. In the worst case we lose the last 5 minutes of writes, not the last 24 hours.
RTO ≤ 60 minutes
Full database failover to the warm standby in another availability zone completes in under an hour, including DNS propagation.
Daily snapshots, 35-day retention
Full database snapshots taken every 24 hours; retained for 35 days. Snapshots are encrypted with a separate KMS key for blast-radius reasons.
Cross-AZ standby
Warm standby in a different AWS availability zone within the Mumbai region. Automatic failover on primary-zone outage.
Quarterly restore drills
Every quarter we restore the previous month's snapshot to an isolated environment, verify integrity, and run smoke tests. Drill reports available on request.
Document & file backup
S3 with cross-region replication (within India) and versioning enabled. Accidental deletes are recoverable for 90 days.
Backup encryption
All backups encrypted at rest with a dedicated KMS key, separate from the primary database key. A compromised primary key does not decrypt backups.
Backup failure alerting
If a daily snapshot fails, on-call is paged within 5 minutes. We do not discover a missing backup the day we need to restore it.
Incident response
When something goes wrong. The clock that's already running.
The DPDP Act gives us 72 hours to notify the regulator and affected individuals once we are aware of a personal data breach. To hit that deadline you need a process that starts before the breach, not after. Ours is below.
Step 1
00:00
Detection
Automated alerts on anomalous read patterns (bulk reads, after-hours access by non-clinical roles, unusual IP geographies). Manual reports via security@advayan.com or in-app 'report a concern' button.
Step 2
00:15
Triage
On-call security engineer pages within 15 minutes of an alert. Classifies severity — none, low, medium, high, critical — using a published rubric that's deliberately conservative.
Step 3
00:30
Containment
If active exploitation suspected — rotate the relevant credentials, revoke sessions, block the IPs, isolate the affected node. The goal in this window is to stop the bleed, not to fix the cause.
Step 4
01:00
Customer notification (high/critical only)
Named contacts at the affected hospital(s) are notified by phone + email within an hour of confirmed high or critical severity. No 'wait until we have all the facts' silence.
Step 5
06:00
CERT-In notification (if in scope)
If the incident is in CERT-In's reportable scope (large-scale data exfiltration, system compromise), the 6-hour reporting clock is hit.
Step 6
24:00
Initial root-cause analysis
First written RCA shared with affected customers within 24 hours of containment. Acknowledges what is known, what is not yet known, and what's being done.
Step 7
72:00
DPDP Data Protection Board notification (if PII breach)
If the incident involves personal data of Indian patients, the DPB and affected individuals are notified within 72 hours, with the detail required by the Act.
Step 8
30 days
Closure report and lessons learned
Final post-mortem published to affected customers within 30 days. Includes timeline, root cause, what we changed, and what we recommend customers verify on their side.
External audit cadence
We pay strangers to break it.
Annual penetration test by a CERT-In empanelled auditor. Quarterly automated DAST scans. Continuous SAST in the CI pipeline. The findings — including the embarrassing ones — drive the next quarter's security backlog.
Last full pen-test: November 2025, CERT-In empanelled vendor
Critical findings: 0 · High: 0 · Medium: 2 (both closed within 14 days)
Next scheduled pen-test: November 2026
Bug bounty: invite-only programme, scope and payouts on request
Audit document pack
Architecture overview (PDF)
Single-page system diagram + data-flow.
Last pen-test executive summary
Redacted; full report under NDA.
ISO 27001 control mapping
Annex A control responses for due diligence.
DPDP compliance brief
Consent, residency, breach, DPO.
NABH digital readiness mapping
12-point checklist with platform responses.
Standard MSA + DPA
Mutual NDA; data-processor agreement template.
Security FAQ
The questions CISOs and DPOs ask us.
Who can see my hospital's data inside MyEMR's team?
Production access is restricted to a named on-call engineering team — currently five people — who undergo annual background checks. Every production access is logged, alerted, and reviewed monthly. We do not run analytics on customer PHI. Engineering uses an anonymised sample dataset for development.
Where exactly is my data stored?
AWS Mumbai region (ap-south-1). Primary database, standby replica, S3 buckets, CloudWatch logs, KMS keys — all in-region. Backups also in-region (we use cross-AZ, not cross-region, replication to satisfy DPDP).
How do you handle a request from law enforcement?
We require formal legal process — a written request from a competent authority under Indian law. We notify the affected hospital before disclosure unless legally prohibited. We disclose the narrowest set of data responsive to the request. We do not provide bulk access.
Can a hospital admin see another hospital's data via the platform?
No. Tenancy is enforced at the database via Postgres row-level security policies tied to each session's hospital_id. A hospital admin cannot construct a query — through the UI or via API — that returns another hospital's rows. Super-admin access (platform owner only) is logged separately.
What happens to my data if I cancel?
Within 15 working days of a written cancellation request, we provide a full data export (clinical, financial, audit logs) in a documented schema. After confirmation of receipt, your data is purged from production within 30 days and from backups within 90 days. We do not retain data 'just in case' beyond contractual obligations.
Do you train AI models on our patient data?
No. Customer PHI is never used for training models, ours or anyone else's. Our AI features call vendor APIs (currently OpenAI and Anthropic) with patient data redacted to the minimum necessary; the API providers' standard data-handling agreements apply. We do not consent to the API providers using our calls for their own training.
What's your password and MFA policy?
Argon2id password hashing. Mandatory MFA for super-admin and hospital-admin roles; optional and recommended for clinical and front-desk users. SMS OTP for India (matches reality), TOTP for users who prefer authenticator apps. SSO via SAML or OIDC available on enterprise tier.
Do you have a public security.txt / responsible disclosure policy?
Yes — security.txt is live at /.well-known/security.txt. Responsible-disclosure researchers are acknowledged in a public hall of fame; cash bounties are part of the invite-only programme. We do not threaten or pursue good-faith researchers.
For your CISO / DPO
Want the full pen-test report?
We share pen-test reports, SBOM, DPA and architecture diagrams under NDA. Reply within one business day.