HIPAA Compliance for Healthcare IT: What MSPs Need to Know Before Signing That BAA

By Acreus Editorial

The Business Reality MSPs Keep Getting Wrong

Most managed service providers approach HIPAA the way contractors approach a building inspection — do the minimum, hope nothing gets flagged. That approach works until it doesn’t, and in healthcare IT, “until it doesn’t” means a federal investigation, a six-figure penalty, and your healthcare clients looking for a new MSP before the ink dries on the OCR settlement.

Here’s what practitioners who’ve worked through HIPAA readiness assessments with MSPs see repeatedly: organizations that think they’re covered because they signed a Business Associate Agreement (BAA). A BAA is a contractual obligation, not a compliance posture. Signing one without a supporting security program is like signing a contract to run a marathon having never laced up running shoes.

If you’re an MSP evaluating HIPAA compliance — or if you’re a healthcare organization deciding which MSP to trust with systems that touch protected health information (PHI) — this guide covers what the decision-stage actually looks like: the controls, the gaps, and how to evaluate whether a potential partner has built real compliance infrastructure or just paperwork.

---

What HIPAA Actually Requires from MSPs (Not the Summary Version)

HIPAA’s Security Rule, codified at 45 CFR Part 164, establishes three categories of safeguards for Business Associates handling electronic PHI (ePHI): administrative, physical, and technical. NIST Special Publication 800-66 Rev. 2 (Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide, published December 2022) maps these requirements directly to actionable controls — it’s the authoritative practitioner reference and the framework any serious MSP should be building against.

Administrative Safeguards (45 CFR §164.308)

This is where most MSPs have the largest gaps. Administrative safeguards require:

Risk Analysis (§164.308(a)(1)) — A documented, thorough assessment of the risks and vulnerabilities to ePHI in your environment. Not a checklist. Not a point-in-time scan. A living document that identifies threats, evaluates likelihood and impact, and informs your remediation roadmap. HHS guidance makes clear this must be updated when there are significant operational or environmental changes.

Workforce Training (§164.308(a)(5)) — Every workforce member who handles ePHI must be trained. MSPs often forget this applies to their own staff — the technician remoting into a healthcare client’s EHR server is subject to workforce training requirements.

Incident Response Procedures (§164.308(a)(6)) — Documented procedures for identifying, responding to, and reporting security incidents involving ePHI. If you don’t have a tested incident response plan that specifically covers PHI breach scenarios, you’re not compliant — you’re gambling.

Contingency Planning (§164.308(a)(7)) — Data backup plan, disaster recovery plan, emergency mode operation plan. For MSPs, this means being able to demonstrate that healthcare client data remains available and recoverable in a breach or outage scenario.

Business Associate Agreements (§164.308(b)(1)) — Yes, you need them. But more importantly, you need to be able to demonstrate the downstream compliance they’re supposed to cover. If you’re subcontracting any work (ticketing systems, backup platforms, remote monitoring tools) that touches ePHI, those subcontractors need BAAs too. This is where the chain-of-custody for ePHI breaks down in MSP environments.

Technical Safeguards (45 CFR §164.312)

Access Controls (§164.312(a)(1)) — Unique user identification, emergency access procedures, automatic logoff, and encryption/decryption mechanisms. In practice: no shared accounts on systems touching ePHI, MFA enforced, session timeouts configured, and full-disk encryption on any endpoint that could access PHI.

Audit Controls (§164.312(b)) — Hardware, software, and procedural mechanisms to record and examine activity on systems containing ePHI. This means logging is on, logs are retained, and someone is actually reviewing them. A logging system with no alert thresholds and no review cadence is a compliance control that doesn’t work.

Integrity (§164.312(c)(1)) — Protection against improper alteration or destruction of ePHI. File integrity monitoring, hash verification, version control for ePHI-containing systems.

