CERT-In Incident Reporting for Hospitals: The Six-Hour Clock

The direction requires reporting within six hours of noticing an incident or being brought to notice about it. Read that phrase slowly, because it is the part hospitals get wrong. The clock does not start when the incident is confirmed, when root cause is understood, when the vendor replies, or when the managing director has been briefed. It starts at the moment somebody in your organisation becomes aware. In practice that is often a staff nurse ringing the helpdesk at two in the morning to say the nursing station screens are showing an unfamiliar message.

This forces a design decision. Your process has to be capable of producing a report on incomplete information, because six hours is not enough time to finish an investigation on a hospital estate of any size. CERT-In accepts an initial intimation and further particulars as they emerge, so the runbook should treat the first report as a factual snapshot rather than a conclusion. Waiting for certainty is how organisations miss the window and then have to explain a delay that looks, in hindsight, like concealment.

The trade-off is real and worth stating. A low reporting threshold means more reports, more management attention consumed by events that turn out to be benign, and in some contracts a notification trigger to insurers or corporate clients. That cost is genuine. It is still smaller than the cost of a late report on a live ransomware event, where the delay itself becomes the finding. Set the threshold low, name one person who can make the call at any hour, and give that person the authority to report without a committee.

The directions carry an annexure listing the incident types that must be reported mandatorily, and the list is broader than most hospital teams assume. Translated into hospital vocabulary it covers malicious code attacks including ransomware on any server, unauthorised access to your systems or data, data breach and data leak, defacement of your website or appointment portal, denial of service against patient-facing services, targeted scanning or probing of critical networks, attacks on identity through phishing and spoofing, compromise of email or social media accounts, fake mobile applications impersonating your hospital, and attacks on digital payment systems.

Two categories deserve particular attention in a clinical setting. The annexure covers attacks on internet of things devices, which in a hospital means infusion pumps, patient monitors, ventilators and building management controllers that sit on the network with firmware nobody has touched since commissioning. It also covers attacks on systems supporting critical infrastructure, which is a reasonable description of a hospital during a mass casualty event. Neither is a theoretical category, and neither is usually owned by the person who reads security bulletins.

The failure pattern is misclassification rather than dishonesty. A helpdesk ticket that reads printer not working turns out to be a print server that was reachable from a compromised workstation. A radiographer reports that the modality worklist has stopped populating and biomedical engineering treats it as an interface fault for two days. Both of those can be reportable events. The way to catch them is a triage rule that routes any unexplained loss of a clinical system to security review before it is closed as a technical fault.

Ownership has to be a named individual, reachable at any hour, with a named alternate. Most hospitals nominate the IT head or, where the role exists, the information security officer as the CERT-In point of contact, and communicate those details to CERT-In as the directions require. Update that nomination when the person leaves. A point of contact who resigned eighteen months ago is a compliance gap that shows up at precisely the wrong moment, and it is one of the easiest to close.

The runbook itself needs more than one function around the table. The medical superintendent or hospital administrator decides whether clinical services move to downtime working. The medical records officer knows which records were in flight. The data protection officer, or whoever carries that responsibility under the DPDP Act 2023, owns the separate notification duty described later. Biomedical engineering owns anything with a CDSCO registration on it, because a networked infusion pump is not an IT asset in any sense the vendor will accept. Legal and communications join once the facts stabilise.

Write down the decision rights before the event, not during it. Who can declare an incident. Who can disconnect a segment of the network knowing that it will stop OPD billing. Who authorises the report to CERT-In. Who speaks to a journalist. In an unrehearsed hospital these questions consume the first three hours, which happen to be the same three hours the six-hour clock is spending.

CERT-In publishes the reporting formats and channels, and the practical answer is to keep the current format saved locally rather than searching for it during an incident. Reports go in by email to the published incident address, with telephone and fax channels also available. The content is unremarkable once you have seen it: who you are, what you observed, when you observed it, what is affected, what you have done so far, and how you can be reached. The difficulty is not the form. It is assembling accurate facts at speed.

That assembly is much easier if the groundwork exists. An asset inventory that says which server runs the pathology module and which VLAN it sits on. A network diagram that is current rather than aspirational. Contact details for the HMS, PACS and LIS vendors that include an escalation path rather than a support portal. Log access that does not require raising a request with the same vendor whose system may be implicated. Hospitals that have these things file a competent report in an hour. Hospitals that do not spend the six hours looking for a diagram.

Keep a copy of everything you send, with timestamps, and record the internal timeline alongside it. When the first alert was raised, by whom, what was decided at each step. That record serves three separate purposes later: supplementary reporting to CERT-In, the DPDP evidence trail, and your own post-incident review. It is also the only defence against the reconstruction problem, where four people remember the same night four different ways.

Reporting to CERT-In does not discharge your obligations under the Digital Personal Data Protection Act 2023. These are two different duties, owed to two different bodies, on two different timelines, about two different things. CERT-In wants to know about a cyber incident so the national response can act. The Act is concerned with a personal data breach and with the people whose data it was. A hospital can have a reportable cyber incident with no personal data exposure, and it can have a personal data breach with no external attacker at all.

Under the Act the data fiduciary must intimate the Data Protection Board and each affected data principal of a personal data breach, and the notified rules set out the particulars and the timelines involved. Because that framework has been phased in, the sensible operating instruction is to hold the current notified text in your compliance file and check it at each review rather than working from an internal summary written when the Act was passed. The Schedule to the Act sets substantial financial penalties for failure to take reasonable security safeguards and for failure to notify a breach.

Practically, that means the incident runbook has two tracks running in parallel from the same set of facts. Track one is the six-hour technical report. Track two is a scoping exercise: which categories of personal data, how many data principals, whether the data was encrypted, what the affected individuals need to be told and in which languages. Track two is slower and it is the one hospitals under-resource, usually because it lands on a quality manager who already has an NABH assessment that month.

The only useful test of an incident process is an unannounced one at an inconvenient hour. Run a tabletop with a scenario your hospital could actually have: the PACS archive is unreachable at 11pm on a Saturday, radiology cannot retrieve priors, and a workstation in the reporting room is showing a ransom note. Do not tell participants the answer. Watch how long it takes for somebody to say the word incident out loud, because that moment is when your six hours started in the eyes of the direction.

Score the exercise on the things that actually fail. Could the on-call engineer reach the point of contact. Did anyone know where the network diagram lived. Did the team have log access without the vendor. Did clinical leadership get told, or did IT try to solve it quietly first. Was there a written record by the end. In most first exercises the technical response is adequate and the coordination is not, which is a comfortable finding because coordination is cheaper to fix.

Then close the loop with a small number of measures you review quarterly: mean time from first alert to declaration, the proportion of clinical system outages that received a security triage before closure, whether the point of contact details are current, and how many staff know the single number to call. HealUDoc activity logs can supply part of the evidence trail for the application layer, but the coordination work sits with the hospital and cannot be bought from a vendor. Rehearsal is the only thing that makes six hours a manageable number rather than an alarming one.