It has been more than 20 years since HIPAA was enacted on August 21, 1996, and in those two decades it has seen quite a bit of change – especially with regards to its impact on IT professionals. First, with the HITECH Act which established the privacy, security, and breach notification rules in 2003, and then the issuance of the Final Omnibus Rule in 2013. Each advancement served to define the responsibilities of IT organizations to protect the confidentiality, integrity, and availability of electronic protected health information (PHI) – one of the central tenants of HIPAA – and stiffen the consequences for noncompliance. But, despite these changes, HIPAA’s enforcement agency (the Office of Civil Rights or OCR) did not begin to issue monetary fines against covered entities until 2011. And only in recent years, with the announcement of the OCR’s Phase 2 HIPAA Audits, did they begin to set their sights on Business Associates (BAs), those 3rd-party providers of services, which, due to their interaction with ePHI, are now legally required to uphold HIPAA.


2016, however, has seen increasing monetary fines, including a $5.55 million settlement by Advocate Health Care[1]. In 2013, the Advocate data breach released information about 4 million users. This breach occurred two years prior to the Anthem breach, disclosed in March 2015, which affected up to 80 million users, making it the largest health care data breach up to that point. Given the time it takes OCR to analyze and respond to data breaches, don’t expect to see any Anthem data breach analysis from OCR in 2016.


In the meantime, OCR is implementing their Phase 2 audits. This round of audits delves more deeply into organization policies with business associates, and examines some documents from live workflows. Some organizations have already received notification of their Phase 2 audits, which were sent on July 11, 2016. A total of 167 entities were notified of their opportunity to participate in a “desk audit,” which would examine their HIPAA implementation against the new Phase 2 guidelines. This initial audit will cover 200-250 entities, with most of them being completed via the desk audit process. A few entities will be selected for onsite audit[2].


What is a Phase 2 Audit?

First, Phase 2 audits cover both Covered Entities (CEs) and Business Associates. (Recall that the Final Omnibus Rule held CEs and BAs joint and severally liable for compliance). In the pilot phase audits, only Covered Entities were examined. Second, in this phase most of the audits will be completed via a “desk audit” procedure.


A desk audit is a nonintrusive audit where the CE or BA receives an information request from OCR. The information is then uploaded via a secure portal to a repository. The auditors will work from the repository to generate their findings.


Based on the updated Phase 2 audit guidelines, Phase 2 audits will cover the following areas.


Privacy Rule Controls

Uses and Disclosures; Authorizations; Verifications

Group Health Plans

Minimum Necessary Standard; Training

Notices; Personnel designations

Right to Access; Complaints

Security Rule Controls

Assigned Responsibility; Workforce Security

Risk Analysis and Risk Management

Incident Response, Business Continuity and Disaster Recovery

Facility and BA controls

Access Control and Workstation Security

Data Breach

Administrative Requirements

Training; Complaints


Breach; Notice


What is different from previous audits is the format of the audit (desk audit vs onsite) and the focus on reviewing not just policies, but worked examples of policy and procedure implementation[3] using actual samples of the forms and contents, as well as the outcomes of the requests contained within the forms. The complete list of all the elements of these initial Phase 2 audits is extensive. You can read the complete list on the HHS website.


Phase 2 audits require data or evidence of the results of an exercise of some of the HIPAA policies or processes. From an entity perspective that takes the audit to a practical level.


Turning specifically to the audit of security controls, most IT and security pros who have been through an IT risk assessment or an ISO audit will be familiar with the HIPAA audit structure. The approach is traditional; comparing policies to evidence the policy has been correctly implemented.


If you have not been through an audit before, don’t panic. Here are some basic rules.


  1. Be prepared. Review the evidence you will need to provide. Wherever possible, gather that evidence in a separate data room.
  2. Be respectful. Even if this is a desk audit being completed via portal, provide only the evidence asked for, in a legible format, within the time frame requested.
  3. Be honest. If you don’t have the evidence requested, notate that you don’t have it, yet. If you have implemented the control, but just don’t have the evidence, provide documentation of what you have implemented.
  4. Be consistent. To the extent possible, use the same format for providing evidence. If you need to pull logs, put them into a nicely formatted, searchable spreadsheet.
  5. Be structured. Make it easy for the auditor to find and examine your responses. If you need to provide policies, have them neatly formatted in the same font and structure. It’s especially nice if you are an auditor reading lots of documentation to have good section headings and white space between sections. PDF is the most advisable format, but make it searchable for ease of verification.


Recall that the purpose of the Security Rule is to ensure two main things:

  1. That ePHI is correct, backed up, and accessible.
  2. That only appropriate, authorized users and processes have access to ePHI.


You can expect that you will need to provide evidence, mostly logs, that cover the controls that ensure the purpose of the Security Rule is being met. For example:

  1. Who is the responsible security officer, and what is their job description?
  2. When was your risk assessment completed?
  3. Have you implemented any remediation or compensating controls identified in your risk assessment?
  4. Can you demonstrate evidence that security violations are being identified and remediated? Expect your incident response procedures to be examined.
  5. Can you demonstrate that the workforce is complying with your security policies and procedures, including security training?
  6. Can you demonstrate that those who need access to ePHI can do so, and that when authorization is revoked (due to change of status, termination, etc.), that the electronic access is changed as well?
  7. What evidence can you show of anti-malware compliance?
  8. Are your cryptographic controls in place and up to date?  [Hint: see our blog post on PCI DSS 3.2 updates for information on SSL/TLS]
  9. Are your disaster recovery and business continuity plans actionable and tested? Include facilities access plans, which should address physical unauthorized access attempts.
  10. Have you implemented all of the access controls and policies required to share data with BAs?
  11. Can you demonstrate compliance with de-identification disposal requirements of electronic media upon change or de-activation?
  12. Don’t forget contracts. Even though you may be responsible for mostly technical controls, the Security Rule does have requirements for your contracts with BAs.


As with most compliance schemes, a number of the requirements are well understood standard security best practices. As our panel at THWACKcamp [See the Shields Up Panel Recap] agreed, the old adage, “If you are secure you are probably compliant,” applies to HIPAA, too.

Have you had a recent audit experience you’d like to share?  Please comment on this post. We can all learn from each other’s experiences. Happy auditing!