HIPAA penetration testing requirements and cost

Does HIPAA require penetration testing today?

The current HIPAA Security Rule does not use the term penetration testing. Instead, the evaluation standard in 45 CFR 164.308(a)(8) requires a covered entity or business associate to perform a periodic technical and nontechnical evaluation of its security policies and procedures. If a customer, contract or OCR inquiry asks you for a penetration test, the honest answer is that the rule does not name one, but it does expect you to test whether your safeguards work. The question you need to answer is how your organization meets that evaluation duty, and whether a penetration test is part of that answer.

What counts as sufficient depends on your risk analysis. NIST SP 800-66 Rev. 2 suggests penetration testing as part of the evaluation where it is reasonable and appropriate, with written approval from senior management, and it lists penetration test results among the internal sources to feed into risk identification. So the test should follow from the risks you identified, the systems that hold electronic protected health information, and the controls you need to confirm. Your organization owns that decision and must document it. A testing firm can perform the test and report findings, but no assessor certifies that a penetration test satisfies HIPAA, and HHS does not recognize private certifications as proof of compliance.

Before you commit budget, confirm three things: which systems your risk analysis places in scope, how your senior management approves the test in writing, and how findings will be tracked into remediation and the next evaluation. Ask any testing provider to show how their scope maps to those systems and who on their team holds the relevant experience. Also watch the pending change: the January 2025 proposed rule would require penetration testing at least once every 12 months, but as of October 2026 it has not been finalized, so the current rule governs today's obligations.

What changes if the 2025 proposal is finalized

Covered entities, including health plans, health care clearinghouses and covered health care providers, are governed today by the Security Rule text in 45 CFR Part 164 Subpart C. That text does not name penetration testing. The closest requirement is the evaluation standard in 164.308(a)(8), which calls for periodic technical and nontechnical evaluation of security policies and procedures. Whether a penetration test belongs in that evaluation is a risk-based decision the entity documents.

No fixed testing frequency: The current rule sets no annual penetration test and no scanning interval, so the schedule follows the entity's own risk analysis and evaluation plan.
Addressable choices still apply: Many technical specifications, including encryption, are addressable, so an entity must document why it chose a measure and what it adopted instead.
NIST guidance is informational: NIST SP 800-66 Rev. 2 suggests penetration testing as part of evaluation with written senior management approval, but it does not bind the entity.
Records matter: Test scope, dates, findings and remediation decisions should be kept with the risk analysis for at least six years.

Confirm with counsel and your compliance lead which testing commitments your contracts with payers or customers already impose, since those may be stricter than the rule itself.

Scoping a penetration test that matches the risk analysis

A penetration test under HIPAA is only as useful as its scope. The decisions below connect the systems holding ePHI, the risk analysis that ranks them, and the written approval that lets testers act, so the results can feed the risk management plan.

Identify every system holding ePHI

Start from the risk analysis inventory of where electronic protected health information is created, received, stored or transmitted. Include EHR modules, billing platforms, file shares, backups, laptops and third-party services that store ePHI for you. A test that skips a system with ePHI leaves a gap the assessor will ask about. Confirm the list with the system owners, not only the IT asset register.

Choose external or internal testing

External tests simulate an attacker from the internet against public addresses, VPN endpoints and exposed services. Internal tests start from a workstation or network segment and show what an insider or a compromised account could reach, including paths to ePHI databases. Most organizations need both, and the risk analysis should explain which threats each one covers.

Scope web and API applications

Patient portals, scheduling tools and integration APIs often expose ePHI through authentication and authorization logic rather than through network flaws. Ask the tester to cover login, session handling, role checks and object-level access to records. Confirm which environments are in scope, such as production or a staging copy with real data, because that choice changes what the findings prove.

Cover cloud and on-premises environments

Hybrid estates need separate scope decisions for each side. For cloud accounts, confirm the provider's testing rules and which services, identity settings and storage buckets are included. For on-premises systems, confirm data center segments, medical devices and legacy servers that cannot tolerate aggressive scanning. Record any exclusion and the compensating control that covers it.

Set rules of engagement and written approval

The NIST guidance suggests penetration testing only with written approval from senior management, and it defines testing as an attempt to compromise security solely to test control effectiveness. Document the approved targets, testing windows, permitted techniques, stop conditions, data handling for any ePHI the testers encounter, and the named contacts. Ask the testing provider to sign these terms before work begins.

Feed findings into risk management

Each finding should map back to an entry in the risk analysis, get a severity and an owner, and drive a dated remediation decision in the risk management plan. Retest after fixes and keep the report, the response and the retest evidence together. Record accepted risks with a reason. The tester supplies the evidence; the covered entity or business associate decides what to do with it.

