HIPAA for MSPs and MSSPs: business associate duties

Is an MSP or MSSP a HIPAA business associate, and what does that mean for HIPAA Security Rule compliance?

A managed service provider or managed security service provider that creates, receives, maintains or transmits protected health information for a covered entity is a business associate and must comply with the Security Rule for electronic protected health information. The definition in 45 CFR 160.103 turns on the work performed, not the vendor's label, and 45 CFR 164.302 applies the Security Rule's standards and implementation specifications to business associates as well as covered entities. When a client asks whether you will sign a business associate agreement and meet the Security Rule, the honest answer is usually yes if your administrators can see, store, back up or move ePHI, even when you never open a patient file. Confirm the scope with the client in writing, including remote monitoring, backup, help desk access and any hosted application that holds records.

The organization owns its HIPAA controls. Your role as a provider is to prepare systems, configurations, logs and documentation so the covered entity or business associate can show how each safeguard works, and to tell the client which evidence you hold and which they must produce themselves. Only an independent assessor or auditor can issue a report about compliance, and no HIPAA certification exists. HHS states that no Security Rule standard requires certification and that it does not endorse private certifications. Be cautious with any vendor that offers a HIPAA certificate or seal, and ask what the client will rely on instead, usually a documented risk analysis and the evidence behind it.

Your direct exposure is the part many providers miss. Business associates are directly liable to the HHS Office for Civil Rights for Security Rule failures, so a client's contract does not transfer the risk away from you. Before you sign, check three things: whether your own risk analysis covers the systems you run for the client, whether your contract defines who reports security incidents and on what timeline, and whether any subcontractor that touches ePHI has its own written agreement with you. Ask the client which controls they expect you to operate and which they keep, and record that split in the agreement. Ambiguity on that point is where disputes and enforcement actions tend to start.

Which Security Rule duties fall directly on the provider

A managed IT or security service provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate, and the Security Rule duties below apply to it directly. The cards separate the duties OCR can enforce against the provider from the duties that flow through the contract, so you can check each one before you sign.

Direct liability for Security Rule failures

Under 45 CFR 164.302, business associates must comply with the Security Rule's standards and implementation specifications, and HHS holds them directly liable to OCR for failures. The covered entity cannot absorb that liability on your behalf. Ask yourself whether your own risk analysis, policies and safeguards cover the systems you run for clients, not only your internal network.

Reporting security incidents to the client

The contract must require you to report security incidents you become aware of to the covered entity, including breaches of unsecured PHI. For an MSP, awareness can start with a support ticket or a monitoring alert on a client's server, not only with a confirmed breach. Confirm how your monitoring escalates alerts to the account owner and who makes the call that a ticket is a reportable incident.

Cooperating with HHS investigations

HHS lists cooperation with its investigations among the HIPAA provisions business associates are directly liable for. For an MSP, that means producing logs, configurations, access records and risk documentation for systems it operates, on OCR's timeline. Before an investigation, confirm where those records live, who can export them, and how long your provider retains them.

Signing agreements with subcontractors

A business associate must enter a business associate agreement with each subcontractor that creates, receives, maintains or transmits PHI for it, and that agreement must flow the same Security Rule requirements down. If you use a cloud host, a backup vendor or a remote support firm for client environments, each one may be a subcontractor. Map every party that touches client ePHI and confirm each signed agreement before work starts.

Complying with Subpart C directly

The contract must require you to comply with Subpart C, which means the standards and implementation specifications apply to your own operations and to the services you deliver. Covered entities cannot transfer that duty to you by contract alone. Check whether your documented policies and risk analysis cover the work you perform for each client, including administrative access by your technicians.

What the business associate contract must contain under 164.314

This table compares the contract elements a covered entity and a managed IT or security provider must address under 164.314(a)(2) and 164.308(b), with what each term requires, who usually negotiates it, and what to check before signing. Read it as a pre-signature checklist: a managed IT provider that holds or can reach ePHI should confirm each row is covered in its agreement, not assume a generic BAA is enough.

