HIPAA Monitoring Implementation Guide

The HIPAA Security Rule's Technical Safeguards (§164.312) include two directly relevant requirements: §164.312(b) Audit Controls — 'implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI' — and §164.312(c) Integrity Controls — mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

The Breach Notification Rule (§164.400–414) additionally requires the ability to determine, within 60 days of discovery, the nature and extent of a breach, the ePHI involved, and the persons to whom it was disclosed. This investigative capability requirement drives the need for a queryable evidence trail extending back at least 6 years (the HIPAA document retention minimum).

OCR enforcement actions consistently penalise organisations for three failures: lack of access controls that log who accessed ePHI, inability to produce audit logs during investigation, and absence of a process to regularly review audit logs. ManySignal addresses all three.

Identify every system that stores, processes, or transmits ePHI: EHR/EMR systems (Epic, Cerner, Athenahealth), claims processing systems, billing systems, PACS (imaging), and any SaaS application with PHI data (Salesforce Health Cloud, Workday for HR data). Each becomes a log source in ManySignal.

For each ePHI system, ingest at minimum: authentication events (who logged in), access events (which records were viewed or modified), export events (data exported or downloaded), and admin events (user account and permission changes). The ManySignal OCSF normalisation maps these to standard event classes regardless of source-specific log formats.

Curiosity access: a user accessing patient records for patients who are not in their care assignment. This requires integration with the EHR's care team data — the entity graph links provider identity to assigned patient population, and any access outside that population is flagged. This is the most common HIPAA violation pattern and the most frequently investigated by OCR.

Bulk access: a provider or staff member accessing significantly more records than their historical baseline in a short period — even within their assigned patient population. This pattern covers data exfiltration for commercial purposes (selling patient data) and is a reportable breach regardless of whether the records were all technically accessible.

External transmission: ePHI exported to an external destination (personal email, USB drive, unapproved cloud storage). Detect via email DLP integration for external forwarding, endpoint DLP for removable media, and cloud app controls for uploads to non-approved SaaS.

HIPAA's 60-day breach notification clock starts at 'discovery' — which OCR defines as when the organisation knew or should have known about the breach. A security monitoring programme that would have detected the breach but didn't (because of gaps in logging or analysis) does not reset the clock; OCR treats it as constructive knowledge.

When ManySignal detects a potential ePHI access breach, the investigate agent automatically constructs a preliminary breach scope report: identities involved, ePHI systems accessed, records potentially viewed or exported, and timeline. This report is the starting point for the 60-day notification analysis — it is produced in hours, not days.

For OCR investigations and HIPAA audits, ManySignal generates a structured evidence package: the audit log configuration (which sources are ingested, at what retention, with what controls), the detection catalogue (which detections are active for ePHI systems), the case timeline for any investigated incidents, and the periodic access review reports.

The evidence package maps each HIPAA Technical Safeguard to the specific ManySignal capability that satisfies it. This mapping document, reviewed and signed by the Security Officer, becomes the primary audit evidence artefact for the technical safeguard controls.