How to Choose a HIPAA-Aware MSP for Healthcare Practices

Healthcare Compliance

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

A healthcare practice should not choose an MSP because it uses the phrase “HIPAA compliant.” Choose one whose contract, access model, evidence, and incident procedures fit the work it will actually perform. HIPAA responsibility follows the relationship and the handling of protected health information, not a marketing label. The goal of due diligence is to establish who can reach electronic protected health information (ePHI), why that access is needed, how it is controlled, and what each party must do when something goes wrong.

Start with the legal and operational boundary

An MSP may be a business associate when its services involve creating, receiving, maintaining, or transmitting PHI for a covered entity. HHS explains that the written arrangement must define permitted and required uses, safeguards, reporting, and other obligations; business associates are also directly liable for certain HIPAA provisions. Review the HHS business-associate guidance with counsel rather than treating the provider’s proposal as a compliance opinion.

A business associate agreement (BAA) is an important boundary, not a certificate that every system, workflow, or configuration is safe. HHS’s sample BAA provisions cover permitted uses and disclosures, safeguards, incident and breach reporting, subcontractors, access to records, and return or destruction of PHI at termination. They are sample provisions, not a substitute for a contract tailored to the practice, the service scope, and applicable state law.

Map the service before evaluating the provider

Create a one-page service and data-flow map. List the systems the MSP will administer, the types of data involved, where those systems are hosted, the support methods used, and every vendor the MSP may bring into the path. Include EHR access, imaging, billing, e-prescribing, patient communications, backups, remote support, identity systems, endpoints, network equipment, and log platforms. Mark whether each service can create, receive, maintain, transmit, or merely display ePHI.

Do not assume encryption or “no-view” support removes a vendor from the chain. HHS’s cloud-computing guidance says a cloud service provider that maintains ePHI can be a business associate even when it lacks the decryption key. Ask the MSP to identify relevant subcontractors, the functions they perform, the countries or regions from which support may occur, and how equivalent restrictions flow down through agreements.

Evaluate five areas with evidence, not assurances

1. Privileged access

Ask for a diagram or written procedure showing how technicians receive administrative access. Look for named accounts, least privilege, multifactor authentication, approval for high-impact changes, time-bounded or just-in-time access where practical, session or change logging, prompt offboarding, and a controlled emergency-access method. Determine whether the provider can administer identity, backups, and security tooling from the same account; excessive concentration can turn one compromised credential into several failures.

2. Safeguard operation and risk evidence

Ask what evidence the provider will supply for the controls in scope: asset coverage, patch exceptions, endpoint protection status, backup jobs, restore exercises, access reviews, vulnerability remediation, and security-event handling. A third-party assessment or certification may inform due diligence, but it does not prove that your specific tenant, endpoints, or workflows are configured correctly. HHS notes that HIPAA does not expressly require a cloud provider to give customers security documentation or audit access, while customers may negotiate additional assurances based on their risk analysis. That makes evidence rights a contract question, not something to assume. See the HHS audit-documentation FAQ.

3. Incident and breach responsibilities

Separate a security incident from a breach determination, and write down who performs each action. The MSP should have a path to preserve logs, contain affected access, notify the practice, support fact-finding, and document its work. HHS states that a business-associate cloud provider must report security incidents involving ePHI, while the BAA can define detail, format, and frequency; breach reporting has separate regulatory requirements. Review the HHS security-incident FAQ and the HHS Breach Notification Rule summary. Contract notice targets should leave the practice enough time to make its own legal, clinical, insurance, and communications decisions.

4. Clinical continuity

Technical recovery targets mean little if the patient workflow still cannot operate. Ask the MSP to trace a realistic outage from detection through clinical escalation, downtime procedures, restoration, validation, and return to normal work. Identify dependencies the MSP does not control, such as an EHR vendor, internet carrier, clearinghouse, or medical-device vendor. Require a named internal owner for clinical decisions; the MSP should not be positioned as the decision-maker for patient-care priorities.

5. Contract control and exit

Reconcile the BAA, master services agreement, statement of work, service levels, security exhibit, and acceptable-use terms. Confirm which document controls if language conflicts. Define included systems, hours, escalation, exclusions, project work, evidence delivery, subcontractor changes, cyber-insurance cooperation, data ownership, credential ownership, log access, termination assistance, and return or destruction of PHI. Avoid vague statements such as “industry-standard security” when a concrete procedure, owner, or evidence item can be named.

Copyable healthcare MSP due-diligence record

Service: [system or support function]

PHI interaction: [creates / receives / maintains / transmits / displays / none confirmed]

BAA party and subcontractors: [names and agreement path]

Privileged access: [account type, MFA, approval, logging, emergency path]

Evidence promised: [artifact, owner, delivery cadence, retention]

Incident duty: [who detects, contains, preserves evidence, and notifies whom]

Continuity dependency: [clinical owner, vendor dependency, downtime method, validation step]

Exit control: [credential transfer, data export, PHI return/destruction, transition support]

Open decision: [risk, accountable person, due date, accepted evidence]

Complete one record for every material service, not one for the entire proposal. Score only after evidence is attached. A useful conclusion is “accepted,” “accepted with a dated corrective action,” or “not accepted,” with the practice’s accountable person named. Have privacy, legal, insurance, and clinical stakeholders review the areas within their responsibility.

Warning signs that should stop the selection process

The provider promises that signing its BAA makes the practice compliant.
It will not identify subcontractors that may handle ePHI or explain how restrictions flow down.
Technicians share administrator credentials or privileged actions cannot be attributed to individuals.
Incident language says only that the provider will notify “as appropriate,” with no owner or usable escalation path.
The proposal promises monitoring or backups but does not define coverage, exceptions, evidence, or restore validation.
The practice cannot obtain its credentials, logs, documentation, and data in a usable form during transition.

Related implementation guides

Use the selection record alongside the practical service expectations in Managed IT for Medical Practices, connect vendor access to the ownership model in the Clinic Network Data Governance Model, and track regulatory developments separately with the HIPAA Updates Guide.

Primary sources

This guide supports vendor due diligence; it is not legal advice or a determination that any organization or provider complies with HIPAA.