Indian hospitals have spent two decades getting good at one kind of audit: the accreditation survey. Clinical protocols, infection control, patient rights — documented, drilled, surveyed. Information security was, for most of that time, an IT department concern that surfaced in accreditation conversations only occasionally.
That era is over. NABH — the National Accreditation Board for Hospitals & Healthcare Providers, India's hospital accreditation body — has been pushing hospitals toward structured digital health and information security practices. At the same time, the Digital Personal Data Protection Act (DPDPA) has made patient data protection a statutory obligation with a regulator behind it, and the Ayushman Bharat Digital Mission (ABDM) is wiring hospitals into national digital health infrastructure — facility and professional registries (HFR and HPR) and consent-based health data exchange.
Three programmes. Three sets of expectations. One hospital IT and quality team, usually already stretched. This guide is about running them as one management system instead of three parallel fire drills.
The Triple Squeeze, Briefly
NABH accreditation. As NABH's standards evolve to cover digital health, hospitals pursuing or renewing accreditation are increasingly assessed on how systematically they manage information: who can access patient records, whether activity is logged, how data is protected, and whether the hospital can keep functioning when systems fail. A caution on specifics: NABH standards are versioned and chapter structures change, so rather than citing clause numbers, this guide describes the categories of expectations — verify the current edition that applies to your accreditation cycle.
DPDPA. Patient data is personal data — much of it exactly the kind a regulator will care most about. The DPDPA makes hospitals data fiduciaries with duties around consent, security safeguards, breach notification to the Data Protection Board, and individual rights. Larger hospital groups may be designated Significant Data Fiduciaries, adding a DPO, data protection impact assessments, and independent audits. The DPDPA framework guide covers the full obligation set.
ABDM. Participation in the Ayushman Bharat Digital Mission means registering in the Health Facility Registry and Health Professional Registry, and exchanging health records through consent artefacts. Interoperability is the point — but interoperability means your systems are now part of a national data fabric, and your security posture is no longer a private matter.
And cutting across all three: hospitals are body corporates under the CERT-In Directions, so a ransomware attack on your HIS is reportable to CERT-In within six hours of noticing it. The CERT-In guide explains that regime; the short version is that your incident response plan needs a very fast clock.
What the Three Programmes Actually Agree On
Here is the useful insight: strip away the differing vocabulary and the three programmes converge on the same handful of control categories. That convergence is what makes a single ISMS — an information security management system in the ISO 27001 sense — the right backbone.
Access control
Accreditation assessors want to see that clinical records are accessed on a need-to-know basis. The DPDPA expects reasonable security safeguards around personal data. ABDM participation assumes you can control which systems and people touch health records. Operationally this is one control family: role-based access tied to job function, joiner-mover-leaver processes that actually revoke access, and periodic access reviews with evidence that they happened.
In hospitals the hard part is the edges: locum doctors, visiting consultants, third-party lab integrations, and the shared workstation at the nursing station that everyone logs into as "nurse1". An ISMS forces you to name these exceptions, risk-assess them, and either fix them or formally accept them — which is also exactly the conversation an accreditation surveyor wants to see documented.
Audit trails and logging
All three programmes, in their own language, expect you to know who did what to patient data and when. That means application-level audit trails in the HIS/EMR, retained and reviewable — plus, under CERT-In, security logs maintained on a rolling 180-day basis. Treat log completeness and retention as a tested control, not an assumed property of the system.
Data protection
Encryption of data at rest and in transit, secure disposal of media, controls over data shared with insurers, TPAs, labs, and software vendors. The DPDPA's highest penalty tier attaches to failure of reasonable security safeguards, which concentrates the mind: the data protection controls you implement for NABH purposes are the same ones that determine your worst-case regulatory exposure.
Business continuity
A hospital is one of the few environments where system downtime has direct clinical consequences. Accreditation expectations around continuity of care, and basic security management, both point to the same work: identified critical systems, downtime procedures the ward staff actually know, tested backups, and a recovery plan that has been exercised rather than merely written.
Incident management
When something goes wrong — a misdirected discharge summary, a ransomware hit, a snooping incident — you need one pipeline: detect, record, classify, escalate, notify, and learn. With CERT-In's 6-hour reporting window and DPDPA breach notification both potentially in play for one event, hospitals need this pipeline to be fast and pre-mapped. Running it through a structured tool like Incident Management means the classification logic and notification deadlines live in the workflow, not in someone's memory.
Building the Hospital ISMS: A Pragmatic Sequence
For a hospital starting from accreditation-era documentation, the path to a working ISMS looks like this:
1. Scope around patient data flows, not departments. Map where patient data lives and moves: HIS/EMR, LIS, RIS/PACS, billing, insurance desk, ABDM integrations, WhatsApp groups (yes, include them — pretending they do not exist helps nobody). The scope statement should follow the data.
2. Run one risk assessment with three lenses. Assess each risk for clinical impact, regulatory exposure (DPDPA, CERT-In), and accreditation impact. One register, three impact columns. This stops the quality team and the IT team from maintaining duelling spreadsheets.
3. Build a single control set, mapped three ways. Define each control once — say, quarterly access reviews for clinical systems — and map it to the NABH expectation category, the DPDPA safeguard duty, and your ISO 27001 Annex A reference if you use the standard as scaffolding. When the accreditation survey, the DPDPA audit, and the internal audit each come around, you produce the same evidence with different cover sheets.
4. Collect evidence continuously, not before the survey. The pre-survey documentation sprint is a hospital tradition that does not survive contact with three concurrent programmes. Evidence — access review sign-offs, backup test results, training completions, downtime drill reports — should accumulate against controls in real time. This is the workflow Audit Management exists for: schedule the audits and surveillance cycles, assign evidence tasks to owners, and walk into the survey with the file already built.
5. Train for the floor, not the binder. Security awareness in a hospital is not phishing posters alone. It is the ward nurse knowing the downtime procedure, the registration desk knowing what consent under DPDPA requires, the resident knowing that browsing a celebrity patient's record is a reportable incident. Tie role-based training to the control set and track completion as evidence.
6. Put your software vendors inside the scope. Hospitals run on vendor software — the HIS vendor, the PACS vendor, the insurance integration, the appointment app. Under the DPDPA those vendors process patient data on your behalf, and under any honest reading of accreditation expectations, their failures are your failures. Maintain a register of data-touching vendors, get security and data protection obligations into contracts, and ask for evidence of their controls on a cycle — not just at onboarding. A hospital that cannot say which vendors can reach patient data has not finished scoping its ISMS.
What to Be Honest About
Two honest notes, because hospital teams deserve straight answers.
First, the regulatory ground is still moving. DPDPA enforcement is phasing in through 2026 and 2027, ABDM integration depth varies widely between hospitals, and NABH standards continue to evolve. Build your ISMS to absorb change — controls mapped to obligations, so when an obligation shifts you re-map rather than rebuild.
Second, no software platform makes a hospital secure. The ISMS lives or dies on whether the medical superintendent backs it, whether access reviews actually happen, and whether the downtime drill gets run. What a platform removes is the coordination tax — the spreadsheets, the chased emails, the evidence archaeology before every survey.
That coordination layer is what Compliance Enablers provides: one risk register, one control library mapped across NABH-style expectations, DPDPA, and ISO 27001, evidence collection on a schedule, and incident workflows with the CERT-In and DPDPA clocks built in. If your hospital is staring down an accreditation renewal and DPDPA readiness in the same year, book a demo and we will show you how other regulated organisations run one system for many masters.
This is general information, not legal advice. Verify current NABH standard editions and statutory obligations with your accreditation consultant and legal counsel.