HIPAA penetration testing

HIPAA penetration testing: what the Security Rule asks for today

A customer's security review, your own risk analysis or a product launch is asking for proof that the systems holding electronic protected health information (ePHI) are tested. The short answer is that the HIPAA Security Rule does not use the term penetration testing. Instead, 45 CFR 164.308(a)(8) requires a covered entity or business associate to perform a periodic technical and nontechnical evaluation of its security safeguards, prompted by environmental or operational changes. The rule leaves the method to the organization. NIST SP 800-66 Rev. 2, the NIST guide that explains how to implement the Security Rule, suggests that penetration testing be part of that evaluation where it is reasonable and appropriate. Penetration testing is therefore a defensible way to meet the evaluation standard, but it is a choice you document, not a line item the rule names.

The test should answer the questions the evaluation and your risk analysis raise: can an outside attacker reach ePHI through internet-facing portals, APIs or remote access, can a compromised workstation or low-privilege account move laterally to systems that store or process patient data, and do authentication and session controls hold up against the attack paths your threat model describes. Commissioning the test usually starts with a short written statement of which ePHI systems are in scope, which threats the test is meant to examine, and what decision the results will feed, such as a remediation plan, a business associate review or a launch sign-off. Confirm with your privacy and compliance leads which systems they consider in scope before a provider scopes the work.

Ask a provider to show how its findings map to your risk analysis, how exploitable issues are validated and retested, and how the report will be used as evidence. Also confirm whether HHS's January 2025 proposed revision, published in the Federal Register as 90 FR 898, has changed since this page was written. The proposal would make penetration testing by a qualified person a required element at least every 12 months, with vulnerability scans at least every six months. As of October 2026 no final rule has been published, so treat that requirement as a planning assumption rather than a current obligation, and review the proposal text with counsel before you rely on it. The HIPAA Security Rule proposed rule is the primary text to check.

Which ePHI systems belong in HIPAA penetration testing scope

HIPAA does not list the systems a penetration test must cover, so scope follows from where ePHI is created, received, maintained or transmitted and what protects that data. The cards below treat each scoping decision as a separate component, and each one needs written confirmation from the client before testing begins.

Systems that handle ePHI directly

Start with the applications and databases that create, receive, maintain or transmit electronic protected health information. Map each one to a data flow diagram that shows where patient records enter, where they are stored, and where they leave. Testing should cover these systems in their production or production-equivalent configuration, because a test against a stripped-down copy may miss the access paths that matter. Confirm with the system owner which records and fields are real ePHI and which are test data, so that rules of engagement protect live patient information during exploitation attempts.

Identity and access systems

Directory services, single sign-on providers, multifactor authentication and privileged access tools decide who can reach ePHI. A weakness in any of them can expose every system behind it, so they belong in scope even when they hold no patient data themselves. Ask the client which identity platforms federate to ePHI systems, which administrative accounts exist, and whether emergency or break-glass access is documented. Testing these components should follow the authorization model the client actually runs, not the one in the design document.

APIs, portals and patient-facing interfaces

Patient portals, provider interfaces, integration APIs and health information exchange endpoints are common routes into ePHI from outside the organization. Scope should list each externally reachable interface, the authentication method it uses, and the data objects it returns. Confirm with the client whether any API serves data to third parties, and whether those third parties have their own access agreements. Authorization flaws between patients, providers and staff are a frequent category of finding here, so role boundaries should be defined before testing starts.

Cloud accounts and hosting environments

ePHI often sits in cloud storage, managed databases, container platforms and backup services spread across several accounts or subscriptions. Each account that stores, processes or can reach ePHI should be named in scope, along with the provider's published rules for security testing and the client's own responsibilities under the shared responsibility model. Confirm which accounts are production, which hold backups, and which administrative roles can change access policies. Misconfigured storage and overly broad roles are common issues, so cloud accounts that look peripheral can matter.

Network zones that connect to ePHI

Segmentation determines how far an attacker could move from a compromised workstation or vendor connection to a system holding ePHI. Scope should cover the network zones that host ePHI systems, the paths between them, and the zones that reach them, including remote access and guest or clinical device networks. Ask the client for current network diagrams and firewall rule reviews, and agree on whether the test will validate segmentation or only assess what is reachable from each zone. Clear boundaries here keep the test from drifting into unrelated infrastructure.

