HIPAA requires audit controls that record and examine activity in systems holding electronic protected health information (ePHI), and procedures to review that activity regularly. It does not prescribe one event list or review schedule, and it does not set a six-year retention period for every raw log. An audit trail is useful only if it records the events your risk analysis says matter and an assigned person reviews and acts on them.
What does HIPAA require for audit trails?
The HHS Security Rule summary says regulated entities must implement mechanisms to record and examine activity in information systems that contain or use ePHI. The same technical safeguards cover access control, integrity, authentication of the person seeking access, and transmission security. The HHS audit protocol also lists a required unique name or number to identify and track each user.
Recording is only half of the duty. The Security Rule also requires procedures to regularly review records of system activity, such as audit logs, access reports, and security incident tracking reports. The audit protocol asks for those procedures and for documentation of the reviews themselves. It checks whether reviews were timely and whether appropriate personnel conducted them.
HHS's 2017 audit controls newsletter says the rule does not specify what an audit log must collect or how often to review the reports. Instead, each organization must consider its risk analysis results and factors such as its technical infrastructure and its hardware and software security capabilities. System purpose, data sensitivity, user roles, integrations, threats, and response capability should decide what you log and review. A vendor's default settings are evidence to inspect, not a complete policy.
How long should audit logs be kept?
No single period applies to every raw log. The Security Rule requires six-year retention for written policies and procedures. The same applies to records of any action, activity, or assessment it requires to be documented. That period runs from creation or from the date the document was last in effect, whichever is later. The HHS summary describes this documentation duty, and neither it nor the audit controls standard names a retention period for raw audit logs.
Set log retention through the risk analysis and any other rules that apply. Consider investigation needs, system capacity, payer or contract terms, state requirements, litigation holds, backup behavior, and how long suspicious activity may take to surface. Document the chosen period and test that records stay usable for all of it. Keep 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.
What should each audit event record?
Each event should show who acted, what they did, to which record, when, and with what result, without copying clinical content into the log. Capture the actor or service identity and its authentication context, the action attempted, and whether it succeeded. Identify the patient, record, or resource at the minimum useful detail. Use a timestamp with time zone from a synchronized clock, plus the source application, session, device, or network context when relevant.
For controlled changes, keep the prior and new values. Add a correlation identifier that links queued or integrated events, and the reason or destination when the workflow collects it. Do not log passwords, secret tokens, full questionnaire narratives, or other content the security team does not need. Logs become a sensitive dataset of their own, so apply access control, retention, backup, and disposal rules to them.
Which events should a mental health practice log?
Let the risk analysis decide the event catalog, starting with the events that change risk. For a mental health assessment workflow, check whether the system records each of these:
- Successful and failed sign-ins
- Account creation, deactivation, role change, and privilege elevation
- Questionnaire assignment, delivery, submission, correction, and deletion
- Views, prints, downloads, reports, and bulk exports
- Score calculation and scoring-version changes
- Reviewer acknowledgment and safety-route handoffs
- Interface delivery, retry, rejection, duplicate, and patient-mismatch events
- Audit-setting changes, logging failures, and time-source failures
- Administrator or support access to a production record
Each step needs its own event. A PHQ-9 workflow may need separate submission, scoring, review, and export events, and a generic “record opened” event cannot prove them. The log should identify each action without repeating the patient's answers.
How do you protect audit logs from tampering?
Attribution starts with unique human accounts. Give each service account a named owner, a narrow purpose, managed credentials, and separate monitoring. Record impersonation or support sessions as the support actor acting on behalf of another identity, so the log keeps that distinction.
Restrict who can read, export, alter, disable, or delete logs, and monitor the administrators who control the logging system. The 2017 newsletter says access to audit trails should be strictly limited to authorized personnel. Use integrity controls suited to the system, keep clocks synchronized, and verify that backups and exports retain the fields an investigation needs. No log is perfectly tamper-proof, so 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.
How should someone review the audit trail?
Define routine queries and event-driven alerts from known risks. Assign an owner, a backup, a frequency, an evidence format, severity rules, an escalation path, and closure criteria. A review can combine automated detection with human judgment, but an alert by itself is not proof of review.
Look for context, not just odd hours, because legitimate crisis coverage may happen 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, and 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 prove by itself why access was allowed. Keep authorization, care-team assignment, disclosure, and incident records linked but distinct.
How do you test the audit trail?
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 shows the expected actor, action, time, outcome, and context.
Next, test the reviewer. Can the assigned person find the event, tell it apart from normal activity, document the decision, and escalate it? Repeat both tests after a change to the platform, identity provider, role model, integration, or retention settings. 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.