fbpx
14
Aug
2014

Retaining Data for a HIPAA Audit

By HIPAA Vault

HIPAA guidelines regarding data retention state that the logs (access/activity) and protected health information (PHI) documentation proving that the covered entity is adhering to the HIPAA Security Rule are retained for six (6) years. This regulation mandates that records are to be retained for essentially any interaction with patient PHI and personally identifiable information (PII), which is covered under HIPAA.

In the event that a breach has occurred or is alleged to have occurred, it is important to be able to prove that the Security Rule and the other facets of HIPAA have been followed. An audit trail is a recorded log of sequential activities, documenting who did what to which data (and when). At its most basic form, that is all “audit trail” refers. However, in HIPAA hosting tasks when PHI is involved, the term audit trail usually refers to specific log files and user access controls. HIPAA requires that internal audits of this data are performed regularly, and indeed, periodic review can show where bottlenecks and weak spots are in the process tree. In the event that a breach has occurred, it is required by HIPAA laws that the covered entity be able to produce this information when subpoenaed.

The verbiage that pertains to data retention requirements is vague in the actual documentation, but the rule of thumb is that if it possible to retain it, it is probably a good idea to do so. At the bare minimum, logging access, user accounts, and modification times is imperative, but there is a wide swath of “best practices” to which others recommend. For example, in internal audits, it is recommended to link all actions to a user account, especially those that require administrator privileges. Automated logging and audit tracking should include: individual access to PHI, any actions taken by a superuser account {root or Admin}, invalid or failed login attempts, user account creation, log file creation/editing, and installation/removal of software or system configuration options. In the event of an audit, many of these items can become problematic if not properly logged. When curious about exactly who did what, it is unlikely that only one user would have had the authorization to take that specific action. Even in the event there was only one authorized account, it is possible that a poor-practice habit of providing a non-administrator account with access is used as commonplace to save time. These are the types of things of which a stringent audit trail should be keeping track of.

Below are some recommended items for auditing:

  • Account access
  • User events
  • Event types (file creation, deletion, modification, etc.)
  • Timestamp
  • Success/Failure
  • Data modification

Once this information has been secured, it is imperative that these logs be configured so they cannot be altered. They must be reviewed frequently to ensure they are functioning properly. Most importantly, this data should be retained for six years. With a long and well-configured audit trail, in the event of a false accusation, the true turn-of-events will be able to be reconstructed well-enough to absolve someone of culpability.

 

Our certifications