Who Needs to Sign Your BAA? A Practical Guide for MSPs | The Digital Strategikon

This article is the companion piece to Vendor Risk Management for Small Healthcare Practices. That guide walked through how a healthcare practice should identify and manage the vendors that touch its patient data. This one goes one level deeper — into the compliance chain that flows from those relationships and what it means for the MSPs, IT providers, and technology vendors sitting in the middle of it. It is part of our broader HIPAA Security Rule resource hub.

A Quick Recap: Where the Chain Begins

In our vendor risk management guide, we described the “compliance risk” category this way: under HIPAA, a vendor that handles PHI on your behalf is a business associate, and you are required to have a Business Associate Agreement (BAA) in place. If you don’t — or if the vendor subcontracts to others who never signed one — the gap is a compliance failure that lands on you.

That’s true from the healthcare practice’s perspective. But the same chain extends further. The MSP that signed a BAA with the practice has its own vendors — its RMM platform, security scanner, PSA, documentation tool, backup provider, email system. Each of those, depending on how they’re deployed in a healthcare environment, is a potential downstream subcontractor Business Associate. And the obligation to execute a written agreement flows down the chain with each link.

This is the compliance gap that rarely gets discussed from the MSP side, and it is an active area of federal enforcement.

The Position Most MSPs Don’t Realize They’re In

When an MSP contracts to deliver IT or cybersecurity services to a healthcare practice, hospital, or health plan, it becomes a Business Associate (BA) under HIPAA. That status is not optional — it is triggered automatically by the nature of the work, not by any agreement the MSP signs or declines to sign. Every vendor the MSP then uses to service that healthcare client potentially becomes a downstream subcontractor Business Associate, and the MSP is directly responsible for ensuring each of those subcontractors has a compliant BAA in place before ePHI flows to them.

The federal regulation is unambiguous. 45 CFR § 164.308(b)(2) states that a business associate may permit a subcontractor to create, receive, maintain, or transmit ePHI on its behalf only if it obtains satisfactory assurances that the subcontractor will appropriately safeguard the information. 45 CFR § 164.308(b)(3) further requires those assurances be documented through a written contract — the downstream BAA. This is not a best practice or a risk preference. It is a mandatory federal requirement, and it applies to the MSP regardless of whether the MSP’s own vendors have ever heard of it.

The BAA obligation is triggered by the data flow, not by whether your vendor has a process for it. Their lack of a process is your liability, not their excuse.

The Four-Word Trigger: Create, Receive, Maintain, Transmit

The BAA obligation activates the moment a vendor touches ePHI in any of four ways: creating, receiving, maintaining, or transmitting it. This is the statutory language from 45 CFR § 160.103, and it is intentionally broad. The threshold question is not “does this vendor intentionally handle PHI?” It is “could this vendor’s system create, receive, maintain, or transmit ePHI in the course of providing its service?” If the answer is yes, a BAA is required.

In practice for an MSP:

An RMM agent deployed on a workstation that processes billing records maintains ePHI, even if the agent never opens a file.
A security scanner running against a server hosting an EHR database transmits and receives diagnostic ePHI in the form of vulnerability telemetry.
A PSA platform that stores a support ticket referencing a patient complaint or a clinic EHR admin request receives ePHI.
A documentation platform hosting a network diagram of a HIPAA-covered environment maintains ePHI-adjacent data with PHI exposure potential.

The same logic from the inventory step of our vendor risk guide applies here: you cannot manage risk you cannot see, and the first step is listing every tool that touches a healthcare client environment and asking whether it could encounter ePHI. If you have never mapped where ePHI actually lives in your client environments, start with asset inventories and network maps.

The Conduit Exception Is Narrower Than You Think

Many technology vendors — particularly those without healthcare-sector experience — will attempt to invoke the “conduit exception” to argue they do not need a BAA. This argument is almost always incorrect when raised by an IT or software vendor, and it is worth understanding exactly why, because you will hear it.

The conduit exception, established under 45 CFR § 160.103, was designed for pure transmission services — entities that move PHI from one point to another without accessing or storing it, such as the U.S. Postal Service, private couriers, and raw ISPs. The exception requires that any storage of PHI be transient — incidental to the transmission itself — and not persistent.