Contract term	What it requires	Who negotiates it	What to check before signing
Compliance with Subpart C	The provider agrees to comply with the Security Rule standards and implementation specifications for the ePHI it creates, receives, maintains or transmits for the client.	Covered entity drafts; provider's legal team and security lead review	Confirm the clause names Subpart C and that the provider can point to its own risk analysis and written policies that meet it.
Scope of systems and ePHI	Defines which systems, backups, admin consoles and support tools the provider touches, since those define what the Security Rule covers in practice.	Usually the provider proposes; covered entity approves	List every managed environment, remote access path and backup location, and confirm none is left out of the agreement.
Flow-down to subcontractors	Requires the provider to bind its own subcontractors that handle ePHI to the same restrictions and safeguards through compliant written agreements.	Provider negotiates with its subcontractors; covered entity reviews the chain	Ask for the list of subcontractors with ePHI access, including cloud backup, monitoring and help desk vendors, and confirm each has a signed agreement.
Security incident reporting	Requires the provider to report security incidents it becomes aware of to the covered entity, including ransomware and unauthorized access to managed systems.	Covered entity sets the notice window; provider accepts or negotiates it	Check the notice period, who receives reports, and whether alerts from the provider's own monitoring count as awareness.
Breaches of unsecured PHI (164.410)	Requires notice to the covered entity of breaches of unsecured PHI, with the information the covered entity needs for its own notifications.	Covered entity typically drives; provider confirms its ability to supply details	Confirm the provider can identify affected records and systems quickly, and who pays for notifications if the breach stems from its environment.
Access to records and cooperation with HHS	Requires the provider to make its practices, books and records available to HHS for compliance review, and to support investigations.	Mostly standard language; provider's legal counsel reviews	Confirm the provider keeps logs and documentation long enough to answer an OCR request, consistent with the six-year documentation standard.
Return or destruction at termination	Sets what happens to ePHI when the engagement ends, including return, destruction or continued protection where return is infeasible.	Covered entity sets exit terms; provider proposes method	Ask how ePHI is removed from backups, remote tools and decommissioned devices, and who certifies the deletion.
Remedies for breach of contract	Gives the covered entity rights when the provider breaches the terms, including termination where the contract allows it.	Covered entity negotiates; provider limits liability	Read the termination right, indemnity and liability caps together, and confirm whether breach by a subcontractor triggers the same remedy.

How HICP guidance hands small practices to their MSP

HICP's 2023 Edition is published by HHS's 405(d) program and is organized into technical volumes by organization size. Technical Volume 1 addresses small healthcare organizations, and the guidance says that a small organization with a managed service provider can give the provider the main HICP document and Volume 1 as the starting point for a shared security plan. The practices in these documents are recommendations, not a list of mandatory controls. A small practice should tailor them after it has completed a risk assessment that reflects its own systems and where its ePHI lives.

Starting document: Hand the MSP the main HICP document and Volume 1, then agree which practices the MSP will implement, monitor or report on.
Tailoring step: Use the practice's risk analysis to decide which recommendations apply, which need adjustment and which do not fit the environment.
Shared responsibilities: Write down, in the service agreement, who runs backups, patching, endpoint protection, logging and access reviews.
Practice-owned decisions: Staff training, workforce access decisions, patient communication and breach judgments stay with the practice even when the MSP operates the tools.
Evidence trail: Ask the MSP for dated records of each practice it implements, so the practice can show what was done and when.

Before signing, confirm with the MSP which HICP practices it has agreed to cover and which it has excluded, and ask who maintains the risk analysis after onboarding.

What the Comstar case shows about vendor-side ransomware

The Comstar resolution agreement is the clearest recent example of how OCR treats a vendor that holds ePHI for covered entities and suffers a ransomware attack. Comstar, a business associate providing billing, collection and ePCR hosting for ambulance services, was hit in March 2022, affecting 585,621 individuals. It detected the attack a week later only because its IT vendor received support tickets, which means the first signal came from outside its own monitoring. OCR's 2025 resolution agreement required a $75,000 payment and cited a failure to conduct an accurate and thorough risk analysis. For an MSP, the lesson is that a managed service can be the place where an incident first becomes visible, and the provider needs to know what its own telemetry would have shown.

Three decisions follow for a provider reviewing its own posture. First, confirm which logs, alerts and endpoint signals your service actually collects from client environments, who watches them, and whether unusual activity such as mass file changes or new administrative accounts reaches a person within a set window. Second, make sure your risk analysis covers the systems you run for clients, including remote management tools, backup consoles and privileged credentials, and that it is updated when the environment changes. Third, check how your contracts set the clock for reporting security incidents to the covered entity under 45 CFR 164.314(a)(2)(i)(C), and confirm that your escalation runbook can meet that clock in practice, not only on paper.

