top of page
Search

Your emergency services database is wrong. Here's why, and why it matters more than ever.

  • 1 hour ago
  • 4 min read

Two fines in the space of three months. One for £122,500. One for £700,000. Both in 2025. Both related to failures in how VoIP providers handled emergency location data.


If you're an Operator Connect or Direct Routing provider delivering Microsoft Teams Phone services, these cases should be on your radar, because the underlying problem they expose isn't just about outages or misconfigured systems. It's about a structural gap in how emergency location data is maintained for voice users. And that gap is sitting, largely unaddressed, in the middle of most carriers' customer bases right now.



What the law requires


Across virtually every major market, telecoms regulators require providers to make accurate and reliable caller location information available to emergency services for all emergency calls, to the extent technically feasible. In most jurisdictions that obligation goes further still: where a service is provided at a fixed location, the registered address must accurately reflect where the end-user's equipment actually is.


This isn't a best-endeavours obligation. It's a requirement that the right address is in the right database at the point the emergency call is answered.


What recent enforcement tells us


A major UK provider was fined £122,500 for providing either inaccurate or no caller location information for emergency calls made by its VoIP customers over a two-year period. That's 948 calls. No members of the public experienced significant harm. The provider self-reported the issue. They still received a six-figure fine.


The regulator's finding was explicit: the provider had failed to test or monitor the availability of accurate caller location information either before launching its VoIP service or while it was live, and had failed to ensure a third-party supplier had correctly configured the relevant systems.


The lesson isn't just about testing and monitoring. It's about what happens when the data pipeline between a customer's actual location and the operator's emergency services database breaks down quietly and invisibly over months or years.


The Teams Phone problem nobody is talking about


Microsoft Teams Phone has become the dominant enterprise voice platform across major markets worldwide. Carriers delivering PSTN connectivity through Operator Connect and Direct Routing are at the heart of that ecosystem, and both programmes create a compliance challenge that didn't exist in the PSTN era.


When a number was tied to a physical line, the address in the emergency services database matched where the line terminated. It was right by definition. With Teams Phone, there's no such relationship. The address registered against a number in the carrier's emergency services database is whatever the customer provided at provisioning, and it stays that way until someone actively changes it.


In practice, that means:


  • Users who've moved offices, sites, or cities since their number was first set up

  • Customers who update location assignments internally in Teams but never think to inform their carrier

  • Organisations where no one is sure who is even responsible for keeping the operator updated

  • Customers who provided an address at onboarding and have never revisited it since


The Operator Connect or Direct Routing provider has no visibility into any of this. They're entirely reliant on the customer notifying them. Many never do, not out of negligence, but because the process for doing so simply isn't front of mind.


The compliance exposure


Emergency location obligations in most markets contain no carve-out for "the customer didn't tell us." The obligation sits with the regulated provider. And recent enforcement has demonstrated clearly that inaccurate location data, not just absent location data, is sufficient to attract a significant fine, even when no harm has occurred and the provider has cooperated fully with the investigation.


The direction of travel across regulators globally is towards greater scrutiny, not less. Carriers who cannot demonstrate active management of their emergency location data are exposed.


What good looks like


The ideal state is an automated, real-time connection between wherever customers manage location assignments for their numbers and the carrier's emergency services database. When a location is updated in Teams, that change propagates immediately upstream. No manual process. No dependence on customer memory. No accumulating drift between the address on record and the address that's actually current.


This is precisely what Haptap Call Manager does as part of its Teams Phone management platform. When a user's location is updated within Teams, Call Manager automatically notifies the upstream Operator Connect or Direct Routing carrier, keeping their emergency services database current. It's not the platform's headline feature. Call Manager is built primarily for bulk user management, number assignment, call flow automation, and governance at scale. But it directly addresses one of the most underappreciated compliance risks in the Teams Phone ecosystem.


The bottom line for carriers


If you're delivering Teams Phone services through Operator Connect or Direct Routing, it's worth asking a direct question: how confident are you that the emergency addresses registered against your customers' numbers reflect where those users actually are today?


If the honest answer is "less confident than I'd like," that gap has a regulatory value attached to it. Regulators have shown they will quantify that value in the form of a fine, even when no harm has occurred and the provider has cooperated fully.


The good news is that it's a solvable problem. And solving it is increasingly a differentiator, not just a compliance cost.


Haptap Call Manager is a white-label Microsoft Teams Phone management platform for Operator Connect carriers, Direct Routing providers, and MSPs. To find out more or book a demonstration, book directly on this page

 
 
 

Comments


bottom of page