What CERT-In and the DPDP Act 2023 actually require, and a practical backup checklist for tier-2/3 hospitals.
Ask a hospital administrator who is responsible for backups, and the honest answer in most tier-2/3 hospitals is: nobody, specifically. IT is one part-time person, or a vendor's AMC contact who shows up when something breaks. That gap is exactly what CERT-In's rules and the DPDP Act were written to close, and exactly what ransomware groups are exploiting.
Healthcare accounted for close to 22% of all cyberattacks tracked in India, per the Data Security Council of India's Cyber Threat Report 2025 — the single most-targeted industry in the country. Patient data is durable in a way payment card data isn't: a stolen card gets cancelled, a stolen medical history doesn't expire. That makes hospital data worth stealing even when there's no ransom involved, and worth encrypting for ransom when there is.
India's largest public hospital learned this directly when a ransomware attack on AIIMS Delhi disrupted its systems for an extended period in 2022, a widely reported case that pushed hospital cybersecurity onto the national agenda rather than leaving it as an internal IT concern. That incident wasn't isolated: security researchers have documented multiple confirmed hospital-targeted incidents in India since, including attacks on smaller facilities that received far less press coverage but caused the same operational disruption locally — delayed admissions, manual fallback processes, and systems that took days or weeks to fully restore.
The pattern behind most of these incidents is consistent. Analysis of recent healthcare cybersecurity incidents shows the majority of breaches trace back to credential theft through email or SMS phishing, or to third-party vendors — billing, lab, and radiology partners — who hold standing administrative access to hospital systems without strong authentication on their own end. A hospital can harden its own systems thoroughly and still be compromised through a vendor's weaker security, which is why vendor access review belongs on the same checklist as internal patching.
It's worth being specific about why hospitals, rather than other data-rich industries, absorb this disproportionately. Banks and telecom operators face similar attacker interest but typically run larger, better-funded security teams and have faced regulatory pressure to harden their systems for longer. Hospitals, particularly outside the largest metro chains, have historically treated IT as a back-office cost centre rather than core infrastructure, which shows up directly in the gap between clinical investment and security investment. That gap is closing, but slowly, and mostly at the largest facilities first — leaving tier-2/3 hospitals as the more exposed segment even though the sector-wide attack numbers don't distinguish by hospital size.
CERT-In's directions under Section 70B(6) of the Information Technology Act, 2000, issued in 2022, apply to any entity operating in India, hospitals included. The two provisions that matter most operationally:
Most hospitals running a mix of unconnected systems can't meet the 6-hour window, because nobody is watching all the systems continuously, and logs live in four different places with four different retention policies, or none at all. A managed support plan with CERT-In incident support exists specifically to close this gap, since meeting a 6-hour clock without a dedicated monitoring process in place is close to impossible for a hospital running lean IT staff.
CERT-In is about incident reporting. The Digital Personal Data Protection Act, 2023 is about the standing obligation to protect the data in the first place. Under Section 8, a hospital, as the data fiduciary deciding how patient data is processed, must take reasonable security safeguards to prevent a personal data breach, and must notify the Data Protection Board and affected patients if a breach occurs.
"Reasonable" isn't defined as a specific checklist in the Act, which is both flexibility and risk: a hospital with no encryption, no access logging and no incident response plan cannot credibly claim its safeguards were reasonable after a breach. The same consent-and-purpose logic that governs a hospital's broader DPDP Act compliance applies directly to security: data collected for treatment can't be secured loosely on the assumption that "it's just for internal use."
This matters practically at the point of a breach investigation, not just in the abstract. If a hospital's patient data is exposed and a case reaches the Data Protection Board, the Board's assessment of "reasonable safeguards" will look at what was actually in place at the time, not what a policy document said should have been in place. A written incident response plan that was never tested, or backup software that was installed but never verified to work, weakens a hospital's position considerably more than having no plan at all and being honest about that gap while working to close it.
Two numbers matter, even if nobody calls them by these names in a tier-2/3 hospital: how much data you can afford to lose (recovery point), and how long you can afford to be down (recovery time). A backup that runs nightly but restores in two days after a ransomware hit still means two days without patient records, billing, or pharmacy stock visibility.
Most hospitals never sit down and actually decide these numbers deliberately; they discover them by accident during an outage. A better approach is to set them in advance, department by department: pharmacy stock data might tolerate losing four hours of updates in a worst case, while IPD medication records should tolerate close to zero. Setting these numbers before an incident, rather than during one, is what turns "we have backups" into an actual, testable commitment.
Ransomware that encrypts your live database will also encrypt a backup sitting on the same network, reachable with the same credentials. A backup that survives an attack has to be offline, air-gapped, or immutable, not just "a copy in another folder."
| Backup approach | Survives ransomware on the live system? |
|---|---|
| Nightly copy to a network drive on the same LAN | No — reachable and encryptable by the same attack |
| Cloud backup with versioning and immutability window | Yes — attacker can't overwrite prior versions |
| Offline/removable media, rotated and stored separately | Yes, if actually disconnected between backups |
| Backup nobody has test-restored in the last 6 months | Unknown — assume no until proven otherwise |
Billing partners, lab equipment vendors, radiology PACS providers and even canteen or asset-tracking suppliers frequently hold standing remote access into hospital systems for support purposes. This access rarely gets reviewed after initial setup. A practical minimum: every external vendor with system access should be on multi-factor authentication, should have access scoped only to the systems they actually service, and should be reviewed at least annually, not left in place indefinitely because nobody remembered to revoke it after a contract ended.
A simple audit any hospital can run this week: list every vendor who currently has remote access to any hospital system, note when that access was last used, and note whether it's still needed. Access that hasn't been used in six months and belongs to a vendor relationship that ended is the most common finding in this kind of review, and it's the easiest fix on this entire page — a five-minute task with no cost and no dependency on a bigger project.
ISO 27001 certification and SOC 2 Type II reports are increasingly referenced in hospital software procurement, particularly for larger multi-location groups. Both are useful signals that a vendor's information security management is externally audited rather than self-described. Neither substitutes for the operational basics above: a vendor with ISO 27001 certification whose hospital client still runs shared logins and untested backups has a certified process on paper and an unprotected hospital in practice. Certifications describe the vendor's own controls; the backup test, the named incident contact, and the vendor access review are the hospital's own responsibility regardless of what the software vendor is certified against.
Coverage of hospital ransomware incidents tends to focus on the ransom demand itself, which is often the smallest part of the real cost. The larger costs are operational: days or weeks of degraded or manual-fallback operations, the staff time spent reconstructing records that weren't cleanly backed up, the CERT-In reporting and remediation process, and, per the DPDP Act's notification requirement, the cost of formally notifying every affected patient if personal data was exposed. A hospital that has never priced out what a week of manual OPD registration and billing would actually cost in lost efficiency and duplicated paperwork tends to underestimate how much a functioning backup and incident-response process is actually worth, relative to its cost to set up.
Hospitals starting from zero shouldn't try to implement every item on the checklist above simultaneously. The realistic sequence: first, get an offline or immutable backup running and test-restore it once, even manually, to confirm it actually works. Second, name the one person who owns security incidents, even if that's a part-time role initially. Third, review vendor access and remove anything obviously stale, like a contractor's login from a project that ended a year ago. Fourth, only once those three are in place, formalise the CERT-In reporting process and the DPDP breach-notification procedure, since those depend on the first three actually functioning to have anything meaningful to report from. Trying to write an incident-response policy before a working backup exists produces a document, not a defence.
CERT-In Directions under Section 70B(6), Information Technology Act, 2000 (cert-in.org.in). Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology (meity.gov.in). Data Security Council of India, Cyber Threat Report 2025 (dsci.in).
Yes, for any entity connected to the internet, hospitals included. CERT-In's 2022 directions under Section 70B of the IT Act require reporting specified categories of cyber incidents within 6 hours of noticing them, and mandate that system logs be maintained within India for 180 days.
Under Section 8, a data fiduciary must take reasonable security safeguards to prevent a personal data breach, and must notify the Data Protection Board and affected patients if a breach happens.
Healthcare data is high-value and hospitals often run older systems with tight budgets and limited dedicated security staff, while downtime creates immediate pressure to pay a ransom.
An offline or immutable backup that ransomware encrypting the live system cannot also reach, tested by an actual restore at least quarterly.
Not inherently. A well-run cloud platform is usually more secure than an on-premise server nobody is actively maintaining, which is the common state in many tier-2/3 hospitals today.
Phishing emails and compromised third-party vendor access, such as billing, lab or radiology partners holding standing admin credentials, are the two most common entry points documented in recent Indian healthcare cyberattack reporting.
Both. Ransomware groups increasingly target smaller, less-defended facilities precisely because they lack dedicated security staff, making them faster to compromise even if the payout per incident is smaller.
See what CERT-In and DPDP compliance actually looks like inside a hospital ERP.
Talk to OneCity