Treat Comstar as an enforcement example, not a model of required controls. The Security Rule does not prescribe a monitoring product or a detection time, and OCR's findings describe what went wrong in one case. Ask your legal and compliance team to confirm the exact notification obligations in each client agreement, and ask your security team to test whether a ransomware scenario would be detected inside your own service boundary. The HHS OCR Comstar resolution agreement is the primary text to read before briefing leadership.

How an MSP gets ready to show HIPAA Security Rule compliance

This sequence establishes which clients make the provider a business associate, documents a risk analysis of the systems it manages, maps where ePHI and privileged access sit, aligns policies to Subpart C, puts subcontractor agreements in place, and tests incident reporting. Each step ends with a written output the provider can show a covered entity or an assessor.

Confirm business associate status for each client
Review each client relationship against the regulatory definition of a business associate, which covers persons who create, receive, maintain or transmit PHI for a covered entity, including through services such as IT management that involve PHI. Record the functions performed, the systems touched and whether the provider has any access to ePHI, even incidental access through administrator rights. The output is a client register that states the status for each relationship and the reason for it, reviewed by someone who understands both the contract and the technical access. Confirm the conclusion with legal counsel where the answer is unclear.
Execute business associate agreements with each covered entity
Where the provider is a business associate, put in place a written contract that requires compliance with Subpart C, flows the same requirements to subcontractors, and requires reporting of security incidents, including breaches of unsecured PHI, to the covered entity. Check the agreement against the contract elements in the organizational requirements standard before signing. The output is a signed agreement for each covered entity client, filed with its effective date and the name of the responsible contact, so the provider can produce it on request.
Run and document a risk analysis of managed systems
Perform an accurate and thorough risk analysis covering every system the provider administers, hosts or can reach on a client's behalf, including remote management tools, backup platforms and ticketing systems that hold ePHI or credentials. Identify threats and vulnerabilities, rate the likelihood and impact of each, and record the controls in place. Enforcement actions against vendors have cited missing or inaccurate risk analyses, so the output is a dated written analysis with a risk management plan that assigns owners and tracks open items. Confirm the scope with each client in writing.
Map ePHI access paths and privileged accounts
Trace how ePHI moves through the environments the provider manages, including where it is stored, backed up, transmitted and viewed, and list every account that can reach it. Pay particular attention to administrator and service accounts, shared credentials, vendor remote access and any tool with broad read rights across client tenants. The output is an access inventory per client showing each account, its role, its authentication method and its review date, along with a diagram of data flows. Ask each client to confirm the inventory matches the systems it expects the provider to manage.
Align policies and procedures to the Security Rule
Write or update policies and procedures so that each safeguard the provider is responsible for has a documented owner and a repeatable process, covering workforce access, training, audit log review, backup and contingency planning, and device and media handling. Map each policy to the Subpart C standards it supports so that an assessor can follow the trail. The output is an approved policy set with version history, retention records and evidence that staff were trained on the policies they apply to. Where a client's contract assigns a duty to the provider, the policy must say so explicitly.
Sign subcontractor agreements with downstream vendors
Identify every vendor that creates, receives, maintains or transmits PHI on the provider's behalf, such as offsite backup, cloud hosting, help desk outsourcing or managed detection services, and obtain written assurances from each one. Those agreements must require the subcontractor to protect ePHI at the same level the provider has promised the covered entity. The output is a subcontractor register listing each vendor, the services it provides, the date its agreement was signed and the date of its last review, with copies of the agreements held on file.
Set and test incident reporting runbooks
Write runbooks that describe how the provider detects, contains, investigates and reports a security incident affecting client systems, including the steps to notify each covered entity under the business associate agreement and the information the notice must contain. Assign a named decision maker and a backup for each client. Test the runbook with a tabletop exercise that includes the provider's own support desk, since a ransomware event at one client may first surface as support tickets. The output is an approved, tested runbook per client and a record of the exercise with the actions it produced.

Where MSP HIPAA projects stall or fail

Most managed IT and security service provider engagements that go wrong under HIPAA do not fail on technology. They stall on paperwork, unclear ownership and records that nobody kept. The six points below are where covered entities and their vendors most often find gaps, and each one names the check that prevents it.

Treating a vendor certificate as proof

A certificate or badge from a private organization does not show HIPAA compliance. HHS states that no Security Rule standard requires certification and that it does not endorse private certifications, and such certificates do not stop OCR from later finding a violation. Ask the MSP for its own written risk analysis, its policies, and evidence that its safeguards operate on your systems, then judge those documents instead of the logo.

