Working With an IT MSP That Doesn't Understand EMS

I sat in on a meeting last month between an EMS agency director and their new MSP account manager. The account manager spent twenty minutes walking through their standard service catalog: patch management, backup verification, firewall rule reviews, and help desk ticketing with a four-hour SLA for critical issues. The director nodded through all of it, then asked one question: \"What happens when CAD goes down at 3 AM on a Saturday?\"

The account manager said they would open a ticket.

That is the gap. Not a small gap. A fundamental mismatch between how generalist MSPs think about IT and what EMS operations actually require. This article covers the operational realities your MSP is probably missing, the contract language that closes the gap, and where the boundary between IT and operations actually sits.

Managed Service Provider for EMS and Fire Departments

Most MSPs come from the corporate world. They understand office networks, file servers, and email. They know how to keep a law firm or a real estate agency running. Those environments have different tolerances. A server outage at a law firm means lost billable hours. A CAD outage at an EMS agency means delayed response times, lost situational awareness, and potential loss of life.

The difference is not academic. It changes how you staff, how you prioritize, and how you measure success.

A 3 AM CAD failure is not a ticket. It is a dispatch center going dark, trucks rolling without full scene information, and medics making clinical decisions without the data they need.

I wrote about the cybersecurity questions nobody asks during agency mergers, and the same principle applies here. The questions you do not ask your MSP upfront are the ones that cost you later.

The 24/7 Shift Reality Your MSP Is Not Staffed For

EMS runs on a 24-hour clock. Shift change at 0700 and 1900 are the most operationally sensitive windows. That is when handoffs happen. That is when the technology has to work without friction. A CAD login failure at 0655 means a crew starting their shift cannot see their first call. An ePCR sync failure at 1900 means the offgoing crew leaves without closing their patient records.

Generalist MSPs staff for business hours. Some offer after-hours support with a callback within thirty minutes. That is not enough.

The problem is not that the MSP is incompetent. The problem is that their staffing model was built for a different operational tempo. They do not have a night shift. They do not have weekend coverage that understands public safety systems. When a CAD server throws an error at 2 AM, the person who answers the phone can reboot a server but cannot assess whether the reboot will break the CAD-to-ePCR data bridge.

The fix is not complicated. Your contract needs to define a separate escalation path for Tier 0 systems with 24/7 coverage staffed by people who understand those systems. Not a general help desk. A specific team.

Securing Unattended Ambulance WiFi Networks

The apparatus bay is a network edge that most MSPs never think about. It is not in the server room or climate controlled. It is a concrete floor with diesel exhaust and a roll-up door that stays open half the day.

Trucks pull in, connect to the bay WiFi, download their daily data, upload patient records, and sync CAD updates. Then they pull out and switch to LTE. That transition has to work every time. A truck that cannot sync its ePCR data because the WiFi handoff failed is a truck that cannot clear the hospital and return to service.

The security side is worse. Unattended trucks with always-on WiFi are a target. An SSID broadcasting in a bay that is open to the street is an invitation. Rogue access points, SSID spoofing, credential harvesting from MDTs that stay logged in between shifts. These are real attack vectors that a generalist MSP will not flag because they do not know to look.

Your MSP needs to audit the apparatus bay network as a separate security zone. Not as an extension of the office network. A separate policy with separate monitoring and separate access controls. If your MSP does not know what an MDT is or how it authenticates, they cannot secure it.

EMS CAD Outage Recovery and MSP Responsibilities

A CAD outage is not a server problem. It is an operational emergency. The cascade goes like this: CAD goes down, dispatch goes to paper. Paper means slower call processing. Slower call processing means longer response times. Meanwhile, ePCR stops receiving dispatch data, so medics have to manually enter call information. Hospital notification systems lose their data feed. The whole chain breaks.

A generalist MSP treats this as a server restore. They find the root cause, apply a fix, and close the ticket. What they do not do is plan for the operational impact of the outage itself.

Your contract needs to define what happens during a CAD outage. Not just the technical recovery steps but the operational playbook: who gets notified, how dispatch switches to backup procedures, how ePCR data gets reconciled after the system comes back, and how you verify data integrity before declaring the system operational again.

