Pen testing for HIPAA is moving from industry best practice to federal law, and the reach of that obligation extends further than most organizations expect. Any entity that creates, receives, maintains, or transmits patient health data including PHI, whether a hospital, a billing firm, a cloud vendor, or a subcontractor two steps removed from direct care, will need to comply. Any vendor, partner, or service provider whose work brings them into contact with electronic patient health information falls within HIPAA’s reach, regardless of how far removed they are from direct patient care.
This blog covers the current HIPAA Security Rule and what it has historically asked of your security program, the full scope of the proposed updates that OCR published in January 2025 and everything they would change, who carries these obligations across the entire regulated relationship, and what a properly built pen testing program looks like from scope through documentation to cost. Covered entities, business associates, and their subcontractors all carry pen testing for HIPAA obligations. Understanding exactly where your organization fits shapes every decision your security team will make.
Who Must Comply With HIPAA
Healthcare providers form the most visible covered entity category under the HIPAA Security Rule. Physicians, hospitals, dentists, pharmacies, therapists, and clinics all qualify if they transmit health information electronically. Health plans, including private insurers, Medicare, Medicaid, and employer-sponsored group plans, represent the second major covered entity category.
Radiology practices, diagnostic imaging centers, and independent clinical laboratories also qualify as covered entities. Nuclear medicine providers, pathology groups, and blood banks qualify when they transmit patient information electronically, bringing distinct security profiles that general hospital guidance does not always address. Clearinghouses that translate health data between nonstandard and standard electronic formats complete the covered entity picture.
Business associates expand these obligations significantly beyond direct providers. Any company that creates, receives, maintains, or transmits ePHI on behalf of a covered entity qualifies as a business associate. Medical billing firms, IT service providers, cloud storage vendors, EHR software companies, and telehealth platforms commonly qualify. Subcontractors that handle ePHI for business associates carry the same obligations further down the chain, which means pen testing for HIPAA responsibilities extend across the entire regulated relationship, not only at the provider level.
What the Current HIPAA Security Rule Requires
The original HIPAA Security Rule took effect in 2003, and its last significant update came through the HIPAA Omnibus Rule in 2013. Both versions were built for a world that predated cloud computing at scale, telehealth as a standard care delivery channel, ransomware as an organized criminal enterprise, and the proliferation of connected medical devices running on legacy operating systems. Flexible by design, the current rule deliberately avoids prescribing specific technologies or testing frequencies, which made sense in 2003 but leaves meaningful gaps today.
Section 164.308(a)(8) of the current Security Rule establishes the Evaluation Standard, requiring periodic technical and nontechnical security assessments of your environment. In plain terms, your organization must actively test whether its security controls work as intended. Section 164.308(a)(1) adds the ongoing, documented risk analysis requirement, meaning you must identify where ePHI lives, assess realistic threats against it, and formally record your findings.
Critically, the current rule does not specify how often to test, what methods to use, or how granular those tests must be. Penetration testing carries no explicit requirement anywhere in the current text, and vulnerability scanning is similarly absent as a named obligation. Organizations have historically interpreted this flexibility in very different ways, with some running rigorous annual programs and others treating a single automated scan as sufficient for multiple years. OCR enforcement data tells the story plainly: risk analysis failures appear in virtually every major enforcement action, which reflects exactly how that flexibility has played out across the sector.
Comparing the Current HIPAA Security Rule and the Proposed Rule
On January 6, 2025, the Office for Civil Rights published in the Federal Register a Notice of Proposed Rulemaking, or NPRM, representing the most significant overhaul of the HIPAA Security Rule since its original adoption. OCR’s regulatory agenda has indicated 2026 as the target for finalization, though the exact date has not been confirmed, and the final rule may differ based on the review of more than 4,700 public comments submitted during the comment period.
A Deeper Understanding of the Proposed Rule – Everything the NPRM Would Change
What the proposed rule would require spans well beyond pen testing alone. Here is the full scope of what OCR has proposed.
1. Structural Shift: All Implementation Specifications Become Required
The most significant structural change in the proposed rule is the elimination of the distinction between “required” and “addressable” implementation specifications. Under the current rule, organizations may treat many safeguards as “addressable,” meaning they can implement alternatives or document why a specification is not reasonable for their environment. Removing this distinction means virtually all implementation specifications would become mandatory, eliminating the flexibility organizations have long used to defer controls like encryption and comprehensive access management.
2. Written Documentation for All Policies and Procedures
All Security Rule policies, procedures, plans, and analyses would need to be in writing. Informal practices and undocumented institutional knowledge would no longer satisfy the standard, regardless of what an organization actually does operationally.
3. Technology Asset Inventory and Network Map
Regulated entities would need to develop and maintain a written technology asset inventory and a network map illustrating how ePHI moves through all relevant electronic information systems. Both must be reviewed and updated at least annually, and also in response to any change in the organization’s environment or operations that could affect ePHI. This inventory is foundational to every other proposed requirement. Without it, accurate pen test scoping, a properly structured risk analysis, and any meaningful audit posture are all significantly harder to demonstrate.
4. Enhanced Risk Analysis
Risk analysis under the proposed rule becomes far more structured than the current general obligation. A written assessment must include a review of the technology asset inventory and network map, identification of all reasonably anticipated threats to the confidentiality, integrity, and availability of ePHI, identification of potential vulnerabilities and predisposing conditions in relevant electronic information systems, and a risk level assigned to each identified threat-vulnerability pair based on likelihood and impact. This replaces the current rule’s broad assessment obligation with a specific, documented, evidence-based framework.
5. Encryption at Rest and in Transit
Currently an “addressable” specification that organizations can opt out of with documented justification, encryption of ePHI at rest and in transit would become a required control under the proposed rule, with only limited exceptions. For organizations that have long operated unencrypted environments under the addressable pathway, this change carries significant implementation cost and timeline pressure.
6. Multi-Factor Authentication
Multi-factor authentication, also currently an addressable specification, would become a required technical control for access to all relevant electronic information systems handling ePHI, with limited exceptions. Deferring MFA deployment would no longer be an option once the rule is finalized.
7. Network Segmentation
Separating systems that handle ePHI from general office networks, guest Wi-Fi, medical devices, and other systems that do not require access to patient data would become an explicit requirement. Most security frameworks already treat network segmentation as a baseline control, but the current HIPAA Security Rule has never mandated it directly.
8. Vulnerability Scanning and Penetration Testing
Two of the most operationally significant new requirements are the explicit testing cadences the proposed rule would establish. Vulnerability scanning would be required at least every six months across all systems that handle ePHI. Penetration testing would be required at least once every 12 months, applying to all covered entities and business associates. Significant changes to your environment, including new EHR deployments, cloud migrations, acquisitions, and major infrastructure changes, would also warrant testing outside the annual cycle regardless of where you fall in your scheduled calendar.
9. Anti-Malware Protection and System Hardening
Technical controls for system configuration would become explicit requirements. Organizations would need to deploy anti-malware protection, remove extraneous software from relevant electronic information systems, and disable network ports in accordance with their risk analysis findings. All three of these decisions currently fall entirely within organizational discretion under the existing rule.
10. Workforce Access Termination
Upon any change or termination of a workforce member’s access to ePHI or relevant electronic information systems, the proposed rule would require notification to certain regulated entities within 24 hours. Delayed access revocation has appeared in multiple documented breach cases as an exploited gap, and this provision addresses it directly with a concrete and enforceable deadline.
11. Incident Response Planning and Testing
Written security incident response plans and procedures would be required, including specific documentation of how workforce members report suspected or known security incidents and how the organization responds to them. Beyond creating these plans, the proposed rule would also require written procedures for testing and revising them regularly. Defining the escalation path for critical pen test findings in your incident response plan before testing begins, rather than after, becomes essential under this framework.
12. 72-Hour Restoration Requirement
Following any disruption to relevant electronic information systems, the proposed rule would require organizations to restore lost systems and data within 72 hours. Organizations would also need to document an analysis of the relative criticality of their information systems and technology assets to determine restoration priority. For organizations that have never formally tested their recovery capabilities, this creates a concrete and enforceable expectation where none currently exists.
13. Annual Compliance Audit
Separate from risk analysis and penetration testing, the proposed rule would require covered entities and business associates to conduct a formal compliance audit at least once every 12 months to verify they meet Security Rule requirements across the board. Treating this as synonymous with a risk assessment or a pen test would leave your organization short on evidence when auditors review each obligation independently.
14. Business Associate Technical Safeguard Verification
Covered entities would need to verify at least once every 12 months that their business associates have deployed the technical safeguards required by the Security Rule. This verification must consist of a written analysis of the business associate’s relevant electronic information systems completed by a subject matter expert, paired with a written certification confirming that the analysis was performed and is accurate. Subcontractors must provide equivalent verification to the business associates they serve. Relying solely on a signed BAA as vendor oversight evidence would no longer be sufficient to meet this requirement.
15. Business Associate Contingency Plan Notification
Business associates would need to notify covered entities within 24 hours of activating their contingency plans, and subcontractors would carry the same obligation toward the business associates they serve. This tightens the notification chain significantly, particularly for organizations that depend on third-party vendors for critical clinical or administrative functions.
16. Group Health Plan Sponsor Obligations
Group health plans would need to include in their plan documents requirements for plan sponsors to comply with the administrative, physical, and technical safeguards of the Security Rule, ensure that agents receiving ePHI agree to implement those same safeguards, and notify their group health plans upon contingency plan activation. This provision extends meaningful security obligations into employer-sponsored plan arrangements that the current rule addresses only partially.
Together, these requirements create a compliance framework where documented, active testing is no longer optional evidence but the foundation every other obligation depends on.
How Pen Testing Supports HIPAA Compliance
Running a penetration test and maintaining a fully compliant security program are not the same thing, but pen testing is one of the most direct ways to generate the evidence both the current and proposed requirements actually demand.
Four penalty tiers define how OCR calculates financial exposure when a breach occurs. Placement on that scale depends directly on documented due diligence within your security program, and pen testing is among the most direct forms of that evidence available. Lower tiers reflect reasonable care, while upper tiers reflect willful neglect or failure to correct known problems. Proactive records of testing, remediation, and retesting move your organization toward the lower penalty tiers where OCR has discretion to reduce or waive financial penalties entirely.
Audit readiness follows directly from the same documentation chain. Currently active OCR audits focus on Security Rule provisions most relevant to hacking and ransomware attacks. Without documented testing evidence, organizations cannot provide auditors with proof that technical controls actually function, and a pen test record tied to remediation and retesting gives auditors precisely what they need to move past the technical control question quickly.
Attackers responsible for major healthcare breaches in recent years relied on three primary entry points: stolen credentials, unpatched vulnerabilities, and lateral movement through poorly segmented networks. Credential theft depends on weak access controls and excessive privilege, both of which pen testing directly surfaces. A well-scoped engagement addresses the vectors healthcare organizations most commonly face.
Two of the largest recent healthcare breaches struck third-party vendors, not the healthcare organizations whose patients were affected. Neither internal testing nor perimeter-only testing prevents breaches originating within a vendor’s compromised infrastructure. Excluding business associate connections from pen testing scope leaves exactly that exposure uncovered, which is why scope boundaries matter as much as testing frequency.
Cyber insurers have restructured healthcare underwriting requirements significantly. Coverage denials and higher premiums follow when an organization cannot demonstrate documented testing and remediation history. Creating the evidentiary record insurers require happens before a breach, not after, and proof of established security protocols prevents insurers from classifying a loss as resulting from negligence.
Ransomware shutdowns have halted prescription processing, delayed surgeries, and cut clinical staff off from patient records for weeks at a time. Care continuity is one of the strongest arguments for annual pen testing beyond regulatory compliance alone. Closing the pathways attackers use to deploy ransomware protects care delivery, not only data records.
Types of Pen Testing for HIPAA
Several distinct forms of pen testing exist, and each targets a different layer of your attack surface. Understanding the differences helps your organization choose the right scope and avoid a program that leaves major exposure unaddressed.
External network testing targets systems visible to the public internet, including firewalls, VPNs, and remote access points. For healthcare organizations, these systems often represent the first door an attacker attempts to open. Internal network testing, by contrast, simulates an attacker who has already breached the perimeter, or an insider threat such as a contractor with legitimate credentials who exceeds their authorized access level.
Web application testing focuses on patient portals, EHR interfaces, clinical APIs, and any application that interacts with ePHI directly. Fast Healthcare Interoperability Resources, known as FHIR, is the modern standard for healthcare data exchange. Health Level Seven, known as HL7, is the older messaging protocol still in wide clinical use. Both FHIR and HL7 APIs must appear within any comprehensive pen testing for HIPAA program.
Wireless testing evaluates the security of Wi-Fi networks in clinical environments where devices transmit ePHI. Social engineering testing assesses whether staff can be manipulated through phishing emails, phone calls, or impersonation attempts. Physical penetration testing evaluates whether unauthorized personnel can gain physical access to servers, workstations, or records rooms.
Beyond these categories, a second classification dimension applies to all of them: how much information the tester begins with. Three approaches define this dimension, and the comparison below explains the practical differences.
Testing Approach | Prior Knowledge Given to Tester | What It Best Simulates |
Black box | None. The tester receives no information about system architecture, credentials, or internal design before the engagement. | An external attacker with no prior access. Closely mirrors how ransomware groups approach an unfamiliar target. |
White box | Full access. The tester receives architecture diagrams, source code, network maps, and administrative credentials. | An insider with deep system knowledge, or a thorough infrastructure and code audit. |
Grey box | Partial knowledge. The tester receives user credentials or limited system information, simulating a compromised or low-privilege account. | A phished employee, a stolen user session, or a contractor who escalates beyond their authorized access level. |
Black box testing places the tester in the position of an external attacker with zero prior knowledge of your systems. No credentials, no architecture diagrams, and no insider information are provided before the engagement begins. Consequently, this approach most closely mirrors the actual experience of a ransomware group probing your network from the outside, making black box external testing the most valuable starting point for many healthcare organizations building a pen testing for HIPAA program.
White box testing gives the tester complete visibility into your environment, including source code, architecture documentation, and administrative credentials. Reaching deeper into your infrastructure than a realistic external attacker typically would, this approach delivers particular value for EHR code reviews, API security audits, and validating internal access controls where thoroughness matters more than simulation accuracy.
Grey box testing provides the practical middle ground most often recommended for compliance-oriented engagements. Providing partial credentials or limited system information simulates a compromised user account, which happens to be the most common initial foothold in documented healthcare breaches. In practice, grey box testing covers the widest range of realistic attack scenarios for organizations building annual pen testing for HIPAA programs, and most qualified testers recommend it as the default approach for scheduled compliance engagements.
Scoping Your Pen Test Correctly
Auditors look for scope coverage, not just testing frequency. A pen test that covers your firewall while ignoring your patient portal and clinical APIs falls short of what both the current and proposed HIPAA requirements expect.
Every system that creates, receives, maintains, or transmits ePHI belongs in scope. Clinical systems such as electronic health records represent the core of any pen testing for HIPAA engagement. Patient portals, which give patients direct online access to their records, are high-value targets precisely because they are publicly accessible and contain large volumes of ePHI.
FHIR adoption has made API layer testing increasingly essential within pen testing scope. Cloud infrastructure hosting ePHI also requires testing, whether your environment runs on a public cloud, a private cloud, or a combination of both. Network segmentation boundaries require testing to confirm that ePHI environments remain isolated from other network zones and that attackers cannot move laterally from lower-risk areas into clinical systems.
IoMT, the Internet of Medical Things, refers to connected medical devices on clinical networks, including infusion pumps, imaging equipment, and patient monitoring systems. Such devices increasingly fall within pen testing scope because many run outdated operating systems carrying known vulnerabilities. Testing them requires careful coordination to avoid disrupting patient care, making scheduling during low-traffic periods essential.
Imaging and diagnostic systems carry scope obligations that extend well beyond standard network infrastructure testing. PACS, or Picture Archiving and Communication Systems, serve as the primary repository for medical imaging studies and ePHI in radiology environments. DICOM, the standard protocol for transmitting imaging studies, governs how image files move between systems and devices. Poorly secured PACS servers have been documented across thousands of healthcare facilities as known and exploitable attack targets, and qualified testers in these environments must understand healthcare imaging protocols, not only general network security techniques. RIS platforms manage imaging schedules and radiology reports, while LIS platforms track and transmit laboratory results. Leaving either out of pen testing scope creates a significant compliance gap for any imaging or diagnostic facility.
Business associate connections represent another consistently overlooked scope element. Any integration between your systems and a third-party vendor that touches ePHI belongs in scope. Limiting testing to your internal environment while leaving third-party connections unchecked creates exactly the kind of gap that OCR investigations, and the proposed BA verification requirements, are designed to expose.
Documentation and Evidence
Running pen testing for HIPAA is not sufficient by itself. Documentation transforms testing activity into demonstrable compliance that survives regulatory scrutiny.
At minimum, your records should contain a clearly defined scope, specifying exactly what systems were tested and what was intentionally excluded. Methodology documentation must describe whether testing was black box, white box, or grey box, what standards were used, and which tools were deployed throughout the engagement. Results documentation must cover each finding, including its severity rating, the systems affected, and a clear explanation of how an attacker could exploit it.
Remediation records matter as much as the findings themselves. Auditors expect documented evidence that your organization acted on test results, not simply received them. A remediation plan with named owners, target completion dates, and tracked closure for each finding demonstrates genuine risk management rather than checkbox compliance.
Discovery of a critical finding during testing creates an immediate obligation beyond documentation. Findings that represent active risk to ePHI before remediation is complete must be escalated to your designated security officer and documented with either an interim risk acceptance decision or a short-term compensating control. Authorized pen testing does not create a breach notification obligation because access is controlled and permitted. If testing reveals that an unauthorized actor has already exploited the vulnerability before your test occurred, however, that discovery requires a breach notification analysis under the Breach Notification Rule. Defining the escalation path for critical findings in your incident response plan before testing begins, not after, is the right approach.
Annual testing without retesting tells auditors your organization found problems and moved on. Each round of testing, remediation, and retesting should produce a complete documentation package retained for at least six years under HIPAA’s record retention requirements. Closely connected to documentation, showing how testing results fed directly into your formal risk analysis significantly strengthens your audit posture and demonstrates to OCR a coherent security program rather than a collection of disconnected activities.
Cost and ROI of Pen Testing for HIPAA
Costs for pen testing for HIPAA vary significantly based on scope, environment complexity, and vendor expertise. Most healthcare organizations should plan for engagements between $10,000 and $50,000 annually for a properly scoped program, with market conditions and vendor credentials moving those figures in either direction.
Scope is the most direct cost driver, because each additional network segment, application, and API layer adds testing hours. HIPAA-specific documentation requirements, including detailed audit trails, evidence packages, and compliance-mapped reporting, typically add 10 to 20 percent to a standard engagement compared to a non-regulated test. Hourly rates for qualified healthcare pen testing specialists run approximately $200 to $400 per hour in current market conditions, varying by provider and engagement structure.
Negotiating retesting into your initial contract typically secures better rates than treating each engagement as a standalone purchase. Structuring a multi-year agreement with your testing firm also builds institutional knowledge about your environment, which improves testing quality over time and reduces ramp-up time at the start of each annual cycle.
Leadership teams that approve pen testing budgets are not spending on compliance alone. Viewed correctly, pen testing for HIPAA returns value across at least six distinct dimensions simultaneously. Regulatory standing improves because documented testing moves your organization toward lower OCR penalty tiers. OCR audit preparation follows from the same documentation at no additional cost. Breach exposure decreases on the attack vectors pen testing directly covers. Insurance premiums become more negotiable and claim denials become harder to sustain. Operational continuity improves as ransomware pathways are closed before attackers can use them. Contract opportunities grow as partners increasingly require documented testing evidence before finalizing agreements.
How to Build Your HIPAA Pen Testing Program
Building a pen testing program that satisfies both current HIPAA requirements and the proposed rule does not require starting from scratch. Following a clear sequence keeps the work manageable and produces documentation auditors can actually use.
Step 1: Build Your Technology Asset Inventory Start here before anything else. Map every system that creates, receives, maintains, or transmits ePHI, including cloud environments, medical devices, imaging systems, and third-party integrations. Without this inventory, your scope will have gaps and your risk analysis will reflect them.
Step 2: Define Your Pen Test Scope Work from the asset inventory to identify every system, application, API, and network boundary that touches ePHI. Include business associate connections. Document what is in scope and, equally important, what is intentionally excluded and why.
Step 3: Select Your Testing Approach Default to grey box for annual compliance engagements. Add black box testing for public-facing surfaces and white box review where deep code or architecture analysis is warranted. Match the approach to the threat you are actually trying to simulate.
Step 4: Choose a Qualified Vendor Look for three things: a documented methodology aligned to NIST SP 800-115, independence from the systems being tested, and demonstrated experience in healthcare environments. Before any work begins, execute a business associate agreement. Testing cannot start without one.
Step 5: Define Your Escalation Path Before the engagement opens, document how critical findings get escalated, who receives them, and what interim controls apply while remediation is in progress. Building this into your incident response plan in advance prevents improvised decisions under pressure.
Step 6: Execute the Test Coordinate scheduling carefully for IoMT devices and imaging systems to avoid care disruption. Ensure testers have everything defined in the scope agreement and nothing beyond it.
Step 7: Document, Remediate, and Retest Receive the findings report and assign each finding an owner, a severity rating, and a remediation deadline. Retest every finding once remediation is complete. A test without documented remediation and verification tells auditors your organization found problems and chose to move on.
Step 8: Feed Findings Into Your Risk Analysis Connect every finding to your formal risk register. Show how the test results influenced specific risk treatment decisions. This connection is what transforms pen testing from a compliance activity into evidence of a functioning security program.
Step 9: Schedule the Next Cycle Annual testing is a floor, not a ceiling. Set the next engagement date before closing the current one. Flag the environmental triggers, new deployments, migrations, acquisitions, significant vendor changes, that would require testing outside the scheduled cycle.
When to Test Outside Your Annual Cycle
Annual pen testing establishes your baseline, but several events change your attack surface in ways that make waiting for the next scheduled cycle genuinely risky. OCR auditors and cyber insurers both look for evidence that your testing program responds to change, not just the calendar.
Retest after any of the following:
- New EHR deployment or major upgrade. Fresh deployments introduce new configurations, integrations, and access pathways that your last test never evaluated. Even a well-tested environment becomes partially unknown after a significant platform change.
- Cloud migration or new cloud service adoption. Moving ePHI to a new environment, or adding a cloud-hosted application to your stack, creates exposure that did not exist during your prior engagement. Inherited misconfigurations in cloud environments are among the most commonly exploited entry points in recent healthcare breaches.
- Merger, acquisition, or new business associate relationship. Connecting your systems to a previously untested network is one of the highest-risk changes any organization can make. The security posture of the environment you are connecting to is unknown until tested.
- Significant network infrastructure changes. Firewall replacements, VPN changes, network segmentation projects, and major hardware refreshes all alter the boundaries your last test mapped. Testing confirms those boundaries hold under active pressure.
- Ransomware incident or confirmed breach. Following any security incident, a fresh pen test determines whether the entry point has been fully closed and whether related vulnerabilities remain exploitable. Remediation without verification is not remediation.
- Staff changes in privileged roles. Departing administrators, credential resets, and access control overhauls warrant at least targeted testing of the systems those individuals could access, particularly where offboarding was rushed or incomplete.
Documenting the decision to retest, or the documented rationale for not retesting, after any of these events demonstrates to auditors and insurers that your program is risk-driven rather than calendar-driven.
Guidance for Small and Mid-Size Healthcare Practices
Solo practices, small clinics, community health centers, and small business associates carry identical HIPAA pen testing obligations to large hospital systems. The regulation draws no distinction based on organization size, revenue, or patient volume. What differs is the practical approach to meeting those obligations with limited internal security resources.
1. Start with scope, not budget. Small practices often assume pen testing is disproportionately expensive for their environment. In reality, a well-defined, narrow scope, one EHR platform, one patient portal, one network boundary, costs significantly less than an enterprise-scale engagement. Defining your scope tightly before approaching vendors is the most effective cost control available to smaller organizations.
2. Outsource the expertise, own the program. Internal IT staff at small practices rarely carry the specialized skills or independence that a qualified pen test requires. Engaging an external vendor satisfies both the expertise and independence criteria the proposed rule expects, and it transfers the technical execution without transferring ownership of the documentation, findings, and remediation process. Your organization still owns those, and auditors will look to you for them.
3. Use the asset inventory as your foundation. For smaller organizations, building the technology asset inventory is often faster than anticipated. A solo practice or small clinic may have one EHR, one billing platform, one patient portal, and a small internal network. Documenting that environment completely, including every device that touches ePHI, creates the foundation for scoping, risk analysis, and audit readiness in a single exercise.
4. Grey box testing is your default. Smaller environments do not require the full range of testing approaches to produce meaningful results. Grey box testing, which simulates a compromised user account, addresses the most realistic threat most small practices face and fits within a scope and budget appropriate to the organization’s size.
5. Negotiate retesting into the initial contract. Small practices are less likely to have ongoing vendor relationships that naturally include retesting. Building retesting into the original engagement contract, before findings are known, typically costs less than commissioning a separate retesting engagement after the fact.
6. Document everything regardless of size. OCR enforcement actions have historically targeted small and mid-size providers at a disproportionate rate, partly because documentation gaps are easier to find in less mature programs. A small practice with thorough documentation of a modest but well-executed pen testing program is in a stronger audit position than a larger organization with inconsistent records of more expensive testing.
Key Takeaways
- Confirm your HIPAA status across your entire organizational chain. Covered entities, business associates, and subcontractors all carry pen testing for HIPAA obligations. Reviewing vendor contracts and data flows to identify every entity that touches ePHI, not just the healthcare provider at the top of the chain, is where this work begins.
- Follow the sequence, not just the schedule. Asset inventory before scoping, scoping before vendor selection, escalation path before testing, remediation before closing. Organizations that run pen tests without this sequence produce findings reports that satisfy no one, not auditors, not insurers, and not OCR.
- Build your technology asset inventory before anything else. The proposed rule treats the asset inventory as foundational to scoping, risk analysis, and audit readiness. Starting it now, before finalization, gives your organization the strongest possible head start on every requirement that follows.
- Schedule annual pen testing now, before the final rule arrives. Running pen testing annually before the requirement becomes binding demonstrates a proactive security posture and builds the documentation record auditors will later require. Organizations that start now enter compliance with a functioning program rather than one assembled under deadline pressure.
- Define your scope completely before selecting a vendor. Mapping every system that creates, receives, maintains, or transmits ePHI, including patient portals, clinical APIs, EHR platforms, cloud environments, IoMT devices, imaging systems, laboratory systems, and business associate connections, must happen before you evaluate vendors or set testing timelines. Major changes to your environment warrant retesting outside the annual cycle.
- Default to grey box testing for most annual engagements. Grey box testing most accurately simulates the realistic threat your environment faces by combining external realism with the access a compromised user account provides. Supplementing with black box testing for public-facing surfaces and white box review for deep code or architecture audits adds coverage where each approach delivers the most value.
- Retest after significant changes, not just annually. New EHR deployments, cloud migrations, acquisitions, new business associate relationships, and security incidents all change your attack surface. Waiting for the next scheduled cycle after any of these events leaves a documented and defensible gap that auditors will find and attackers may find first.
- Execute a business associate agreement with your pen testing vendor before work begins. Any tester who accesses ePHI during an engagement is a business associate under HIPAA. Allowing testing to begin without a signed agreement creates a compliance violation before the first vulnerability is documented.
- Connect every test finding to your formal risk analysis and establish your escalation path before testing starts. Pen testing for HIPAA produces its highest compliance value when findings feed directly into your risk register and drive prioritized remediation. Critical findings require immediate escalation to your security officer, not just a place in the remediation queue.
- Small practices should scope tightly and document thoroughly. A narrow, well-executed program with complete documentation is more defensible than a broad program with inconsistent records. OCR enforcement has historically targeted smaller organizations where documentation gaps are easiest to find. Size does not reduce the obligation, but it does allow you to right-size the approach.
- Budget for retesting in every engagement, not just initial testing. A penetration test that identifies critical findings and never verifies remediation tells auditors your organization found serious vulnerabilities and chose to move on. Negotiating retesting rounds into your contract at the outset, and documenting every round of remediation and verification, is what closes that gap.
- Treat the FAQ section as a pre-engagement checklist. Before selecting a vendor, confirm your team can answer every question in that section. Gaps in those answers are gaps in your program, and closing them before testing begins is significantly cheaper than closing them during an OCR investigation.
Summary
Pen testing for HIPAA sits at the intersection of regulatory obligation and genuine security practice. The HIPAA Security Rule has always required organizations to evaluate whether their security controls actually work, and the Evaluation Standard at Section 164.308(a)(8) makes that a formal, auditable obligation. For two decades, however, the absence of specific testing requirements gave organizations wide latitude to interpret those obligations on their own terms, and OCR enforcement data shows clearly how inconsistently that latitude has been applied.
The proposed rule published in January 2025 would change that entirely. Annual penetration testing, biannual vulnerability scanning, mandatory encryption, required MFA, network segmentation, technology asset inventories, enhanced risk analysis, written incident response plans, 72-hour restoration requirements, an annual compliance audit, and formal business associate verification are all on the table. OCR’s regulatory agenda targets 2026 for finalization, though the exact date remains unconfirmed, and the final form may be narrowed based on industry feedback.
Organizations that approach pen testing as a standalone compliance checkbox will find themselves rebuilding their program every audit cycle. A structured program, sequenced from asset inventory through remediation and retesting, produces documentation that compounds in value over time. Each completed cycle strengthens your risk analysis, tightens your audit posture, and closes the gaps attackers depend on finding first.
Healthcare organizations that wait for the final rule to act will face compressed timelines and a vendor market under pressure from simultaneous demand across the entire sector. Starting now, with a functioning and documented program, is the most defensible position any covered entity or business associate can take.
Small and mid-size practices carry the same obligations as large systems and face the same enforcement exposure. A modest but well-documented program, properly scoped and consistently executed, satisfies OCR’s requirements and produces the evidence insurers and auditors actually need.
When to retest is as important as whether to retest. Environmental changes, new vendor relationships, infrastructure upgrades, and security incidents all create exposure that the annual cycle was not designed to catch. A program that responds to change, not just the calendar, is the standard the proposed rule implies and the standard OCR enforcement has consistently rewarded.
FAQs
1. Does a vulnerability scan count as a pen test?
No, and conflating the two is one of the most common mistakes in HIPAA compliance programs. A vulnerability scan uses automated tools to identify known weaknesses across your systems. A penetration test involves a qualified specialist actively attempting to exploit those weaknesses, along with others that automated tools do not capture. The proposed rule treats them as separate requirements with separate cadences precisely because they serve different purposes. Running scans every six months does not satisfy the annual pen testing obligation, and running an annual pen test does not replace the biannual scanning requirement.
2. Can our internal security team run the pen test?
Possibly, but with important caveats. The proposed rule requires testing by a qualified person with appropriate knowledge of generally accepted cybersecurity principles and methods. Internal teams can meet the knowledge standard, but they must also demonstrate independence from the systems being tested and document their methodology rigorously. In practice, most auditors view third-party testing as the cleaner answer because it removes any question about independence and adds external objectivity to findings. If your organization chooses internal testing, the documentation burden is higher, not lower.
3. What happens if we find a critical vulnerability mid-test?
Stop and escalate immediately to your designated security officer. Document the finding with a severity rating, the systems at risk, and the potential exposure to ePHI. Decide on an interim compensating control or a formal risk acceptance while remediation is underway. Authorized pen testing does not trigger breach notification obligations on its own. If the test reveals that an unauthorized party has already exploited the vulnerability before your engagement began, that discovery requires a breach notification analysis under the HIPAA Breach Notification Rule. Define this escalation path before testing starts, not after.
4. What does a qualified pen testing vendor actually look like?
Three markers distinguish qualified vendors from those packaging automated scans as manual testing. First, a documented methodology aligned to a recognized framework such as NIST SP 800-115. Second, genuine independence from the systems being tested, meaning no conflict of interest from also managing or hosting those systems. Third, demonstrated experience in healthcare security environments specifically, including familiarity with FHIR and HL7 APIs, PACS systems, IoMT devices, and the regulatory context those environments carry. Any vendor unwilling to sign a business associate agreement before the engagement begins does not qualify, regardless of technical credentials.
5. How long should we retain pen testing records?
HIPAA requires a minimum retention period of six years for Security Rule documentation from the date of creation or the date it was last in effect, whichever is later. This applies to pen test reports, methodology documentation, findings, remediation records, and retesting evidence. Storing these records in a format that is accessible and auditor-ready, not archived and difficult to retrieve, is what separates organizations that move through OCR audits quickly from those that spend weeks locating documentation under deadline pressure.
How databrackets can help you with Pen Testing for HIPAA
databrackets is an authorized & accredited FedRAMP 3PAO with ISO/IEC 17020:2012 accreditation from A2LA. We are also an authorized certifying body for ISO 27001 and an authorized C3PAO for CMMC.
For over 15 years, we have been helping organizations achieve compliance or certification with the most rigorous cybersecurity and data privacy standards, including NIST SP 800-53, NIST SP 800-171, NIST Cybersecurity Framework, ISO 27001, SOC 2, CMMC, HIPAA, and GDPR. We offer specialized Pen Testing Services to organizations who want to comply with these and other global security frameworks.
For HIPAA Compliance, we offer 3 Engagement Options to help you prove your compliance with HIPAA – our DIY Toolkit (ideal for MSPs and mature in-house IT teams), and Hybrid or Consulting Services. We have HIPAA Training Modules for staff and privacy officers which can be customized to include your privacy policies. You can partner with us to prove your compliance on an annual basis and engage our team to support your organization if you are audited.
Srini Kolathur
Co-Author: Aditi Salhotra
Manager – Digital Marketing and Business Development
Aditi is a Digital Marketing and Business Development Professional at databrackets.com. She is a strong advocate of good cyber hygiene and is proud of the company’s mission to safeguard organizations from cyber threats and ensure their business continuity in adverse situations.