Missing or generic business associate agreements

A business associate agreement that only repeats a template often omits what the Security Rule requires: compliance with Subpart C, flow-down to subcontractors, and reporting of security incidents to the covered entity. Check that the agreement names the systems and data in scope, sets incident reporting duties, and covers any subcontractor the MSP uses for backup, hosting or remote support.

No documented risk analysis for managed systems

Many MSPs assess their own company but not the client environments they run, so ePHI on file servers, backups and remote access tools is never mapped or rated. The Comstar resolution agreement cited an inaccurate and incomplete risk analysis as a central failure. Require a risk analysis that covers every system the MSP administers for you, with ePHI locations, threats and a risk management plan.

Unclear split of responsibilities

Under a managed model, patching, log review, access reviews and backup testing can each be assumed by both parties, and then performed by neither. Write a responsibility matrix that assigns each Security Rule safeguard to the covered entity, the MSP or both, and name the person who approves changes to access. Review it when systems, staff or subcontractors change.

Slow incident escalation

A ransomware event can sit in a vendor's queue for days before the covered entity hears about it. The Comstar case involved detection only after the IT vendor received support tickets a week later. Define in the contract who detects, who triages, how fast the client is told, and who makes the call on breach assessment, then test that path with a tabletop exercise before an incident occurs.

No evidence retention

Logs, access review records, training attendance and backup restore tests often live in the MSP's own tools and disappear when the contract ends or a ticketing system rolls over. The Security Rule's documentation standard calls for records to be kept and made available, and the proposed rule would add more verification. Agree in writing who keeps which records, the retention period, and how the covered entity receives copies at exit.

Questions MSPs ask about HIPAA business associate duties

Does an MSP need to sign a business associate agreement?

Yes, if the MSP creates, receives, maintains or transmits PHI for a covered entity while doing its managed services. The regulatory definition of a business associate covers persons who handle PHI for a covered entity outside their own workforce, and managed IT and security work on systems holding ePHI typically fits that definition. Whether a specific engagement qualifies depends on access: a provider that administers servers, backups or email containing ePHI is usually in scope, while one with no access to ePHI may not be. The covered entity must have a written contract that requires the provider to comply with Subpart C, flows the same duties to its own subcontractors, and requires reporting of security incidents. Ask the provider to confirm in writing what data it can reach and how it will be handled.

Is an MSP directly liable under the HIPAA Security Rule?

Yes. Business associates must comply with the Security Rule's standards and implementation specifications, and HHS states they are directly liable to the Office for Civil Rights for Security Rule failures. That liability does not depend on the contract alone. A covered entity can still face its own exposure if it fails to obtain satisfactory assurances, and a provider can face enforcement even when the covered entity was careless. The practical consequence is that an MSP needs its own documented risk analysis, policies, workforce training and incident response for the environments it operates, not only a copy of the client's program.

Does a HIPAA certification exist for MSPs?

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private organizations' certifications. HHS also notes that such certifications do not prevent a later finding of violation. Vendors may offer certificates or badges, and a covered entity may still ask for them, but they prove only what their scope and assessor covered. Ask for the scope statement, the assessor's name and the date of the assessment, and check those against the systems the provider actually runs for you.

What would the proposed Security Rule change mean for MSPs?

HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rulemaking under Long-Term Actions with final action projected for July 2027. The proposal would make the requirements more prescriptive, so a business associate should expect more specific expectations for asset inventories, network mapping, encryption, multi-factor authentication and verification of safeguards. Until a final rule issues, the current regulation governs. Track the Federal Register proposal and ask the covered entity how it plans to respond to any final text.

Can an MSP handle HIPAA security work without outside help?

An MSP can perform the work itself if it has the staff, documentation and independent review to meet the Security Rule for its own environment and for the systems it operates for clients. Doing so usually requires a designated security official, a current risk analysis, written policies, workforce training, audit log review and tested incident response. Many smaller providers bring in consultants or an implementation partner to prepare systems, controls and evidence, but the provider still owns its controls. An independent assessor, not a consultant, provides any third-party opinion. Ask whoever you engage to state clearly which parts they perform and which the provider must own.

What effort should a covered entity expect from its MSP?

