Public safety agencies depend on technology more than ever, but increasingly, they don’t fully control it.
SaaS vendors host critical systems. Integrations connect core workflows. Third parties often maintain privileged access to operational environments. When something goes wrong at a vendor, it doesn’t stay contained. It shows up in dispatch queues, investigative timelines, and public communications.
In public safety, third-party risk is operational risk.
Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled from 15% to 30%. As agencies rely more heavily on cloud platforms and interconnected systems, that trend carries different implications for this sector. A vendor incident can impact life-safety operations, investigative integrity, and community trust, not just IT uptime.
Public safety organizations don’t need a radically different Third-Party Risk Management (TPRM) framework than other sectors. But they do need different weighting.
Here are four areas that deserve elevated priority.
- Mission Resilience and Operational Continuity
For most industries, availability is a business metric. For public safety, it is a safety requirement. When a core service is disrupted, the question isn’t “How long until the ticket is resolved?” It’s “How do we operate right now?”
Recent cyber attacks and incidents illustrate how vendor dependencies can quickly become operational constraints. Even when 911 call-taking remains functional, loss of public notification systems or supporting integrations changes how agencies manage fast-moving events. Generic SaaS uptime guarantees aren’t enough for public safety. Agencies should expect clear answers to operationally relevant questions:
- What are the recovery time objectives (RTO) and recovery point objectives (RPO)?
- How often is disaster recovery tested?
- What does outage communication look like in practice?
- What documented continuity or degraded-mode workflows exist?
Importantly, vendors should be tiered by mission impact. Dispatch, records and evidence systems should not be governed the same way as low-impact business tools.
- Sensitive Data Protection and Compliance Obligations
Public safety data is uniquely consequential: criminal justice information, victim and witness details, intelligence and investigative records, sensitive location data, and often health-related information in EMS contexts. Exposure doesn’t just create reputational damage; it can compromise investigations, endanger individuals, trigger mandatory notifications and audits, or lead to litigation. That’s why public safety TPRM can’t stop at a security questionnaire; it must confirm that the vendor’s controls are real, operating, and enforceable.
CJIS expectations are a prime example. The CJIS Security Addendum binds contractors to a security program consistent with CJIS policy, effectively extending core security requirements to vendors. The CJIS Security Policy itself reinforces that criminal justice information requires secure access to services and controls; agencies can’t meet those expectations if vendors are out of scope.
Real-world incidents reinforce this point. In January 2026, the Anchorage Police Department took servers offline and disabled vendor access following a cyber incident involving that technology service provider. Even without confirmed data acquisition, the response demonstrated a critical reality: vendor access pathways must be controllable, severable, and auditable on short notice.
For vendors handling sensitive data, agencies should prioritize:
- Strong identity and privileged access controls (MFA/SSO where possible, least privilege, well-governed support access)
- Clear encryption and key management practices
- Tenant segregation validation for multitenant SaaS environments
- Transparent subprocessor disclosures
- Explicit contractual language around incident notification timelines, cooperation requirements, and data-handling limitations around data retention, deletion, and secondary use
- Integrity, Auditability, and Defensibility of Records
Public safety technology systems don’t just store data; they create records that must be defensible in court.
If you can’t demonstrate who accessed, modified, exported, or deleted a record, and when, you don’t just have a security issue, you likely have an evidentiary or a governance problem.
Integrity must be treated as a first-class third party risk category.
The Public Safety Threat Alliance (PSTA) reported that extortion attacks against public safety answering points doubled in 2024, with increased year-over-year disruption. Attacks impacting dispatch and enterprise networks can spread to connected NG911 systems, creating both continuity and integrity risks.
As disruptive attacks increase, agencies are more likely to need defensible audit trails to reconstruct events, validate record integrity, and support investigations and legal scrutiny.
“We have logs” is not the same as “We can use these logs to defend actions and data handling under scrutiny.”
Agencies should require:
- Evidence-grade audit trails, including admin and support actions
- Tamper resistance and clear chain-of-custody controls
- Log retention aligned to investigative and legal timelines
- Controlled export and deletion workflows
- The ability to produce logs quickly during incidents or inquiries
- Ecosystem Dependency Risk, Integrations, and Vendor Change
Modern public safety environments are increasingly interconnected.
Integrations, APIs, service accounts, data pipelines, and identity federation, create powerful capabilities, but they also create concentrated risk. A vendor can be small in spend yet large in operational impact if it maintains persistent access into core systems.
NIST’s supply chain risk management guidance explicitly frames the need to identify, assess, and mitigate cybersecurity risks throughout the supply chain, not just at the primary vendor layer.
CISA’s 2025 guidance for 911 centers similarly highlights that new technology integration expands threat vectors and that increasing interconnection can broaden the attack surface.
For public safety agencies, that means managing more than just a vendor list. It means managing access pathways. The more systems you connect, the more you need to govern the connections, not just the vendors.
A mature TPRM program should:
- Maintain an inventory of integrations and service accounts (not just vendors)
- Limit token scope and enforce rotation practices
- Require subprocessor disclosure and material change notifications
- Assess how vendors manage their own dependencies (cloud hosts, monitoring tools, subprocessors)
- Plan for vendor exit and data portability before it becomes urgent
Vendor acquisition, platform migrations and upstream supply chain events are common. In public safety environments, they can create immediate operational and compliance consequences.
Public safety organizations don’t need a radically different TPRM framework, but they need different prioritizations. Viewed through a public safety lens, four categories rise to the top:
- Operational continuity
- Sensitive data protection
- Record integrity and defensibility
- Ecosystem and dependency risk
The strongest programs treat TPRM as a lifecycle capability, not a procurement checklist. They tier vendors by mission impact, validate controls with evidence, enforce expectations contractually, monitor continuously, and maintain the ability to quickly contain vendor access when conditions change.
Is your agency assessing third-party risk through a public safety lens? Reach out to learn how the Mark43 Public Safety Platform can help safeguard your mission-critical systems, sensitive data, and ensure operational continuity and explore our Trust Center.
