Skip to main content
    Cybersecurity5 min read

    HIPAA Security Risk Assessment vs. Penetration Test: What Auditors Actually Want

    By Patrick NevelsLast updated

    A HIPAA Security Risk Assessment is the governance deliverable. A penetration test is the technical evidence that makes it defensible. Here is how to run both without paying twice for the same work.

    Risk assessment clipboard, laptop with exploit code, and a glowing blue shield with a medical caduceus watermark

    Quote in 48 hours

    Scope your HIPAA pentest

    §164.308(a)(8) evidence. PHI-safe testing. Quote in 24 hours.

    What HIPAA actually requires

    45 CFR §164.308(a)(1)(ii)(A) is short and heavily litigated. It requires an "accurate and thorough assessment of the potential risks and vulnerabilities" to the confidentiality, integrity, and availability of ePHI. That single sentence is the source of every HIPAA Security Risk Assessment on the market. What the sentence does not say — and what OCR has repeatedly clarified in its guidance — is that a questionnaire is enough.

    OCR expects the risk assessment to be grounded in the reality of your environment: a current asset inventory, a documented data-flow map for ePHI, threat modeling, and evidence that the highest-priority technical risks were validated rather than assumed. That last piece is where the penetration test enters.

    SRA and pentest are not the same artifact

    Magnifying glass over an inventory of servers, laptops, mobile devices, infusion pumps, and patient monitors with a risk-inventory sidebar
    An SRA inventories and prioritizes risk. A pentest proves which risks an attacker can actually exploit.

    Think of the SRA as the plan and the pentest as the proof:

    • SRA — inventories ePHI systems, identifies threats and vulnerabilities, ranks likelihood and impact, and produces a written remediation plan. It is a governance document owned by the security or compliance function.
    • Penetration test — simulates a real attacker against the systems in that inventory, validates which vulnerabilities are actually exploitable, and produces a technical report with evidence: request/response logs, screenshots, chained attack paths, and remediation guidance. It is a technical artifact owned by the offensive-security or engineering function.

    The two are complementary. The SRA without a pentest is a story without evidence. The pentest without an SRA is evidence without a story. OCR wants both.

    What OCR investigators look for

    OCR Audit Compliance Report stamped COMPLIANT next to a lifecycle diagram of SRA, Pentest, and Remediation
    OCR wants the full lifecycle: SRA identifies risk, pentest validates it, remediation closes the loop.

    When OCR opens an investigation — usually triggered by a breach notification, a complaint, or a random audit — the first document request almost always asks for the current Security Risk Assessment and any supporting technical evaluations. Investigators specifically look for:

    • An up-to-date ePHI asset inventory that matches the SRA scope.
    • Risk rankings backed by evidence, not just self-scored questionnaires.
    • A recent penetration test report against the systems in that inventory.
    • A remediation plan with owners and dates, and evidence that critical findings were fixed or accepted with a signed rationale.
    • Three years of history, since retention for these artifacts is six years for HIPAA documentation and typically three years for individual test cycles.

    Missing the pentest report is one of the most common aggravating factors cited in recent OCR resolution agreements. The 2025 NPRM will make this explicit by writing annual pentesting into §164.308 directly.

    How to sequence SRA and pentest so you are not paying twice

    1. Run or refresh the SRA first. Its output tells you the ePHI boundary and the highest-priority technical risks.
    2. Scope the pentest from the SRA. Every "high" technical risk in the SRA becomes an in-scope test objective. Every system in the ePHI inventory becomes an in-scope asset.
    3. Run the pentest. Prefer a hybrid engagement that pairs AI agents for breadth with a senior human tester for validation and sign-off.
    4. Feed findings back into the SRA. Update likelihood and impact based on real exploitability. Update the remediation plan with the pentest report’s guidance.
    5. Retest and attach evidence. Close the loop for OCR, BAAs, and insurers.
    6. Layer continuous scanning for the six-month vulnerability-scan floor the NPRM proposes.

    Common failure modes

    • Treating an SRA as a compliance checkbox. A questionnaire-only SRA with no technical validation is exactly what OCR criticizes in resolution agreements.
    • Buying a pentest without an SRA. You get a report, but no governance narrative and no prioritized remediation plan.
    • Letting scope drift between the two. If your SRA covers 40 systems and your pentest covers 12, an OCR investigator will notice.
    • One and done annually. Both artifacts need to refresh after material changes, not just on the calendar.

    Bottom line

    An SRA without a pentest is a story without evidence. A pentest without an SRA is evidence without a story. HIPAA, the 2025 NPRM, OCR, enterprise BAAs, and cyber insurers all expect both. Run them in sequence, keep the scopes aligned, and retain three years of paired evidence.

    For what an OCR-ready pentest actually delivers, see our HIPAA penetration testing page, or read the full HIPAA pentest requirements and frequency guide.

    Frequently asked questions

    Ready to find what attackers would find?

    AI-powered, hybrid, or fully manual penetration testing with audit-ready reports for SOC 2, PCI DSS, HIPAA, and CMMC. Most engagements can start within 24 hours.

    Share this article