HHS has explicitly addressed the “no-view” argument in its cloud computing guidance, confirming that a provider storing encrypted ePHI is still a business associate that needs a BAA even if it lacks the decryption key. Even if a vendor claims it cannot read encrypted data, if it is maintaining that data — storing it, processing it, or operating infrastructure through which it passes persistently — the conduit exception does not apply.

This matters because a security scanning or vulnerability management vendor is, almost by definition, not a conduit. Its entire job is to reach into a client environment, interrogate systems that hold ePHI, and persistently store the diagnostic results. Under HHS’s cloud computing guidance and HHS FAQ 2077, a service with that kind of persistent access to ePHI is a business associate, not a transient pipe. So when a scanning, RMM, or backup vendor asserts “conduit exempt” status, the right response is not to accept it at face value — the persistent-access test, not the vendor’s characterization, decides the question.

Conduit Exception: What Qualifies vs. What Does Not

Entity Type	Conduit Applies?	BAA Required?
U.S. Postal Service / private couriers	Yes	No
Raw ISP / packet carrier	Yes	No
RMM platform (agents on endpoints)	No	Yes
PSA / ticketing system	No	Yes
Security scanner / vulnerability management	No	Yes
Documentation / wiki platform	No	Yes
Email provider (with message storage)	No	Yes
Cloud storage / backup vendor	No	Yes

The Regulatory Framework: HIPAA Security Rule + NIST SP 800-66r2

The BAA requirement sits within the HIPAA Security Rule’s Administrative Safeguards at 45 CFR § 164.308. Key provisions for MSPs:

45 CFR § 164.308(a)(1) — Requires a security management process including a mandatory risk analysis and risk management program.
45 CFR § 164.308(b)(1) — Governs business associate contracts, requiring covered entities to obtain satisfactory assurances before permitting a BA to handle ePHI.
45 CFR § 164.308(b)(2) — Extends that obligation downstream: business associates must obtain the same satisfactory assurances from their subcontractors.
45 CFR § 164.314(a)(1) — Specifies the contract content requirements that make a BAA legally sufficient.

NIST Special Publication 800-66, Revision 2 — published in February 2024 in collaboration with HHS OCR — provides the implementation guidance that maps these regulatory requirements to practical cybersecurity controls. SP 800-66r2 explicitly identifies “Manage Business Associates” as a key compliance activity, instructing regulated entities to identify BA relationships, establish a process for measuring contract performance, and establish a process for terminating the contract if security requirements are not met. SP 800-66r2 applies to both covered entities and their business associates — meaning MSPs are directly within its scope. The same document leans heavily on the risk analysis as the foundation of everything else, a point we make at length in why your risk analysis cannot be a checkbox.

Building Your Vendor BAA Inventory

This maps directly to the inventory step of our vendor risk management guide — but applied to the MSP’s own tool stack rather than the practice’s. Every tool deployed in or connected to a healthcare client environment belongs on the list. For each vendor, capture:

Vendor name and service description.
Access type: Does the vendor’s system store, transmit, process, or have incidental access to ePHI?
Deployment model: Agent on endpoint, cloud-hosted, or API access?
BAA status: Executed, pending, declined, or not yet requested.
BAA effective date and document version.
Subcontractor cascade: Does the vendor’s BAA require flow-down obligations to their own sub-processors?
Annual review date: Mergers, acquisitions, and new data flows can invalidate prior risk determinations.

What a Compliant BAA Must Actually Contain

A BAA is not a form letter or a one-line addendum. Under 45 CFR § 164.504(e) and 164.314(a), a HIPAA-compliant BAA must include:

Permitted and required uses and disclosures of PHI — what the BA is allowed to do with ePHI and nothing more.
Safeguard obligations — appropriate administrative, physical, and technical safeguards per the Security Rule.
Breach notification requirements — timelines and procedures for reporting security incidents and breaches.
Subcontractor flow-down — the BA must require its own subcontractors that handle ePHI to execute downstream BAAs with equivalent protections (45 CFR § 164.308(b)(2) and 45 CFR § 164.502(e)(1)(ii)).
Access and amendment rights — the BA must support the covered entity’s individual rights obligations.
Return or destruction of PHI upon termination — all ePHI must be returned or destroyed when the relationship ends.
HHS audit access — the BA must make its internal practices, books, and records available to the Secretary for compliance determination.

