Retaining access logs for healthcare breach notifications
A breach notice is only as good as the evidence behind it. In a healthcare setting, the useful records are rarely the pretty dashboards. You need raw access logs, authentication records, file events, and whatever ties a request to a specific record or export.
That matters when a processor sits between providers and patients. The patient may never have a direct account with the system that was hit, which makes notification harder to explain and harder to support. If the investigation starts weeks after the intrusion, and notices go out months later, you need enough history to show the scope without guessing at it.
Keep the logs long enough to reconstruct who saw what
Retention has to outlast the breach response window, not the detection window. If a server breach is detected on one date and file access is later pinned to a separate multi-day period, the investigation needs logs covering both points and the gap in between. Short retention leaves you with a clean system and no evidence.
For healthcare breach notifications, that usually means keeping:
- access logs for file and record activity
- authentication and session logs
- admin and privilege logs
- export and download events
- audit trails that show record-level access
The useful part is the link between event and identity. A log line that says a file was touched is weak on its own. A line with a timestamp, user ID, source address, and record identifier can be used to trace exposure across a long chain of systems. Without that, you only know something happened. You do not know which patient data moved.
Set retention around notification windows and investigation lag
Retention should cover the longest realistic path from intrusion to notice. Healthcare breach notifications can land long after the initial activity, especially when forensic work takes time and provider-side records must be matched to processor-side events. That lag is not rare enough to ignore.
The minimum useful window is not just the time since detection. It also has to cover:
- the access period before detection
- the investigation period after detection
- the time needed to confirm exposed record sets
- the period before notices are mailed or published
If you only keep logs for operational troubleshooting, they may expire just as the legal and forensic work starts. That is a bad trade. You save disk space and lose the evidence needed to prove what was exposed, which patient records were touched, and whether the access was limited or broad.
Preserve access trails with timestamps, user IDs, and record identifiers
Timestamps without identities are thin. Identities without record identifiers are not much better. The trail needs enough detail to connect a person, a session, and a specific record or file. That is what lets investigators separate a routine support task from unauthorised access.
A decent trail usually includes:
- precise event time
- unique user or service account ID
- action taken, such as read, export, copy, or delete
- source system or host
- patient or record reference
- outcome or error state
When those pieces are present, incident reconstruction becomes much cleaner. You can line up file access against authentication events, spot unusual bursts, and match the accessed files to the records named in notifications. If you cannot tie the logs back to records, your notice may be accurate only at a very high level. That is usually not good enough.
Separate operational logging from evidence-grade retention
Operational logs are there to keep the lights on. Evidence-grade retention is there to survive an incident. Those are not the same job, and they should not share the same expiry rules.
A practical setup keeps short-lived high-volume logs for day-to-day monitoring, then copies the relevant security records into a protected store with tighter controls and longer retention. Access to that store should be restricted, logged, and reviewed, because the evidence is now part of the incident response chain. If someone can alter it quietly, the whole record set becomes suspect.
For healthcare breach notifications, the real failure is often not missing alerts. It is missing history. By the time the notices are drafted, the only thing left that can answer hard questions is the access record, and that record is only useful if it still exists.