Third-party and self-hosted platforms

Business associates, cloud service providers and self-hosted open-source platforms may create, receive, maintain or transmit ePHI on the client's behalf. For each one, confirm whether the client owns the infrastructure and can authorize testing, or whether the vendor's contract or hosting terms restrict it. Business associate agreements define responsibilities for safeguards, but they do not automatically grant testing rights, so written approval from the provider is needed where the environment is not the client's own. For self-hosted platforms, agree in advance which hardening guidance from the project will serve as the reference for findings.

Which weakness categories a HIPAA penetration test looks for

What access control and authentication weaknesses does a HIPAA penetration test examine?

It examines whether only the right people and services can reach ePHI, and whether they prove who they are strongly enough. Testers review how accounts are created, shared, elevated and removed, whether multi-factor authentication covers remote access and administrative consoles, and whether role-based permissions match clinical and billing duties. In a healthcare setting, a shared login on a clinical application or a former employee's account that still works can expose records of many patients at once. The main risk is unauthorized access to ePHI, which undermines confidentiality and makes it hard to show who viewed or changed a record. Testers report these as weakness categories with affected systems, not as lists of login attempts.

How do exposed services and misconfigurations put patient data at risk?

Misconfiguration is one of the most common reasons ePHI systems are reachable from places they should not be. Testers look for services listening on external addresses that were meant for internal use, default settings left in place, verbose error pages, storage or backup locations without access restrictions, and administrative interfaces reachable from the internet. In a hospital, a legacy imaging server or a vendor-managed remote support tool that is publicly reachable can become a path to stored records. The concern is confidentiality of ePHI and, where an attacker can change settings, integrity of clinical data. Confirm with your cloud and infrastructure teams which assets are intended to be public before testing begins, because that baseline determines what counts as an exposure.

Why does network segmentation between ePHI systems and the rest of the network matter?

Segmentation limits how far a compromise can spread once an attacker reaches any single device. Testers check whether systems holding ePHI, such as the electronic health record database, billing platform and backup repository, are separated from general office networks, guest Wi-Fi, medical devices and third-party connections, and whether the controls between those zones actually block traffic. A common finding is a flat network where a workstation on the administrative side can reach the database segment directly. This affects availability as well as confidentiality, because a spreading compromise can disrupt clinical operations. Scope the test so that segmentation boundaries are tested from both sides, and confirm the zones with your network documentation.

What makes APIs and patient portals insecure in a healthcare environment?

Insecure APIs and portals usually fail through authorization logic rather than through obvious flaws. Testers examine whether one patient can view another patient's records by changing an identifier in a request, whether APIs return more data than the screen displays, whether sessions expire properly, and whether input is validated before it reaches back-end systems. Patient portals, telehealth interfaces and integration endpoints that exchange data with laboratories or payers are common areas of interest. The risk is unauthorized disclosure of ePHI at scale and corruption of records through unvalidated input. Application-layer testing against recognized guidance, such as the OWASP Web Security Testing Guide, is typically the method used here, and the test plan should name each API and portal in scope.

How can weak logging and monitoring hide misuse of ePHI?

Logging weaknesses do not usually let an attacker in, but they let misuse go unnoticed. Testers check whether authentication events, record access, privilege changes and administrative actions are recorded, whether logs are protected from alteration, whether they reach a central place where someone reviews them, and whether alerts fire for unusual access such as bulk record retrieval. The HIPAA Security Rule expects audit controls and activity review, so gaps here also affect compliance evidence. The impact is that an intrusion or insider access may persist for a long time without detection, and investigators may be unable to establish which records were viewed. Ask the tester to confirm which log sources they will sample so the findings reflect what your security operations team can actually see.

Why are unpatched and end-of-life components a priority in healthcare testing?

