An audit trail is useful only if it records the events your risk analysis says matter. Someone must also review those events. HIPAA requires audit controls for systems with electronic protected health information and procedures to review system activity. It does not prescribe one universal event list, review schedule, or six-year retention period for every log.
Start with the legal floor
The current HHS Security Rule summary says regulated entities need mechanisms to record and examine system activity involving electronic protected health information, or ePHI. It also requires procedures to verify identity, protect integrity, control access, and secure transmission.
Audit controls are only half of the work. The HHS HIPAA audit protocol looks for procedures to review audit logs, access reports, and security-incident tracking reports. It also looks for evidence that those procedures were used.
Translate that floor through the organization's risk analysis. System purpose, data sensitivity, user roles, integrations, threats, and response capability should determine what to log and how to review it. A vendor's default settings are evidence to inspect, not a complete policy.
Do not apply the six-year rule to every raw log
HIPAA sets six-year retention for specified policies and procedures. The same period applies to documentation of required actions, activities, or assessments. The Security Rule does not set one raw audit-log retention period for every system. HHS makes that distinction in its policies and documentation summary.
Set log retention through the risk analysis and other applicable rules. Consider investigation needs, system capacity, payer or contract terms, state requirements, litigation holds, backup behavior, and the period in which suspicious activity may be found. Document the chosen period and test that records remain usable for it.
Retain proof of required reviews and actions under the organization's documentation policy. A saved report with no reviewer, date, scope, finding, or follow-up is weak evidence that review occurred.
Define the event record
An event should answer enough questions to support detection and investigation without copying unnecessary clinical content into the log. Useful fields may include:
- actor or service identity and authentication context;
- action attempted and whether it succeeded;
- patient, record, or resource identifier at the minimum useful detail;
- timestamp with time zone and a synchronized clock source;
- source application, session, device, or network context when relevant;
- prior and new values for controlled changes;
- correlation identifier across queued or integrated events; and
- reason or destination when the workflow collects it.
Do not log passwords, secret tokens, full questionnaire narratives, or other content that the security team does not need. Logs create their own sensitive dataset. Apply access control, retention, backup, and disposal rules to them.
Cover the events that change risk
The risk analysis should decide the event catalog. For a mental health assessment workflow, candidates include:
- successful and failed authentication;
- account creation, deactivation, role change, and privilege elevation;
- assignment, delivery, submission, correction, and deletion of a questionnaire;
- view, print, download, report, and bulk export;
- score calculation and scoring-version change;
- reviewer acknowledgment and safety-route handoff;
- interface delivery, retry, rejection, duplicate, and patient mismatch;
- audit-setting change, log failure, and time-source failure; and
- administrator or support access to a production record.
For example, a PHQ-9 workflow may need separate submission, scoring, review, and export events. A generic “record opened” event cannot prove them. The log should identify the action without repeating the patient's answers.
Protect the evidence
Unique human accounts are essential for attribution. Give service accounts a named owner, narrow purpose, managed credentials, and separate monitoring. Record impersonation or support sessions as the support actor acting on behalf of another identity rather than erasing the distinction.
Restrict who can read, export, alter, disable, or delete logs. Monitor the administrators who control the logging system. Use integrity controls suited to the system, preserve time synchronization, and verify that backups and exports retain the fields needed for investigation.
No log is perfectly tamper-proof. State the control that exists and test it. “Immutable” is not a useful label if a privileged administrator can change retention, disable collection, or delete the storage account without a separate event.
Build a review process that ends in action
Define routine queries and event-driven alerts from known risks. Assign an owner, backup, frequency, evidence format, severity rules, escalation path, and closure criteria. A review can combine automated detection with human judgment, but the alert itself is not proof of review.
Look for context, not just odd hours. Legitimate crisis coverage may occur overnight. Examine access without an assigned relationship, unusual record volume, repeated denials, bulk export, and sudden privilege changes. Also check disabled controls, unexpected geography, and service accounts acting outside their purpose.
Record the review window, systems covered, filters used, exceptions examined, finding, action, and closure. Link confirmed incidents to the incident-response record. Preserve uncertainty when the logs cannot establish what happened.
An audit log is not the same as an accounting of disclosures under the Privacy Rule. It also does not automatically prove why access was allowed. Keep authorization, care-team assignment, disclosure, and incident records linked but distinct.
Test the trail before relying on it
Use non-patient records to create known events. Test successful and failed sign-in, blocked access, role changes, response views, corrections, and export. Then rotate a service credential, trigger an interface retry, and disable a test control. Confirm that each event has the expected actor, action, time, outcome, and context.
Then test the reviewer. Can the assigned person find the event, distinguish it from normal activity, document the decision, and escalate it? Repeat the test after a platform, identity provider, role model, integration, or retention setting changes.
The HIPAA assessment workflow guide places audit evidence in the wider data lifecycle. The vendor checklist covers contracts and representative tests before a third-party system handles ePHI.
A defensible audit program can show three things: the right events were recorded, the evidence was protected, and assigned people reviewed and acted on it.