info@cetonix.com +91 (966) 512-1196 Mon–Fri, 09:30–18:00 IST
HomeInsightsHIPAA §164.308(a)(8): The Technical Evaluation Nobody Docu

HIPAA §164.308(a)(8): The Technical Evaluation Nobody Documents

There is no HIPAA certification. There is a Security Rule requirement for periodic technical evaluation, and most organisations cannot evidence it.

Compliance Cetonix
HIPAA §164.308(a)(8): The Technical Evaluation Nobody Documents

First, the correction that this topic always needs: there is no such thing as HIPAA certification. The US Department of Health and Human Services does not recognise, endorse or accredit any HIPAA certification, and no certificate provides a safe harbour in an OCR investigation. Vendors selling one are selling a document with no regulatory standing.

What the Security Rule does require is considerably more specific, and most organisations we assess cannot evidence it.

The two provisions that matter

§164.308(a)(1)(ii)(A) — Risk analysis. Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the covered entity or business associate. This is a required implementation specification, not addressable.

§164.308(a)(8) — Evaluation. Perform a periodic technical and non-technical evaluation, based initially upon the standards implemented under this rule and subsequently in response to environmental or operational changes affecting the security of ePHI, which establishes the extent to which policies and procedures meet the requirements of this subpart.

Read that second one carefully. It requires a technical evaluation, performed periodically, and repeated in response to changes. It does not prescribe a penetration test, but a technical evaluation of systems handling ePHI is precisely what a penetration test produces.

Why organisations fail this

Rarely because they do nothing. Usually because what they do is not documented in a form that survives scrutiny.

The recurring gaps:

  • A questionnaire instead of an assessment. A completed spreadsheet of yes/no answers is not an accurate and thorough assessment of risks and vulnerabilities.
  • No technical component. Policies reviewed, controls discussed, no system tested.
  • Performed once. “Periodic” means recurring. A risk analysis from four years ago does not evidence a current position.
  • Not repeated after change. A significant platform migration, a new integration or a new mobile application changes the risk picture and triggers the requirement again.
  • No risk management output. §164.308(a)(1)(ii)(B) requires that identified risks be reduced to a reasonable and appropriate level. Findings with no remediation record evidence that you found problems and left them.

What good evidence looks like

A written risk analysis identifying where ePHI lives, how it moves, and what threatens it — with reasoning, not just conclusions. A technical evaluation of the systems that create, receive, maintain or transmit ePHI. Findings mapped to the specific safeguards they affect, so the link between the test and the rule is explicit. A risk management plan showing what was done about each finding. Retest evidence closing them.

Mapping findings to safeguards is the step most often skipped and the one that makes the evidence usable. An investigator or an enterprise customer reading a generic report has to construct the link themselves; a report that states it does the work for them.

Testing where minors’ data is involved

Where systems hold children’s data — paediatric care, school health programmes, identity platforms serving educational institutions — FERPA and COPPA may apply alongside HIPAA, and testing should be designed accordingly.

Our practice is that records are counted and classified rather than copied. Where a vulnerability exposes data, we record how many records were reachable and of what type, and stop at the minimum needed to evidence the finding. Children’s data and images are masked in every copy of the report, including the client’s own. The count is what a risk team needs; the records themselves create an exposure that outlasts the engagement.

Business associates

If you process ePHI on behalf of a covered entity, these obligations apply to you directly, not merely through your business associate agreement. The 2013 Omnibus Rule made business associates directly liable for Security Rule compliance. Your covered-entity customers are increasingly asking for evidence before renewing, and a technical evaluation is the evidence they ask for.

← JWT Algorithm and Key Confusion: Still Working in 2026Offline-Capable Mobile Apps: When You Push Trust to the Device →