An addendum that disclaims BA status, characterizes PHI exposure as “incidental,” or states the agreement is entered into solely at the customer’s request — rather than as a legal obligation — does not meet these requirements and is not a valid BAA.

Red Flags When a Vendor Pushes Back

MSPs negotiating downstream BAAs with their technology vendors will occasionally encounter resistance. The following responses should be treated as disqualifying:

“We don’t typically require a BAA.” The obligation is triggered by the data flow, not the vendor’s standard practice. Their lack of a process is a liability to the MSP.
“Our exposure to PHI is incidental.” For any IT vendor with persistent system access, this claim does not withstand legal scrutiny under HHS guidance.
“Encryption means we can’t see the data.” HHS OCR has explicitly rejected this argument. Lacking a decryption key does not remove BA status where ePHI is being maintained.
“We’re conduit exempt.” Reserved for pure transmission services with only transient storage. A scanning, RMM, backup, or ticketing vendor is not a conduit — full stop.
“We’ll sign, but only with language disclaiming BA status.” A BAA that simultaneously disclaims the obligations it is supposed to establish provides no actual legal protection.
Incorrect entity names or copy-paste artifacts in the document. Basic document control failures in a compliance document signal broader process immaturity and should be flagged before execution.

Direct Liability: OCR Enforces Against Business Associates

Since the HITECH Act (2009) and the 2013 Omnibus Final Rule, business associates are directly liable to HHS OCR — not just contractually liable to their covered entity customers. Per the HHS direct-liability fact sheet, OCR has enumerated the categories of direct enforcement authority over business associates, including failure to comply with the HIPAA Security Rule, failure to enter into downstream BAAs with subcontractors that handle PHI, and impermissible uses and disclosures of PHI.

Enforcement is active. In 2023, HHS OCR settled with business associate MedEvolve for $350,000 following an investigation that highlighted BAA and vendor risk management gaps, per the MedEvolve resolution agreement. OCR also settled with business associates Elgon for $80,000 (Elgon resolution agreement) and VPN Solutions for $90,000 (VPN Solutions resolution agreement) following ransomware incidents that exposed Security Rule noncompliance. Civil penalties are tiered by culpability.

The statutory tier structure is fixed, but the dollar amounts are adjusted annually for inflation, so any specific figure ages quickly. Always confirm the current numbers against the HHS Privacy Rule summary and the latest annual adjustment notice in the Federal Register — the 2024 inflation-adjustment notice set the figures applied to penalties assessed on or after August 8, 2024. After the post-2015 adjustments, per-violation penalties range from roughly $137 to about $71,162 depending on culpability tier, with annual caps that reach roughly $2.1 million at the highest tier; the exact current figures are whatever the most recent Federal Register notice specifies. The four culpability tiers are:

Violation Category	Relative Penalty Tier
Unknowing	Lowest per-violation minimum
Reasonable cause	Second tier
Willful neglect, corrected	Third tier
Willful neglect, not corrected	Highest tier (subject to the top annual cap)

State Law Overlays: Why Geography Doesn’t Protect You

HIPAA establishes the federal floor. Several states have enacted laws that impose stricter, broader, or parallel obligations on any entity that handles the health information of their residents, regardless of where the MSP or vendor is physically located. An MSP based in Alabama serving a client whose patients include California, Texas, or New York residents is subject to those states’ requirements — because these laws follow the data, not the geography of the service provider.

California — Confidentiality of Medical Information Act (CMIA)

The California Confidentiality of Medical Information Act (CMIA), codified at California Civil Code §§ 56 et seq., predates HIPAA by more than 15 years and in several respects imposes stricter standards. CMIA applies to health care providers, health care service plans, contractors, and pharmaceutical companies — a definition that reaches IT service providers and vendors who handle medical information of California residents under California Civil Code § 56.10.

Key distinctions from federal HIPAA:

