Pass your HIPAA security assessment

If you handle ePHI, Pentest Today gives you the technical-safeguard evidence and policies a HIPAA risk assessment expects — pentest, scans, and documentation in one place.

Get started See how it works

What a HIPAA review asks for

The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic protected health information (ePHI).

✓A security risk analysis covering systems that touch ePHI

✓Penetration testing and vulnerability scanning evidence

✓Access control and audit-logging policies

✓Encryption and transmission-security documentation

✓An incident response and breach-notification plan

What closes each requirement

Control	What they ask	Evidence	Where it comes from
§164.308(a)(1)(ii)(A) · risk analysis	An accurate and thorough assessment of the risks to ePHI's confidentiality, integrity, and availability, across the systems that actually touch it — not a template with your logo on it.	The technical inputs the analysis is built from: dated pentest and scan findings with severity and business impact, scoped to the systems marked as touching ePHI, and the architecture diagram showing where that data flows. The analysis itself — the likelihood and impact ratings and the sign-off — is the covered entity's or business associate's own work; nothing here stands in for it.	The pentest and scan workflow, plus the generated architecture diagram, both scoped to whichever systems the intake marks as part of the ePHI path.
§164.308(a)(1)(ii)(B) · risk management	Proof that a risk identified in the analysis actually got reduced to a reasonable level — a remediation with a date, not a risk still sitting in the register a year later.	The Vulnerability Management Policy's severity-based remediation SLAs — 7 days for critical, 30 for high — paired with the retest that restates each finding as fixed or not fixed, dated after the original.	The policy pack's Vulnerability Management Policy and the retest workflow, both keyed to the same findings.
§164.308(a)(6) · security incident procedures	A documented process for identifying, reporting, and responding to a suspected incident involving ePHI, with someone named to run it.	The Incident Response Policy — severity tiers, response-time targets, the containment-through-recovery lifecycle, and a post-incident review within five business days for the top two severities — plus the named incident response owner.	The policy pack, generated from the intake's named incident owner and monitoring tooling.
§164.312(a) · access control	Technical policies restricting who and what can reach systems holding ePHI, and a way to identify each person who does — the 'unique user identification' language shows up almost verbatim in reviewer checklists.	The Access Control Policy's account and authentication sections: every account tied to one named person rather than shared, administrative and production paths locked behind MFA, and a standing review of who still needs what — read against your intake's actual authentication setup, not assumed.	The policy pack, drawn from the intake's authentication method and MFA status fields rather than stated as a given.
§164.312(b) · audit controls	A record of who touched systems holding ePHI and when, so an access question has an answer instead of a shrug.	The logging and monitoring tooling named in the Incident Response Policy's current-implementation section, plus the dated run history behind every pentest and scan — a population an assessor can actually sample.	The policy pack, from the intake's logging and monitoring field, and the report's own scan-run history.
§164.312(e) · transmission security	That ePHI is protected while it's in motion across a network, not only while it's sitting in a database.	The Data Handling Policy's encryption standard — TLS 1.2 or higher in transit, plaintext protocols disabled — read against the intake's own encryption summary rather than the template default alone.	The policy pack, generated from the intake's encryption summary field.

What the report actually contains

Detailed Findings — a finding on a system in the ePHI path, illustrative

3. Appointment confirmation link exposes any patient's visit, and its cancel action, when the code is changed — no login required Severity: HIGH CVSS: 8.2 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N Status: triaged Affected Asset: https://portal.[REDACTED]health.com/appointments/confirm/{code} OWASP Category: A01:2021 – Broken Access Control Retest Status: pending Reproduction: 1. Take the confirmation link from a test patient's appointment reminder email. 2. Change the numeric code at the end of the link by one and open it in a browser that has never signed in. 3. GET /appointments/confirm/2261[REDACTED] Evidence: HTTP/1.1 200 OK content-type: text/html; charset=utf-8 The page renders a different patient's name, appointment date and time, treating provider and visit reason ('Follow-up: cardiology'), and offers Cancel and Reschedule buttons for that visit. Nothing prompts for a login, and nothing checks the code beyond whether an appointment with that number exists. Cancel was exercised only against the test patient's own appointment, reached through the same unauthenticated link; it succeeded without a login, so the action is as unprotected as the page. Business Impact: Anyone on the internet who counts through confirmation codes can read patients' names, visit times, providers and visit reasons without an account, and can cancel the visit while they are there. That is ePHI disclosed to people with no right to it — the exposure the Security Rule's access control standard at §164.312(a)(1) exists to prevent — and because it needs no credentials, it is a finding a risk analysis cannot leave open. Remediation: Require the patient to prove who they are before the page renders anything — a portal login, or at minimum a second factor bound to the appointment such as date of birth — because a short numeric code in a URL is effectively public once it can be counted through. Replace the sequential code with a long random token that expires after the visit. Treat a request with a wrong code as an attempted access to ePHI and write it to the audit trail the Security Rule expects, not only the error log. Cover the fix with a test that requests a neighbouring code and asserts nothing renders.

Illustrative example, written in the format the product generates. Not taken from a customer engagement.

How this review actually runs

There's no certifying body to route this through, so who does what has to be settled by contract, not by an auditor's checklist.

The covered entity owns the risk analysis and the decision about what counts as reasonable and appropriate. A business associate handling ePHI on the covered entity's behalf signs a Business Associate Agreement first, which is what puts the Security Rule's safeguard obligations on it at all — no BAA, no obligation, regardless of what the systems actually do.

