Most HIPAA risk assessments fail in the same place: they are either a compliance checklist filled out by someone who has never touched the infrastructure, or a technical scan with no mapping back to the actual regulatory requirement. Neither survives a real audit or a serious breach investigation. Here is a two component methodology that closes that gap, built for security teams and consultants who need output that is both technically accurate and defensible under 45 CFR 164.308(a)(1).
Why a Single Method Is Not Enough
The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of potential risks to electronic protected health information (ePHI). The word thorough is doing a lot of work in that sentence. A pure interview based assessment captures administrative and physical safeguards well, but it depends entirely on what the interviewee knows or is willing to disclose about their own environment. A pure technical scan captures live misconfigurations accurately, but has no way to evaluate policy, training, or access governance, all of which HIPAA explicitly requires you to assess.
The fix is running both in parallel and reconciling the results.
• Component One: Structured Interview Against NIST 800-66
NIST Special Publication 800-66 is the implementation guide HHS itself points to for translating the Security Rule into actionable controls. We use it as the interview skeleton rather than inventing a custom questionnaire, because it maps cleanly to the administrative, physical, and technical safeguard categories auditors expect to see addressed.
The interview walks through each safeguard category and asks the entity to describe, not just confirm, their current control. “Do you have an access control policy” gets a yes or no that means nothing. “Walk me through how a new employee gets ePHI system access, and how that access is removed on termination” produces an actual answer you can evaluate.
Each answer gets scored on two axes: likelihood a threat exploits the gap, and impact if it does, on a 1 to 5 scale for each. The product of those two numbers becomes the risk score for that control, which is what lets you rank findings instead of presenting an undifferentiated list.
• Component Two: Technical Verification
This is where the interview gets checked against reality. Self reported controls are frequently aspirational rather than accurate, not out of dishonesty but because the person answering often does not have direct visibility into the current state of the infrastructure.
For cloud hosted environments, we run Prowler, an open source tool that audits AWS, Azure, and GCP environments against security best practice frameworks, including HIPAA specific checks.
prowler aws –compliance hipaa_aws
That single command produces a pass or fail result against dozens of HIPAA relevant technical checks, encryption at rest, logging configuration, public exposure of storage buckets, IAM policy weaknesses, and more. Each result maps back to a specific safeguard from Component One, so you are not just generating two separate reports, you are cross referencing them.
When the interview says “we encrypt all ePHI at rest” and the technical scan confirms unencrypted storage volumes, that gap is no longer a hypothetical governance question. It is a documented, verifiable finding with a clear remediation path, and it carries far more weight in front of an auditor than either source alone would.
Reconciling the Two
The real value of this approach shows up in the reconciliation step. Three outcomes are possible for every control:
Confirmed. Interview and technical evidence agree the control is in place. Contradicted. The interview claims a control exists, the technical scan shows it does not. This is your highest priority finding category, since it indicates either a knowledge gap or an undocumented, drifted configuration. Unverifiable. The control is administrative or physical in nature (background checks, facility access logs) and has no technical signal to check against, so it stays interview only, clearly flagged as such in the final report.
Structuring the output this way does two things. It gives the entity a prioritized, evidence backed remediation list instead of a wall of undifferentiated checkboxes. And it gives auditors and enterprise security reviewers exactly the kind of documentation they are trained to look for: not just “we did an assessment,” but “here is the method, here is the evidence, here is how contradictions were resolved.”
Where This Fits
This methodology works whether you are running it as an internal security function or bringing in outside help. If you are a startup building toward SOC 2 or a HealthTech company handling PHI directly, the interview plus technical verification model scales down easily to a lean team while still producing output that holds up if a client, investor, or auditor asks to see your work.
The pattern generalizes past HIPAA too. Any compliance framework with both administrative and technical requirements benefits from checking self reported controls against independently verifiable evidence rather than trusting one source alone.
____
About Mohamed AbdulleÂ
Mohamed Abdulle is the founder of Packet33, a penetration testing and compliance advisory firm for SaaS and HealthTech startups.Â
Join our LinkedIn group Information Security Community!