Known vulnerabilities in components that are no longer updated are among the easiest weaknesses to confirm and among the hardest to fix. Testers identify software versions and firmware on servers, clinical applications, medical devices, network equipment and self-hosted open-source platforms, then compare them against vendor support status and published vulnerability information. Medical devices and older clinical systems are often difficult to patch because of validation requirements or vendor restrictions, which makes compensating controls and segmentation important. Unsupported components threaten ePHI confidentiality, integrity and availability at once, since a disruption can halt care delivery. Ask for an inventory of in-scope assets with versions and support dates before testing, and confirm with each vendor how patches are applied to regulated devices.

Can a HIPAA penetration test cover all of these categories at once?

A single engagement can cover these categories, but only when the scope names the systems that hold or transmit ePHI and the test methods are matched to each category. Network, application, configuration and segmentation work usually require different skills and different rules of engagement, so the statement of work should list them separately. Some categories, such as logging, are better assessed through document review and sampling than through active testing. Because DeployOpen runs security testing as fixed-scope engagements agreed in writing before work starts, the scope document is where these categories are defined. Ask any provider to show how each category maps to specific in-scope assets and to the evaluation that your risk analysis calls for.

What drives HIPAA penetration testing cost and duration

This table compares the components that set the size of a HIPAA penetration test, such as the systems holding ePHI, the number of user roles and the reporting format. Read each row as a question to answer in the scope document before requesting a quote. The main takeaway is that cost follows the written scope, so vague scope produces vague quotes.

Cost driver	Why it moves cost or effort	What to ask for in a written quote
Applications and APIs handling ePHI	Each patient portal, billing system, API gateway or integration that creates, receives, stores or transmits ePHI adds test planning, authenticated testing and findings analysis. Shared components tested once cost less than separate builds.	A list of every in-scope application and API, the ePHI data flows each one touches, and which are excluded and why.
External network footprint	More public IP addresses, domains and exposed services increase discovery and validation time. Cloud-hosted assets that change often may need a fixed snapshot date.	The exact address ranges and domains in scope, the asset count the provider assumed, and how out-of-scope assets are handled if discovered.
Internal network and segmentation	Testing from inside the network, including segments that host ePHI systems, adds time for access setup and lateral movement analysis. Testing segmentation between ePHI and non-ePHI zones is a separate effort.	The subnets and VLANs included, whether segmentation validation is in scope, and the assumed starting position for internal testing.
Cloud accounts and environments	Each cloud account, subscription, project or Kubernetes cluster adds configuration review and access setup. Multiple environments such as production and staging each need a decision on whether they are tested.	The accounts and environments named, the provider testing rules that apply, and whether configuration review is included or priced separately.
User roles and authentication	Each distinct role, such as patient, clinician, administrator or business associate user, needs its own authenticated testing path. Single sign-on, multifactor authentication and delegated access add setup and verification work.	The number of roles tested, the test accounts the client will provide, and how multifactor and single sign-on flows are handled.
Test depth and approach	Credentialed testing usually takes more effort than unauthenticated testing because it covers more functions. Automated scanning alone costs less than manual testing of business logic and access control.	Whether the test is black box, grey box or white box, the depth of manual testing, and which test categories are covered.
Retest rounds	Retesting verifies that fixes closed the findings. Each round adds work on the same systems, and the number of rounds depends on how many findings are remediated and when.	The number of retest rounds included, the time window for retesting, and whether retests are fixed-price or billed by effort.
Reporting format for the auditor or customer	A full technical report, an executive summary, a letter for a customer or a format mapped to a specific assessor template each require different drafting and review effort.	A sample of the required report format, the audience for each version, and whether a summary letter for customers is included.
Pre-test preparation and coordination	Scope workshops, asset inventories, rules of engagement, test windows and coordination with the client's hosting provider or managed service provider take client and provider time. Gaps in the inventory often add change requests.	Who prepares the asset inventory, the number of scoping meetings included, and the process for scope changes during testing.

How HIPAA penetration testing runs from scoping to retest

The sequence turns a broad HIPAA evaluation expectation into a bounded test of the systems that hold or reach ePHI, with written evidence of what was tested, what was found and whether the fixes held. Each phase produces an artifact a security officer, auditor or customer can review.