Scoping happens next, and it decides almost everything downstream: which systems actually touch ePHI, versus which sit next to them but don't. A pentest, a scan, and the generated policies and diagrams get pointed at that scoped set — the systems in the ePHI path, not the whole company — because an assessment scoped to everything dilutes the evidence for the systems that actually matter and costs more to produce for no safeguard gained.

The technical evidence attaches once scope is settled: findings against the in-scope systems feed the risk analysis as inputs, not as the analysis itself, and the policies' current-implementation sections carry the access, audit, and transmission controls the analysis will weigh.

It stalls on scope almost every time — an assessment run against the marketing site and the corporate laptop fleet because nobody drew the ePHI boundary first, while the system that actually stores patient records never gets tested at all.

What gets this sent back

An assessment scoped to the whole company instead of the ePHI path. Testing the marketing site and the internal HR tool produces findings, but none of them evidence the systems that actually store or transmit patient data, so the risk analysis is left exactly as unsupported as before the assessment ran.

No signed Business Associate Agreement before the work starts. Without a BAA in place first, nothing that follows is actually governed by the Security Rule's safeguard requirements, which makes the eventual evidence a courtesy rather than a documented obligation either party can point to.

Treating a vendor's deliverable as the risk analysis itself. No document a vendor hands over is the risk analysis on its own — it's the covered entity's or business associate's own assessment — and a finished-looking report with someone else's name on the analysis line invites exactly the scrutiny it was meant to avoid.

Access controls documented for the whole system, not the ePHI-touching parts. A policy stating MFA and least privilege in general doesn't answer which specific systems hold patient data or who can reach them, and that's the narrower question §164.312(a) is actually asking.

No record of who reviewed a flagged risk or when. A risk analysis with findings but no record of who assessed them and when reads as a document assembled once for the file, which is the opposite of the ongoing process §164.308(a)(1)(ii)(B) expects.

How Pentest Today gets you there

01find what reviewers will find

Scan

Authenticated and external scans across web, API, and cloud surface the issues before an assessor does — de-duped, triaged, and mapped to CVE/CVSS.

02human-verified evidence

Pentest

Approved-target scans become a client-ready pentest report: validated findings, evidence, reproduction steps, remediation, and the retest letter auditors accept.

03the paperwork, written for you

Policy Generator

Generate the policies and system architecture diagrams the review expects — access control, cryptography, incident response — pre-mapped to controls.

Free · no account

Start your Pentest

Our agent swarm and human experts test your endpoints and deliver an audit, fast.

Start your Pentest How it works

Other reviews we prepare for

GDPR

GDPR Article 32 requires appropriate technical and organizational measures to secure personal data, including regular testing of their effectiveness.

PCI DSS

PCI DSS protects cardholder data and explicitly requires both internal and external penetration testing at least annually.

NIST CSF

The NIST Cybersecurity Framework organizes security around Identify, Protect, Detect, Respond, and Recover.

FedRAMP

FedRAMP authorizes cloud services for U.S. federal use, built on NIST 800-53 controls and requiring penetration testing.

CMMC

CMMC verifies that defense contractors protect Controlled Unclassified Information (CUI) per NIST 800-171.

Meta TPA

Meta requires apps and vendors that access Platform Data to complete an annual Third-Party Assessment (formerly the Data Protection Assessment) with an approved assessor.

HIPAA, answered

Does HIPAA require penetration testing?

The Security Rule doesn't name penetration testing directly, but §164.308(a)(1)(ii)(A) requires an accurate risk analysis of systems handling ePHI, and §164.312 requires technical safeguards a risk analysis has to weigh. A pentest and scan are the standard way to produce dated, specific findings for the systems in that scope.

Is there such a thing as being 'HIPAA certified'?

No — HIPAA has no certifying body and no certification to earn, despite how often the phrase gets used in marketing. What exists is a security risk analysis the covered entity or business associate performs and documents themselves, using whatever safeguard evidence they've assembled.

Does Pentest Today perform our HIPAA risk analysis?

No. Pentest Today generates the supporting policies, diagrams, and technical findings that feed a risk analysis — it doesn't perform, deliver, or sign off on the analysis itself. That assessment, including the likelihood and impact judgments, is work only the covered entity or business associate can do.

Who needs to sign a Business Associate Agreement?

Any vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity needs a signed BAA before that work starts. It's the agreement that puts the Security Rule's safeguard obligations on the vendor at all — without one, there's no HIPAA obligation to evidence.

What's the biggest reason a HIPAA assessment falls short?

Scope, almost every time. An assessment run against the whole company instead of the systems that actually touch ePHI produces findings that don't evidence the risk that matters, while the systems handling patient data go untested. Drawing that boundary first is what the rest of the evidence depends on.

Does encrypting data in transit satisfy HIPAA's transmission security requirement?

Encryption in transit is the core of §164.312(e), but the requirement is broader than one control: it covers guarding against unauthorized access to ePHI while it moves across a network. TLS 1.2 or higher is the baseline most assessments document; whether that covers the whole requirement depends on what else touches the transmission path.

Is the pentest a real test or just a scanner dump?

Both scanning and AI triage are scoped to your approved targets, and every finding is reviewed and signed off by a human before delivery — so the report reflects verified findings, not raw scanner noise.

How fast can I get a report?

Most reports turn around in hours, not weeks. You connect an approved target, we scan and verify, and you export a client-ready report and policy pack.

Get the evidence for your HIPAA review this week.

Start a scan on an approved target and walk in with the report, policies, and diagrams already done.

Get started Browse all audits