CERT-In's 2022 directions for hospitals: 6-hour reports, 180-day logs and clock sync

The short answer

CERT-In’s directions of 28 April 2022, issued under section 70B(6) of the IT Act, ask covered organisations to do four things a hospital IT team feels directly: report listed cyber incidents to CERT-In within 6 hours of noticing them; keep logs of all ICT systems securely for a rolling 180 days within India; sync system clocks to NIC or NPL time servers; and name a point of contact for CERT-In.¹¹

The directions took effect 60 days after issue, and not following them may invite action under section 70B(7) of the IT Act.¹ This is a summary, not legal advice.

Who the directions cover

The directions name service providers, intermediaries, data centres, body corporates and government organisations.¹ Hospitals run by companies are body corporates, and government hospitals are government organisations. A hospital run by a trust or society should ask its counsel how the definitions apply. Either way, the practices below are sound security hygiene, and the DPDP Rules ask for related things from 2027.

Six hours to report

Direction (ii) asks for incidents listed in Annexure I to be reported within 6 hours of noticing them or being told about them.¹ The list is long. The entries most likely in a hospital:¹

• unauthorised access of IT systems or data;
• data breach and data leak;
• malicious code, including ransomware;
• attacks on servers such as databases and mail;
• attacks on cloud systems;
• attacks on, or suspicious activity affecting, systems related to artificial intelligence and machine learning.

Six hours means the report goes in before you understand the incident. Prepare a short form with what you know, and update it later:

• which system or service is affected, and where it runs;
• what was seen, by whom, and at what time (in synced time, see below);
• whether patient data may be involved;
• what has been done so far, such as accounts disabled or systems isolated;
• who CERT-In should call back.

Keep the form with the on-call runbook, not on a shared drive that may be encrypted in the incident.

The DPDP Rules add a separate report to the Data Protection Board, with a 72-hour detailed follow-up, for personal data breaches.² Our breach notification post lays the two clocks side by side.

180 days of logs, in India

Direction (iv) asks organisations to enable logs of all their ICT systems and keep them securely for a rolling 180 days within Indian jurisdiction, and to hand them to CERT-In with an incident report or when directed.¹

Three questions to ask of each system:

The DPDP Rules then ask for logs of access to personal data, kept for one year.² If you’re setting retention once, setting it for a year covers both.

“Securely” is worth taking seriously. A log that anyone with admin rights can edit tells an investigator little. Write logs to a separate system, restrict who can delete them, and consider sealing them so later changes show. Our post why logs aren’t evidence explains the difference.

One clock for every system

Direction (i) asks all ICT system clocks to sync with the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or with servers traceable to them.¹

This sounds minor until you reconstruct an incident. If the firewall, the EMR and the AI vendor’s API each keep slightly different time, you can’t line up who did what first. In a hospital, check the systems that are easy to forget: modality workstations, nurse-station PCs, lab analysers’ interface servers, and any cloud tenant that keeps its own time.

A point of contact

Direction (iii) asks each organisation to designate a Point of Contact to interface with CERT-In and send the details in the format in Annexure II.¹ Name a primary and a deputy, keep the details current, and make sure the person can file a report at night and on Sundays.

AI systems are on the list

Annexure I explicitly lists attacks and suspicious activity affecting systems related to artificial intelligence and machine learning.¹ For hospitals adding AI scribes, chat assistants and agents, that has two consequences:

1. The AI tool’s activity belongs in your logs. If an AI integration account starts pulling far more records than usual, you need a log line that shows it, kept for 180 days.
2. The AI vendor’s logs may be needed in an incident. The contract should say the vendor keeps logs, where, for how long, and how fast it gives them to you.

The India AI Governance Guidelines go a step further and suggest that existing incident reporting, such as CERT-In’s, be used to monitor vulnerabilities in AI systems across critical sectors.³

A hospital IT checklist

1. List every ICT system, including vendor-hosted ones and AI tools.
2. For each: logging on, 180 days kept, stored in India, access to delete restricted.
3. Point every system’s clock at NIC, NPL or a traceable source.
4. Register the point of contact and a deputy.
5. Write the 6-hour report template and practise filling it.
6. Put log retention, location and incident notice in every vendor contract.
7. Rehearse one incident a year, end to end.

For the personal data side of the same incident, read the DPDP Rules for hospitals overview. For what Deedglass does around AI agent writes in hospitals, see /healthcare.

To try the checks on synthetic data, open the playground in your browser. To see what an AI agent on your machine can change, run npx deedglass scan (what the grade means) or paste its MCP config into /check; neither uploads your data. Our AI agent permissions report shows what public agent setups commonly leave open.

Written with AI assistance and checked against our claims register.