Contractor scope: CMIA’s “contractor” definition captures vendors and service providers — not just the covered entity — making it directly relevant to MSPs handling California-resident patient data.
Stricter authorization requirements: Under California Civil Code § 56.11, a valid authorization must be handwritten by the person who signs it or in typeface no smaller than 14-point type, and must include the specific uses and limitations and an expiration date.
Dual enforcement track: HIPAA and CMIA are separate laws with separate penalty tracks. A single incident can trigger both federal OCR enforcement and California civil liability simultaneously.
Civil penalties: Under California Civil Code § 56.36, a negligent release can trigger nominal damages of $1,000 plus actual damages. Knowing and willful violations carry administrative fines and potential criminal liability.

CMIA can reach contractors handling California medical information, so an MSP serving a healthcare client whose patient population includes California residents should get counsel on its exposure even if the MSP has no California office. The contractor scope, authorization, and damages provisions above all flow from California Civil Code § 56.10, § 56.11, and § 56.36.

Texas — House Bill 300 (HB 300)

Texas House Bill 300, effective September 1, 2012, substantially expands on HIPAA and creates one of the broadest covered-entity definitions in the country. Under HB 300 and the Texas Medical Privacy Act (Chapter 181 of the Texas Health and Safety Code), any person or organization that assembles, collects, analyzes, uses, evaluates, stores, or transmits PHI about a Texas resident is covered — regardless of where that organization is located.

The practical consequence is significant: an entity classified as a Business Associate under federal HIPAA is reclassified as a Covered Entity under Texas law. That reclassification carries heavier direct obligations:

Mandatory customized employee training: Under Texas Health & Safety Code § 181.101, employees must receive training tailored to their specific job duties — not generic HIPAA training — by the 90th day after hire, plus retraining within a reasonable period when a material change in state or federal PHI law affects their duties (not later than the first anniversary of that legal change).
Tiered civil penalties: Under Texas Health & Safety Code § 181.201, penalties run up to $5,000 per violation for negligent violations, up to $25,000 for knowing or intentional violations, and up to $250,000 only where PHI is knowingly or intentionally used for financial gain. A court may assess up to $1.5 million annually where the violations constitute a pattern or practice.
Breach notification: Texas’s general breach-notification statute, Business & Commerce Code § 521.053, requires notice without unreasonable delay and no later than the 60th day after determining a breach occurred, plus notice to the Texas Attorney General within 30 days if at least 250 Texas residents are affected.
State enforcement authority: The Texas Attorney General and multiple state agencies hold enforcement authority independent of federal OCR.

New York — SHIELD Act

The Stop Hacks and Improve Electronic Data Security (SHIELD) Act, signed into law in July 2019 and amended in December 2024, applies to any person or business that owns or licenses computerized data containing the private information of a New York resident, regardless of where the business is located.

Key obligations:

Affirmative data security program: Organizations must develop, implement, and maintain reasonable safeguards covering administrative, technical, and physical security measures — organized around the same categories as the HIPAA Security Rule.
Service provider contracts: The SHIELD Act requires contracts with service providers handling covered information, guaranteeing they comply with required security safeguards — a contract-based analog to the BAA requirement for New York resident data.
30-day breach notification: As of the December 2024 amendment, organizations must notify affected New York residents within 30 days of discovering a breach — significantly tighter than HIPAA’s 60-day window.
State authority notification: Under New York GBS § 899-aa, whenever any New York residents are to be notified of a breach, the business must also notify the State Attorney General, the Department of State, and the Division of State Police. A separate rule requires notice to consumer reporting agencies when more than 5,000 New York residents are notified at one time.
Penalties: Up to $5,000 per violation for failure to maintain reasonable safeguards; up to $20 per failed notification instance (not to exceed $250,000) for breach notification failures.

Under New York GBS § 899-bb, an entity that is subject to and in compliance with HIPAA/HITECH data-security requirements is treated as a “compliant regulated entity” for SHIELD’s reasonable-security provision. But SHIELD still reaches broader categories of New York “private information” beyond PHI — so HIPAA compliance alone does not fully discharge SHIELD obligations for that wider data set.

State Law Comparison at a Glance

	HIPAA (Federal)	California CMIA	Texas HB 300	NY SHIELD Act
