For years, public safety agencies have been told that managed IT services are managed IT services. The MSP sells email support, endpoint management, cybersecurity monitoring, cloud migration, help desk, and a “government tier.” The agency signs because the proposal looks professional, the pricing is lower than building an internal team, and the contract says 24/7 support.
Then the agency gets into the work.
The MSP is good at Microsoft 365, endpoint tools, patching, laptops, printers, user accounts, firewalls, and general help desk work. That is real work. It has value.
Then CAD slows down at 0200. RMS is not sending the correct data to mobile. A CJIS auditor asks who has logical access to unencrypted CJI. The dispatch floor reports a recurring interface issue. The vendor says it is not their system. The generic ticket queue cannot distinguish between a broken monitor in administration and a dispatch-impacting application failure. The disaster recovery plan restores office productivity but does not explain how the PSAP keeps running without losing call handling continuity.
That is the moment the agency learns the truth.
Public safety is not corporate IT with higher uptime. It is a different category of operation. Sentinel's position is not that generic MSPs are bad. Many are excellent at the work they were designed to perform. The issue is category fit. A firm built for corporate productivity infrastructure is not automatically built to sustain CAD, RMS, JMS, radio, NG911, CJIS, evidence, mobile data, dispatch operations, and the governance record that public safety oversight demands. This Insight is about why the two are different, where the boundary actually lives, and what a public safety MSP has to be built to carry.
The False-Equivalence Opener
The conversation usually starts with a frustrated leader.
The chief, city manager, sheriff, dispatch director, or IT director says some version of this: “We have a managed services provider. Why are we still having these problems?”
That question is fair. They are paying for managed services. They have a contract. They have a help desk. They have escalation language. They have cybersecurity tools. They may even have quarterly business reviews.
When you look under the hood, the answer becomes clear. The MSP is managing the parts of the environment it understands. It is not carrying the operational technology stack that actually runs the agency's mission. The MSP can reset passwords, patch endpoints, manage Microsoft, procure laptops, support office networks, monitor antivirus, and help with cloud services. It may not understand how CAD data moves into RMS, how mobile units consume dispatch data, how CJIS access changes the support model, how radio logs matter during a critical incident, how dispatch priority differs from business priority, or how a vendor escalation needs to be documented for council, a state auditor, or an Inspector General.
From the operational side, this shows up as frustration on the floor. The dispatcher says, “We reported this already.” The supervisor says, “The ticket is still open.” The chief asks IT, “Why does this keep happening?” IT says, “The MSP is looking at it.” The MSP says, “We are waiting on the vendor.” The vendor says, “We need logs from the MSP.” The issue sits in the middle while the people doing the work build a workaround. That workaround is where confidence starts to die.
From the engineering side, the MSP is not necessarily doing anything wrong. They are following the model they were hired under. The problem is that the model is wrong for the environment. Public safety systems are not isolated business applications. CAD, RMS, JMS, evidence, mobile data, radio, logging, telephony, and NG911 are interconnected operational systems. A support model that cannot see across those seams will always miss the problem that lives between them.
The National 911 Program describes CAD today as extending beyond the dispatch center and feeding downstream records throughout the public safety ecosystem, including police, fire, EMS, and partner systems. That alone should tell agencies why a basic IT support model is insufficient for this environment.
The MSP was not failing at corporate IT. It was being asked to carry public safety operations with a corporate IT operating model.
What Generic MSPs Actually Do Well
This argument cannot be MSP-bashing because that would be dishonest. Generic MSPs are good at many things public agencies need.
They are often very good at Microsoft 365 administration, endpoint management, workstation support, basic network monitoring, firewall maintenance, backup tools, email security, patching, user provisioning, laptop replacement, printer support, remote support, administrative cloud migration, and general help desk operations.
For the administrative side of a city or county, a competent MSP can be the right answer. Finance, HR, the clerk's office, community development, parks, public works administration, document storage, email, productivity suites, phones, general cybersecurity, endpoint protection. These are all places where a traditional MSP may provide strong value.
If an agency asks us, “Should we keep our MSP for administrative IT?” the answer is not automatically no. The better answer is this. Keep the MSP where the MSP is structurally aligned to the work. Do not assume that same model can carry the public safety stack.
That is the distinction.
A city may need a generic MSP and a public safety technology partner. Those are not mutually exclusive. When the roles are clear, the relationship can work very well. The generic MSP carries the administrative environment. The public safety partner carries the mission-critical operational environment. The agency benefits because each firm is operating inside the category it actually understands.
The problem is not that generic MSPs are weak. The problem is that public safety agencies are sold the idea that strength in corporate IT equals fluency in mission-critical operations.
The Category Boundary
This is the heart of the argument. Public safety is not corporate IT. It has a different priority model, a different uptime expectation, a different compliance regime, a different vendor ecosystem, and a different cost-of-failure curve.
In corporate IT, downtime usually means lost productivity. A department cannot work. Email is delayed. A finance process waits until morning. In public safety, downtime can affect call handling, dispatch, field response, records accuracy, officer safety, fire response, EMS coordination, evidence integrity, jail operations, and community trust. That is not a premium version of the same problem. It is a different problem.
Public safety also lives under a different oversight environment. Council, county commissioners, state auditors, prosecutors, public records requests, CJIS audits, IG reviews, media scrutiny, and community stakeholders all have the ability to ask why a system failed, how the failure was handled, who was notified, what the record shows, and whether the agency had a defensible plan.
Architecturally, the category boundary is just as sharp. A corporate MSP designs around business continuity. A public safety sustainment model designs around mission continuity. That changes everything. SLA language has to reflect operational consequence, not generic user impact. Monitoring has to include mission-critical application health, not just endpoint and server status. Disaster recovery has to be measured against dispatch continuity, not office recovery. Security has to account for CJIS, chain-of-custody, evidence workflows, and protected operational data. Maintenance windows have to be negotiated around 24/7 operations. Vendor escalation has to be mapped before the outage, not during it.
The Bureau of Justice Assistance's law enforcement CAD system guidance states that all aspects of CAD must be optimized for rapid response time and system reliability, because time is of the essence in public safety operations. That is the category boundary in one sentence.
Same building. Same network closet. Completely different operating model.
The CJIS Reality
CJIS is not the same thing as SOC 2. It is not ISO 27001 with a law enforcement label. It is not a checkbox. It is an operating discipline.
SOC 2 evaluates controls at a service organization across trust services categories such as security, availability, processing integrity, confidentiality, and privacy. ISO/IEC 27001 helps organizations establish an information security management system and apply risk management processes appropriate to their needs. Both can be valuable. Neither replaces CJIS.
The FBI CJIS Security Policy applies to every individual, including contractors and private entities, with access to, or operating in support of, criminal justice services and information. It governs the creation, viewing, modification, transmission, dissemination, storage, and destruction of CJI.
That matters for managed services. A real CJIS-capable support model has to address personnel screening, fingerprint-based background checks where required, logical and physical access control, security awareness training, encryption posture, audit logging, incident response, media protection, remote access controls, vendor access governance, state CJIS Systems Agency coordination, and documentation that survives audit.
Colorado's CJIS security guidance, for example, states that fingerprint-based background checks are required for personnel with unescorted physical or logical access to unencrypted CJI or areas where it is processed or stored. The FBI's outsourcing standard also requires parties involved in outsourcing arrangements to maintain security practices consistent with federal and state laws and the CJIS Security Policy. That is a very different statement than “we have a security policy” or “we are SOC 2 aligned.”
A generic MSP may say, “We do CJIS.” Sometimes what they mean is, “We support a police department and we have security tools.” Those are not the same.
CJIS compliance is not a certificate the MSP waves during procurement. It is the discipline that governs who touches the system, how they touch it, what gets logged, what gets encrypted, what gets reported, and what survives audit.
The Platform Fluency Gap
A generic MSP engineer may be excellent. They may know Microsoft, Cisco, Fortinet, Palo Alto, CrowdStrike, SentinelOne, AWS, Azure, VMware, backup tooling, endpoint management, and identity management. That is valuable.
Public safety platform fluency is different. Platform fluency means understanding how the technology behaves inside the operation.
A public safety technologist needs to understand how CAD call types drive response recommendations, how unit status affects dispatch visibility, how RMS validation affects NIBRS reporting, how mobile data clients consume CAD and RMS information, how evidence storage and redaction affect discovery, how JMS booking interfaces affect court and medical workflows, how radio fleet maps and encryption keys affect mutual aid, how CAD-to-CAD, NG911, ALI/ANI, GIS, AVL, paging, and station alerting interact, and how a small configuration change can alter an entire shift's workflow.
The Bureau of Justice Assistance's RMS guidance describes RMS as supporting incident reports, arrests, warrants, case management, field contacts, internal affairs, crime analysis, interfaces, administration, and reporting. That is not a normal business application. That is the agency's operational and legal record environment.
That fluency is not built in a quarter. It is built by sitting through implementations, watching dispatch floors, managing vendor escalations, handling configuration drift, living with bad interfaces, learning how records staff actually validate data, and understanding how every “minor” change becomes operational when the system is live.
This connects directly to the bench problem we have written about elsewhere. Even when a generic MSP wants to build public safety fluency, the path is long, expensive, and hard to retain. The people who gain that expertise become valuable to vendors, large agencies, and specialty firms. The generic MSP either cannot keep them or cannot spread them across enough accounts to make the model work.
Public safety platform fluency is not knowing where the server lives. It is knowing what happens on the floor when the workflow breaks.
The Priority Model Mismatch
This is one of the most visible failure points.
A generic MSP triages tickets using a corporate impact model. Priority one might mean many users affected. Priority two might mean one department affected. Priority three might mean a single user. The structure makes sense in corporate IT.
In public safety, impact is not just volume. It is consequence. A CAD issue affecting one dispatcher at 0200 may matter more than an email issue affecting twenty administrative users at 0900. A mobile data issue affecting patrol during a high-priority incident may matter more than an office outage. A radio logging issue may look minor until an incident review, a lawsuit, or a discovery request asks what was said and when.
When a dispatch-impacting ticket lands in the same queue as a corporate endpoint issue, the floor notices. First, they wait. Then they call instead of opening tickets. Then they text the one person who usually fixes things. Then they create workarounds. Then they stop trusting the support model. Once that happens, the agency loses its issue record because people stop using the system designed to document the issue.
That is why Sentinel Response™ was designed differently. The priority model has to reflect mission impact, not just corporate user impact. Sentinel's Managed Technology Services model is built around the realities of CJIS environments, 911 center uptime expectations, and the specific vendor stacks agencies actually run, not repackaged enterprise IT.
The moment the dispatcher believes the ticketing system does not understand the floor, the agency has already lost the support model.
The DR And Continuity Gap
A generic disaster recovery plan can look excellent on paper and still be wrong for public safety.
Corporate DR often assumes some amount of productivity loss is tolerable. Email is down for a few hours. File shares restore by morning. A business unit operates manually for a day. Public safety does not have that luxury.
A dispatch floor cannot go dark. A 911 center cannot wait for Monday. A jail booking workflow cannot simply pause. A records system may have manual fallback, but the fallback has to be drilled, staffed, documented, and reconciled. A radio system failure needs an operational failover path, not just a vendor callback.
The DR model changes at every layer. RTO and RPO targets are tighter. Redundancy has to include operational workflow, not just infrastructure. Failover has to be tested with dispatchers, supervisors, vendors, and neighboring agencies. Alternate ECC or PSAP procedures must be defined. Data reconciliation has to be planned. Public notification responsibilities must be known. Vendor escalation has to be integrated into the drill. Manual-mode procedures must be more than a binder on a shelf.
CISA's guidance for cyber disruptions in evolving 911 environments specifically recommends that emergency communications centers update continuity-of-operations plans for cyber disruption events, identify alternate emergency communications centers, maintain data, and engage partners and stakeholders. NENA's PSAP disaster and contingency planning guidance also tells PSAP authorities to consider technical and operational security impacts when implementing disaster, recovery, and contingency plans.
The April 2014 multistate 911 outage is a useful reminder that public safety reliability failures are not theoretical. The FCC's report on that event said it demonstrated the need for vigilant oversight of how public safety and service providers manage NG911 deployment during the transition from legacy systems to all-IP systems.
Public safety disaster recovery is not the art of restoring systems. It is the discipline of keeping the mission alive while systems are failing.
The Vendor Ecosystem Gap
A generic MSP usually lives in a corporate vendor ecosystem. Microsoft, AWS, Azure, Cisco, Palo Alto, Fortinet, CrowdStrike, SentinelOne, Dell, HP, backup vendors, endpoint vendors, identity tools, and cloud providers.
A public safety technology partner lives in a different ecosystem. Motorola. CentralSquare. Tyler. Hexagon. Axon. Flock. FirstNet. RapidSOS. Intrado. Solacom. NICE. Eventide. State radio authorities. Regional 911 boards. State CJIS agencies. Message switch providers. State records bureaus. Local prosecutors. Courts. Jail systems. Fire RMS. ePCR. GIS. CAD-to-CAD. Regional data-sharing bodies.
That ecosystem matters because when something breaks, the fastest path to resolution is not always technical. Sometimes it is relational, procedural, and political.
Technically, those relationships unlock logs, escalation paths, interface documentation, API clarification, known-issue histories, release notes, configuration guidance, and product-specific troubleshooting. A generic MSP may be able to say, “The network is clean.” A public safety technologist has to say, “The CAD-to-mobile interface is dropping this field because the code table mapping changed after the last vendor release.” Those are different conversations.
Operationally, relationships matter because public safety escalations are rarely isolated. A radio issue may involve the regional radio authority. A CJIS issue may involve the state CJIS Systems Officer. An RMS issue may affect prosecutor discovery. A CAD outage may require notification to city leadership, neighboring agencies, and dispatch leadership. A 911 routing issue may involve the regional 911 board and telecom providers.
Generic MSPs can be excellent in their world. Public safety has its own vendor language, its own politics, and its own consequences.
Public safety support is not just knowing who to call. It is knowing what the call means, what record it creates, and who else has to know before the issue becomes political.
The Audit Defensibility Gap
Council does not read the MSP's marketing copy. Neither does the state auditor. Neither does the prosecutor. Neither does the Inspector General. Neither does a plaintiff's attorney. Neither does the city manager after a failed system event.
They read the record.
They look for ticket history, incident response notes, vendor escalation timelines, change approvals, CJIS audit responses, disaster recovery drill records, access logs, security training records, risk registers, and proof that the agency knew what was happening and acted reasonably. That is where generic MSP documentation often falls short.
The MSP may have tickets. Are they categorized by public safety system? Do they identify operational impact? Do they show vendor accountability? Do they preserve CJIS-sensitive context correctly? Do they support a council briefing? Do they support a budget request? Do they show recurring issues by platform? Do they document manual-mode response during an outage? Do they connect the ticket to operational risk?
Sentinel's position is that documentation is not a separate deliverable. Documentation is the operating posture. Most providers close tickets. Sentinel closes risks. Issues are owned, tracked, and resolved through a structured accountability model that produces a defensible record.
That is the difference.
In public safety, if the issue was not documented in a way leadership can defend, the issue was not truly managed.
What A Public Safety MSP Actually Has To Be
This is where Sentinel Sustain™ should be defined clearly. A public safety MSP is not a generic MSP with a government badge. It has to be built differently.
Sentinel Sustain is the managed technology subscription for end-to-end operations of platforms Sentinel helped stand up. Sustainment, systems administration, vendor coordination, version-upgrade discipline, and 24/7 incident response. The system must still deliver outcomes three years out because someone is still accountable for it. That is the point.
A public safety MSP has to be independent. It cannot be financially aligned to selling a platform. It has to be practitioner-led. The people governing the work have to understand the floor, the field, the command staff, the technology stack, and the politics. It has to be vendor-neutral. The agency's interest has to come first. If the vendor is underperforming, the MSP must be able to say so. It has to be CJIS-fluent by default. Not as an add-on. Not as a policy appendix. As a core operating discipline.
It has to be mission-critical in its priority model. The support model has to understand the difference between business inconvenience and operational consequence. It has to be built around documentation. Tickets, dashboards, escalation logs, after-action records, change approvals, and quarterly reviews must be standard output. It has to be connected to the actual public safety ecosystem. The partner has to understand CAD, RMS, JMS, evidence, mobile, radio, telephony, NG911, prosecutors, state CJIS, and regional governance. It has to be 24/7/365 in posture, not just phone availability. There is a difference between answering the phone after hours and being built to operate mission-critical systems after hours.
Sentinel's Managed Technology Services operate the infrastructure, security, applications, and continuity programs mission-critical agencies depend on every day, with offerings built around CJIS realities, 911 center uptime expectations, and the vendor stacks agencies actually run. The firm operates technology agencies cannot afford to lose, built by practitioners who have run dispatch floors, EOC technology stacks, and clinical IT environments. The two of us, Justin and Jason, founded Sentinel after decades of this work on both sides of the table. We have operated CAD, RMS, JMS, mobile, evidence, and radio systems from inside agencies. We have managed program deployments for vendors. We have sat in dispatch supervisor seats and project manager seats and command staff briefings. The practitioners we bring into the firm have lived the work, and every Sentinel practitioner is mentored and guided by one of the founders. That is structural, not aspirational.
We operate as a small firm by design. That is the source of our agility and the source of our depth. Every Sentinel customer has the backing of the whole firm, including both founders, because the firm is small enough that nothing happens at scale without the founders knowing about it. The agency does not get a junior account manager and an offshore queue. The agency gets a practitioner working their environment, with a senior bench standing behind that practitioner, and with the founders accessible when the situation requires founder-level engagement.
Independent. Practitioner-led. Vendor-neutral. While the phases move, Sentinel stays.
A public safety MSP is not the firm that answers the phone. It is the firm that understands what the call means before the agency has to explain it.
The Cost Case
Yes, Sentinel-tier services cost more than generic MSP services. We should not run from that.
The agency is not buying a premium SKU of the same product. It is buying a different product entirely.
Generic MSP pricing is built around corporate IT economics. Per-user support, endpoint support, help desk volume, cybersecurity stack, remote monitoring, and administrative cloud systems. Current market guides commonly place managed IT services somewhere around 100 to 400 dollars per user per month depending on scope, with professional or advanced consulting often billed hourly in the 100 to 300-plus dollar range. That may be completely reasonable for the work.
If the agency buys generic MSP coverage and then still has to pay CAD vendor admin hours, RMS vendor professional services, radio vendor support, evidence platform configuration assistance, internal overtime, after-hours staff troubleshooting, emergency consulting, and eventual remediation when the support model fails, the agency did not save money. It paid twice.
The honest comparison is not “generic MSP versus Sentinel.” The honest comparison is laid out below.
| Model | What The Agency Thinks It Is Buying | What The Agency Actually Carries |
|---|---|---|
| Generic MSP, Public Safety Bolt-On | One managed services contract covering everything, with a “government tier.” | Strong corporate IT support, weak public safety platform coverage, the accountability gap between vendors, generic priority model, business-continuity DR, audit documentation that does not survive scrutiny, and the eventual cost of remediation. |
| Generic MSP Plus Vendor Hours | MSP coverage plus per-vendor professional services as needed. | Two cost categories instead of one, narrow vendor-specific knowledge, separate portals, separate tickets, limited cross-system ownership, vendor incentive misalignment, and the same accountability gap at every system boundary. |
| Public Safety MSP (Sentinel Sustain™) | A managed technology subscription built for the public safety operating model. | Cross-system practitioner coverage, vendor-neutral ownership, CJIS-fluent operating discipline, mission-critical priority model, public-safety DR posture, audit-defensible documentation, Sentinel Response™ ticketing included, and one accountable partner across the operational stack. |
The agency can do its own numbers. The real comparison is rarely “the price of Sentinel” against “the price of the generic MSP.” It is the price of the generic MSP plus vendor admin hours plus internal overtime plus unresolved public safety tickets plus weak documentation plus remediation plus the political cost of failure, weighed against a public safety sustainment model designed to carry the operational stack from the beginning.
A cheaper MSP is only cheaper if it can carry the work. If it cannot, the agency pays once for the contract and again for everything the contract could not do.
The Closing Position
Generic MSPs have an important place in public agencies. They can support the administrative technology environment well. They can stabilize office IT, improve endpoint hygiene, reduce help desk burden, and modernize general infrastructure.
Public safety is not administrative IT. Public safety is the work that cannot wait.
That is why the category matters. The dispatch floor, the jail, the radio system, the RMS, the evidence platform, the NG911 environment, the mobile data environment, and the CJIS record are not simply technology assets. They are operational infrastructure. The agency that treats them like ordinary IT will eventually learn the difference. The lesson usually arrives during an outage, an audit, a budget hearing, a failed escalation, or a critical incident.
A generic MSP and a public safety MSP are not on the same product ladder. They are different categories of firm doing different work. The agency that mistakes one for the other will pay the difference twice. The MSP that protects email is not the MSP that protects the dispatch floor. Those are different systems, different failure modes, different consequences, and different operating disciplines.
Sentinel governs the operational technology. We never sell the platforms. Independent. Practitioner-led. Vendor-neutral. Built by founders who have led the work, staffed with practitioners mentored by those same founders, operated as a small firm where every agency has the backing of the whole bench. While the phases move, Sentinel stays.
If you are an agency that has spent the last twelve months trying to get answers from a generic MSP about a CAD interface that keeps failing, this is the structural alternative. If you are an agency where the IT director cannot produce a defensible record of the last twelve months of public safety technology support, this is the structural alternative. If you are an agency where CJIS audit prep means a fire drill instead of a routine artifact pull, this is the structural alternative.
Generic MSPs are built for the work that can wait. Public safety is the work that cannot. That is the category Sentinel was built to carry, and it is the category the work has always required.