This is where the tabletop exercise framework I wrote about becomes relevant. Run a CAD outage scenario with your MSP in the room. See how they respond. See whether they understand the clinical impact or just the technical one.

Public Safety IT Service Level Agreement vs Operational Agreement

Standard SLAs measure technical metrics like uptime percentage, response time, and resolution time. These are useful, but they do not capture what matters in a public safety environment.

An Operational Level Agreement shifts the focus from technical metrics to functional outcomes. Instead of \"99.9% CAD uptime,\" the OLA says \"CAD dispatch capability maintained during all shift change windows.\" Instead of \"four-hour critical ticket response,\" the OLA says \"Tier 0 system outage triggers immediate escalation to on-call engineer with CAD-specific training.\"

The difference is subtle in wording and massive in practice. An SLA tells you the server is running. An OLA tells you the crew can take the call.

Here is what the contract addendum should include:

• Criticality tiering. CAD, ePCR, and dispatch systems are Tier 0. They get immediate, non-ticketed escalation with a phone call to a specific person. No ticket queue, no triage.
• Environment awareness. The MSP must document and audit the apparatus bay network and mobile device security as a separate scope, not as part of a general office audit.
• Change management restrictions. Blackout windows during peak call volume and shift changes. Any change to a Tier 0 system requires a clinical impact analysis before execution.
• On-site context. The account manager must complete a ride-along shift before the contract starts. They need to see how the technology is actually used in the field, not just how it looks in the server room.

The Boundary Between IT and Operations

The hardest conversation is not about what the MSP does. It is about what the agency owns.

The MSP manages the network, the servers, the endpoints, and the security stack. That is the utility layer. It is necessary but not sufficient for operational readiness. The agency owns the clinical workflow integration, the CAD-to-ePCR data mapping, the MDT login procedures, and the human interface of technology in the field.

When those two layers conflict, the MSP wins on technical correctness and the agency loses on operational reality. A security update that breaks a legacy CAD API is technically correct. The MSP patched a vulnerability, but the agency cannot dispatch. The MSP met their SLA while the agency has an operational crisis.

A change management process that requires clinical impact analysis before any change to Tier 0 systems solves this. The MSP proposes the change, the agency approves it based on operational impact, and the MSP executes it during an approved window. That is the boundary. The MSP owns the technical execution and the agency owns the operational outcome.

Frequently Asked Questions

Why is a generalist MSP often a poor fit for an EMS agency?

Generalist MSPs are built for corporate environments where downtime means lost revenue. In EMS, downtime means delayed response and potential loss of life. The staffing model, escalation paths, and system knowledge required for public safety are different from what a generalist MSP typically provides.

What is the difference between an SLA and an OLA in an EMS context?

An SLA measures technical metrics like uptime percentage and response time. An OLA measures functional outcomes like whether dispatch capability is maintained during shift changes. The SLA tells you the server is running. The OLA tells you the crew can take the call.

Who should own the final decision on IT changes in a public safety agency?

The agency's operational leadership owns the final decision. The MSP provides technical expertise and recommendations. But the agency must approve changes based on potential impact on field operations. A security update that breaks CAD is not a win, even if it closes a vulnerability.

What should an EMS agency look for when hiring an MSP?

Look for an MSP that has public safety experience or is willing to invest in learning it. Require a ride-along as part of the onboarding process. Ask how they handle 3 AM outages. Ask whether they have staff who understand CAD and ePCR systems. If the answer is \"we open a ticket,\" keep looking.

How do you secure unattended ambulance WiFi networks?

Treat the apparatus bay as a separate security zone with its own policy and monitoring, plus separate access controls. Audit SSID exposure. Require certificate-based authentication for MDTs. The transition between bay WiFi and LTE needs to work without dropping sessions. Your MSP should document this as a distinct scope, not as an afterthought.

---

The gap between a generalist MSP and an EMS agency is not malice. It is a difference in operational context. The MSP does not know what they do not know. Your job is to close that gap with contract language, operational requirements, and a clear boundary between what IT does and what the agency owns. Start with the ride-along, then fix the contract, then test the outage response. In that order.

-- Steven