Expect the provider to supply documented evidence, not just assurances. The covered entity should ask for the signed business associate agreement, a list of subcontractors that touch ePHI with their own agreements, the provider's most recent risk analysis summary, incident response and breach reporting commitments, and evidence of backups and access reviews for the systems it manages. Effort recurs: reviews, access recertification, log checks and annual contract updates all take time on both sides. Cost depends on the number of systems, the provider's scope and how much assessment support the covered entity requires. Request a written scope and deliverables before engagement, and confirm reporting timelines for security incidents in the contract.

How to choose an assessor or consultant for MSP HIPAA work

A managed IT or security provider that also runs the HIPAA work it is asked to assess has a conflict of interest. These four checks help you separate the firm that prepares systems and evidence from the independent party that tests them, and they should be settled in writing before any scope is signed.

Independence from the implementation work

Ask whether the firm that configures, hardens or operates your systems is also the firm that assesses them. Only an independent assessor can issue a report or opinion on Security Rule compliance. An implementation partner can prepare systems, controls and evidence, but it cannot certify its own work. Ask who signs the final report, who pays them, and whether they have any role in your managed services contract. Illustrative: an MSP that wrote the backup configuration should not be the party testing whether that configuration meets contingency planning.

Healthcare and managed-service experience

Check whether the assessor has worked with covered entities and business associates, and specifically with managed service providers that hold ePHI for other organizations. Ask how they treat the business associate role, subcontractors and the contract terms in 45 CFR 164.314. Ask for examples of how they scoped a risk analysis for a provider that manages many client environments. Confirm they can explain the difference between a Security Rule assessment and a general IT audit, and that they use the HHS and NIST SP 800-66 Rev. 2 guidance as reference points.

Clarity on evidence and certification

Require a written statement of what the firm delivers. Typical deliverables include a gap analysis, an updated risk analysis, policies and procedures, configuration evidence and remediation tracking. Confirm which items the firm will certify, if any, and which are only prepared for your review. HIPAA has no official certification, so any firm offering a HIPAA certificate should be asked to explain what the document means and whether HHS recognizes it. Ask for a sample deliverable before signing.

Questions to ask before signing scope

Before a written scope is agreed, ask these questions: Who owns the security official role after the engagement? Which of your client environments are in scope? What happens if the assessment finds a gap that the firm also fixes? How are subcontractors used, and do they sign business associate agreements? What are the deliverables, dates and acceptance criteria? Get the answers in the statement of work. Fixed-scope agreements with named deliverables make it easier to compare quotes and to show OCR later what was done and by whom.

Where an implementation partner fits in an MSP's HIPAA program

An implementation partner can help a managed IT or security service provider (MSP or MSSP) prepare the systems and evidence behind its HIPAA program, but it cannot take over the provider's obligations. The provider owns its controls, its risk analysis and its contract duties to covered entities. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including its cloud accounts, data centers or air-gapped networks. For an MSP, that work might cover logging and monitoring stacks, backup systems, identity services or ticketing and documentation tools that hold or touch ePHI for its clients. DeployOpen can also prepare configuration records, system inventories and evidence packages that an independent assessor may later review. It does not issue audit reports, attestations or certifications. Only an independent auditor or assessor issues those, and HHS does not recognize private certifications for HIPAA, so any vendor claiming a HIPAA certificate should be questioned.

Engagements are fixed-scope. Before work starts, the provider and DeployOpen should agree in writing on which client environments, platforms and Security Rule safeguards are in scope, what each deliverable is, who receives it and what acceptance looks like. A useful scope statement names the systems and the business associate agreement or subcontractor terms it supports, so the provider can show that its own contracts under 45 CFR 164.314 match what the technology actually does. Ask for the statement of work to separate one-time build work (installation, hardening, initial documentation) from recurring work (monitoring, upgrades, testing), because retainers for ongoing support are priced differently from fixed-scope projects. DeployOpen does not publish a price list, so the quote should follow directly from that written scope.

Before engaging anyone, the MSP should confirm three things: which Security Rule duties it carries as a business associate, which of those duties its contracts pass down to its own subcontractors, and who in its organization will sign off on the evidence. Its risk analysis under 45 CFR 164.308(a)(1) must still reflect the partner's work, and its incident reporting duties to clients stay with the MSP. A partner can shorten the path to evidence, but the provider must still be able to explain its safeguards to a covered entity and to OCR. Also ask the partner which outputs are designed for an assessor and which are internal, so the provider does not confuse a readiness package with an assessment result.

HIPAA for managed IT and security service providers