Agree written scope and rules of engagement
The client security officer and the testing provider agree in writing which systems, domains, IP ranges, applications and test types are in scope, along with exclusions, testing windows, emergency contacts and any restrictions on tests that could affect production ePHI. Your organization's cloud or hosting provider may have its own testing rules, so confirm those first. The step closes when both parties sign the scope and rules of engagement document.
Confirm assets and ePHI data flows
Working from your asset inventory and architecture diagrams, the provider confirms which applications, databases, interfaces, backups and third-party services create, receive, store or transmit ePHI. Your team validates the list and flags systems that were missed or retired. The output is a reviewed asset list and data-flow map that ties each in-scope system to its ePHI role, which also feeds the risk analysis the Security Rule requires.
Test from outside the network
Testers examine internet-facing hosts, services, remote access entry points and public application interfaces from an external vantage point, looking for exposed services, weak configuration and exploitable weaknesses in the perimeter. Testing stays within the agreed targets and pauses if a critical issue affects availability. The step closes with a list of confirmed external observations, each with evidence and the conditions needed to reproduce it.
Test from inside the network and at the application layer
From a position inside the environment, testers assess authentication, access control, trust relationships, directory services and the handling of ePHI within applications and APIs. They check whether a user with ordinary access can reach records outside their role. Findings are recorded against the affected system and role. The step closes with validated internal and application findings, each linked to the asset list so remediation owners are clear.
Validate segmentation around ePHI systems
Where your architecture relies on network segmentation or isolation to limit ePHI exposure, testers attempt to reach ePHI systems from networks that should not have access. The goal is to confirm that the boundary works as your documentation says. If segmentation is not in place or fails, the report says so. The step closes with a segmentation result for each boundary tested, which supports your risk analysis and any later review of access controls.
Deliver the report with severity ratings
The provider issues a report that describes the method, scope, dates, tester qualifications, limitations and each finding with a severity rating, affected assets, evidence and a recommended fix. The report should separate confirmed issues from observations. Ask the provider to explain how it assigns severity so your team can apply the same logic to your risk register. The step closes when the client accepts the report as the baseline for remediation.
Remediate and record decisions
Your team owns remediation. For each finding, you fix the issue, document a compensating control, or record a risk acceptance with a named approver. The provider does not implement these controls if your engagement forbids it, which keeps testing independent from remediation. The step closes with a remediation tracker that shows the status and decision for every finding, which becomes part of your evidence file.
Retest to confirm corrections
The provider retests the fixed findings to confirm that the corrections work and do not open new exposure. Findings that remain open or are accepted are carried into the next evaluation. The retest report identifies each finding as closed, still open or accepted. Ask what the provider needs from you to reproduce each fix, and confirm whether the retest will be issued as a separate document. The step closes with a signed retest report.

How the HIPAA Security Rule and the proposed rule treat penetration testing

This table compares the current HIPAA evaluation standard, the January 2025 proposed revision, and adjacent frameworks that often set testing expectations for the same systems. Read the first two rows to see what applies today and what could change, then use the remaining rows to see which other obligations your customers, auditors or assessors may bring. Confirm every requirement with counsel and your assessor before scoping.

Requirement or framework	What it expects	What to confirm or retain
45 CFR 164.308(a)(8) evaluation	Periodic technical and nontechnical evaluation of security safeguards. The text does not name penetration testing.	NIST SP 800-66 Rev. 2 suggests penetration testing within the evaluation where reasonable and appropriate. Document the reasoning.
January 2025 proposed Security Rule revision (90 FR 898)	Penetration testing by a qualified person at least every 12 months, and vulnerability scans at least every six months.	Proposed only. As of October 2026 no final rule has been published, so confirm the current status in the Federal Register.
PCI DSS requirements 11.4.2 and 11.4.3	Internal and external penetration tests at least every 12 months and after significant changes, by a tester with organizational independence.	Applies only where cardholder data is in scope. Confirm the scope boundary with your payment assessor.
HITRUST assessment	Penetration test reports can serve as evidence for direct testing of requirement statements. Assessor firms may test but may not perform remediation.	Confirm the assessment type, the testing timing and who may perform the test with your HITRUST assessor.
SOC 2 Trust Services Criteria	No explicit penetration testing requirement. Auditors and customers often expect a test covering the systems in the system description.	Scope the test to the system description and confirm expectations with your SOC 2 auditor.
CIS Safeguards 18.2 and 18.5	External and internal penetration tests at least annually. CIS maps Safeguard 18.2 to ISO/IEC 27001 control A.8.8.	A voluntary benchmark. Customers and assessors may use it as a baseline, so keep dated reports and remediation records.