How a HIPAA-aligned penetration test runs from scope to remediation

The sequence turns a penetration test into evidence that the organization evaluated its safeguards, tied to the risk analysis, with findings tracked to closure and records kept under the documentation standard. Durations depend on scope and are agreed in writing before work starts.

Authorize the test in writing
Senior management approves the test in writing before any tester touches a system. NIST SP 800-66 Rev. 2 suggests this written approval as part of a penetration test used in the evaluation, so the approval should name the systems, the testing window, the permitted techniques and the people who can stop the test. The organization owns this decision. The output is a signed authorization letter and a rules-of-engagement document that the security official and the system owners both hold.
Define scope from the risk analysis
The scope comes from the organization's risk analysis and asset inventory, not from a list of convenient targets. Staff identify which electronic information systems store, process or transmit ePHI, which internet-facing services and internal segments reach them, and which third-party hosts are involved. Any system outside the organization's control needs the provider's written consent before testing. The output is a scoped asset list with owners, data classifications and test boundaries, reviewed by the security official.
Agree rules of engagement and safety controls
Testers and the organization agree how testing will run: source addresses, timing, accounts to be used, whether social engineering or denial-of-service testing is excluded, data handling rules, and how a tester must respond if they encounter real patient records. Backups, monitoring and an emergency contact are confirmed before testing begins. The output is a signed rules-of-engagement document and a tested contact path, so the team can halt the test without delay.
Run the test under the agreed rules
Qualified testers attempt to compromise the in-scope systems to check whether existing controls work, covering external, internal and application attack paths as agreed. The NIST guide describes this as testing whose sole purpose is to measure control effectiveness. The team logs every action with timestamps and keeps the activity within the boundaries set in step three. The output is a time-stamped activity log and a list of any events that required the test to pause or stop.
Report findings with severity and affected ePHI systems
The testers deliver a written report that describes each finding, how it was reached, its severity and the business impact, and names the affected systems and whether they hold ePHI. Findings should map to the Security Rule standards they weaken, so the risk analysis and risk management plan can be updated. The organization reviews the draft for accuracy before it is finalized. The output is a final report that the security official accepts and that feeds the risk management plan.
Track remediation and retest the fixes
The organization assigns each finding to an owner, sets a target date and records the decision for any risk it accepts, including why and who approved it. Once fixes are applied, the testers or another qualified person retest the affected systems to confirm the weakness is closed. The output is a remediation register showing each finding's status, the approved exceptions and the retest results, which the security official reviews on a regular basis.
Retain records and feed the evaluation
The authorization, scope, rules of engagement, report, remediation register and retest results form part of the documentation that the Security Rule's documentation standard requires organizations to keep for six years, and to make available to the people responsible for implementing the safeguards. The results also feed the next periodic evaluation under the evaluation standard. The output is a retained, indexed evidence package that can answer an OCR request about what was tested, what was found and how it was fixed.

What must be in place before testing starts

HIPAA does not name penetration testing, but a test is only useful when the organization can say what it covers, who approved it, and who will act on the results. The five items below connect the asset inventory, the risk analysis, the written authorization, the response plan and the remediation owners, so each test feeds the evaluation the Security Rule already requires.

Current asset inventory

Before any test, list every system that creates, receives, stores or transmits electronic protected health information, including cloud accounts, APIs, remote access gateways and backup targets. Check the inventory against the network, cloud account lists and the identity directory, and confirm each entry has an owner and a data classification. A test that misses a system that holds ePHI produces a clean report that does not describe the real exposure. Ask whether the inventory was reconciled in the last cycle, not whether one exists.

Risk analysis that lists test sources

NIST SP 800-66 Rev. 2 lists vulnerability scans and system security test results, such as penetration tests, among the internal sources an entity uses to identify vulnerabilities in its risk assessment. Check that the risk analysis names the test as an input, records which systems and threats it targets, and states how findings feed back into risk ratings. If the risk analysis does not mention the test, the test results will not show up in the risk management plan.

Written authorization from senior management

NIST SP 800-66 Rev. 2 suggests that penetration testing, where testers try to compromise systems solely to test control effectiveness, happen with written approval from senior management. The document should name the systems in scope, the test window, the permitted techniques, the testing firm and the individuals who may stop the test. Check that the signer has authority over the systems in scope, and that the document covers any third-party hosting provider whose infrastructure is included.

Backup and incident contacts

