1. Introduction: The ABDM Health Data Security Audit
The Ayushman Bharat Digital Mission (ABDM), formerly the National Digital Health Mission (NDHM), is India's flagship programme to create a seamless, interoperable digital health ecosystem. Governed by the National Health Authority (NHA) under the Ministry of Health and Family Welfare, ABDM establishes the digital public infrastructure (DPI) that connects patients, doctors, hospitals, diagnostic labs, pharmacies, insurers and public-health authorities through federated, consent-driven exchange of health records. Because this ecosystem processes some of the most sensitive personal data that exists, ABDM enforces a rigorous set of technical, procedural and legal security controls that every participating entity must satisfy before and during integration.
The ABDM Health Data Security Audit is the assurance activity through which a Health Information Provider (HIP), Health Information User (HIU), Health Repository Provider (HRP), Health Locker, Consent Manager or other integrator demonstrates that it meets the security, privacy and interoperability obligations of the ABDM Sandbox and Milestone framework. In practice this maps to the NHA's Health Data Management (HDM) Policy, the ABDM Data Privacy Policy, the milestone-based go-live gates (M1, M2, M3), and the underlying Indian legal instruments: the Digital Personal Data Protection Act, 2023 (DPDP Act), the Information Technology Act, 2000 (including the SPDI Rules, 2011 and CERT-In directions of 28 April 2022), and, where applicable, ISO/IEC 27001 and NABH digital-health standards.
This guide is written for two audiences at once. For the auditor or assessor, it enumerates every control family, the specific evidence to demand, the milestone-based certification lifecycle and the scoring rationale. For the implementer or product team, it translates each requirement into concrete engineering, DevSecOps and governance deliverables so that a health-tech product can pass its ABDM milestone gate and sustain compliance thereafter.
Copyright and source note
The ABDM Health Data Management Policy, ABDM Data Privacy Policy, Sandbox documentation and milestone criteria are published by the National Health Authority, Government of India. This guide is CyberSigma's original interpretation and auditor commentary; it paraphrases requirements for practitioner use and does not reproduce NHA copyrighted text. Always verify against the authoritative documents on the official ABDM Sandbox portal and the current NHA circulars, as milestone criteria and API specifications are versioned and evolve. Where this guide references the DPDP Act, 2023 and CERT-In directions, those are Government of India statutory instruments.
2. What is ABDM Health Data Security
ABDM is built on a federated architecture: health records are not centralised in a single national database. Instead, records remain with the originating provider (the HIP) and are exchanged on demand, with the patient's explicit, purpose-bound, time-bound consent, to a requesting user (the HIU) through the Health Information Exchange and Consent Manager (HIE-CM). Security in ABDM is therefore not merely perimeter defence; it is the assurance that identity, consent, encryption, interoperability and auditability hold across independent organisations that have never met, over public networks, at population scale.
The ABDM Health Data Security scope spans five interlocking layers. The identity layer covers ABHA (Ayushman Bharat Health Account, formerly Health ID) creation and authentication, and Healthcare Professionals Registry (HPR) and Health Facility Registry (HFR) enrolment. The consent layer covers the consent artefact lifecycle managed by the Consent Manager, including grant, fetch, notify, revoke and expiry. The exchange layer covers the FHIR R4 based data-transfer flows over the HIE-CM gateway, secured with mutual TLS, request signing and payload encryption. The data-protection layer covers encryption at rest and in transit, key management, data minimisation, retention and de-identification. The governance layer covers policies, DPO accountability, grievance redressal, breach reporting and third-party assurance.
An ABDM Health Data Security Audit evaluates all five layers against the applicable milestone criteria and the HDM Policy principles: notice, choice and consent, purpose limitation, collection and use limitation, data quality, security safeguards, accountability, and the rights of the data principal (access, correction, portability, erasure, nomination and grievance).
3. Who must comply
Any entity that integrates with ABDM building blocks, or that processes ABHA-linked health data, falls within scope. The specific obligations vary by the role the entity plays in the ecosystem. An organisation may hold more than one role simultaneously (for example, a hospital chain is typically both an HIP and an HIU).
| ABDM role / entity | Description | Primary security obligations |
|---|---|---|
| Health Information Provider (HIP) | Hospitals, clinics, labs, pharmacies, radiology centres that create and hold patient records | Link care contexts to ABHA, respond to consent-based data requests, encrypt and sign FHIR bundles, maintain audit trails |
| Health Information User (HIU) | Providers, insurers, researchers, apps that request and consume health records | Raise valid consent requests, honour purpose and expiry, secure received data, delete on expiry |
| Health Repository Provider (HRP) / Health Locker | PHR apps and lockers storing patient-controlled records | Strong encryption at rest, patient-controlled access, secure key custody, no secondary use without consent |
| Consent Manager (HIE-CM) | Manages consent artefacts and mediates exchange (e.g., ABDM's own CM) | Consent artefact integrity, non-repudiation, notification, revocation propagation |
| Interoperable PHR / third-party app | Patient-facing applications integrating ABHA login | Secure ABHA authentication, session security, least-privilege data access |
| Insurers and TPAs (via ABDM/NHCX) | Claims processing using health data | Purpose-limited access, consent verification, PII/PHI protection in claims pipeline |
| Technology Service Providers (TSP) / integrators | Vendors building ABDM integration for providers | Secure SDLC, secrets management, contractual data-processing controls under DPDP |
| Government health programmes and state agencies | Public-health analytics and programme delivery | De-identification, aggregate use, lawful basis, data-sharing agreements |
- Milestone-gated entities: Any applicant progressing through the ABDM Sandbox from M1 to M3 must demonstrate security controls appropriate to their milestone before production credentials are issued.
- DPDP-regulated Data Fiduciaries: All the above are Data Fiduciaries (or Data Processors) under the DPDP Act, 2023, and large-volume processors may be notified as Significant Data Fiduciaries with enhanced duties (DPO, DPIA, independent audit).
- CERT-In reporting entities: All service providers, intermediaries and data centres must comply with the CERT-In directions of 28 April 2022 (6-hour incident reporting, log retention, clock synchronisation).
4. Structure of the ABDM Health Data Security framework
The audit is organised into control domains that map to the HDM Policy principles, the milestone criteria and the underlying statutory obligations. Each domain decomposes into control families and individual, testable controls. The table below sets out the domain architecture used throughout this guide; the master checklist in section 5 then enumerates each family in detail.
| Domain ID | Domain | Representative control families | Primary source |
|---|---|---|---|
| D1 | Governance, Policy and Accountability | HDM policy adoption, DPO, roles, third-party governance | HDM Policy; DPDP s.8-10 |
| D2 | Consent Management | Consent artefact lifecycle, purpose/expiry, revocation, notification | HDM Policy; HIE-CM spec |
| D3 | Identity and Access Management | ABHA/HPR/HFR verification, authN/authZ, session, privileged access | ABDM IAM; DPDP; ISO 27001 A.5.15-A.5.18 |
| D4 | Data Protection and Cryptography | Encryption in transit/at rest, key management, signing, tokenisation | SPDI Rules; ISO 27001 A.8.24; NIST |
| D5 | Interoperability and Secure Exchange | FHIR R4 conformance, mTLS gateway, request signing, schema validation | ABDM FHIR/HIE-CM spec |
| D6 | Data Lifecycle and Minimisation | Collection limitation, retention, de-identification, deletion, portability | HDM Policy; DPDP s.6-8 |
| D7 | Application and Product Security | Secure SDLC, VAPT, API security, mobile/PHR app hardening | OWASP ASVS/MASVS; CERT-In |
| D8 | Infrastructure and Cloud Security | Network segmentation, hardening, MEITY-empanelled cloud, backups | CERT-In; ISO 27001 A.8 |
| D9 | Logging, Monitoring and Audit Trail | Immutable audit logs, NTP sync, 180-day retention, SIEM | CERT-In directions; ISO 27001 A.8.15-A.8.16 |
| D10 | Incident Management and Breach Reporting | 6-hour CERT-In reporting, DPDP breach notice, IR plan, BCP/DR | CERT-In; DPDP s.8(6) |
| D11 | Data Principal Rights and Grievance | Access, correction, erasure, nomination, grievance redressal | HDM Policy; DPDP s.11-14 |
| D12 | Third-Party and Supply-Chain Assurance | Processor contracts, sub-processor control, SBOM, due diligence | DPDP s.8(2); ISO 27001 A.5.19-A.5.23 |
5. Master assessment checklist
This is the core of the audit. Each h3 below corresponds to a control domain from section 4. For every family the tables state precisely what the assessor must verify and the typical evidence that satisfies each control. Implementers should treat the 'What to verify' column as an acceptance criterion and the 'Typical evidence' column as a deliverables list. No control area is omitted.
D1 — Governance, Policy and Accountability
| What to verify | Typical evidence |
|---|---|
| The entity has formally adopted an internal policy aligned to the ABDM HDM Policy and Data Privacy Policy | Signed, board-approved information security and health-data policy with version history and ABDM mapping |
| A Data Protection Officer / Grievance Officer is appointed with published contact details | Appointment letter, org chart, published DPO/Grievance Officer contact on website and app |
| Security and privacy roles and responsibilities (RACI) are documented | RACI matrix; job descriptions referencing ABDM controls |
| Management review of the ABDM security programme occurs on a defined cadence | Minutes of management/security steering committee meetings |
| A privacy notice consistent with HDM Policy is presented at point of collection | Screenshots of in-app notice; notice text; consent capture flow |
| A Data Protection Impact Assessment (DPIA) has been performed for ABDM data flows | Completed DPIA report with risk treatment plan |
| Risk register covering health-data risks is maintained and reviewed | Risk register with owners, ratings and treatment status |
D2 — Consent Management
Consent is the legal and technical spine of ABDM. Every data exchange must be traceable to a valid, unexpired, purpose-matched consent artefact. This family is scrutinised more heavily than any other during a milestone assessment.
| What to verify | Typical evidence |
|---|---|
| Consent artefacts capture purpose, HI types, date range, data-eraser expiry and requester/receiver | Sample consent artefact JSON; HIE-CM consent init/grant logs |
| The system enforces purpose limitation — data is used only for the granted purpose code | Access-control test showing purpose mismatch is rejected; code review of authorisation guard |
| Consent expiry and data-eraser dates are enforced; expired data is deleted | Automated deletion job logs; test evidence of post-expiry denial and record erasure |
| Consent revocation is honoured immediately and propagated | Revocation event logs; test showing access blocked after revoke |
| Consent notifications are sent to the data principal on grant, fetch and revoke | Notification logs; sample notification payloads to CM |
| Consent artefacts are signed and tamper-evident (non-repudiation) | Signature verification records; digital signature validation logs |
| Auto-approval or standing consent (if used) is bounded and lawful | Configuration of auto-approval policies; scope limits; audit of triggered grants |
| Consent for minors and nominees follows HDM Policy (guardian/nominee handling) | Guardian-consent flow evidence; nominee configuration; age-gating logic |
D3 — Identity and Access Management
| What to verify | Typical evidence |
|---|---|
| ABHA number/address is verified through the official ABDM authentication flow (Aadhaar OTP, mobile OTP, or biometric as configured) | Auth flow diagrams; API logs showing verification; no local Aadhaar storage without lawful basis |
| Healthcare professionals are validated against HPR before privileged clinical actions | HPR verification API logs; provider onboarding records |
| Health facilities are registered and validated against HFR | HFR facility ID mapping; registration certificates |
| Multi-factor authentication is enforced for administrative and clinical users | MFA policy and enforcement configuration; sample login audit |
| Role-based access control implements least privilege for health data | RBAC matrix; access-review reports; segregation-of-duties evidence |
| Session management is secure (timeout, re-authentication, token expiry, no fixation) | Session config; token TTL settings; VAPT session tests |
| Privileged access is logged, time-bound and reviewed (PAM) | Privileged access logs; break-glass procedure; quarterly access recertification |
| Service-to-service credentials (client ID/secret, API keys) are rotated and vaulted | Secrets-vault inventory; rotation policy; no secrets in code (SAST/secret-scan report) |
D4 — Data Protection and Cryptography
| What to verify | Typical evidence |
|---|---|
| All data in transit uses TLS 1.2+ (preferably 1.3) with strong cipher suites; mTLS on ABDM gateway calls | TLS scan (SSL Labs/testssl); cipher configuration; mTLS certificate inventory |
| Health data at rest is encrypted with AES-256 or equivalent | Storage encryption configuration; DB/TDE settings; disk encryption evidence |
| Cryptographic keys are managed in an HSM or MEITY-recognised KMS with defined lifecycle | KMS/HSM inventory; key rotation policy; access controls to key material |
| Payloads exchanged over HIE-CM are encrypted and signed per ABDM crypto spec (e.g., ECDH key exchange, hybrid encryption) | Encryption implementation review; interop test logs; key-exchange handshake capture |
| Sensitive fields are tokenised/masked in non-production and in logs | Data-masking config; log samples showing no PHI leakage; non-prod data policy |
| Certificate lifecycle is managed (issuance, renewal, revocation, no expiry gaps) | Certificate inventory with expiry monitoring; renewal runbook |
| No hardcoded keys, weak algorithms (MD5, SHA-1, DES) or deprecated protocols in use | SAST/crypto-scan report; algorithm inventory |
D5 — Interoperability and Secure Exchange
| What to verify | Typical evidence |
|---|---|
| Data is exchanged as valid FHIR R4 bundles conforming to ABDM profiles (DiagnosticReport, Prescription, OPConsultation, DischargeSummary, etc.) | FHIR validator output; sample bundles; ABDM profile conformance report |
| All ABDM gateway calls (/care-contexts, /consents, /health-information) succeed against the sandbox test suite | Sandbox milestone test results; API call/response logs |
| Requests to the gateway are signed and carry correct HIP/HIU identifiers | Request signing implementation; header inspection; signature verification |
| Input validation and schema validation reject malformed or oversized payloads | Negative test cases; WAF/validation logs; fuzzing results |
| Idempotency and correlation IDs (X-CM-ID, transaction IDs) are handled correctly | Transaction trace logs; idempotency test evidence |
| Data-push callbacks (/on-*) are authenticated and processed securely | Callback authentication config; replay-protection evidence |
| Interoperability does not leak more data than the consent scope permits | Field-level scope test; bundle content vs consent HI types comparison |
D6 — Data Lifecycle and Minimisation
| What to verify | Typical evidence |
|---|---|
| Only data necessary for the stated purpose is collected (collection limitation) | Data-flow inventory; field-level justification; data map |
| A documented retention schedule exists and is enforced for health records | Retention policy; automated retention/deletion jobs; deletion logs |
| Data received by an HIU is deleted on consent expiry / data-eraser date | Post-expiry deletion evidence; scheduled purge logs |
| De-identification/anonymisation is applied for analytics and secondary use | De-identification method (k-anonymity/pseudonymisation); re-identification risk assessment |
| Data portability is supported (patient can export/transfer records) | Export feature evidence; FHIR export sample |
| Secure deletion and media sanitisation procedures exist for decommissioning | Sanitisation policy; certificates of destruction; crypto-shredding evidence |
| Backups containing health data are encrypted and access-controlled | Backup encryption config; restore test logs; backup access controls |
D7 — Application and Product Security
| What to verify | Typical evidence |
|---|---|
| A secure SDLC with threat modelling and security gates is followed | SDLC policy; threat models; security sign-off in release pipeline |
| Application VAPT (web/API) has been performed by a CERT-In empanelled auditor with no open critical/high findings | CERT-In empanelled VAPT report; remediation evidence; re-test/closure certificate |
| Mobile/PHR apps are hardened per OWASP MASVS (root/jailbreak detection, secure storage, cert pinning, no PHI in logs) | MASVS test report; mobile pentest; secure-storage review |
| APIs follow OWASP API Top 10 controls (authZ per object, rate limiting, no excessive data exposure) | API pentest; rate-limit config; BOLA/IDOR test evidence |
| SAST, DAST and SCA run in CI with policy-based blocking | Pipeline config; scan reports; dependency-vulnerability (SCA) results |
| Secrets scanning prevents credentials in source control | Secret-scan reports; pre-commit hooks; vault usage |
| Security headers, CSRF/XSS protections and input sanitisation are implemented | Header scan; XSS/CSRF test results; security header config |
D8 — Infrastructure and Cloud Security
| What to verify | Typical evidence |
|---|---|
| Hosting uses a MEITY-empanelled cloud service provider with data localised in India | MEITY empanelment evidence; region configuration; data-residency attestation |
| Network segmentation isolates health-data workloads (DMZ, private subnets, no direct DB exposure) | Network architecture diagram; security-group/firewall rules; segmentation test |
| Systems are hardened to CIS benchmarks and patched on a defined SLA | CIS benchmark scan; patch management records; vulnerability SLA report |
| WAF and DDoS protection front public endpoints | WAF policy; DDoS protection config; blocked-attack logs |
| Configuration management and IaC scanning prevent drift and misconfiguration | IaC scan reports (Checkov/tfsec); CMDB; drift-detection logs |
| Backups follow 3-2-1 and are tested via periodic restores | Backup policy; restore test evidence; RTO/RPO records |
| Anti-malware/EDR is deployed on servers and endpoints handling health data | EDR coverage report; alerting configuration |
D9 — Logging, Monitoring and Audit Trail
| What to verify | Typical evidence |
|---|---|
| Every access to and exchange of health data is logged (who, what, when, on whose consent) | Audit-log samples; access-trail export; consent-linked access records |
| Logs are retained for at least 180 days as required by CERT-In directions | Log-retention configuration; storage evidence; retention policy |
| System clocks are synchronised to NIC/NPL NTP as required by CERT-In | NTP configuration pointing to NIC/NPL; time-sync monitoring |
| Audit logs are immutable/tamper-evident and access to them is restricted | WORM storage or log-integrity hashing; log-access controls |
| A SIEM correlates security events and generates alerts | SIEM dashboards; use-case/rule catalogue; sample alerts |
| Security monitoring covers consent misuse and anomalous data access | Anomaly-detection rules; alert on abnormal fetch volumes |
| Log content excludes plaintext PHI/credentials | Log-scrubbing config; sample logs reviewed for PHI leakage |
D10 — Incident Management and Breach Reporting
| What to verify | Typical evidence |
|---|---|
| A documented incident response plan with roles, severities and playbooks exists | IR plan; playbooks; contact tree |
| Cyber incidents are reportable to CERT-In within 6 hours of detection | CERT-In reporting procedure; template; evidence of any prior report/drill |
| Personal-data breaches are notified to the Data Protection Board and affected principals per DPDP | Breach-notification procedure; DPDP-aligned notice template |
| A defined process notifies ABDM/NHA of security incidents affecting the ecosystem | ABDM incident notification procedure; escalation matrix |
| IR is exercised through tabletop or simulation at least annually | Tabletop exercise report; lessons-learned actions |
| Business continuity and disaster recovery plans exist with tested RTO/RPO | BCP/DR plan; DR test results; RTO/RPO metrics |
| Post-incident root-cause analysis and corrective actions are tracked | Sample RCA; CAPA tracker |
D11 — Data Principal Rights and Grievance
| What to verify | Typical evidence |
|---|---|
| Data principals can access and obtain a copy of their health data | Access-request workflow; fulfilment evidence |
| Correction and updating of inaccurate data is supported | Correction workflow; audit trail of changes |
| Erasure/withdrawal of consent leads to deletion where lawful | Erasure workflow; deletion confirmation to principal |
| Nomination (nominee to exercise rights) is supported per DPDP | Nominee configuration; guardian handling for minors |
| A grievance redressal mechanism with defined SLAs is published and functional | Grievance workflow; SLA policy; sample resolved grievances; escalation to Grievance Officer |
| Rights requests are authenticated to prevent impersonation | Identity-verification step in rights workflow |
| Response timelines meet HDM/DPDP expectations | Grievance/rights SLA metrics and adherence report |
D12 — Third-Party and Supply-Chain Assurance
| What to verify | Typical evidence |
|---|---|
| Data-processing agreements bind all processors and TSPs to DPDP/HDM obligations | Signed DPAs; data-processing clauses; ABDM flow-down terms |
| Sub-processors are inventoried, approved and contractually controlled | Sub-processor register; approval workflow |
| Third-party security is assessed before onboarding and periodically | Vendor risk assessments; security questionnaires; audit reports (SOC 2/ISO 27001) |
| A software bill of materials (SBOM) and dependency governance exist | SBOM; SCA reports; open-source policy |
| Cloud and infrastructure providers meet ABDM/MEITY residency requirements | Provider attestations; region configuration |
| Right-to-audit and breach-notification clauses are present in vendor contracts | Contract clauses; audit-rights evidence |
| Offboarding ensures data return/destruction by third parties | Offboarding checklist; destruction certificates |
6. Scoping the ABDM Health Data Security Audit
Accurate scoping prevents both under-assessment (missing a data flow) and over-assessment (auditing systems that never touch ABDM data). Scope is defined by the ABDM role(s) the entity plays, the milestone being pursued, and the systems, environments and third parties in the health-data path.
- Roles in scope: Identify every ABDM role the entity performs (HIP, HIU, HRP, PHR app, CM integration). Each role adds control families — an HIU adds strong obligations around received-data deletion; an HIP adds care-context linking and bundle-signing.
- Milestone in scope: M1 (identity and registry integration), M2 (consent and data exchange in sandbox), M3 (production readiness). The depth of security evidence increases with each milestone.
- Data flows in scope: Map every path where ABHA-linked data is created, transmitted, stored, processed or deleted, including callbacks and analytics pipelines.
- Environments in scope: Sandbox and production must both be assessed; non-production environments are in scope where they hold real or realistic health data.
- Interfaces in scope: HIE-CM gateway, ABHA/HPR/HFR APIs, FHIR endpoints, PHR/patient apps, insurer/NHCX interfaces if applicable.
- Third parties in scope: Cloud providers, TSPs/integrators, SMS/notification gateways, analytics processors — any party in the data path.
- Out of scope (justify explicitly): Corporate systems with no health-data path, provided they are network-segregated; document the segregation as evidence.
Scoping tip for assessors
Insist on a current, signed data-flow diagram before fieldwork. If the entity cannot produce one, that is itself a finding under D6 (data lifecycle) and D1 (governance) — you cannot protect data whose path you have not mapped.
7. Implementation approach (phased)
Implementers should treat ABDM readiness as a programme aligned to the milestone gates, not a one-off pentest. The following phases take a health-tech product from zero to sustained compliance.
Phase 1 — Discovery and gap assessment
- Activities: Confirm ABDM roles and target milestone; map all health-data flows; run a gap assessment against domains D1-D12; perform an initial DPIA; establish the risk register.
- Deliverables: Role and scope statement, data-flow diagrams, gap-assessment report with prioritised remediation backlog, DPIA v1, risk register.
Phase 2 — Governance and policy foundation
- Activities: Adopt HDM-aligned policies; appoint DPO/Grievance Officer; define RACI; put DPAs in place with processors; stand up the incident-response and breach-notification procedures (CERT-In 6-hour, DPDP).
- Deliverables: Approved policy suite, appointment records, DPA templates and signed agreements, IR/BCP/DR plans, grievance mechanism.
Phase 3 — Technical build and hardening
- Activities: Implement ABHA/HPR/HFR verification, consent lifecycle, FHIR R4 bundles, mTLS and payload encryption/signing; enforce RBAC/MFA, secrets vaulting, encryption at rest, logging with NTP sync and 180-day retention; harden infrastructure on MEITY-empanelled cloud.
- Deliverables: Working sandbox integration, crypto and key-management implementation, RBAC matrix, centralised logging/SIEM, hardened infrastructure baseline.
Phase 4 — Verification and testing
- Activities: Run ABDM sandbox milestone test suites; conduct CERT-In empanelled VAPT (web/API/mobile); execute SAST/DAST/SCA; perform interoperability and negative testing; validate consent enforcement and post-expiry deletion.
- Deliverables: Sandbox milestone pass evidence, VAPT report with closure certificate, scan reports, interoperability conformance evidence, consent-enforcement test pack.
Phase 5 — Milestone certification and go-live
- Activities: Compile the evidence pack; submit for the target ABDM milestone; obtain production credentials; deploy to production with change control; conduct a production readiness review.
- Deliverables: Milestone approval, production ABDM credentials, go-live checklist sign-off, production runbooks.
Phase 6 — Sustained compliance and continuous assurance
- Activities: Continuous monitoring; periodic access recertification; annual VAPT and DPIA refresh; vendor reassessment; incident drills; track KPIs; re-audit on major changes.
- Deliverables: Continuous-assurance calendar, annual audit reports, updated DPIA, KPI dashboards, drill reports.
8. Maturity / capability model
While ABDM milestones are pass/fail gates, CyberSigma applies a five-level capability model to help entities benchmark and improve beyond the minimum. This model lets an assessor express findings as a maturity score per domain rather than a bare pass/fail, and helps product teams prioritise investment.
| Level | Name | Characteristics | Indicative readiness |
|---|---|---|---|
| L1 | Initial / Ad hoc | Controls absent or informal; no data-flow map; consent handling manual or partial | Not milestone-ready |
| L2 | Developing | Basic policies exist; sandbox integration begun; some encryption and logging but gaps in consent enforcement and audit trails | Approaching M1 |
| L3 | Defined | Documented, repeatable controls across most domains; consent lifecycle enforced; VAPT performed; logging with retention and NTP | M2 capable |
| L4 | Managed | Controls measured with KPIs; SIEM monitoring; continuous scanning; access recertification; incident drills | M3 / production-ready |
| L5 | Optimising | Continuous improvement; automated compliance evidence; threat-led testing; proactive de-identification and privacy engineering | Best-practice, audit-resilient |
Scoring guidance: an entity should reach at least L3 across all domains and L4 in D2 (consent), D4 (cryptography) and D9 (logging) before seeking M3 production credentials. Any domain at L1 is a blocking finding.
9. Assessment and audit approach
The audit follows a structured, evidence-led lifecycle. The steps below define how a CyberSigma assessor conducts an ABDM Health Data Security Audit end to end.
- Engagement scoping and planning: agree roles, milestone, systems, environments and third parties; issue the evidence request list; agree timelines and access.
- Documentation review: examine policies, DPIA, data-flow diagrams, DPAs, IR/BCP plans and prior audit reports against domains D1-D12.
- Technical control testing: verify encryption, mTLS, signing, RBAC/MFA, secrets management, logging, NTP sync and retention through configuration inspection and live tests.
- Consent and interoperability testing: execute end-to-end flows in the sandbox — consent init/grant/fetch/revoke and FHIR bundle exchange — confirming purpose limitation and expiry deletion.
- Security testing review: review or witness CERT-In empanelled VAPT, SAST/DAST/SCA and mobile testing; validate closure of critical/high findings.
- Interviews and walkthroughs: interview DPO, engineering, operations and support to corroborate documented controls and grievance handling.
- Gap analysis and risk rating: consolidate findings, assign severities and map each to the relevant domain and statutory obligation.
- Reporting: issue a findings report with maturity scores, milestone-readiness verdict and a prioritised remediation plan.
- Remediation and re-test: verify closure of blocking findings; issue closure/attestation supporting the ABDM milestone submission.
- Surveillance and re-audit: schedule periodic re-assessment and trigger-based re-audit on significant change.
10. Evidence request list
The following categorised list is issued at engagement start. Implementers should assemble these artefacts in an evidence pack indexed to the domain IDs in section 4.
- Governance: HDM-aligned policies, privacy policy, DPO/Grievance Officer appointment, RACI, management-review minutes, DPIA, risk register.
- Consent: sample consent artefacts, HIE-CM logs, purpose/expiry enforcement test results, revocation and notification logs, minor/nominee handling evidence.
- Identity and access: ABHA/HPR/HFR verification logs, RBAC matrix, MFA config, access-recertification reports, PAM/break-glass procedures, secrets-vault inventory.
- Cryptography: TLS/mTLS scans, at-rest encryption config, KMS/HSM inventory, key-rotation policy, ABDM payload encryption/signing implementation notes.
- Interoperability: FHIR validator output, sandbox milestone test results, gateway API logs, request-signing evidence, negative/schema-validation tests.
- Data lifecycle: data-flow diagrams, data map, retention schedule, deletion/purge logs, de-identification method, backup encryption and restore evidence.
- Application security: secure SDLC policy, threat models, CERT-In empanelled VAPT report and closure certificate, SAST/DAST/SCA reports, mobile MASVS report.
- Infrastructure and cloud: MEITY empanelment evidence, network diagrams, firewall/security-group rules, CIS benchmark scans, patch records, WAF/DDoS config, EDR coverage.
- Logging and monitoring: audit-log samples, retention config (180-day), NTP config (NIC/NPL), SIEM dashboards and rules, log-integrity evidence.
- Incident and continuity: IR plan, CERT-In and DPDP breach-notification procedures, tabletop/drill reports, BCP/DR plan and DR test results, sample RCAs.
- Data principal rights: access/correction/erasure workflows, nomination config, grievance mechanism and SLA metrics, sample resolved grievances.
- Third party: signed DPAs, sub-processor register, vendor risk assessments, SBOM/SCA, right-to-audit clauses, offboarding/destruction certificates.
11. Roles and responsibilities
| Role | Responsibilities in ABDM security programme |
|---|---|
| Board / Senior Management | Approve policies and budget; own residual risk; sponsor the ABDM programme; review posture periodically |
| Data Protection Officer (DPO) | Own HDM/DPDP compliance; oversee DPIA, consent governance and breach notification; liaise with NHA and CERT-In |
| Grievance Officer | Handle data-principal grievances within SLA; maintain grievance register; escalate as required |
| Chief Information Security Officer | Own the security control environment (D3-D10); drive VAPT, SIEM, hardening and incident response |
| Product / Engineering lead | Implement ABDM integration, consent lifecycle, FHIR, cryptography and secure SDLC controls |
| DevSecOps / Platform team | Maintain CI security gates, secrets vaulting, IaC scanning, logging, NTP and cloud hardening |
| Compliance / Privacy team | Maintain evidence pack, DPAs, retention schedule, rights workflows and audit readiness |
| SOC / Monitoring team | Operate SIEM, detect consent misuse and anomalies, run incident response and drills |
| Third-party / Vendor manager | Manage DPAs, sub-processor register, vendor assessments and offboarding |
| Independent auditor (CyberSigma) | Conduct the ABDM Health Data Security Audit, issue findings, validate remediation and milestone readiness |
12. KPIs to track
- Percentage of data exchanges backed by a valid, unexpired, purpose-matched consent artefact (target 100%).
- Mean time to enforce consent revocation across systems (target near real-time).
- Percentage of expired/withdrawn-consent data deleted within SLA (target 100%).
- Number of open critical/high VAPT findings on ABDM-facing systems (target zero before go-live).
- Percentage of ABDM endpoints on TLS 1.2+ with mTLS where required (target 100%).
- Audit-log coverage: percentage of health-data accesses logged with actor, purpose and consent reference (target 100%).
- Log retention adherence and NTP-sync uptime (target meeting CERT-In 180-day and time-sync requirements).
- Mean time to detect and mean time to respond to security incidents.
- CERT-In 6-hour reporting adherence for reportable incidents (target 100%).
- Grievance resolution within SLA (target 100%) and average resolution time.
- Percentage of processors under signed DPAs with current risk assessments (target 100%).
- Access-recertification completion rate and privileged-access review coverage.
13. Readiness checklist
- ABDM roles and target milestone confirmed and documented
- Signed data-flow diagrams covering all ABHA-linked data paths
- HDM/DPDP-aligned policy suite approved; DPO and Grievance Officer appointed
- DPIA completed and risk register maintained
- Consent lifecycle (grant, fetch, revoke, expiry, notify) implemented and tested
- Purpose limitation and post-expiry deletion enforced and evidenced
- ABHA/HPR/HFR verification integrated; RBAC and MFA enforced
- TLS 1.2+/mTLS in transit; AES-256 at rest; keys in HSM/KMS with rotation
- ABDM payload encryption and request signing implemented per spec
- FHIR R4 bundles conform to ABDM profiles; sandbox milestone tests passed
- Audit logging with actor/purpose/consent reference; 180-day retention; NIC/NPL NTP sync
- SIEM monitoring with consent-misuse and anomaly detection
- CERT-In empanelled VAPT completed with critical/high findings closed
- SAST/DAST/SCA and secrets scanning in CI; mobile MASVS testing done
- MEITY-empanelled cloud with India data residency and network segmentation
- IR plan with CERT-In 6-hour and DPDP breach notification; BCP/DR tested
- Data-principal rights (access, correction, erasure, nomination) and grievance SLA operational
- DPAs signed with all processors; sub-processor register and SBOM maintained
- Evidence pack assembled and indexed to domains D1-D12
14. Common gaps
- Consent treated as a checkbox rather than enforced: data accessible after expiry or beyond the granted purpose, with no automated deletion on the data-eraser date.
- Missing or stale data-flow maps, so analytics or logging pipelines quietly carry PHI outside the assessed scope.
- Plaintext PHI or credentials appearing in application logs and error traces.
- Weak or default TLS configuration and absent mTLS on gateway calls; deprecated ciphers still enabled.
- Secrets (client secrets, API keys) hardcoded in source or config instead of a vault, and never rotated.
- Log retention below the CERT-In 180-day requirement and clocks not synchronised to NIC/NPL NTP.
- VAPT performed by a non-empanelled tester, or critical/high findings left open at go-live.
- No CERT-In 6-hour incident-reporting procedure and no DPDP-aligned breach-notification path.
- Hosting outside MEITY-empanelled/Indian infrastructure, breaching data-residency expectations.
- Processors and TSPs engaged without signed DPAs, sub-processor inventory or right-to-audit clauses.
- Grievance mechanism published but non-functional, with no SLA tracking or Grievance Officer accountability.
- Mobile/PHR apps lacking secure storage, certificate pinning and root/jailbreak detection.
15. ABDM Health Data Security mapped to other frameworks
The ABDM control domains align closely with India's statutory regime and international standards, letting entities reuse existing certifications as evidence. The mapping below is indicative, not one-to-one.
| ABDM domain | DPDP Act, 2023 | ISO/IEC 27001:2022 | CERT-In / other |
|---|---|---|---|
| D1 Governance and Accountability | s.8 duties, s.10 SDF (DPO, DPIA, audit) | A.5.1-A.5.4 policies and roles | NHA HDM Policy; ISO 27701 |
| D2 Consent Management | s.6-7 consent, notice | A.5.34 privacy and PII protection | HDM Policy; HIE-CM spec |
| D3 Identity and Access | s.8(4) reasonable safeguards | A.5.15-A.5.18 access control | ABDM ABHA/HPR/HFR spec |
| D4 Cryptography | s.8(5) security safeguards | A.8.24 cryptography | SPDI Rules; NIST guidance |
| D5 Interoperability and Exchange | s.8(2) processor obligations | A.8.26 application security requirements | ABDM FHIR R4 profiles |
| D6 Data Lifecycle and Minimisation | s.6(1) purpose, s.8(7) retention | A.8.10-A.8.12 deletion/masking | HDM Policy de-identification |
| D7 Application and Product Security | s.8(4) safeguards | A.8.25-A.8.29 secure development | OWASP ASVS/MASVS; CERT-In VAPT |
| D8 Infrastructure and Cloud | s.8(4) safeguards | A.8.1-A.8.9 infrastructure | MEITY empanelment; CIS |
| D9 Logging and Monitoring | s.8(4) safeguards | A.8.15-A.8.16 logging/monitoring | CERT-In (180-day logs, NTP) |
| D10 Incident and Breach | s.8(6) breach intimation | A.5.24-A.5.28 incident management | CERT-In 6-hour directions |
| D11 Data Principal Rights | s.11-14 rights and grievance | A.5.34 PII; A.5.32 IP/records | HDM Policy patient rights |
| D12 Third-Party Assurance | s.8(2) processor contracts | A.5.19-A.5.23 supplier security | ISO 27001/SOC 2 attestations |
16. How CyberSigma helps
Partner with CyberSigma for ABDM readiness and assurance
CyberSigma is a CERT-In empanelled cybersecurity firm with PCI QSA credentials and deep experience in Indian health-data compliance. We take health-tech and healthcare-provider teams end to end: ABDM role and milestone scoping, gap assessment against domains D1-D12, DPIA and DPDP alignment, consent-lifecycle and FHIR interoperability validation, CERT-In empanelled VAPT of web/API/mobile, cryptography and key-management review, cloud and logging hardening, and a fully indexed evidence pack for your M1-M3 submissions. Post go-live we provide continuous assurance — annual re-audit, SIEM monitoring guidance, incident-response drills and vendor reassessment — so your ABDM integration stays compliant as the ecosystem evolves. Talk to CyberSigma to book an ABDM Health Data Security readiness assessment.
Frequently asked questions
What data does ABDM protect?
Sensitive personal health data linked to ABHA, governed by the ABDM Health Data Management Policy and India’s DPDP Act.
Official documents
CyberSigma resources
Need help with ABDM Health Data?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.