In January 2025, HHS's Office for Civil Rights published a Notice of Proposed Rulemaking that would, for the first time, put hard numbers on what "reasonable" application security testing means under HIPAA: penetration testing at least once every 12 months and vulnerability scanning at least once every 6 months. Until now, the Security Rule has leaned on vague language like "reasonable and appropriate" safeguards, leaving covered entities and business associates to guess how much testing is enough. That ambiguity has been expensive — OCR closed 22 enforcement actions in 2023 alone, and healthcare breaches reported to HHS affected over 167 million records in 2023. This post breaks down what HIPAA security testing requirements actually say today, what's changing, how testing vendors like Veracode fit into a HIPAA program, and where the gaps still are.
What Does HIPAA Actually Require for Application Security Testing?
HIPAA does not name a specific tool, cadence, or test type — it requires a documented, risk-based process. The Security Rule's core testing obligation lives in the Security Management Process standard, 45 CFR §164.308(a)(1)(ii)(A)-(B), which requires covered entities and business associates to conduct an accurate and thorough risk analysis and implement security measures "sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." Nowhere does the current rule say "run a SAST scan" or "perform an annual pentest." That flexibility was intentional when the Security Rule was finalized in 2003, but two decades later it has become the rule's biggest weakness: organizations can technically claim compliance with a single spreadsheet-based risk assessment and no code-level testing at all. Auditors and OCR investigators have increasingly filled that gap by referencing NIST SP 800-66 and NIST SP 800-53 as the de facto testing standard, which explicitly call for vulnerability scanning, static and dynamic application testing, and periodic penetration testing of systems that touch electronic protected health information (ePHI).
Which HIPAA Rule Section Actually Forces You to Test Your Code?
The Evaluation standard, 45 CFR §164.308(a)(8), is the section that turns "have a risk analysis" into "keep testing." It requires 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." In practice, OCR has interpreted "environmental or operational changes" to include new application releases, new integrations, and newly disclosed CVEs — meaning a single annual pentest doesn't satisfy the rule if your engineering team ships weekly. The 2025 NPRM would codify this explicitly: proposed §164.308(a)(15) requires written verification, at least once every 12 months, that all technology asset security measures are effective, plus vulnerability scans every 6 months and penetration tests every 12 months performed by a qualified person. If finalized, this converts a fuzzy "periodic evaluation" duty into a testing SLA with a calendar on it.
How Often Must Covered Entities and Business Associates Test Applications?
Today, the honest answer is "as often as your risk analysis says it should be," which is why most mature healthcare programs have settled on a de facto standard of continuous scanning plus an annual third-party penetration test. That pattern shows up repeatedly in OCR resolution agreements: the 2023 Banner Health settlement ($1.25 million) and the 2024 Heritage Valley Health System settlement cited failure to conduct sufficient technical evaluation of systems following known vulnerabilities, not merely failure to have a written policy. Under the pending rule, the cadence becomes explicit — vulnerability scans every 6 months, penetration tests every 12 months, and patching of critical vulnerabilities within 15 calendar days (72 hours for exploited vulnerabilities under emergency conditions) once finalized. Given HHS's typical 1-2 year gap between NPRM and final rule, most compliance teams are already building toward these numbers now rather than waiting, since OCR audits routinely use them as the benchmark for "reasonable" even pre-finalization.
Where Does Veracode Fit Into a HIPAA Testing Program, and What's Missing?
Veracode fits as a static and dynamic application scanning platform, but scanning output alone does not satisfy HIPAA's evaluation and risk-analysis requirements — evidence of remediation and continuous monitoring does. Veracode's SAST/DAST/SCA suite is commonly used by healthcare software vendors to generate the vulnerability findings that feed into a risk analysis, and its policy scanning can gate releases against known CWE categories. But three gaps show up consistently in HIPAA audit prep with Veracode-only stacks: first, Veracode's scan-based model is oriented around point-in-time assessments tied to build pipelines rather than continuously validated production posture, which is a poor match for §164.308(a)(8)'s "in response to environmental or operational changes" language. Second, Veracode doesn't natively map findings to HIPAA Security Rule citations or generate the audit-ready evidence packages (risk analysis documentation, remediation timelines, sign-off trails) that OCR investigators actually request during an investigation — teams typically bolt on spreadsheets or GRC tools to translate CWE/CVSS findings into compliance language. Third, Veracode's per-seat, per-application pricing model tends to push smaller health-tech vendors and business associates toward reduced scan frequency to control cost, which directly undercuts the 6-month/12-month cadence the 2025 NPRM proposes.
What Happens If You Fail a HIPAA Security Risk Assessment or Audit?
Failing an OCR investigation typically means a resolution agreement with a corrective action plan and a monetary penalty, and the penalties have been climbing. In 2023, OCR's HIPAA penalty tiers ranged from $141 to $2,134,831 per violation category per year (inflation-adjusted under the HITECH Act), and 2024 settlements included the $950,000 Cascade Eye and Skin Centers agreement following a ransomware incident tied to unpatched, internet-facing vulnerabilities. Beyond the direct fine, a corrective action plan usually mandates exactly the testing regimen the organization skipped — a documented risk analysis, a remediation plan with fixed deadlines, and typically two to three years of OCR monitoring with quarterly reporting. The 2023 HHS breach report data shows hacking and IT incidents caused roughly 79% of the year's large breaches, and a large share involved vulnerabilities that had appeared in a vendor's own automated scan output months earlier but were never remediated — meaning the scanning existed, but the testing program's core requirement (validated, tracked, closed-loop remediation) did not.
Does a SOC 2 Report or Existing Pentest Satisfy HIPAA Security Testing Requirements?
No — a SOC 2 Type II report or a generic annual pentest report can support a HIPAA risk analysis, but neither one is automatically sufficient on its own. SOC 2 evaluates controls against the AICPA Trust Services Criteria, which overlaps substantially with HIPAA's technical safeguards but doesn't require testing scoped specifically to ePHI-handling systems or map findings to 45 CFR §164.312's access control, audit control, integrity, and transmission security requirements. Similarly, a penetration test scoped only to network perimeter assets misses the application-layer and API testing that most ePHI exposure actually comes through — Verizon's 2024 Data Breach Investigations Report found web applications involved in a majority of healthcare-sector breaches, well above network-layer vectors. Auditors preparing for OCR review typically need application-layer SAST/DAST/SCA results, API security testing, cloud configuration review, and evidence that findings from all of the above were triaged and remediated on a tracked timeline — not just a single point-in-time report filed away after the audit ends.
How Safeguard Helps
Safeguard is built for exactly the gap described above: turning continuous application security testing into HIPAA-mapped, audit-ready evidence instead of a pile of disconnected scan reports. Safeguard runs software composition analysis, static analysis, and secrets/config scanning continuously across every commit and container build — not on a scheduled quarterly cadence — so the "6 months for scans, 12 months for pentests" cadence in the 2025 NPRM is met by default rather than by calendar reminder. Every finding is automatically tagged to the relevant HIPAA Security Rule citation (§164.308, §164.312) and CVSS/CWE classification, and tracked through a remediation SLA dashboard that gives compliance teams the exact artifact OCR investigators ask for first: proof that a known vulnerability was found, triaged, and closed within a defined timeframe, not just discovered. Safeguard's SBOM generation and continuous dependency monitoring also close the specific failure pattern behind many 2023-2024 OCR settlements — vulnerable, unpatched components sitting unnoticed in production for months. For teams migrating off a Veracode-only pipeline, Safeguard ingests existing scan history and remediation records so nothing is lost, while adding the compliance mapping, evidence packaging, and continuous cadence that pure application scanning was never designed to provide. The result is a HIPAA security testing program that satisfies the letter of §164.308(a)(8) today and is already aligned to the codified 12-month/6-month/15-day timelines HHS is expected to finalize.