Protect patient data before it becomes a breach report

ePHI exposure triggers mandatory breach notification

Under HIPAA, unauthorized access to just one patient's records requires breach notification to HHS and potentially to the patient. The access control flaws that cause these exposures, such as IDOR and broken authorization in FHIR APIs, are exactly what Penetrify finds.

HIPAA Security Rule requires regular testing

45 CFR §164.308(a)(8) requires regular technical and nontechnical evaluations of your security controls. "Regular" means more than once a year when you're shipping code monthly, and Penetrify makes continuous testing economically practical.

FHIR APIs introduce new attack surfaces

Modern healthcare interoperability standards (FHIR R4, SMART on FHIR) create API endpoints that expose patient data at scale. Misconfigured authorization on a single FHIR endpoint can expose your entire patient population.

45 CFR §164.308(a)(8): Regular evaluation of technical and nontechnical safeguards

Control 10.m: Penetration testing as part of the vulnerability management program

CC6.1: Logical access controls with penetration testing evidence

A.12.6: Technical vulnerability management with regular security testing

HIPAA Today, and the Proposed Rule That Makes Pentesting Explicit

The current HIPAA Security Rule requires "regular" technical and nontechnical evaluation of safeguards (45 CFR §164.308(a)(8)) without naming penetration testing explicitly, which is why healthcare security programmes vary so widely. That ambiguity is on its way out: the HHS proposed Security Rule update (NPRM published 6 January 2025) would make the requirements explicit, including penetration testing at least once every 12 months and vulnerability scanning at least every six months.

As of mid-2026 the rule is still proposed, not final, and OCR continues to enforce the current Security Rule. But the direction is unambiguous, and OCR investigations already treat the absence of technical testing as evidence of an inadequate risk analysis, the most-cited deficiency in enforcement actions. Building the testing cadence now means the eventual final rule is a non-event; waiting means retrofitting a programme under a compliance deadline.

Continuous testing also answers the "regular" standard today better than any annual engagement: a documented history of scans across the year, each with findings and remediation evidence, is precisely the kind of ongoing evaluation §164.308(a)(8) describes.

FHIR and SMART on FHIR: Interoperability Is an Attack Surface

US interoperability mandates pushed patient data behind standardized APIs: FHIR R4 resources, SMART on FHIR authorization, bulk data export. Standardization helps attackers too: they know exactly which endpoints exist (/Patient, /Observation, /DocumentReference) and exactly what a misconfigured one leaks. A single FHIR endpoint that fails to enforce resource-level authorization can expose an entire patient population, and unlike a stolen laptop, it does so silently.

The recurring failure modes are specific: resource IDs accepted without verifying the requesting user's care relationship (IDOR at population scale), SMART scopes issued broadly and never enforced per-resource, and bulk export endpoints reachable with credentials scoped for single-record access. Penetrify tests these authorization boundaries the way an attacker probes them: across roles, across patients, across scopes, on every deployment of your API.

Penetrify tests authorization boundaries across all user roles (clinician, admin, patient) and specifically probes for IDOR vulnerabilities that expose patient records outside authorized care relationships. This is the #1 cause of healthcare data breaches.

Every scan produces a timestamped, severity-ranked report. When OCR audits your security program, you can demonstrate a documented history of regular security testing across your entire application, not a single annual report from one point in time.

Penetrify tests FHIR R4 and SMART on FHIR implementations for authorization boundary enforcement, scope validation, and resource access control: the specific attack surfaces that standard DAST tools are not configured to test.

Penetrify never modifies, deletes, or exfiltrates data. It tests by observing application responses, not by performing write operations. Safe to run against staging environments that mirror production patient data structure.