Transmission Security (§164.312(e)(1)) — Encryption of ePHI transmitted over networks. TLS 1.2 minimum (1.3 preferred). Any tool your MSP uses to remotely access healthcare client systems must use encrypted transmission — this is non-negotiable and frequently missed in legacy RMM/remote access configurations.

Physical Safeguards (45 CFR §164.310)

For MSPs, physical safeguards apply to the data centers and physical infrastructure hosting ePHI. Workstation use and security controls, media controls (including secure disposal of devices that stored ePHI), and facility access controls are all in scope. If your technicians work remotely, workstation security policies need to account for home environments.

---

The Risk Analysis Requirement Is Not Optional — and Most MSPs Fail It

The HHS Office for Civil Rights (OCR) has been explicit in its enforcement guidance: failure to conduct an adequate, organization-wide risk analysis is the single most commonly cited HIPAA violation in enforcement actions. Per OCR’s official enforcement data, it has appeared in virtually every settlement since the Omnibus Rule expanded Business Associate obligations in 2013.

An adequate risk analysis (per HHS guidance at https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html) must:

1. Identify the scope — all ePHI created, received, maintained, or transmitted
2. Gather data — document all locations ePHI exists across the environment
3. Identify threats and vulnerabilities — specific to the environment, not generic
4. Assess current controls — evaluate the adequacy of existing safeguards
5. Determine likelihood and impact — for each identified threat
6. Determine risk level — prioritized by severity
7. Finalize documentation — in written, updatable form
8. Review and update periodically and after environmental changes

MSPs that hand healthcare clients a generic “HIPAA risk assessment template” filled in with checkboxes are not meeting this standard. Practitioners working through real HIPAA engagements report that healthcare organizations are increasingly sophisticated about this distinction — they know the difference between a real risk analysis and a compliance theater document, and they’re asking for the real thing before signing contracts.

---

What Differentiates Compliant MSPs in Competitive Evaluations

Healthcare organizations comparing MSPs don’t just want HIPAA compliance — they want evidence of it. Here’s what separates MSPs that win these evaluations from those that don’t:

1. A Current, Documented Risk Analysis

Not “we have one from 2022.” A living document, updated within the last 12 months or after any significant infrastructure change. If you can’t produce it, the conversation usually ends there.

2. Documented Security Policies Specific to ePHI

Generic IT policies aren’t enough. Healthcare clients want to see policies that specifically address PHI handling, breach notification, workforce sanctions for violations, and third-party subcontractor requirements.

3. Evidence of Workforce Training

Training completion records, signed acknowledgments, and — ideally — tabletop exercise documentation showing your staff knows how to respond to a PHI breach scenario. Healthcare legal counsel often asks for this during vendor due diligence.

4. Subcontractor and Tooling BAA Inventory

A complete list of every subcontractor and tool that could touch ePHI, with corresponding BAAs on file. This is the most common gap practitioners encounter — an MSP with strong internal controls but a monitoring tool or ticketing platform that’s never been through BAA procurement.

5. Breach Notification Readiness

HIPAA’s Breach Notification Rule (45 CFR Part 164, Subpart D) requires notification to covered entities within 60 days of discovery. MSPs must have documented procedures, chain of command, and template notifications ready. Healthcare clients ask whether you’ve ever reported a breach — and how you handled it.

6. Annual Security Reviews and Penetration Testing

Regular vulnerability scanning and annual penetration testing of environments touching ePHI. Healthcare organizations are increasingly requiring this as a contract term, not just a nice-to-have.

---

The Breach Notification Math: Why Getting This Wrong Is Expensive

The Office for Civil Rights enforces HIPAA with civil money penalties (CMPs) under a tiered structure:

Tier	Knowledge Level	Annual Cap
1	Did not know	$100 – $50,000/violation, up to $25K/yr
2	Reasonable cause	$1,000 – $50,000/violation, up to $100K/yr
3	Willful neglect, corrected	$10,000 – $50,000/violation, up to $250K/yr
4	Willful neglect, not corrected	$50,000/violation, up to $1.9M/yr