Applies to MSPs?	Yes (as BA)	Yes (as contractor)	Yes (as Covered Entity)	Yes (extraterritorial)
Written vendor-agreement rule (cited sections)?	Yes (BAA)	Not in the cited CMIA sections	Not in the cited Ch. 181 / § 521.053 provisions	Yes (service provider contract)
Breach notification window	60 days	Not set by cited CMIA sections	60 days (§ 521.053); AG within 30 days if ≥250 TX residents	30 days
Max civil penalty	Inflation-adjusted tiers (annual cap ~$2.1M at top tier)	$1,000+ nominal + actual	Up to $250,000/violation; up to $1.5M/yr for a pattern	$5,000/violation
Criminal penalties?	Yes	Yes	Yes	No (civil only)
Follows data regardless of MSP location?	Yes	Yes	Yes	Yes

What Good Looks Like

Vendors that have built compliance into their product and process execute downstream BAAs without friction. Characteristics of a mature vendor BAA process include:

A self-serve BAA initiation workflow accessible from within the platform or via a dedicated compliance portal.
A standard BAA template aligned to HHS model provisions and the 2013 Omnibus Final Rule, with no carve-outs that disclaim BA status.
Counter-signature by a named officer or authorized representative, with a complete audit trail.
Acknowledgment of the subcontractor relationship and explicit flow-down obligations to their own sub-processors.
Completion within 24–72 hours of request.

The HHS Model Business Associate Agreement — available directly from HHS.gov — provides the baseline template that any vendor should be able to execute or adapt without significant modification. When a vendor cannot execute a standard BAA without requiring you to first explain federal law to them, that friction is itself a vendor risk signal — and the appropriate response is the same one we described in the tiering step of our vendor risk guide: tier by risk, and treat high-friction compliance as a high-risk indicator.

Practical Checklist for MSPs

Aligned to the risk management requirements of 45 CFR § 164.308(a)(1) and NIST SP 800-66r2:

Maintain a written vendor inventory of all tools deployed in or connected to healthcare client environments.
Classify each vendor’s access type (store / transmit / process / incidental).
Confirm BAA execution status and file executed copies with version control.
Verify BAAs include subcontractor flow-down language (45 CFR § 164.308(b)(2)).
Review vendor BAAs annually or upon material change (new sub-processors, mergers, product changes).
Assess state-law overlay applicability: if any client’s patient population includes California, Texas, or New York residents, apply the stricter state standard to all vendor contracts in that engagement.
Establish a written process for responding when a vendor declines or cannot execute a compliant BAA.
Document the risk determination for any vendor assessed and found not to require a BAA, with supporting rationale.
Ensure BAA templates reflect the 2013 Omnibus Final Rule and applicable state-law overlays.

45 CFR § 164.316(b)(1) requires the Security Rule’s policies, procedures, and required documentation to be maintained in written or electronic form, and 45 CFR § 164.316(b)(2)(i) imposes the six-year retention period for that documentation. In an OCR investigation or audit, the vendor BAA inventory and execution records are among the first documents requested.

The Byzantine Takeaway

The “conduit exempt” claim is the tell. A security scanner, RMM agent, backup provider, or ticketing platform reaches into a healthcare environment and persistently handles what it finds — none of that is a transient pipe, and no amount of confident assertion changes the regulation. When a vendor leads with “we don’t need a BAA,” they are telling you something useful about how seriously they take the data they are about to touch on your behalf. The MSP is the one holding the downstream obligation, so the MSP gets to decide whether that risk is acceptable. Done right, this is not about distrust — it is about a team effort to protect patients’ data and strengthen everyone’s security posture, with the written agreements to prove it.

Where to start: build the vendor BAA inventory described above, then work it from highest exposure to lowest — your RMM, security scanning, backup, and email systems first. For the practice-side view of this same chain, read Vendor Risk Management for Small Healthcare Practices, and for the question of who carries which obligation in an MSP relationship, see Business Associates, BAAs, and MSPs: Who Is Responsible?.

This article is intended for informational purposes and does not constitute legal advice. MSPs should consult qualified HIPAA counsel when evaluating specific vendor arrangements or applicable state-law requirements.