A managed security service provider for healthcare is a third-party organization that takes operational responsibility for the security controls a covered entity must maintain under the HIPAA Security Rule, including continuous monitoring, incident response, risk analysis support, and the documentation that OCR expects to see in an investigation.
What separates a qualified healthcare MSSP from a general security vendor is not the services they list. What matters is whether those services map explicitly to the administrative, physical, and technical safeguards in 45 CFR Part 164, and whether the provider can demonstrate that mapping under audit conditions. The covered entity remains liable for HIPAA compliance regardless of who operates the controls. Choosing the wrong MSSP does not transfer that liability. It compounds it.
Get a Gap Assessment, Not a Sales Pitch
HIPAA's Security Rule Is a Specification, Not a Suggestion
The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes three categories of safeguards: administrative, physical, and technical. Each contains required implementations and addressable ones. “Addressable” means you must either implement the control or document a reasoned equivalent. Neither category is optional.
When you bring on a managed security service provider for healthcare, you delegate the operational execution of specific safeguards; you do not hand off the liability. OCR holds the covered entity responsible regardless of who runs the systems. That’s why choosing an MSSP is a risk management decision with legal consequences, not a procurement decision with vendor preferences.
Here’s what the rule requires, and what that means for any MSSP you’re evaluating.
Criterion 1: They Must Sign a Business Associate Agreement
Any vendor that accesses, processes, stores, or transmits protected health information on your behalf is a Business Associate under HIPAA, which means a signed Business Associate Agreement (BAA) is a legal prerequisite, not a contract nicety.
A BAA obligates the MSSP to safeguard PHI, report breaches within defined timeframes, extend the same obligations to their subcontractors, and destroy or return PHI when the engagement ends. A vendor who won’t sign one, or who offers a BAA with carve-outs that narrow their breach notification obligations, is telling you they intend to operate with less accountability than HIPAA requires of them. Walk away.
The question to ask:
“Can you provide your standard BAA, and walk me through what your breach notification obligations are under it, including your timeline and escalation path to the covered entity?”
Criterion 2: They Must Support a Documented Risk Analysis
§164.308(a)(1) requires covered entities to conductan accurateand thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI. The analysis must be documented, kept current, and actively inform the security program.
It is also the most consistently cited deficiency in OCR enforcement actions. In October 2024, OCR launched a formal Risk Analysis Initiative specifically targeting this requirement, in response to what the agency described in its 2024 Report to Congress as “numerous instances” where regulated entities’ risk analyses were inadequate, incomplete in scope, or never conducted at all. Organizations either skip it entirely, treat it as a one-time checkbox, or complete it and then let it sit while their security program runs on separate assumptions.
A qualified healthcare MSSP should conduct or directly support this risk analysis and connect its findings to the managed services they configure for you. If your security partner can’t show you how their service decisions trace back to your documented risk profile, they are making security decisions without the context HIPAA requires.
The question to ask:
“How do you conduct a HIPAA security risk analysis, and how does that output drive the specific controls you configure for our environment?”
The HIPAA risk analysis isn't a compliance checkbox. It's the document that tells OCR whether your security program was built around your actual risks or assembled without context, and the difference between those two answers determines how an investigation ends.
Criterion 3: They Must Map Their Services to the Technical Safeguards
§164.312 defines four technical safeguard categories that apply to any systemcontainingePHI. These are not principles. They are control requirements. Your MSSP’s service stack should satisfy each one explicitly.
The four §164.312 technical safeguard categories and what your MSSP must deliver to satisfy each one:
| HIPAA Technical Safeguard | What Your MSSP Must Deliver |
|---|---|
| Audit Controls §164.312(b) | SIEM: Active, Not Passive Log ingestion, normalization, correlation rules, and alerting running continuously. Retention policies must satisfy HIPAA documentation requirements and applicable state breach notification laws. |
| Integrity Controls §164.312(c)(1) | EDR (Behavioral) · File Integrity Monitoring Endpoint detection and response with behavioral detection, not signature-based antivirus. FIM flags unauthorized changes to ePHI systems before they become reportable incidents. |
| Transmission Security §164.312(e)(1) | TLS 1.2 Minimum · TLS 1.3 Preferred All ePHI in transit must be encrypted. SSL, TLS 1.0, and TLS 1.1 are deprecated, and their presence in your environment is an audit finding, not a configuration preference. |
Access Controls (§164.312(a)(1))
Only authorized users may access ePHI. Your MSSP should manage or directly support identity and access management (IAM), role-based access controls (RBAC), and phishing-resistant multi-factor authentication, specifically FIDO2 or certificate-based MFA, across the systems that touch patient data. Implementations aligned with NIST SP 800-63B provide a recognized standard for evaluating whether those controls are actually strong enough.
Audit Controls (§164.312(b))
Systems must record and allow examination of activity involving ePHI. In practice, this means a properly configured SIEM with log ingestion, normalization, correlation rules, and alerting, running continuously and producing an auditable event trail. Collecting logs is not the same as operating audit controls. Your MSSP should be doing both, with retention policies that satisfy both HIPAA’s documentation requirements and your state’s breach notification laws.
A SIEM that collects logs without active correlation rules, tuned alerting, and a human analyst reviewing escalations is a storage system, and a storage system does not satisfy §164.312(b)'s audit control requirement, no matter what the vendor's service description says.
Integrity Controls (§164.312(c)(1))
ePHI must be protected against improper alteration or destruction. This requires endpoint protection: specifically EDR solutions capable of behavioral detection, not just signature-based antivirus, combined with file integrity monitoring (FIM) that flags unauthorized changes before they become reportable incidents.
Transmission Security (§164.312(e)(1))
ePHI moving across electronic networks requires encryption in transit. TLS 1.2 at minimum, TLS 1.3 preferred. Older protocols such as SSL and TLS 1.0/1.1 are deprecated, and their presence in your environment is a finding, not a configuration preference.
The question to ask:
“Which of your managed services satisfies each of these four technical safeguard categories, and how do you produce documentation of that coverage for audit purposes?”
See How Your Security Stack Measures Up
Criterion 4: They Must Have a Tested, Healthcare-Specific Incident Response Plan
§164.308(a)(6) requires covered entities toidentifyand respond to suspected or known security incidents, mitigate harm, and document both the incident and the response. OCR will ask for that documentation. “We handled it” is not documentation.
Your MSSP’s incident response process must account for a healthcare-specific determination that general security firms rarely pre-plan: whether a security incident constitutes a HIPAA breach under the four-factor risk assessment defined in 45 CFR §164.402. That assessment evaluates the nature and extent of the PHI involved, who accessed it, whether PHI was actually acquired or viewed, and the extent to which the risk to the PHI has been mitigated. Getting that determination wrong, in either direction, and that carries its own liability.
On notification timelines: HIPAA’s Breach Notification Rule (45 CFR §164.404) requires notification without unreasonable delay, with 60 calendar days as the outer limit, not the target. An MSSP whose incident response timeline is built around “we have 60 days” rather than “we move as fast as the investigation allows” is treating the ceiling as the plan.
Ask them to walk you through a ransomware scenario. If ePHI is encrypted, what happens in the first hour? Who runs the four-factor risk assessment, and how is it documented? What does the breach notification package look like? An MSSP that responds in generalities has never run a healthcare incident to completion. That’s not a negotiating point. It’s a disqualifier.
The question to ask:
“Walk me through a real healthcare incident response you’ve managed, specifically how you conducted the breach determination under §164.402, the timeline you hit, and the documentation you produced for the covered entity.”
Criterion 5: They Must Know What to Do With Assets They Can't Patch
In remediation engagements involving healthcare networks, one of the first things we encounter is a list of connected medical devices and legacy clinical systems that haven’t received a security update in years. This is not because the IT team forgot, but because patching them requires manufacturer coordination, FDA change control considerations, and scheduled clinical downtime that the organization can’t absorb on a standard cycle. The devices are online, often network-adjacent to systems containing ePHI, and completely outside the MSSP’s standard endpoint management workflow.
Research by Palo Alto Networks found that 53% of connected medical devices in hospitals have known critical vulnerabilities. Most of them cannot simply be patched. An MSSP that treats these assets the same as any other managed endpoint will either push a change that disrupts a clinical workflow or skip the asset entirely and leave it unmonitored. Neither outcome is acceptable, and neither reflects familiarity with how healthcare environments actually operate.
A qualified MSSP should assess the risk each of these assets introduces, implement compensating controls: network segmentation to isolate device traffic, passive monitoring tools that observe device behavior without interacting with clinical functions, and documented exception policies that satisfy your risk analysis requirements. These should be flagged them in your ongoing risk register. This criterion doesn’t appear as a named safeguard in the HIPAA Security Rule, but it sits squarely within the scope of a required risk analysis, and it’s where general-purpose MSSPs most reliably reveal their limits.
The question to ask:
“How do you secure connected medical devices and legacy clinical systems that can’t be patched on a standard schedule, and what specific compensating controls do you document in the risk register?”
Criterion 6: They Must Generate Audit-Ready Documentation as Standard Output
§164.316 requires written policies, procedures, and documentation. The burden of proof falls on the covered entity when OCR requests records. Your MSSP should produce that documentation as a routine output of their operations. If preparing for an audit requires your team to reconstruct timelines, chase down log exports, or manually compile evidence from your vendor’s portal, your MSSP has transferred the compliance work back to you without reducing the underlying risk.
The documentation your MSSP should generate continuously includes security incident records, access logs, risk analysis outputs, and evidence of safeguard implementation, formatted and retained in a way that maps directly to §164.316’s requirements. If they manage your SIEM and your endpoint security but can’t produce a clean audit package from either system, the managed part of managed security is doing less work than it should.
The question to ask:
“What documentation does your service generate automatically, what format does it come in, and how does it map to the record-keeping requirements in §164.316?”
The Questions That Separate Qualified MSSPs from Vendors with Healthcare Logos
Every MSSP in this space uses the words “HIPAA-compliant.” Very few can answer these six questions without hedging:
- Will they sign a BAA, and what breach notification obligations does it actually impose on them?
- Can they conduct or directly support a HIPAA risk analysis and show how it connects to the services they configure?
- Do their managed services map explicitly to all four technical safeguard categories in §164.312?
- Do they have a tested, healthcare-specific incident response plan that includes the four-factor breach determination under §164.402, and can they prove it with a real example?
- Do they have a defined approach for connected medical devices and legacy clinical systems, including specific compensating controls?
- Does their service produce audit-ready documentation as standard output, or does your team have to assemble it from their data?
If any answer is vague, generic, or hedged with “that depends on the engagement,” you have your answer. Vendors who can’t account for these requirements either haven’t worked deeply enough in healthcare or haven’t thought carefully enough about what your exposure looks like when something goes wrong.
Why Infrastructure and Security Belong With the Same Partner
There’s a structural argument here that goes beyond the HIPAA checklist.
When your IT infrastructure and your security monitoring sit with separate vendors, the security team works with incomplete context. They see alerts, but they don’t fully understand the clinical workflows those alerts are touching. They know a system behaved anomalously, but they don’t own the access controls that govern it. Misconfigurations happen at that handoff. Audit trails develop inconsistencies at that handoff. When a breach investigation starts, the gap between what your MSP knows and what your MSSP knows is exactly where the timeline falls apart.
Organizations that align their security programs to the NIST Cybersecurity Framework (CSF) 2.0, which structures security operations across Identify, Protect, Detect, Respond, and Recover. Organizations benefit most from having those functions governed under a single operational picture. Splitting Identify and Protect between an MSP and Detect and Respond between an MSSP creates seams in that framework that are difficult to audit and harder to defend.
Meriplex manages both IT infrastructure and cybersecurity services for healthcare organizations under one roof. Our security team and infrastructure team work from the same environment, which means when something anomalous happens in your network, the team responding already understands the clinical system it’s affecting, the access controls around it, and the documentation required to demonstrate an appropriate response to OCR.
In a HIPAA audit, that shared context is the difference between a clean response and an extended investigation.
When infrastructure management and security monitoring sit with separate vendors, the gap between what each team knows is invisible on an org chart and obvious during a breach investigation. In healthcare, that gap is where response timelines fall apart and OCR findings are made.
