CERT-In Log Retention: 180 Days of Hospital System Logs

Application logs are where a hospital investigation is actually won or lost, and they are the layer most often left at default settings. From the hospital management system you want authentication events including failures, session creation and termination, patient record access with the identity of the record viewed, creation and amendment of clinical notes with before and after values, prescription and order entry, billing adjustments and discounts, print and export actions, and every change to a user account or a role definition. Read access matters as much as write access, because unauthorised viewing is the commonest form of patient data misuse.

From the picture archiving and communication system, capture study access and retrieval, DICOM query and retrieve transactions with the calling application entity title, exports to removable media or CD, changes to the modality worklist configuration, and administrative access to the archive itself. From the laboratory information system, capture result entry and verification with the verifying user, amendments to released reports, reference range and test master changes, quality control overrides, and analyser interface connections. These are also the events an NABL assessor asks about, so the logging work pays twice.

Be honest about what your systems can actually produce. Some hospital applications write a single application log with mixed operational and audit content, some write audit events into database tables that are not exposed for export, and some legacy modules log nothing useful at all. Establish that reality first with a written gap list, because a policy that assumes complete application logging across an estate that cannot deliver it is worse than a policy that names the gaps and schedules them for remediation.

Underneath the clinical applications sits the layer that answers how an attacker got in and where they went. Collect authentication and directory logs from your domain controllers, firewall traffic and administrative change logs, VPN session records, DHCP leases so an address can be resolved to a device, DNS query logs, endpoint detection telemetry, and administrative access to hypervisors, backup systems and storage. Backup system logs deserve a special mention: in a ransomware event, the first question after what happened is what happened to the backups, and that answer lives there.

Two hospital-specific sources are usually missed. The first is the medical device and building services segment, where infusion pump servers, monitoring central stations, pneumatic tube controllers and access control systems generate logs that no one collects because they belong to biomedical engineering or facilities rather than IT. The second is remote support access. Most hospitals grant standing remote access to at least half a dozen vendors, and unless those sessions are logged with an identifiable individual at the far end, a substantial part of your privileged activity is invisible.

Retention does not have to be uniform across sources. High-volume, low-value telemetry such as raw firewall permits can be summarised or sampled after a short hot window provided the underlying obligation is met, while identity and clinical record access events should be retained in full and searchable for the entire period. Write the tiering down as a documented decision with a reason attached, because an undocumented decision looks identical to an oversight when someone examines it later.

The directions require connection to the network time protocol servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them, and this is not a formality. Logs from twenty sources are only useful if you can put their events in one order. If the PACS server is eleven minutes ahead of the domain controller and the firewall is on a different time zone, the reconstruction of an incident becomes guesswork, and any conclusion you draw is contestable. Time synchronisation is the cheapest control on the list and the one whose absence quietly ruins the rest.

Build it as a hierarchy rather than pointing every device at an external source. Two internal time servers synchronise upstream to the national sources, all servers, network equipment and workstations synchronise to those two, and the configuration is enforced through group policy or device templates rather than left to individual builds. Store timestamps in a defined form, decide whether you are recording in Indian Standard Time or in UTC with offset, and be consistent, because mixing the two across sources produces exactly the confusion you were trying to avoid.

Then deal with the equipment that cannot participate. Older modalities, some analysers and a surprising number of embedded device controllers either do not support the protocol or have it disabled by a vendor configuration you are not permitted to change. Maintain a register of those exceptions with the measured drift for each, check them on a schedule, and record the correction so an investigator can normalise their timestamps afterwards. That register is a five-minute quarterly job that makes an incident timeline defensible.

Sizing starts with measurement, not with a vendor calculator. Turn on the logging you intend to keep for a representative week, including a Monday OPD peak and a weekend, and measure the events per second and the average event size per source. Multiply out to 180 days, add headroom for growth and for the incident weeks when volumes spike, and apply whatever compression your platform genuinely achieves rather than the figure on the datasheet. The number you get is usually larger than the first guess and smaller than the panic estimate.

As an illustrative example only, and with every figure here to be replaced by your own measurements: a mid-sized hospital sustaining 500 events per second at an average of 500 bytes per event generates roughly 21 gigabytes of raw log per day, which is a little over 3.8 terabytes across 180 days before compression. Whether that lands as a modest storage line item or a significant one depends entirely on your architecture, and the cost driver is rarely the raw capacity. It is the indexing and search tier, which is priced very differently from cold object storage.

That is why tiering is the main lever available to you. Keep a hot searchable window of perhaps thirty days where analysts work interactively, a warm tier for the remainder of the 180 days that can be searched with a slower restore, and cold immutable archive beyond that for anything you keep longer for other reasons. The trade-off is response time during an investigation, and it is an acceptable trade-off provided the restore path has actually been tested rather than assumed.

A hospital can meet the retention obligation and still be useless in an investigation, and this happens more often than non-compliance. The logs exist, in eleven different formats, on nine systems, three of which require a vendor to extract them, with user identifiers that do not match between systems because the HMS calls someone by employee code and the domain calls them by username. Six hours into an incident, that estate cannot answer a simple question like which accounts touched this patient record yesterday.

The fix is normalisation and identity mapping, done in advance. Bring sources into one platform, map the fields you will search on most into common names, and maintain a mapping between application user identifiers and directory identities so that one person resolves to one searchable entity. Then write and test the queries you already know you will need, rather than composing them under pressure. Ten saved searches covering the predictable questions turn a two-day extraction exercise into an afternoon.

Protect the logs themselves as well. Store them where a compromised administrator account cannot delete them, which in practice means write-once storage or a separate trust boundary, and record access to the log platform in the log platform. Assign a named custodian who can produce logs on a lawful direction, with a documented process for how a request is received, authorised and fulfilled. HealUDoc activity logs can feed the application layer of that pipeline alongside the encounter record, but the correlation work across sources is a hospital responsibility.

There is a genuine tension between keeping detailed logs for 180 days and the data minimisation principles that run through the Digital Personal Data Protection Act 2023. Access logs are themselves personal data, about staff as well as patients, and a log line reading that a named counsellor opened a named patient record can be sensitive in ways the raw event does not suggest. Treat the log platform as a system holding personal data, with its own access controls, its own retention schedule and its own entry in your records of processing.

Reconcile the two by being precise rather than by keeping less. Log the identifier of the record accessed rather than copying clinical content into the log. Restrict who can search the platform freely, and require a stated purpose for searches touching an identifiable individual. Keep the security retention period distinct from the clinical retention period, which is set by medical record rules and by your own NABH-linked policy, and make sure disposal at the end of each is actually executed rather than merely scheduled.

Finally, review the whole arrangement on a fixed cycle rather than after an incident. Confirm that every source on the inventory is still shipping, because silent log source failure is the most common finding in any log health check and it is invisible until the day you look for events that were never collected. Confirm that the storage location is still in India after a platform upgrade. Confirm that the person named as custodian still works here. None of that is difficult; all of it decays without a calendar entry.