Acquiring a clinic does not just mean acquiring its patients, physicians, or revenue stream. It also means acquiring every cybersecurity vulnerability, from exposed access points to poorly governed third-party API integration, that is sitting behind that clinic’s digital operations.
The moment those vulnerabilities are connected to your system, you open yourself to a plethora of cyberattacks.
Yet, the due diligence checklist is more concerned with financial statements, payer contracts, and pending litigation.
You Inherit More Than the Business
In 2016, Marriott acquired Starwood Hotels. What the financial due diligence failed to see was that Starwood’s network had been compromised since 2014.
The breach was not discovered until 2018. And, by then, over 500 million guest records had been exposed.
A 2024 report by Forescout found that over half of the companies that have gone through M&A had encountered critical cybersecurity risks in target companies, which put deals in jeopardy.
In healthcare, web applications often touch ePHI, billing data, scheduling workflows, and vendor-connected systems. It becomes an M&A issue and soon a HIPAA compliance issue.
If you are buying a clinic and you are not pentesting its internet-facing and business-critical applications before integration, you are accepting the hidden risks as your own.
Why Web Applications Are at Risk in Clinic Acquisitions
A clinic’s IT environment typically includes infrastructure that is visible. This includes firewalls, endpoint protection, and network segmentation, along with patch histories, all of which a security reviewer can evaluate.
Web applications are different. They expose functionality and data through a user interface (UI) or an API, even interacting with patients through the clinic’s website.
They are built on top of frameworks, libraries, and third-party components that may not have been updated in years. And they routinely contain vulnerabilities that go unchecked because the flaw is not in a known software component.
The typical web application attack surface in a small to mid-size clinic acquisition includes:
- Patient portal: This includes authentication, role-based access controls, session management, and how patient records are retrieved and displayed.
- Scheduling and intake forms: These are generally input handling, data storage, and whether form submissions are validated server-side.
- Billing and payment applications: Any portal that connects to a clearinghouse.
- EHR integration middleware: Interfaces based on HL7 or FHIR, often utilizing platforms like Mirth Connect for data flow between systems.
- Telehealth platforms: These deal with the authentication flows, session isolation, and how video or messaging data is handled.
- Third-party vendor integrations: These are any external services that connect via an API and interact with protected health information (PHI).
Each of these systems processes ePHI and can be vulnerable to application-layer attacks unrelated to network perimeter security. Many clinics, especially those that haven’t undergone web application penetration testing, may unknowingly harbor these vulnerabilities for years.
How the Risks Begin at Integration and Continue into Post-Acquisition
Healthcare M&A integration connects two different IT environments of two different companies.
For web apps, this means the acquired clinic’s systems get linked to the acquirer’s network, identity infrastructure, and often its EHR. Not only do the access controls get reconfigured in the process, but the User accounts get migrated as well, and APIs get opened to pass data between legacy systems and new ones.
This is the highest-risk window in the entire transaction lifecycle. And one of the most common timeframes for cyberattacks.
As firewalls are temporarily loosened to facilitate connectivity, the IT teams from both organizations work under deadline pressure, raising the chances of them missing a red flag.
Attackers know this and use the integration phase to make their move. It is when threat actors exploit misconfigurations introduced during migration or a business logic flaw that was dormant in an isolated system.
After the merger, the acquiring organization becomes the responsible covered entity for the clinic’s PHI from the moment the deal closes under HIPAA.
If a breach is later discovered to have originated in the acquired clinic’s patient portal, the acquirer faces OCR’s scrutiny of whether it conducted adequate risk analysis under 45 CFR 164.308(a)(1), and whether it had appropriate safeguards in place.
“We inherited it” is not a defense OCR accepts as it looks for evidence of risk analysis and risk management. This is where pre-integration web application pentesting comes in.
A web application pentest done before integration closes any attack window. It tells the acquiring organization exactly what vulnerabilities exist in each application before those applications are connected to anything critical.
Addressing application security as part of M&A healthcare due diligence should not be an afterthought anymore. HHS’s proposed updates to the HIPAA Security Rule, published in December 2024, include proposals for mandatory penetration testing every 12 months and mandatory vulnerability scanning every 6 months.
Organizations acquiring clinics should get ahead of the curve. As it is, without a pre-integration security test they would be starting from a compliance deficit on day one.
What a Pre-Integration Web Application Pentest Should Cover
A web application pentest scoped for M&A in healthcare should not be treated as a generic checklist exercise. It needs to reflect the specific applications being acquired and the specific risks they carry.
At a minimum, the scope should include:
- Patient Portal: Patient portals handle ePHI directly and should be tested for login vulnerability by credential stuffing, session management through session tokens, role-based access controls, etc.
- Patient-Facing Scheduling, Intake, and Billing Applications: These applications often receive less security attention than the patient portal because they are perceived to pose minimal risk.
Testing here focuses on business logic, input handling, and data exposure in API responses.
- EHR-Facing APIs and Integration Middleware: HL7 and FHIR-based APIs sit between the clinic’s front-end systems and its EHR. Testing begins with API authentication and authorization and assessment of middleware platforms for known and zero-day vulnerabilities.
- Telehealth Platforms: This includes testing the veracity of session isolation and authentication flows such as whether chat logs are encrypted and whether the platform’s API connections to EHR are properly authenticated.
- Third-Party Vendor Integrations: In a typical clinic, every external service with an API connection to the clinic’s systems is a potential attack vector. EHR vendors, billing services, patient communication platforms, and even analytics tools fall under this category.
Testing should be done to check whether these third-party vendor integrations create an attack surface by external connection.
- Admin Interfaces: Most people think admin interfaces in clinic web applications are accessible only to internal staff. And that thinking is why many internet-facing applications do not properly separate admin panels from the patient-facing surfaces.
Testing here assesses whether admin functionality enforces the same authorization controls as patient-facing functionality.
The resulting report should map findings to HIPAA Security Rule requirements, document proof-of-concept evidence for every confirmed vulnerability, and prioritize findings by the risk they represent to ePHI, not just by generic CVSS severity score.
This report then serves three functions: it informs remediation before integration, it provides compliance documentation for HIPAA risk analysis, and it creates a baseline security posture for the acquired clinic that the acquiring organization can reference going forward.
Addressing these healthcare integration issues before the two environments are connected is substantially easier and less expensive than remediating them after.
How Does a Web Application Pentest Works: Four Steps
Understanding how a web application penetration test operates is essential for setting realistic expectations in an M&A scenario.
The process generally unfolds in four main steps.
- Information Gathering: The first step by a tester is to map the acquired clinic’s application environment before attempting any exploitation.
This involves both passive reconnaissance (collecting publicly available information about the target) and active reconnaissance (fingerprinting the application’s technology stack, scanning open ports, identifying subdomains, and examining source code and error pages for information about the server environment).
Everything discovered is documented to form the foundation for what gets tested next.
- Research and Exploitation: Using what information was gathered, the tester identifies vulnerabilities and attempts to exploit them.
Tools like Burp Suite are used to intercept and manipulate traffic, SQLMap for injection testing, and Hydra or John Ripper for credential attacks.
Critically, this phase also involves identifying third-party software components embedded in the application and testing those for known vulnerabilities.
- Reporting and Recommendations: Every successful exploit is documented with enough detail for both technical staff and leadership to understand the finding and its business impact.
The results should be categorized based on severity. It will help the client company focus its efforts on fixing the most critical parts of its system.
- Remediation and Ongoing Support: In this final step, critical and high vulnerabilities are addressed first. Prioritization plays a key role as it helps in allocating resources accordingly.
Certain vulnerabilities that have been identified might require prior access to the internal system, while others pose a risk of remote code execution. These should be prioritized appropriately to account for their likelihood and potential impact.
Many firms provide ongoing support in the form of a retest as part of the engagement. It is done to verify that fixes hold before the acquired clinic’s systems are connected to the acquiring organization’s network.
How KLEAP can help
KLEAP’s web application penetration tests are conducted manually. No automated scanner substitutes for the testing that matters.
Every engagement is scoped to the specific applications being tested, led by a dedicated security expert who understands how healthcare applications handle PHI and what HIPAA’s risk analysis requirements demand in terms of evidence.
For M&A engagements, we scope the web application pentest to the acquired clinic’s full application surface, deliver findings mapped to HIPAA Security Rule controls, and provide a remediation roadmap that gives the acquiring organization a clear picture of what needs to be fixed before integration
However, KLEAP’s work doesn’t end there. We also advise what to monitor after.
The result is healthcare due diligence that holds up to OCR scrutiny, not just the acquisition deal.
If you are in the process of acquiring a clinic, or if you haven’t thought of web application pentesting as part of your due diligence process yet, KLEAP can provide you with a detailed scope in just one call.
