HIPAA Security Rule Penetration Testing Obligations for SaaS Companies
SaaS companies must test for HIPAA vulnerabilities now, before the rule makes it explicit.
For SaaS companies handling ePHI, HIPAA penetration testing is not something to postpone until the rule names it. The current Security Rule’s risk analysis and evaluation standards already call for the evidence that testing provides. The January 2025 proposal would make annual testing explicit. Teams should test now, cover the full ePHI environment, and document the path from finding to verified fix.
Why HIPAA's Security Rule creates a penetration testing obligation without naming one
The Security Rule never says “penetration test,” yet it requires the outcome one produces. Two administrative standards create that obligation together. The risk analysis standard, §164.308(a)(1)(ii)(A), requires “an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI”. The periodic evaluation standard, §164.308(a)(8), requires technical and nontechnical evaluation of how well security policies and procedures meet the rule. One requires finding the risks, while the other requires evaluating the safeguards.
Identifying weaknesses without testing whether they are exploitable leaves the technical assessment incomplete, while evaluating safeguards without adversarial testing leaves their effectiveness unproven. A finding such as “unauthenticated user can enumerate patient records via the API” establishes a concrete failure that a spreadsheet cannot demonstrate. HIPAA risk analysis guidance lists penetration test results, vulnerability scan output, and audit reports as internal sources to use when building the vulnerability list. That places testing within the evidence used to support risk analysis, rather than outside compliance as an optional security exercise.
How OCR enforcement turns an implied obligation into real financial exposure
OCR’s Risk Analysis Initiative shows what happens when risk analysis stops at paperwork. OCR announced the MMG Fusion settlement in March 2026 as the initiative’s 12th enforcement action. The Comstar action in May 2025 was its 9th action and OCR’s 13th ransomware enforcement action. The pattern is about inadequate investigation of risk. OCR is not citing organizations for missing a test named in the rule, but for assessments that fail to establish that they examined their actual attack surface thoroughly.
The corrective action plans turn that distinction into practical demands. A questionnaire-only assessment does not demonstrate which technical vulnerabilities are real or exploitable, so findings from scans and tests become evidence needed to support the analysis. Weak analysis leads to settlement exposure and corrective work that requires more than revised documents. Waiting until the rule names testing as a requirement leaves that compliance gap open. For a SaaS company acting as a business associate, the exposure is direct because business associates are fully within enforcement scope. A covered entity customer does not shield its software provider from responsibility for the ePHI it handles.
What the January 2025 NPRM would change and where it stands today
The January 2025 NPRM remains a proposal. HHS published it in the Federal Register on January 6, 2025, as the most significant proposed Security Rule update in more than two decades. As of late 2026, the Unified Agenda lists RIN 0945-AA22 under long-term actions, with final action projected for July 2027. OCR is still reviewing public comments, and many health systems have asked for a narrower rule. The current Security Rule remains in force during that review.
The proposal would require penetration testing at least every 12 months and vulnerability scanning at least every 6 months. It would also require a written technology asset inventory and network map reviewed at least every 12 months, a written risk analysis with defined contents, and an annual compliance audit. Critical risks would have to be patched within 15 calendar days and high risks within 30. Removing the distinction between “addressable” and “required” implementation specifications would also remove flexibility used to defer technical controls.
The testing requirement would apply to “qualified persons” with appropriate knowledge and experience in generally accepted cybersecurity principles and methods for protecting ePHI. That is not a mandate for an informal assessment by whoever happens to be available. The practical stance is to build on a “would comply” basis.
What systems must be in scope for a HIPAA penetration test
For teams putting that stance into practice, scope should follow the ePHI. HIPAA scope guidance ties the obligation to systems that create, receive, maintain, or transmit ePHI. In a health-tech SaaS environment, that includes the patient-facing web and mobile application, the provider or admin portal, and APIs, including FHIR and HL7 interfaces. It also covers the cloud environment that hosts the ePHI database, authentication systems, role-based access controls, and third-party integrations that touch patient data. The main web application is only one part.
The proposed asset inventory and network map would give that scope a written foundation. The map of ePHI flows becomes the scoping document, so an asset appearing on it belongs in the test. Testing only the external perimeter or one application leaves other patient-data paths unexamined, the most common reason a HIPAA penetration test fails to satisfy an auditor. The proposal also requires testing network segmentation around ePHI repositories to validate the boundary. For multi-tenant SaaS, that same logic requires tenant isolation testing with accounts in separate tenants. Architecture documentation alone does not prove that one tenant cannot reach another’s data.
The difference between a vulnerability scan and a penetration test under the proposed rule
A vulnerability scan and a penetration test answer different questions. A scanner checks systems for known weaknesses and reports problems such as missing patches, outdated libraries, or misconfigured endpoints. A penetration test tries to exploit those weaknesses to see whether they let an attacker reach patient data or move deeper into the environment. The difference is evidence of what an attacker can do. That explains why the proposal separates scanning every six months from annual penetration testing.
Automated scanners and AI-only approaches do not provide the human-driven adversarial testing needed to uncover business logic flaws, chained exploits, and access control failures that tools cannot surface alone. A Security Risk Assessment documents known risks, while scanning identifies known technical weaknesses. Penetration testing establishes their practical consequences and tests paths that a scanner may miss entirely. Calling scanner output a penetration test leaves the gap OCR’s corrective action plans aim to close, a risk analysis that records weaknesses without showing how they threaten ePHI.
What methodology and tester qualifications make a HIPAA penetration test defensible
A defensible test needs a documented method, qualified testers, and proof of exploitation. For buyers applying the proposal’s “qualified persons” standard, relevant credentials include OSCP (Offensive Security Certified Professional), CREST accreditation, or equivalent credentials. Recognized frameworks such as OWASP ASVS, PTES, NIST SP 800-115, or MITRE ATT&CK provide a basis for repeatable work. Credentials alone are not the finished evidence. The report must show how the method was applied to the systems in scope.
Whitebox testing gives testers source code, cloud configurations, and documentation, providing the most complete coverage for SaaS applications handling ePHI. That access supports the “accurate and thorough” standard by exposing business logic, authentication flows, and cloud misconfigurations that external-only testing cannot reach. Grey-box testing, with authenticated credentials and limited internal knowledge, is the practical minimum because it enables direct testing of authorization boundaries and tenant isolation. Pure black-box testing lacks that internal access.
Every material finding needs a working exploit. The report used for compliance should include an executive summary, a written account of the scope and methodology, CVSS-scored findings with proof of exploitation, and remediation guidance that developers can use. Retest evidence must then show that fixes were independently verified.
How to evaluate a penetration testing vendor against HIPAA's requirements
A vendor’s HIPAA coverage claim is only a starting point. The lesson for technical buyers is to test that claim during scoping. Establish whether the engagement covers every material application and API, uses authenticated access, and validates admin, provider, and patient roles. Tenant isolation should be tested with separate tenant accounts. Cloud scope should include identity and access management policies, storage permissions, and network segmentation.
Buyers should establish whether findings come with proof-of-concept output, whether Critical and High findings are remediated and independently retested before report closure, and whether the report maps findings to HIPAA risk analysis requirements. A comprehensive SaaS test promised in two days signals a shallow assessment. So does a findings list built from scores without exploitation evidence, or an engagement with no retest included or offered.
Findings that cannot be routed to Jira, GitHub, or Slack create a gap between discovery and remediation that extends vulnerability windows. A polished report does not compensate for that gap. The useful deliverable is evidence that developers can act on and that an auditor or OCR investigator can connect to the organization’s risk analysis.
How one penetration test can satisfy HIPAA, SOC 2, and ISO 27001 simultaneously
One well-scoped test can produce evidence for HIPAA risk analysis, SOC 2’s CC4.1 evaluation activity, and ISO 27001’s Annex A 8.8 and 8.29 controls. Separate frameworks do not automatically require separate engagements. A rigorous whitebox assessment can support all three when its scope covers the relevant systems and its findings are mapped to each framework. The same report can show how findings relate to HIPAA requirements, SOC 2 Trust Services Criteria, and ISO control numbers.
SOC 2 does not formally require penetration testing, although it appears as a point of focus under CC4.1 and most Type II auditors expect it in practice. Scanner output alone is rarely enough. For the evidence to be usable, the test, remediation tickets, and retest must fall inside or just before the observation window. SOC 2 CC7.4/CC7.5 and ISO 27001 Clause 10 also look for evidence that identified issues were resolved. CC7.3 concerns evaluation and classification of security events.
Business associate agreements, health-system procurement questionnaires, and cyber-insurance underwriters more often call for a penetration test report alongside a completed risk assessment.
What to do with penetration test findings to stay compliant between annual tests
To follow through on compliance, teams should add every validated finding to the risk register. Map it to likelihood and impact on ePHI, assign an owner and deadline, and document the rationale for accepting any risk. Undocumented acceptance creates another risk analysis failure. The proposed patching deadlines are 15 calendar days for critical risks and 30 for high risks, but even under the current rule, extended remediation windows for severe ePHI findings are difficult to defend.
Independent retesting should verify closure, with the retest artifact retained with the original report. Under the proposal, policies, scan reports, remediation plans, and risk assessments would have to be kept for six years. Centralizing those records when the test closes avoids trying to reconstruct the evidence at audit time. The record needs to connect the finding, the decision, the fix, and its verification.
Annual testing is the proposed minimum. Major upgrades, cloud migrations, new patient portals or APIs, mergers, and material incidents create a need for targeted retesting between annual cycles. Continuous pull-request scanning adds automated checks to each code change before production, addressing new weaknesses between human-led assessments without pretending to replace them. The compliance posture OCR expects and the security posture health-tech SaaS needs converge on the same program of rigorous testing, documented remediation, independent retest verification, and continuous scanning.