Testing can trigger alerts, lock accounts or degrade a clinical system, so the test team needs named contacts on both sides before the first packet is sent. Check that each contact has a phone number that works outside business hours, that the security operations team knows the test dates, and that a documented procedure says when to pause testing and when a real incident must be reported under the organization's incident response plan. Confirm that backups of in-scope systems exist and have been restored successfully before testing begins.

Named remediation owners

Each finding needs a named owner who can change the system, a target date set through the risk management process, and a record of how the fix was verified. Check that owners are assigned by system rather than by department, so a finding in a clinical application does not wait for a general IT queue. Confirm who signs off on accepted risks, because an unowned finding is the one that will be cited in a later review.

Tester qualifications and data handling

The proposed 2025 rule defines a qualified person for penetration testing as someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting ePHI. Check the tester's experience with systems that hold ePHI, the rules for handling any PHI the tester sees during the test, and the secure storage and deletion of test data and reports. Ask the tester to name the methods it will use and confirm that testing will not copy patient records out of the environment.

Who owns the test, who performs it and who verifies it

The covered entity or business associate remains responsible for its Security Rule program, including any penetration testing it chooses to rely on. The Security Rule places the duty to evaluate safeguards on the regulated entity, so the organization decides whether testing is reasonable and appropriate, approves its scope, and accepts the residual risk the results reveal. NIST SP 800-66 Rev. 2 suggests that penetration tests run with written approval from senior management, which is a decision only the organization can make.

Approves scope and rules of engagement: Senior management signs off on which systems are tested, which techniques are allowed, and when testing may run.
Owns risk decisions: The organization decides how findings feed the risk analysis and risk management plan and which remediation is accepted, deferred or compensated.
Retains evidence: The organization keeps the approval, the test report, remediation tickets and retest results as part of its six-year documentation.
Designates the security official: The named security official coordinates the testing program and reports results to leadership.
Manages vendor contracts: Any outside tester or partner that touches ePHI systems should be covered by a business associate agreement where the Security Rule requires one.

Before engaging anyone, confirm internally who holds the written approval and who will receive the final report.

Choosing a penetration testing firm for ePHI systems

A penetration test of systems holding ePHI is only as useful as the firm running it, the rules it operates under and the report it hands back. The cards below cover the checks that separate a qualified firm from a generic scanning vendor, and the questions to put in writing before any work begins.

Healthcare and ePHI experience

Ask for two or three engagements against environments that resemble yours, such as an EHR integration, a patient portal or a clinical data warehouse. Experience with health care systems matters because the risk analysis that drives the test depends on how ePHI moves through those systems, and testers who understand that flow find the paths that matter. Ask how they have handled systems that cannot be taken offline during testing, and confirm those references can be shared under a nondisclosure agreement.

Tester qualifications

The proposed rule would require penetration testing by a qualified person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting ePHI. Ask who will actually run the test, what security certifications or training they hold, and how many years they have tested web, network, cloud and API targets. Confirm that a named lead tester is assigned and that you can approve any change in staffing.

Written rules of engagement

NIST SP 800-66 Rev. 2 suggests that penetration testing be approved in writing by senior management before it starts. The rules of engagement should name the systems in scope, the source addresses testers will use, the testing windows, the techniques that are off limits, such as denial of service, and the escalation contact for a critical finding or an outage. Without these terms in writing, a test can disrupt clinical operations or create an unauthorized access event that your own incident process must then handle.

Data handling for encountered ePHI

Testers often reach databases, file shares and logs that contain real patient records. The agreement should say what the tester may view, how screenshots and extracts are stored, where data is held during testing, how long it is kept and how it is destroyed. Ask whether the firm will sign a business associate agreement if it may access ePHI, and whether testing can use synthetic records or masked data instead. Confirm that evidence of a finding can be shown with metadata rather than the record itself.

Reporting quality

A useful report ties each finding to a specific system, shows how it was reached, rates its severity against your risk analysis and gives a concrete fix. Ask for a sample report with identifying details removed. Check that it separates confirmed exploitation from theoretical risk, lists the systems that were tested and the ones that were not, and states the methods used so your team and any later assessor can reproduce the result. A report that only lists scanner output does not satisfy the evaluation your own program must perform.

Retesting and remediation support

A finding is closed only when a retest confirms the fix. Ask whether retesting is included in the quote or billed separately, how many retest rounds are covered, and how long after delivery retests can be scheduled. Ask whether the firm will supply evidence that a retest was performed and what it showed, since that evidence belongs in your documentation. Clarify that the firm prepares technical evidence while your organization owns the decision to accept any residual risk.

Common questions about HIPAA penetration testing

Is a penetration test legally required under HIPAA today?

