Home/Resources/Why E911 compliance decays

Resources · E911 and MLTS compliance

Compliance is not a project outcome. It is a state that decays.

A deployment that passed testing on the day it went live can be non-compliant within a quarter, without anyone changing the phone system.

The mechanism

Dispatchable location depends on a mapping between a device and a physical place — a building, a floor, often a wing or corridor. That mapping is accurate at the moment it is built and is invalidated by ordinary operational activity thereafter.

Nothing in the phone system detects this. A desk phone moved two floors up still registers, still dials, still completes calls. It simply reports the wrong floor to the answering point, and it will keep doing so until someone reconciles the location database against reality.

This is why compliance frequently looks fine from a configuration screen and is not. The configuration is unchanged. The building is what moved.

What actually causes the drift

  • A department relocates to a different floor and the handsets go with it, unremapped.
  • A batch of devices is redeployed from storage to whichever desks needed them, with no record of where they landed.
  • A wing is reconfigured or renumbered, so the location labels in the database no longer describe the building.
  • New soft clients and mobile devices are added by users rather than provisioned centrally, so they never enter the location mapping at all.
  • Staff turnover removes the only person who understood how the location data was structured.

None of these are failures of discipline. They are normal operations. The problem is that the compliance obligation is coupled to physical reality while the change processes that alter physical reality do not treat E911 as a stakeholder.

The governance cycle

What keeps it in place instead.

01

Annual validation

Test 911 calls placed from each site with the answering point's agreement, rather than a configuration screenshot standing in for evidence.

02

Change control

Moves, adds and changes trigger a location review as part of the change process, not after someone notices.

03

Record maintenance

ELIN and ALI records reconciled against the actual estate, so the database describes the building as it is now.

04

Regulatory review

Obligations re-checked when the underlying rules change, rather than assumed static.

Questions that establish whether you have drifted

These four tend to expose the gap faster than an audit, because they ask about process rather than configuration.

  • When a department relocated last quarter, did anyone update the location database — and is there a process that would have made that automatic?
  • Has a test 911 call been placed from each site since deployment, with the answering point's agreement?
  • Does your change-management process name E911 location data as an affected system?
  • If the person who built the location mapping left tomorrow, could anyone else reconcile it?

An organization that can answer the third question yes usually has not drifted far. An organization whose only evidence is a deployment-day acceptance document usually has, and will not know by how much until someone checks.

Why this is a governance budget, not a project budget

Treating compliance as a project produces a correct estate on handover day and an unknown one eighteen months later. The remediation cost then recurs, because each cycle rediscovers drift that governance would have prevented.

The practical consequence is that the ongoing cycle is usually the cheaper line item of the two, and the one most often cut first.

Related

Where to go next.

Establish where the estate actually stands today.

The free multi-site assessment reviews your position across every site under both statutes, including how far the location data has drifted since deployment.