How testing changes for cloud, on-premises and self-hosted ePHI systems

Cloud-hosted ePHI systems divide responsibility between the covered entity or business associate and the cloud provider. Testing scope follows that division: the client tests its own configurations, workloads, identities and applications, while the provider's underlying infrastructure is governed by the provider's published testing rules. Those rules vary by service and change over time, so the version you scope against should be recorded in the statement of work.

Provider rules: Confirm the provider's current penetration testing policy, permitted services, notification expectations and prohibited activities, and record the version you tested against.
Account boundaries: Name every subscription, project, account or tenant in scope, and separate production ePHI accounts from shared logging or security accounts.
Managed services: Identify which managed databases, storage, queues and key services the provider operates, and agree that testing covers your configuration of them, not the platform itself.
Identity and access: Agree which test identities are created, what roles they hold, how long they last and how they are removed, since cloud identity is often the main path into ePHI.
Data location and keys: Confirm the regions where ePHI resides, including backups and replicas, and who controls the encryption keys, so the test covers every copy.

Before testing starts, check the provider's current rules, the shared responsibility matrix and a written list of ePHI-bearing resources.

What the HIPAA penetration test report gives your compliance team and customers

A HIPAA penetration test produces several components, and each one serves a different reader. Agree the format of each component before testing starts, because the full technical report is usually shared with a much smaller audience than the summary materials.

Executive summary

A short narrative for leadership that states the scope tested, the overall exposure, the number of findings by severity and the findings that need action first. It feeds the risk analysis and the governance record that the evaluation standard expects an organization to keep. Check that it names the systems in scope and the testing dates, since a summary without them cannot be tied back to a specific evaluation.

Technical findings with severity and assets

Each finding should name the affected asset, such as an ePHI application, API, database or remote access gateway, describe the weakness category, and give a severity rating with the reasoning behind it. Ask the provider to explain how the rating was assigned and whether it reflects the sensitivity of the ePHI on that asset. This section feeds your risk analysis and is the part most likely to be reviewed by an internal audit or a regulator.

Scope and methodology statement

This statement records which systems, accounts, network zones and data flows were in scope, what was excluded, which test types were performed, and whether testing was internal, external or both. It is the document that proves the test covered the systems that create, receive, maintain or transmit ePHI. Confirm that it lists the test dates and any limits the tester agreed to, because gaps here weaken every other deliverable.

Remediation guidance

Remediation guidance tells engineering teams how to fix each finding and whether a fix is a configuration change, a code change or a compensating control. Ask for guidance that is specific to your platform and version, not generic advice. Your risk management plan should show which findings you accepted, which you mitigated and who owns each action and its target date.

Retest report showing closed findings

A retest report shows, finding by finding, whether each correction was verified, partly fixed or still open. Without a retest, the original report shows only what was wrong at one point in time. Agree in advance whether retesting is included in the quote, how long after remediation it will happen and whether the tester will confirm closure in writing. Keep the retest with the original report so the two form one evidence chain.

Summary letter for customers

A summary letter confirms that a qualified tester performed the test, states the period, scope category and high-level outcome, and states whether critical findings were verified as closed. It is written for a customer's security or procurement team, so it does not contain exploitable detail. Agree the letter's wording and recipients with the provider before testing, and confirm that the provider will sign it, since it is the item most often requested in customer security reviews.

What your team prepares before HIPAA penetration testing starts

Before a tester sends a single packet, your team should name one technical contact with authority over the systems in scope, plus a documented escalation path that reaches a decision-maker within hours, not days. The tester needs that person to confirm scope changes, approve a pause if a test causes instability, and coordinate with hosting, cloud and application owners. Pair that contact with an asset and data-flow inventory that marks every system that creates, receives, stores or transmits electronic protected health information (ePHI), including the identity provider, logging pipeline, backups and any third-party services that touch those flows. Gaps in this inventory are the most common reason a scoped test misses the systems that matter most to HIPAA risk analysis, so ask whether the inventory matches the risk analysis your organization already maintains under 45 CFR 164.308(a)(8).

