Public Safety Data Belongs to Public Safety. Not the Vendor.

Why secure, open access to agency data should be a fundamental right, not a feature vendors charge extra for.

‍

By Kevin Biegert

Vice President of Platform Connections, GovWorx  |  Former Deputy Director and IT Director, Jeffcom 911

‍

I spent more than a decade working in public safety, starting as a dispatcher and eventually helping lead the technology and operations of one of Colorado's busiest 911 communications centers. During that time, I learned something that has shaped how I think about technology, vendors, and the responsibility we have to the communities we serve.

Public safety agencies should never have to ask permission, or pay an additional fee, to access and use their own data.

That sounds like a pretty reasonable expectation. Unfortunately, anyone who has managed technology inside a 911 center knows it isn't always how our industry operates.

I sat on the agency side of the table. I've managed CAD systems, telephony, recording infrastructure, networks, databases, and the integrations that tie them together. I've dealt with vendors who were incredible partners and others who made accessing our own information more difficult than it ever needed to be.

And I've seen how something as simple as getting two systems to share information can turn into a months-long project involving contracts, additional licensing, proprietary interfaces, and unexpected costs.

In public safety, that isn't just frustrating. It can hold back the very innovation that makes our agencies more effective.

‍

The Data Is Ours to Steward

Every day, emergency communications centers generate an extraordinary amount of information.

911 calls, radio transmissions, CAD events, incident details, location information, response times, telecommunicator performance data, and countless other records tell the story of how an agency operates and serves its community.

These records are incredibly valuable. They help us understand what's working, identify where we can improve, train our people, support investigations, make better operational decisions, and ultimately deliver better outcomes.

They are also incredibly sensitive.

Public safety agencies have a responsibility to protect that information. We operate within strict security requirements, privacy obligations, retention policies, and legal standards. That responsibility is something I've taken seriously throughout my career.

But here's an important distinction.

Securing data and restricting an agency's ability to use its data are two very different things.

Security should control who can access information, what they're authorized to do with it, and how that access is protected and audited.

It should not become an excuse for a software company to control which other technologies an agency is allowed to use.

Our agencies are responsible for stewarding their information. Our technology vendors should help us fulfill that responsibility, not take it away from us.

‍

When Data Becomes a Business Model

One of the more troubling practices in public safety technology is the idea that vendors can charge customers additional fees simply to access or share information the customer has already paid to collect, process, and store.

Want to connect your CAD system to a new analytics platform? There's an interface fee.

Want to share call recordings with a quality assurance application? That may require another license.

Want to send operational data into a reporting solution your agency already owns? You'll need to negotiate access.

And in some cases, if the third-party application competes with something the incumbent vendor sells, the conversation becomes even more difficult.

I understand that integrations require engineering, security, maintenance, and support. Those activities have real costs. But there is a fundamental difference between charging for professional services and charging a customer for the privilege of accessing its own information.

An agency should not have to pay a toll every time its data needs to move between authorized systems.

More importantly, technology providers should not be deciding which competing solutions an agency can or cannot use.

That decision belongs to the agency.

‍

Open APIs Are About Freedom of Choice

When I talk about open APIs, I'm not talking about making sensitive public safety information openly available to the world.

I'm talking about secure, documented, standards-based methods that allow agencies to connect their systems and use their data in the ways they determine are appropriate.

Imagine a communications center that wants to use a third-party analytics platform to better understand response times. Or a new AI-powered tool to analyze call handling, support telecommunicators, or identify patterns across incidents.

That agency should be able to authorize the connection and make the appropriate data available without having to negotiate with every incumbent vendor standing between the systems.

The same should be true when connecting CAD, recording systems, training platforms, records management systems, and other operational technologies.

And yes, that includes sharing data with a competitor's product.

The agency chose that product for a reason. The vendor holding the data should respect that decision.

To me, meaningful interoperability requires more than an API existing somewhere in a product's documentation. It means the API is usable, supported, secure, and capable of providing the information agencies actually need.

It means appropriate authentication, role-based permissions, encryption, audit trails, and agency-controlled authorization.

And it means customers shouldn't face additional access fees just because they want to use their data somewhere else.

‍

Security and Openness Are Not Opposing Goals

Having worked in public safety IT and cybersecurity, I know the first objection people raise when discussing open data access: What about security?

It's a fair question. And the answer cannot be to weaken security controls.

Public safety information isn't ordinary business data. It can include criminal justice information, personally identifiable information, medical details, and records that demand careful handling.

Open APIs must be designed around those realities.

Agencies need to determine which data is shared, with whom, for what purpose, and under what conditions. Access should be authenticated, limited to what is necessary, monitored, and revocable.

Sensitive information should never be available simply because an integration exists.

But strong security architecture should make authorized interoperability possible, not prevent it.

In fact, well-designed APIs with consistent access controls and detailed audit records can be far safer than the workarounds agencies sometimes resort to when vendors make information difficult to obtain.

We shouldn't force agencies to choose between protecting their data and putting it to work.

We can, and should, do both.

‍

Innovation Happens When Agencies Have Choices

Public safety technology is entering a period of significant change.

AI is creating opportunities to improve call handling, quality assurance, training, resource recommendations, operational intelligence, and many other functions.

But none of these systems can reach their full potential if the information they need remains trapped in proprietary silos.

The future of public safety technology won't be built by one vendor doing everything.

It will be built by agencies choosing the systems that work best for their operations and being able to connect those systems securely and reliably.

Some agencies will want tightly integrated platforms. Others will want to combine solutions from multiple providers. Most will likely do some of both.

That's exactly how it should be.

A vendor should earn an agency's business because its technology delivers better outcomes, not because it has made accessing data or switching systems prohibitively expensive.

‍

A Commitment Worth Making

This philosophy is one of the reasons I joined GovWorx.

We believe the data an agency entrusts to our platform, along with the agency-specific information and outputs it generates, should remain under that agency's control.

And we're committed to building our platform around secure, open APIs that give customers access to their data without additional API access fees.

If an agency wants to share that information with another authorized system, we should help make that possible.

If that system happens to be offered by a company we compete with, the answer should be the same.

Our responsibility is to protect the data, make it accessible through appropriate security controls, and respect the customer's decisions about how it is used.

That's the standard I wanted from technology partners when I was working inside a 911 center. It's the standard I believe our industry should expect today.

For too long, public safety agencies have had to adapt their operations around the limitations and business models of their technology vendors.

It's time to reverse that relationship.

Your agency. Your data. Your choice.

That's not a premium feature. That's how public safety technology should work.

‍

‍

ABOUT THE AUTHOR

Kevin Biegert is Vice President of Platform Connections at GovWorx and previously served as Deputy Director of Information Technology and IT Director at Jeffcom 911 in Colorado. His public safety career includes frontline emergency dispatch, IT leadership, cybersecurity, and emergency communications technology modernization. In 2021, he was recognized by APCO International as its Information Technologist of the Year. Kevin advocates for secure interoperability, agency data stewardship, and removing the technical and commercial barriers that limit public safety innovation.

‍