The Compliance Equation: Demystifying Compliance Audits


As an initial matter the term audit does not appear anywhere in the HIPAA Security Rule outside of the context of controls. There is no mention of an audit as is commonly thought of when discussed in the abstract, as in a financial audit. To be specific the Security Rule contains no reference to the word audit that approximates its dictionary definition: “to make an audit of; examine (accounts, records, etc.) for purposes of verification.” The same is true for the HIPAA Privacy Rule and Breach Notification Rules.

That said, the Office of Civil Rights (“OCR”) which manages HIPAA enforcement certainly does discuss its audit protocols, and when it conducts audits the dictionary definition above is certainly on point. With respect to the HIPAA Security Rule, risk assessments are certainly a form of self-assessment and evaluation but remain contextually distinct from a financial audit or an OCR audit. The Security Rule also specifies that certain controls must be audited, but the latter is a narrow use of the term. Although risk assessments performed annually, or better still quarterly, has an emerged as an industry best practice, it is not a mandated requirement of the Security Rule.

In general, OCR recommends that minimally you perform a baseline risk assessment, a risk assessment when your operational environment changes in a substantive manner (e.g., you move it), and when there are material changes to the law. Therefore, when HIPAA vendors indicate that a yearly audit is required it amounts to nothing more than marketing speak, especially if used in the context of a financial or OCR audit.

In short, it is a clever and often lucrative manner of selling professional services, that gives the organization the illusion of compliance, as discussed below, but not required by law.

Heavyweight versus Lightweight Audit Processes

An audit equivalent to an OCR or financial audit is not required by law. Certainly, knowledge of OCR audit principles helps prepare an organization to argue that they are HIPAA compliant, but too often what vendors sell are complex heavyweight processes (SOC2, HITRUST, ISO 27000 etc.) that are so complicated only their “high priests” (mentors, coaches, subject matter experts, etc.) understand it, with the obvious implications that you have to purchase their professional services, year in and year out, to ensure compliance.

Heavyweight Processes are Inherently defective

Heavyweight processes force an organization to follow the vendor’s proprietary audit methodology, which is often purposely and needlessness complex. For example, to determine whether an organization complies with a respective regulatory regime, the heavyweight methodology almost always requires the organization to answer dozens of questions per requirement, most of which are not necessary as discussed below. Although this may give the appearance of rigorousness, it is nothing more than a sophisticated way to hide the fact that the methodology, at the end of the day, captures nothing but a static view of compliance at a point in time, and often only provides a yes/no answer to compliance with a respective requirement, when often a requirement’s state of compliance is more nuanced (e.g. missing, planned, basic, functional, excellent etc.), second, the result of the audit process is usually nothing more than a report which captures organizational compliance at the time completed. It is a static view of organizational compliance. The principal deliverable is paper, perhaps with remediation recommendations. However, remediation remains the responsibility of the organization.

Agile Compliance

Agile Compliance is derived from best practices originally implemented by the software industry over the last two decades. This approach values human communication and feedback, close collaboration with customers, adapting to changes, and producing working results with each sprint. A sprint generally last between 2-3 weeks. Instead of capturing requirements directly from the consumers of the proposed software, Product Owners (i.e., a role that has evolved in the software industry over the last decade) create “stories” that represent what the users want.

The Product Owner must have deep understanding of the subject matter domain targeted and of cross-functional process flows between silos that the solution impacts. The Agile approach favors intuitive software over extensive training and documentation. Working software is produced during each sprint so that the “story” (i.e., the end users’ requirement) can be validated in short order. The Agile challenge is that there remains a dearth of Product Owners that have the required skillsets to perform their respective roles effectively. An organization is fortunate if they have Products Owners that are good at what they do, let alone excel in their roles. This remains true even though Agile has dominated the software industry for over twenty years. Why? Because Product Owners require deep process skills, and these are hard to come by. There are no academic programs that we are aware of that provide the foundational skills, and assuming there were, these process skills are hard won only through actual experience. Product Owners communities have exploded throughout the U.S. to fill this gap.

Agile Audit Processes Deliver on the Promise

We introduced the term “Agile Compliance” over a decade ago. The term has caught on and is now widely used, not only in compliance, but in the other disciplines as well. However, the compliance industry has by and large only paid lip service to the concept. It certainly has not been widely adopted. In fact, the opposite is true, heavyweight processes continue to dominate. Below we provide an example of how an Agile methodology can be used to demystify Compliance Audits and provide audit results of higher quality in a significantly shorter period.

The Compliance Equation®

The Compliance Equation postulates that a compliance regime requirement requires that three elements must be present to determine whether an organization complies with a requirement. 

  1. Policy (which describes what an organization intends to do to comply).
  2. Processes (that are actualized in the organization and underpin the Policy).
  3. Tracking Mechanisms (the ability to capture process results providing evidence of compliance).

If all three are present then an organization can legitimately claim compliance with a respective requirement, otherwise it can’t. The Compliance Equation® is axiomatic and applies across all compliance regimes. Below is an example of a Checklist Item (“CLI”). Our Privacy Checklist contains a CLI for every requirement of the Privacy Rule:ChecklistExThe graphic above makes it obvious that this is not a yes/no checklist for each requirement. A CLI contains the following elements:

  1. A description of the requirement.
  2. A reference to the regulations that is clickable if use want to read the law as it currently exists.
  3. A Policy statement (i.e., first element of the Compliance Equation®) that can be used out-of-box (e.g., our model Privacy Rule Policy represents an aggregate of the policy statements contained in our CLIs).
  4. Recommended processes (i.e., second element of the Compliance Equation) each organization must implement analogous processes that underpin the Policy, some in fact may already exist.
  5. Recommended Tracking Mechanisms (third element of the Compliance Equation) which provides visible demonstrable evidence that in fact the processes are actualized in your organization.

The third element is by far the most important vis-à-vis any audit, internal or external. Why? Because its evidentiary value carries more weight from an auditor’s perspective.

An Agile Audit

Because our checklists for the Privacy Rule and Security Rule contain a CLI for each requirement, then an audit consists of walking through CLIs and asking only one question: “Does this requirement satisfy the Compliance Equation®?” If the answer is “yes” then you can make a good faith argument that you comply, if “no” then you can’t.

Remember, as discussed above, that you can answer “yes” even though your compliance has a value of “Basic” according to our Scorecards. Instead of answering dozens of questions per requirement, our Agile audit process requires that you only ask one.

Further, it allows you to score the requirement and thereby eliminates the static nature of the requirement’s score. The score can be modified higher or lower, in real time, as you discover (e.g., through risk assessments) that its value is no longer representative of the last audit.


To claim the benefits of Agile compliance your initiative must reflect it in a manner that provides effective results, and a dramatically reduces cost. A heavyweight process is readily recognized by the complexity inherent in it. An Agile process should be readily easy to understand. We deliver mature compliance programs with an Agile process embedded in-the-box. There is no need to invent it. Once you understand our Agile methodology you won’t need a team of consultants to help you conduct an audit year in and year out. In fact, you can conduct them more frequently as the need arises.