For MSPs, Tier 4 — willful neglect that wasn’t corrected — is the exposure zone when an MSP had no risk analysis, no policies, and no training program. The 2023 OCR settlement with Doctors’ Management Services for $100,000 following a ransomware attack highlighted that Business Associates face the same penalty exposure as covered entities.

State attorneys general can also pursue independent HIPAA enforcement, and many states have layered additional privacy requirements on top of the federal floor.

---

Making the Decision: What to Ask Before Hiring a HIPAA-Ready MSP

If you’re a healthcare organization evaluating MSP partners, or an MSP benchmarking your own program, these are the decision-stage questions that matter:

1. Can you provide your current, documented HIPAA risk analysis? (Not a template — the completed document)
2. Do you have a complete BAA inventory for all subcontractors and tools that touch ePHI?
3. What is your documented incident response procedure for PHI breaches, and when was it last tested?
4. How do you handle the disposal of devices that stored ePHI?
5. Do you conduct annual penetration testing on environments handling ePHI? Can you provide recent reports?
6. How do you train your workforce on HIPAA requirements, and can you provide training completion records?
7. What is your subcontractor assessment process before signing BAAs?

MSPs that can answer these questions with documentation don’t just win healthcare IT business — they hold it, because healthcare organizations don’t enjoy going through this evaluation process again.

---

FAQ Schema

Q: Does my MSP need a BAA with every healthcare client?

A: Yes. Under the HIPAA Omnibus Rule (effective 2013), any Business Associate — including MSPs — that creates, receives, maintains, or transmits ePHI on behalf of a covered entity must have a signed BAA. Operating without one exposes both parties to OCR enforcement. The BAA must include specific required provisions under 45 CFR §164.314(a)(2).

Q: What’s the difference between HIPAA “required” and “addressable” safeguards?

A: The HIPAA Security Rule designates some implementation specifications as “required” (must be implemented) and others as “addressable” (must be assessed and either implemented, implemented via equivalent alternative, or documented as not applicable with justification). “Addressable” does not mean optional — OCR expects documentation of the decision-making process regardless of what you implement.

Q: Can an MSP be fined directly by OCR for a HIPAA violation?

A: Yes. Since the Omnibus Rule, Business Associates are directly liable under HIPAA and subject to civil money penalties from OCR. The Business Associate’s covered entity client cannot shield them from enforcement.

Q: What is the minimum required content in a HIPAA BAA?

A: Per 45 CFR §164.314(a)(2), a BAA must establish permitted uses and disclosures of PHI, require appropriate safeguards, require reporting of security incidents and breaches, ensure subcontractors are also bound, and require return or destruction of PHI at contract termination. Many generic BAA templates miss one or more of these elements.

Q: How often does a HIPAA risk analysis need to be updated?

A: HHS guidance does not prescribe a specific frequency — but requires updates when there are “changes in the environment or operations that affect the security of ePHI.” Best practice (and what practitioners advise for MSP-managed environments) is annual review plus triggered updates after significant infrastructure changes, new tool deployments, or security incidents.

---

Next Step: Know Where Your Program Actually Stands

The gap between “we signed the BAA” and “we’re HIPAA compliant” is where enforcement actions happen. A compliance assessment maps your current controls against the full Security Rule requirements, identifies where your risk analysis needs work, and builds a prioritized remediation roadmap — so you can go into healthcare IT engagements with documentation, not just confidence.

Request a Free HIPAA Compliance Assessment →

CertifyDefense serves MSPs and network engineering firms managing healthcare IT environments. Our assessments are built against HHS guidance and NIST SP 800-66 Rev. 2 — the same standards OCR uses in enforcement.

---

Sources: HHS Office for Civil Rights HIPAA Security Rule (45 CFR Part 164); NIST Special Publication 800-66 Rev. 2 (December 2022); HHS OCR Enforcement Actions and Settlements (hhs.gov/hipaa/for-professionals/compliance-enforcement). Last reviewed: February 2026.