How to compare healthcare penetration testing proposals

Two proposals can both promise a healthcare penetration test and cover very different work. One may focus on systems reachable from the internet. Another may include internal access or hands-on testing of a patient portal. Comparing prices before scope leaves the main question open: what will each provider test?

Ask each provider to describe the work against the same brief. Answers to the same brief show what each test covers and what support follows the report.

Start with the question your team needs answered

An asset list tells a tester where to work. An objective explains what the test should establish.

For example, your team might want to understand whether a compromised staff account could reach sensitive systems. That is a different assignment from testing whether an outside attacker could get through an internet-facing application. Describe the concern before requesting a price, then ask the provider to explain the proposed approach.

NIST describes penetration testing as assessors attempting to circumvent or defeat a system’s security features, typically under specific constraints. Keep those constraints visible when comparing proposals. An external network test does not automatically include internal systems, application workflows or the software interfaces that connect services.

Source: NIST definition of penetration testing.

Put the coverage side by side

Use the same questions for each proposal:

• Which systems, applications and locations are included, and which are excluded?
• What access will testers receive, and what will they investigate with that access?
• What hands-on validation is included beyond automated scanning?
• Which deliverables and follow-up activities are included in the quoted price?

Ask the provider to identify assumptions that could change the work or cost. If the proposal depends on test accounts, a working test environment or permission from a third-party platform, establish who supplies each one and when.

Suppose both proposals mention a patient portal. One covers its public sign-in page; the other also examines what authorized users can access after signing in. Those are different scopes. The useful comparison is whether each addresses your testing objective, with the difference documented before you approve the engagement.

Agree on clinical boundaries before testing

Healthcare teams have to consider availability alongside confidentiality. A system supporting patient care may need different handling from an isolated test application.

Bring the people responsible for clinical systems into the scoping conversation. Identify sensitive systems, acceptable testing windows and activities that require a separate decision. Ask who can pause the test, how that person will be reached and what happens if testing affects normal operations.

NIST calls the guidelines and constraints established before testing the rules of engagement. Ask to see how the provider will document yours, including how changes to the agreed scope are approved.

Also settle how sensitive evidence will be collected, shared, retained and removed. If testers could encounter protected health information, have your privacy and legal teams review the contract terms for that access before testing starts. Send technical scoping information through the agreed secure channel.

Source: NIST definition of rules of engagement.

Check whether the report will support decisions

Request a sample report with customer and system details removed. Read it from two perspectives: could leadership understand the significance, and could the technical owner act on the finding?

OWASP’s Web Security Testing Guide recommends reporting that serves both audiences, with the agreed scope, limitations and findings clearly explained. OWASP presents that structure as a suggested approach, not a required format.

Look for a clear connection between the affected system, the evidence, the potential impact and the recommended correction. Ask how the provider will distinguish a validated finding from an issue it could not fully investigate. A limitation should remain visible in the report so it does not become an assumption that an area was tested and found secure.

Source: OWASP Web Security Testing Guide, Reporting.

Price the follow-up as well as the test

Agree on what happens when an important finding appears during testing. Who receives it, how quickly will it be raised, and does further validation require approval?

Then clarify the work after delivery. A findings meeting, help interpreting recommendations and a remediation retest are separate activities. Ask which are included, the time available to request them and how the provider will record the result. Keep any additional charges visible in the comparison.

Your team will still need to assign corrective work and confirm what changed. Our guide to turning healthcare security findings into a remediation plan explains that next step.

Keep the engagement connected to your broader risk work

A penetration test provides evidence about the systems and scenarios examined. Your Security Risk Analysis considers risks to electronic protected health information across the organization, including administrative, physical and technical safeguards.

HHS’s current Security Rule summary describes risk analysis and periodic evaluation requirements. The current rule does not name penetration testing as a universal requirement. HHS has proposed requiring it at least once every 12 months, and that proposal is not final. Plan the engagement around your risk and testing objective.

Sources: HHS Security Rule summary and proposed-rule fact sheet.

Medcurity offers external, internal and web application penetration testing for healthcare organizations and the business associates that support them. Each engagement starts with a defined objective, authorized scope and agreed testing boundaries, and the engagement agreement documents the final coverage. See how Medcurity plans healthcare penetration testing.

Bring your testing objective to a conversation with our team. Request a scoped penetration test, and we’ll discuss the scope and next steps before testing begins.