Next, prepare test accounts for each role the application or platform supports, such as patient, clinician, administrator, billing and support staff. Testers need these to check whether role boundaries hold, and an account per role lets them do that without using real staff credentials. Agree on testing windows in writing, record any change freeze that overlaps them, and confirm that backups are current and restorable before testing begins. Write down the procedure for stopping a test, the criteria for declaring a possible incident, and who notifies whom if a tester triggers a monitoring alert. Your security operations team should know the test is happening, and the test should be recorded so that alerts can be matched to test activity afterward.

Finally, plan for ePHI that testers may encounter. Where possible, use synthetic or de-identified data in test environments, and confirm with the vendor and your own environment that production records are not needed to demonstrate a finding. If testers must view or handle real ePHI, your legal and privacy team should approve in writing how that access is limited, logged, stored, and destroyed, and whether a business associate agreement covers the tester. Ask the provider to describe its handling and destruction practices before work starts, and confirm that findings reports do not reproduce patient records.

What to check when choosing a HIPAA penetration testing provider

Each check below answers a question a buyer must settle before signing: who is testing, whether they can judge their own later work, what is in bounds, how ePHI is protected during the test, and what evidence comes back. Treat them as parallel decisions, and record the answers in the written scope and quote.

Tester qualifications and documentation

Ask who will perform the test, what hands-on experience they have with web applications, networks, cloud and the platforms in scope, and how that experience is documented. HIPAA does not name a tester credential, so the security rule's requirement for a qualified person is judged by your own risk analysis. Ask for named roles, relevant certifications held by those individuals, and a sample of how findings are written up. Confirm any certification claim directly with the issuing body.

Independence from remediation work

Confirm whether the provider would later fix the issues it finds, configure the controls it tested, or operate the systems it assessed. A firm that remediates its own findings weakens the value of the retest and of the report as evidence of an independent evaluation. Put the separation in writing: which teams test, which teams remediate, and who signs off on closure.

Written scope and rules of engagement

The scope should list the ePHI systems, applications, APIs, network ranges, cloud accounts and user roles in bounds, along with explicit exclusions such as third-party hosted services you do not control. Rules of engagement should cover testing windows, source addresses, emergency contacts, and what happens if the tester reaches production patient data. Ask for both documents to be signed before testing begins.

Data handling and confidentiality for ePHI

Testers may encounter ePHI in screens, responses, logs or files. Ask how the provider limits access to that data, where evidence is stored, how long it is retained, whether test data can be synthetic, and how it is destroyed at the end. Your business associate terms should be settled before any test that could expose ePHI, and the contract should address breach notification by the tester.

Report format and retest terms

Ask for a sample report before you buy. It should give each finding a severity, affected asset, reproduction summary at a defensive level, and a recommended fix, with an executive summary for leadership. Confirm whether a retest of critical and high findings is included, how long the provider keeps records, and whether the report can be shared with your auditor or customers.

Confidential references and a written quote

Ask for references from comparable regulated organizations, shared under a non-disclosure agreement, and check that they describe a test of similar scope. Request a written quote that ties every line to the written scope, lists which parts are one-time and which recur, and states what changes the price, such as added hosts or a retest. DeployOpen does not publish a price list, so a quote follows from the written scope.

What HIPAA penetration testing costs, takes and needs from your team

What drives the cost of a HIPAA penetration test?

The main cost driver is the amount of work the scope creates, not a standard rate for HIPAA. Cost follows the number of in-scope systems that hold or transmit ePHI, the number and complexity of applications and APIs, how many user roles and integrations need testing, whether testing is internal, external or both, and whether the team must test from an assumed-user position. Each of these is set in the written scope before work starts, so ask for a quote that lists each asset class, test type and access level separately. No fixed price applies to HIPAA testing as a category, and no figure is given here because none was supplied.

How long does a HIPAA penetration test take?