No current provision of the Security Rule names penetration testing. The evaluation standard in 45 CFR 164.308(a)(8) requires periodic technical and nontechnical evaluation of security policies and procedures, and the risk analysis standard requires you to identify threats and vulnerabilities to ePHI. A penetration test is one way to meet those duties, and NIST SP 800-66 Rev. 2 suggests it as part of the evaluation where reasonable and appropriate, with written approval from senior management. Your obligation is to evaluate your controls in a way that fits your risk, and to document how you did it and why. Ask your counsel or compliance lead to confirm how this applies to your environment.

Does a penetration test certify HIPAA compliance?

No. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications, so a penetration test cannot certify HIPAA compliance. It produces findings about specific systems on the date tested. Those findings are evidence that feeds your evaluation and risk management records. Treat the report as one input among policies, access reviews, logs and remediation tracking. When a customer asks for proof, ask for the scope, the tester's qualifications, the findings, and evidence that each finding was fixed or formally accepted.

How often should we run a penetration test for HIPAA?

The current rule sets no fixed interval. The evaluation standard calls for periodic evaluation, and the frequency should follow your risk analysis, system changes and threat environment. The January 2025 proposed rule would require penetration testing of relevant systems by a qualified person at least once every 12 months, or more often if the risk analysis calls for it, plus automated vulnerability scans at least every six months. That proposal is not final. As of October 2026 the latest Unified Agenda projects final action in July 2027. Plan for at least annual testing after major changes, and confirm the final text before you commit to a contract term.

Can our own security team perform the penetration test?

Yes, in principle. The proposed rule defines a qualified person as someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for protecting ePHI, and it does not require an outside firm. The practical questions are whether your team has current offensive testing skills, whether it can test independently of the people who run the systems, and whether your documentation will convince an assessor or customer. Many organizations use internal staff for routine checks and bring in an outside tester for periodic deeper tests. Written rules of engagement and senior management approval are still good practice.

What does a HIPAA penetration test cost, and what drives the price?

No supplied figure gives a market price, so ask for a written, scoped quote rather than relying on a benchmark. The main cost drivers are the number and type of systems in scope (web applications, APIs, internal networks, cloud accounts, medical devices), the depth of testing (automated scanning versus manual attack paths), whether the test includes social engineering or wireless testing, how many retests you need after fixes, and whether a report formatted for your risk analysis is included. The only regulatory effort figure supplied comes from the proposed rule's impact analysis, where HHS estimated an average of 3 hours per entity with a range of 2 to 10 hours for penetration testing. That estimate covers a regulatory burden, not the cost of a real test of a complex environment.

What do we need from our team before a penetration test starts?

Several things need to be in place before testing begins. You need a current inventory of systems that create, receive, maintain or transmit ePHI, so the scope matches your risk analysis. You need a named owner who can approve the test in writing, define permitted techniques and accept production risk. You need backups verified, monitoring alerted for the test window, and a contact who can stop testing if something breaks. Engineers should prepare test accounts, network access paths and a plan for handling any ePHI the tester encounters. Your business associates may also need notice if their hosted systems are in scope, so confirm their contract terms first.

How DeployOpen prepares systems and evidence for HIPAA penetration testing

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, then runs security testing against them. We prepare the systems and the evidence a penetration test needs, while your organization owns its risk analysis, its security official role and its decision about who tests and what happens to the findings.

How we scope

Agree a written scope listing the ePHI systems, networks, applications and APIs to be tested before work starts.
Confirm rules of engagement, testing windows, and the written senior management approval that NIST SP 800-66 Rev. 2 suggests for penetration testing.
Map test scope to your risk analysis so the systems tested match where ePHI actually lives in your environment.

How we build

Configure the self-hosted platforms in your cloud accounts or data center with logging, access controls and encryption enabled before testing begins.
Set up test accounts, staging copies and monitoring so the test exercises realistic controls without exposing live patient records.
Record the baseline configuration and vulnerability scan results that the testers and your risk analysis will reference.

How we hand over

Deliver a written report of tested systems, methods, findings, severity ratings and reproduction steps for your security team.
Document remediation tracking entries that link each finding to the affected system, owner and risk management decision.
Provide the test evidence package, including scope, approvals and retest results, for your auditor or OCR inquiry file.

How we support

Support engagements through a retainer for retesting, upgrades and continuous testing when your risk analysis calls for more frequent tests.
Confirm with your compliance lead which testing cadence applies today and which the pending rule would require, since the proposal is not final.
Ask any provider, including us, to state in writing what it tests, what it does not test and who signs the final report.