Duration depends mainly on scope size, how quickly the client confirms access and test accounts, and how many findings need validation and reporting. A narrow external test of one patient portal moves faster than an internal test that spans electronic health record integrations, file shares and cloud storage. Delays usually come from waiting on credentials, environment access or change windows rather than from the testing itself. Ask the provider to state the active testing window, the reporting window and the dependencies on your side as separate line items in the proposal.

What does our team need to provide before testing starts?

Plan for a clear set of inputs before the first test day. These usually include a written scope listing in-scope hosts, applications and cloud accounts, test user accounts for each role that handles ePHI, network diagrams or data flow maps, rules of engagement covering testing windows and emergency contacts, and a named person who can approve changes if a test affects production. Confirm whether the test will run against production or a non-production copy that mirrors it, since that choice changes both risk and the value of the results. Your team should also confirm backup and monitoring coverage so that any disruption is detected and handled.

Can our internal team run a HIPAA penetration test themselves?

An internal team can run testing if it has the skills, time and independence the test needs, but the HIPAA Security Rule does not require a particular tester type or organizational structure. The practical question is whether the people testing can find weaknesses they did not build, document results to a standard an outside reviewer will accept, and verify that fixes work. Many organizations use internal staff for routine scanning and outside testers for periodic penetration tests. If you choose a mixed model, document who tested what, how independence was maintained and how findings were tracked to closure.

How often should we test under the current HIPAA rule and the proposed rule?

The current Security Rule requires periodic technical and nontechnical evaluations under 45 CFR 164.308(a)(8) but sets no fixed testing frequency, so the interval is set by your own risk analysis and changes to your environment. The January 2025 proposed revision (90 FR 898) would require penetration testing by a qualified person at least every 12 months and vulnerability scans at least every six months, but no final rule had been published as of October 2026. Plan to the proposed frequency if you want to be ready, and confirm the final text before treating it as binding.

Is a vulnerability scan enough for HIPAA?

A vulnerability scan alone does not establish the kind of evaluation that penetration testing provides, although it is a useful input. Scanners identify known weaknesses and missing patches across many hosts quickly, but they rarely show whether a weakness can be chained into access to ePHI or whether authentication and authorization logic holds. NIST SP 800-66 Rev. 2 suggests penetration testing as part of the evaluation where it is reasonable and appropriate. Use scans for frequent coverage and penetration tests for periodic depth, and record how both feed your risk analysis.

How does retesting work after a HIPAA penetration test?

Retesting checks whether the fixes for reported findings actually work. The usual sequence is that the client remediates findings, provides evidence of each change, and the tester re-validates the specific issues against the original test conditions. Results should show which findings closed, which remain open and any compensating controls accepted in the risk analysis. Ask the provider whether retest is included in the fixed scope or quoted separately, how many retest rounds are covered and how the retest report is issued, so that you can show the closure trail to an auditor or customer.

How DeployOpen scopes, tests, reports and retests HIPAA systems

DeployOpen plans and runs HIPAA penetration testing as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before work starts. We align the test with the systems that create, receive, store or transmit ePHI, and we document results so your risk analysis and evaluation records can use them.

How we scope

Map the systems that create, receive, maintain or transmit ePHI, including the hosting and integration paths around them
Agree in writing which external, internal, application and API targets are in scope, and which are excluded
Confirm rules of engagement, test windows, credentials and any third-party hosting terms before testing starts

How we build

Select a test approach for each target, combining automated scanning with manual testing by experienced testers
Test authentication, access control and session handling in applications that expose ePHI to users or other systems
Record each finding with affected asset, evidence, risk rating and a remediation path that your team can act on

How we hand over

Deliver a report that states scope, methodology, dates, tester roles, findings and mitigating recommendations
Map findings to the risk analysis and evaluation activities you can present to HHS or your covered entity customers
Walk through results with your security, compliance and engineering leads so remediation owners are clear

How we support

Retest critical and high findings after fixes so you hold verified closure evidence, not only vendor confirmation
Offer ongoing support and continuous testing as a retainer when systems change or the annual test cycle needs planning
Confirm with your legal and compliance advisers how the report will be shared with customers, auditors and business associates