BTW Media Intelligence

Summary

Ofcom's final enforcement record says BT's emergency call handling service was disrupted from 06:24 to 16:56 on 25 June 2023. The incident affected about 14,000 emergency calls and included approximately one hour of total outage. BT was the national call-handling provider connecting 999 and 112 callers to emergency authorities, so failure inside one operator's platform became a countrywide public-network continuity problem. [1][2][3]
The regulator divided the incident into three phases. A configuration-file error first disrupted the primary platform. BT's initial transfer to disaster recovery then failed because instructions were poorly documented and the team was unfamiliar with the process. Traffic was eventually moved, but the backup platform lacked enough capacity and functionality to restore normal service immediately. [1][2][3]
BT's earlier public review described a complex software caching issue and three primary clusters, while Ofcom's later decision identified a configuration error in a media-server file. Those accounts should not be blended into an invented root cause. The final regulatory description controls the article's finding; BT's language remains an attributed operator account. [2][7]
Official impact figures measure different things. Ofcom reported nearly 14,000 unsuccessful attempts from 12,392 callers. The government review reported 9,641 unique callers unable to access 999 or 112, with many more delayed or disrupted. These numbers are compatible with different counting methods, but the public sources do not provide enough detail to collapse them into one metric. [3][4][5][6]
Ofcom found that BT failed to take appropriate and proportionate measures to prepare for an availability compromise, specifically by lacking adequately defined and tested procedures and an appropriate backup system. It imposed a GBP 17.5 million penalty for breaches of section 105A(1)(c) of the Communications Act 2003 and Regulation 9 of the 2022 Security Measures Regulations. The statutory term "security compromise" includes loss of availability and does not mean that Ofcom found a cyberattack. [1][2][3][10][11]
No serious harm was confirmed by emergency authorities, but Ofcom judged the potential harm extremely significant. Text relay disruption also put deaf and speech-impaired users at increased risk. The evidence supports an accessibility and public-safety risk finding, not an unsupported claim about a specific death, injury or medical outcome. [1][3]
Accountability follows practical control. BT controlled platform configuration, alarm coverage, failure-domain design, failover procedures, backup capacity, call-handler continuity and repair evidence. Government and emergency authorities controlled system-wide plans, public instructions, oversight and exercises. Other communications providers controlled originating-network tests and customer communication. Ofcom controlled investigation, enforcement and public follow-up.

The national 999 path was network infrastructure, not an application feature

The first accountability question is architectural: what service was BT operating, and where did public dependence converge?

BT did not merely provide a customer-facing telephone application. It operated the emergency call handling service that received 999 and 112 traffic and transferred calls to the police, fire, ambulance or coastguard authority required by the caller. It also provided relay functions that gave people with hearing or speech difficulties a path to emergency and non-emergency communications. That role placed BT inside a national public-network chain whose useful outcome was not a ringing tone or an available process. The useful outcome was a call answered by a trained handler and successfully transferred to the appropriate emergency authority.

[1][2][3]

This distinction matters because infrastructure assurance must follow the complete service path. An originating mobile or fixed network can be healthy while the national handling platform is unable to accept or transfer a call. A server can be running while agent sessions restart when a call arrives. A disaster-recovery site can be reachable while its capacity is too low for the traffic it must absorb. A platform dashboard can show partial restoration while callers still wait, retry or fail. Availability at any one layer is therefore an incomplete measure of emergency access.

BT's central role also concentrated operational authority. The company controlled the primary emergency call handling platform, the disaster-recovery environment, the switch procedure, the agents' technical environment and the information it supplied to Ofcom and government during the incident. Emergency authorities controlled their own receiving operations and local response. Other communications providers controlled the delivery of originating traffic toward the national service. Government controlled broader oversight and cross-system coordination. These responsibilities were connected, but they were not interchangeable.

Centralization is not automatically a defect. A national handling service can standardize transfer, location, accessibility and operational practice. It can concentrate expertise and make a single set of interfaces easier to govern. The accountability cost is that the shared point must meet a correspondingly high evidence standard. It needs failure domains that remain independent under the changes that actually occur, a backup that can carry realistic national demand, alarms that identify service degradation rather than only component health, and procedures that operators can execute during pressure.

This is also why the incident fits a network-infrastructure accountability target without rhetorical stretching. Remove call routing, node design, shared configuration, disaster recovery, traffic capacity and operator transition from the story, and the central failure disappears. What remains would not explain why thousands of people could not reach emergency services. The network control plane is not an analogy here. It is the causal path.

Three phases reveal three different control failures

A single outage duration can obscure the operational sequence. Ofcom's three-phase chronology separates the initial platform disruption, the unsuccessful recovery attempt and the constrained backup operation. Each phase points to a different set of controls.

Phase 1 ran from 06:24 to 07:33. Ofcom found that a configuration error in a file on a server disrupted the emergency call handling system. Agent systems restarted when calls were received. Agents could be logged out. Calls could be disconnected or dropped while being transferred, or returned to the queue. BT could see that the service was failing but could not initially determine the cause. It attempted to move service to the disaster-recovery platform. [2][3]

This phase tested detection and diagnosis. A critical service needs alarms tied to public outcomes: call-answer rate, transfer success, unexpected agent restarts, repeated logouts, queue recycling, text relay success and destination completion. Component alarms are still useful, but they are limited public evidence if the software can remain technically alive while every received call triggers a disruptive state change. BT's review said the expected alarms did not make the affected primary cluster clear.

Ofcom later found inadequate warning systems and inadequate procedures for assessing severity, impact, likely cause and possible mitigation. [3][7]

Phase 2 ran from 07:33 to 08:50. The first attempt to move service to disaster recovery was unsuccessful because of human error. Ofcom connected that error to poorly documented instructions and a team unfamiliar with the process. The service moved from partial disruption into total outage. During this period, a person trying to call 999 or 112 could not connect to a BT call handling agent. [2][3]

This phase tested execution. A disaster-recovery design is not complete when equipment exists or a runbook is stored. The people on duty must recognize when to invoke it, understand which state the primary platform is in, follow an unambiguous sequence, detect a wrong choice, reverse or correct it safely, and verify that traffic has moved. The process must work while demand is rising, public consequences are severe and technical information is incomplete.

Phase 3 ran from 08:50 to 16:56. Traffic had moved successfully to disaster recovery, and the rate of unsuccessful calls fell, but ordinary service was not immediately restored. The backup platform struggled with demand. Ofcom found that its capacity and functionality were inadequate for a level of traffic that might reasonably be expected. [2][3]

This phase tested capacity and degraded-mode design. A backup may be acceptable if it preserves essential service even when normal features are reduced. But the reduction must be deliberate, bounded and consistent with the service's public function. Emergency calling generates predictable retry behavior: when a call fails or remains unanswered, callers often try again. The backup design must account for that feedback, not only steady-state average traffic. It must also preserve accessibility paths and the ability to transfer calls, not only accept them.

The three phases prevent a misleading root-cause narrative. The configuration error explains the start. It does not explain why detection and diagnosis were weak, why the first recovery step failed, or why the backup could not carry demand after the transfer succeeded. Those later effects were prolonged by controls within BT's authority. Ofcom said so explicitly when it linked the incident's scale and impact to absent operational and incident procedures and to reduced disaster-recovery capacity and functionality. [1][2]

The sequence also provides a practical test for remediation. A credible exercise must reproduce all three challenges: an ambiguous primary-platform failure, a decision to transfer under uncertainty, and high demand on the backup. Testing only a clean planned switchover would miss the conditions that made this incident difficult.

The final root-cause record must remain separate from BT's earlier account

Public incident narratives evolve. Early operator statements are often based on incomplete evidence; later regulator findings may use documents and interviews that are not public in full. Responsible analysis should show that evolution rather than select whichever phrase appears most technical.

BT's public review described a "complex software caching issue" in the primary emergency call handling platform. It said the service used three primary clusters with a high level of resilience and that any one cluster could handle the full national load. The review also said alarms did not make clear which cluster was affected. During recovery, responders selected a primary cluster that was itself faulty, contributing to the unsuccessful first move. BT reported that landline traffic moved to disaster recovery by 08:37 and mobile traffic by 08:50. [7]

Ofcom's later non-confidential decision identified an error in a configuration file in a media server within the main platform, controlling message services associated with emergency calls. The decision described a main platform with three identical nodes, each intended to process all traffic, and a separate disaster-recovery platform. It also contained the evidence supporting the regulator's legal findings and penalty. [2]

The two descriptions can coexist at their proper level. A caching behavior may have been part of BT's technical understanding, while a configuration-file error is the final public regulatory finding. The sources available to the public do not show enough low-level detail to assert how the file, cache, message service and node behavior interacted. It would be unsound to manufacture a chain such as "an engineer changed a cache parameter across all nodes" unless the decision actually established each element. It would be equally unsound to ignore the final decision and repeat only BT's preferred phrasing.

The article should therefore use a hierarchy of claims.

First, Ofcom confirmed a configuration-file error in a media server and linked it to the primary emergency call handling disruption. That is the root-cause statement supported by the final enforcement record.

Second, BT had earlier described the issue as a complex software caching problem and had supplied architectural and restoration details. Those are attributed operator statements that add context but do not override the regulator.

Third, the public record leaves important questions unanswered. It does not identify a supplier, an individual operator, the complete change ticket, the exact configuration key, the full alarm stream or every node transition. Those items should be requested as evidence rather than filled in by inference.

This hierarchy is more than cautious wording. It assigns responsibility to evidence owners. BT can disclose configuration history, test results and internal review. Ofcom can explain the basis of its findings within legal limits. Government can publish progress against systemic recommendations. Outside analysts can compare these records and identify gaps. No one should turn uncertainty into an accusation against an unnamed person or vendor.

The same discipline rejects a cyberattack frame. The statutory regime uses "security compromise" broadly to include anything that compromises availability, performance or functionality. Ofcom's finding was about preparation for an availability failure. The public sources describe a technical fault. They do not report hostile access, malicious configuration or an external actor. Calling the event a cyberattack would confuse a legal term with an unsupported cause.

Three primary nodes did not establish three independent failure domains

BT's architecture included three primary nodes, and each was intended to carry all emergency call traffic. On paper, that provides spare capacity and multiple operating instances. The incident shows why component count is not sufficient evidence of resilience.

The nodes were described as identical. Identical systems can be easier to operate, patch and scale, but they can also share susceptibility. A configuration-file error can propagate through a common deployment process or affect software that behaves the same way everywhere. A shared message service can create a common control surface. A common management plane can apply the same mistaken state to nominally separate nodes. The public record does not establish exactly which of these propagation paths occurred, so the article should not select one.

It does establish the more important outcome: the primary arrangement did not prevent nationwide service disruption.

Independence has to be defined against plausible causes. Geographic separation addresses site loss but not shared configuration. Separate hardware addresses some component faults but not identical software behavior. Spare compute capacity addresses demand but not a control-plane error. Multiple instances address random failure but may not address an update applied everywhere. A sound design documents which failure classes each layer can contain and where common dependencies remain.

For emergency calling, this analysis should include at least six dimensions.

Configuration independence: Can a bad file, policy or rollout affect every primary node at once? Are changes canaried, validated and reversible? Does a known-good configuration remain outside the normal deployment path?

State independence: Can bad runtime state spread or synchronize? Are message stores, caches, databases and queues isolated enough that one condition does not impair all nodes?

Monitoring independence: Can operators see service outcomes even if the affected platform's own telemetry is misleading or incomplete? Are synthetic 999 and 112 tests run from multiple networks?

Operational independence: Can responders isolate, drain or bypass a node without relying on the same console or procedure that is failing?

Recovery independence: Does disaster recovery use sufficiently separate configuration, software state and operational access to survive the primary cause?

Capacity independence: Can the remaining path absorb retries and surge demand, rather than only normal average volume?

A platform can satisfy some of these and fail others. The right accountability question is not "Did BT have redundancy?" The public record already shows that it did. The question is "Which failure classes was that redundancy proven to contain before the incident, and which tests now prove it contains the configuration and transition failures that occurred?"

As an analytical analogy rather than a source-established fact about every system, this distinction can matter across network infrastructure. DNS platforms, BGP route-control systems, mobile cores, authentication services and emergency call chains can use multiple instances behind a common control plane. The visible data-plane count can then be high while the number of independent management domains is one. Audit should therefore follow deployment authority and shared state, not only topology.

Disaster recovery was a capacity and operability claim

The existence of a separate disaster-recovery platform was a necessary control. The incident showed that existence alone was not enough.

The first transfer failed. Ofcom attributed the immediate mistake to human error and identified poorly documented instructions and unfamiliarity with the process. That finding should not be read as permission to stop at individual blame. A critical recovery procedure is a designed interface between people and infrastructure. Its clarity, validation, rehearsal, permissions, observability and error recovery are organisational controls. If trained responders can make a predictable wrong selection under pressure, the procedure and tooling deserve examination.

The operational test should ask what the responder saw. Was the health of each primary node displayed clearly? Did the interface distinguish a node that was available from one that was safe to receive traffic? Did the runbook identify prerequisites and rollback points? Did the tool prevent an invalid destination? Could another operator verify the choice? Did the team rehearse the exact unplanned transfer, or only planned maintenance? The public decision does not answer these questions, so they remain evidence requests rather than conclusions.

Once the transfer succeeded, capacity became the next issue. The disaster-recovery platform reduced failed calls but struggled with demand. Ofcom found limited public evidence capacity and functionality for a reasonably expected level. A backup used for a national emergency service cannot be sized only for a quiet-day average if failure itself causes retries, duplicate attempts, longer handling times and public uncertainty. The demand model must include incident behavior.

Capacity also has several meanings. Compute and network throughput are obvious. Agent concurrency, queue depth, transfer interfaces, relay services, logging, location support and downstream emergency-authority connections may each become the limiting resource. A backup that accepts a call but cannot transfer it promptly has not preserved the public outcome. A backup that supports voice but loses text relay has created an accessibility failure. A backup that becomes overloaded by its own diagnostic logging may have nominal resources but limited public evidence usable capacity.

The design goal is not necessarily a perfect duplicate of the primary. A degraded mode can be defensible if it preserves the essential service, prioritizes urgent traffic fairly, communicates limitations and returns to normal safely. But degraded-mode decisions must be explicit before the incident. Operators should know which features may be reduced, which must never be lost, and how demand will be controlled without excluding users who depend on accessibility services.

Testing is therefore a production claim. A successful planned switchover at low volume demonstrates only a subset of the required assurance. Strong evidence would include unannounced or minimally announced exercises, transfers while the primary state is ambiguous, full national load plus retry amplification, loss of one or more accessibility components, failure of the first recovery action and restoration back to primary. The exercise should measure caller outcomes, not only infrastructure status.

Ofcom's finding makes the accountability line clear. BT controlled whether an appropriate backup system existed and whether it could limit adverse effects and enable recovery. Government and emergency authorities had interests in the outcome, but they did not configure or operate BT's platform. Shared oversight should strengthen the test, not dilute operator responsibility for the assets and procedures it controlled.

"Human error" should start the control analysis, not end it

The phrase "human error" appears in the final chronology because a person made an unsuccessful recovery choice. It is relevant, but it is not a complete explanation of why the system entered total outage.

People operate network infrastructure through information and constraints designed by organisations. A runbook tells them what to do. A console tells them what is healthy. Access controls determine what they can change. Training builds or fails to build familiarity. Exercises expose or fail to expose ambiguity. Escalation rules determine when another person reviews the decision. Tooling can allow a dangerous selection or block it. Documentation can be current or stale.

Ofcom tied the failed transfer to poor documentation and unfamiliarity. Those findings move responsibility from an isolated act to repeatable organisational controls. If a process is critical enough that one mistaken selection can move a national service from partial disruption to total outage, the process should be designed with verification and recovery around that consequence.

Several practical controls follow.

The destination should be identified by service readiness, not merely by a node name. The interface should show whether the candidate platform has passed health checks under load. The runbook should include decision criteria, prerequisites, irreversible steps and confirmation points. A second qualified operator should verify the route where time permits, or the system should enforce an automated guard. Training should include ambiguous telemetry and partial primary failure. Exercises should require the team to detect and correct an initial wrong action.

None of this eliminates human responsibility. It makes responsibility usable. The operator remains accountable for following approved procedure and escalating uncertainty. Management remains accountable for procedure quality, staffing and training. Platform owners remain accountable for observability and safety constraints. Executives remain accountable for funding realistic capacity and exercises. Regulators remain accountable for testing whether the system of controls is credible.

The alternative is a weak accountability cycle. An incident occurs. A report identifies human error. The individual receives more training. The underlying interface, documentation and organisational assumptions remain unchanged. The next person faces the same trap. A stronger closeout asks whether the error became harder to make, easier to detect and safer to recover from.

This approach is especially important in public networks because response conditions are inherently stressful. Demand rises. Information is incomplete. The public cannot be told to wait for a maintenance window. Procedures should be judged under those conditions, not only in a calm review meeting after the event.

The impact figures describe different denominators

Public confidence depends on accurate impact reporting. The BT incident produced several official figures that should not be treated as interchangeable.

Ofcom's 2024 penalty notice says nearly 14,000 emergency call attempts were unsuccessful between 06:24 and 16:56, made by 12,392 different callers. An individual caller can make multiple attempts, so attempts and callers naturally differ. The notice also says the event affected about 14,000 emergency calls and included approximately one hour of total outage. [1][3]

The government's post-incident review says 9,641 unique callers were unable to access emergency services via 999 or 112, with many more delayed or disrupted. It divides the event into disruption, denial and delay. That measure may apply a different definition of "unable to access," deduplicate identities differently or cover different records. The public review should be reported on its own terms. [4][5][6]

The later government summary of Ofcom's security reporting says about 23 percent of emergency call attempts were unsuccessful and identifies a 51-minute period with complete failure. That percentage adds scale, but it still requires a denominator and time boundary. It should not be used to calculate a new caller count unless the underlying data supports the calculation. [8]

These distinctions are not pedantic. They correspond to different public harms.

An unsuccessful attempt measures load placed on the failing service and the work created by retries. A unique caller measure approximates the number of people or devices that encountered failure. A delayed call may eventually connect but still create serious risk. A dropped transfer can fail after an agent has answered, which is operationally different from a call that never reaches the queue. Text relay disruption can affect a user across both emergency and ordinary communications.

A good incident dataset would preserve all of these categories by interval. It would show attempts, unique callers, answer time, transfer success, abandonment, retry chains, originating network, accessibility path and emergency authority. It would also protect personal data. Aggregated 15-minute reporting, already part of Ofcom's emergency call handling expectations, can show when service returned unevenly and whether the backup improved outcomes.

The current public record is sufficient to establish a severe nationwide disruption. It is not sufficient to attribute a specific failed response or health outcome to a particular call. That boundary should remain explicit. Public accountability is strengthened, not weakened, when analysis states what the numbers measure and where they stop.

Accessibility paths are part of the core service

Emergency-call resilience cannot be evaluated only through standard voice calls. BT's role included relay services, and Ofcom widened its investigation to understand effects on text relay, emergency video relay and mobile SMS access to emergency organisations. The penalty notice says text relay disruption prevented people with hearing and speech difficulties from making calls, including to friends, family, businesses and services, and left them at increased risk of harm. [1][3]

This impact has two accountability implications.

First, accessibility is not an optional feature that can be removed casually in degraded mode. For some users, relay is the usable path to emergency assistance. A backup design that restores ordinary voice while leaving relay unavailable does not provide equivalent public access. Capacity planning, exercises and monitoring should therefore include each supported mode.

Second, aggregate voice metrics may conceal unequal consequences. A 95 percent answer target can still hide complete failure for a smaller accessibility channel. Service-level dashboards should separate modalities and surface when one population has no viable path. Public incident communication should provide alternatives that those users can actually use.

The source set does not establish that a particular disabled person suffered a confirmed serious outcome. It does establish that an accessibility path was disrupted and that Ofcom considered the risk significant. The correct response is neither to exaggerate individual causation nor to minimize the structural exclusion. It is to demand evidence that future failover tests include relay services, that backup capacity covers them and that public instructions are accessible.

The legal finding concerned availability preparation, not hostile intrusion

Ofcom's decision applied the post-2022 telecom security framework to a technical availability failure. That application is important because it shows that network security duties are broader than cyberattack response.

Section 105A of the Communications Act requires providers of public electronic communications networks and services to take appropriate and proportionate measures to identify and reduce risks of security compromise and to prepare for its occurrence. The statutory definition includes anything that compromises availability, performance or functionality. Regulation 9 of the Electronic Communications (Security Measures) Regulations addresses preparation for such compromises, including appropriate procedures and backup. [1][2][10][11]

Ofcom found that BT had not taken sufficient measures in two areas. It lacked clearly defined and tested means and procedures for identifying, assessing and addressing a security compromise. It also lacked an appropriate backup system capable of adequately limiting adverse effects and enabling recovery. Those findings map directly to the incident's first failed transition, inadequate warning and assessment, and constrained disaster-recovery operation. [1][2]

The regulator imposed a GBP 17.5 million penalty. The amount included a 30 percent settlement discount because BT admitted liability and completed Ofcom's settlement process. Ofcom considered the matter very serious and said the incident's scale and impact were prolonged by factors within BT's control. It also considered remediation and cooperation. [1][2][3]

Ofcom had examined other provisions, including section 105C and General Conditions A3.2 and C5.8 through C5.12. A3.2 concerns the fullest possible availability of public voice and Internet services and uninterrupted access to emergency organisations. The C5 provisions relate to relay services. The final case page says Ofcom did not pursue findings on those provisions as an administrative priority, focusing on section 105A and Regulation 9. The article should therefore not convert the investigation scope into a finding of breach on every provision. [1][9]

The legal framing produces a useful control standard. A provider cannot satisfy resilience duties by reacting competently only after a failure is understood. Preparation includes the procedures, backup capability and testing needed before the event. The duty also concerns proportion: a national emergency call service merits controls aligned with its potential consequences and the operator's resources.

Ofcom's emergency call handling standards provide related operational context. They expect procedures commensurate with the service's critical nature, 99.999 percent monthly availability, sufficient network, system and human resources for prompt answer, business continuity assessment, 15-minute data and outage reporting. Those standards predate the 2023 incident and describe expected practice, while later resilience guidance expands provider expectations around design, testing, monitoring, response and recovery. [12][13][14][17]

The later documents should be used carefully. They can identify what good resilience evidence now looks like. They should not be cited as proof that every later paragraph was a binding rule breached in 2023. The final Ofcom decision is the authority for the actual legal finding.

Government oversight must test the chain, not replace operator control

The government post-incident review treated the event as a system-wide resilience lesson. It called for continued risk management, stronger government oversight, better public communication and exercises across a range of scenarios. It also described the event as the first nationwide loss of the public emergency call service in its 86-year history. [4][5][6]

These recommendations address a real governance gap. Emergency calling crosses organisational boundaries. BT handles calls. Communications providers originate them. Emergency authorities receive them. Government departments oversee policy and national resilience. Local responders communicate alternatives. An exercise that tests only one organisation cannot prove that the chain works.

System-wide oversight should establish a common service map, failure scenarios and evidence format. The map should identify which actor owns each transition and dependency. The scenarios should include total primary loss, ambiguous partial degradation, failed first recovery, reduced backup capacity, accessibility-path failure and contradictory public information. The evidence should record caller outcomes across originating networks and emergency authorities.

Oversight should also define escalation. During a national outage, government needs timely, technically accurate information without taking over the operator's engineering role. BT remains responsible for its platform and recovery. Government remains responsible for coordinating national consequences, supporting emergency authorities and giving the public usable advice. Ofcom remains responsible for regulatory assessment. Clear boundaries make cooperation faster because each actor knows what it must decide and disclose.

Public communication deserves technical treatment. An alternative number is only useful if the network path supporting it is independent enough, if the receiving authority can absorb demand, if the number is consistent across messages and if users can access it. Advising people to use another channel without testing that channel can move congestion rather than restore service. Exercises should therefore test communication as part of infrastructure, including accessibility and regional variation.

The government said critical recommendations had been delivered and that it would oversee remaining work. That is a progress statement, not a complete evidence pack. Durable public assurance would connect each recommendation to an owner, due date, completion artifact, exercise result and residual risk. Where details cannot be public for security reasons, an independent assessor can verify them and publish bounded conclusions.

Remediation should be measured by changed failure behavior

Ofcom and BT describe several corrective actions. BT fixed the initiating error, improved fault monitoring, improved the disaster-recovery platform and documented a clearer switch process. The government reported progress on wider recommendations. These changes correspond to the failure sequence and are relevant to penalty and closeout. [3][4][7]

The remaining question is effectiveness. A control is not proven because a document says it was added. It is proven when the system behaves differently under the condition it is intended to contain.

For configuration governance, evidence would show schema validation, peer review, staged rollout, canary behavior, automatic rollback and protection of a known-good state. A test should introduce a malformed or unsafe configuration and demonstrate that it cannot impair every primary node.

For monitoring, evidence would show synthetic calls, agent-session stability, queue and transfer outcomes, relay-service checks and alarms independent of the affected platform. A test should create partial failure and demonstrate that operators can identify the affected service path quickly.

For disaster recovery, evidence would show current runbooks, role assignments, regular operator practice, guarded selection of a safe destination and successful transfer under ambiguous primary status. A test should include a deliberately unsuccessful first action and demonstrate recovery without prolonged total outage.

For capacity, evidence would show demand assumptions, retry amplification, queue limits, agent concurrency, transfer throughput and accessibility-path load. A test should run at or above the reasonably expected national demand used in design.

For public communication, evidence would show pre-agreed messages, accessible alternatives, authority to issue updates, consistency across government and responders, and withdrawal of temporary instructions after recovery.

For independent assurance, evidence would show who witnessed the tests, what failed, what was retested and which risks remain. An assessor does not need to publish exploitable details to state whether the control passed a defined scenario.

The strongest remediation program would connect these artifacts. A configuration test would trigger monitoring. Monitoring would drive a declared incident. The team would execute failover. Backup would carry load. Emergency authorities would confirm successful transfer. Public communication would activate only if needed. The system would then return to primary service without losing evidence. That chain is what the public actually depends on.

Accountability matrix

Accountability should be assigned to the actor with practical control over each safeguard and evidence record.

Stage	Primary control owner	Required control	Evidence that should exist	Public uncertainty
Prevention	BT platform owners	Validate configuration, isolate deployment failure domains, preserve a known-good state	Change records, schema checks, canary results, rollback tests	The complete configuration and approval record is not public
Prevention	BT architecture owners	Ensure primary nodes do not share unacceptable common mode	Dependency map, configuration-domain design, injected-fault tests	The unredacted topology and shared-state detail is not public
Detection	BT operations	Detect failed calls, agent restarts, transfer drops, queue recycling and relay failure	Synthetic calls, service-outcome dashboards, alarm history	The complete alarm stream and threshold design is not public
Assessment	BT incident command	Identify severity, scope and likely cause promptly	Incident timeline, decision log, escalation record	Public sources do not show every decision or timestamp
Containment	BT network operations	Isolate unsafe primary capacity and prevent retry amplification	Traffic controls, safe-drain procedure, bounded logging evidence	The exact containment actions are not fully public
Recovery	BT recovery team	Transfer to a verified safe disaster-recovery destination	Current runbook, training record, guarded switch log, rollback points	The precise first-transfer mistake and interface are partly redacted
Capacity	BT service owners	Carry reasonably expected demand in disaster recovery	Load model, stress test, agent and transfer throughput results	Public documents do not publish the current tested ceiling
Accessibility	BT and emergency-service partners	Preserve text, video and other supported access paths	Modality-specific monitoring and failover tests	Complete post-remediation accessibility results are not public
Originating delivery	Other communications providers	Test 999/112 delivery through the full national chain	Test-call records across networks and access types	Coverage and cadence are not fully visible publicly
Emergency response	Emergency authorities	Receive, transfer and act on calls during degraded operation	Continuity plans, exercise results, alternative contact capacity	Local readiness may vary and is not fully documented here
Public communication	Government and emergency authorities	Issue accurate, consistent and accessible instructions	Approved messages, decision authority, channel tests	Public evidence does not show every exercise or regional path
Regulatory accountability	Ofcom	Investigate, enforce, guide and monitor	Confirmation decision, penalty record, follow-up program	Some technical evidence is confidential
Verification	BT, government and independent assessors	Prove corrective controls under realistic scenarios	Dated test artifacts, witnessed results, residual-risk statement	Public remediation summaries do not establish every result

The matrix prevents two common errors.

The first is over-centralized blame. BT controlled the platform and much of the incident response, but it did not control every local emergency plan or public message. Government and emergency authorities had their own continuity responsibilities.

The second is diluted responsibility. Calling the event a "whole-system failure" must not obscure BT's control over configuration, monitoring, failover and backup capacity. Shared public consequences do not make every technical decision shared.

The matrix also clarifies remedy. A penalty can acknowledge a breach and deter future failure. It does not itself prove that the platform has changed. A government review can coordinate recommendations. It does not itself test BT's load ceiling. A BT remediation statement can identify work completed. It does not itself provide independent assurance. Each artifact has a proper role.

What would close the remaining evidence gaps

The public record is strong enough to support Ofcom's findings and the main accountability thesis. It is not complete enough to evaluate every claimed repair. Several bounded disclosures would materially improve confidence.

A configuration lineage: the relevant file's purpose, validation rules, approval path, deployment scope and rollback protection. Sensitive values can be removed while preserving the control sequence.

A failure-domain statement: which configuration, software, data, management and access dependencies are shared across the three primary nodes and disaster recovery, and which are deliberately independent.

A monitoring coverage map: the synthetic calls and service-outcome measures used for voice, text relay, video relay, mobile SMS and transfer to each emergency authority.

A failover exercise record: date, scenario, initial conditions, roles, decision points, transfer time, errors, caller outcomes, backup load and return-to-primary result.

A capacity basis: the demand model used for disaster recovery, including retry amplification and modality-specific requirements, plus the tested ceiling and safety margin.

A runbook usability result: evidence that staff who may be on duty can execute the procedure from current documentation, not only that subject-matter experts can explain it.

A corrective-action verification table: each action, owner, completion date, test, independent reviewer, result and residual risk.

A public impact methodology: definitions for unsuccessful attempt, unique caller, denied call, delayed call, dropped transfer and modality disruption, so different official counts can be understood without guesswork.

Not all raw data should be public. Emergency network details can create security and privacy risks. But confidentiality should change the form of assurance, not eliminate it. Ofcom or an independent assessor can confirm that a test covered defined scenarios and passed measurable thresholds without exposing configurations or personal call records.

Lessons for other public network operators

BT's incident is specific, but the control questions apply to other shared network services.

First, count control planes, not only servers. Three nodes behind one configuration path may provide less independence than two systems with separately governed state. DNS, BGP, mobile core, authentication and call-routing operators should map common mode explicitly.

Second, test failed recovery, not only successful failover. The first action during an incident may be wrong because information is incomplete. A resilient process detects the error, limits its effect and provides a clear correction path.

Third, size backup for failure demand. Retries, duplicate attempts, longer handling and public uncertainty increase load. The backup must be tested against the incident-shaped curve rather than a normal average.

Fourth, monitor service outcomes from outside the platform. An internal health signal can remain green while customers cannot complete a transaction. Synthetic calls and end-to-end transfer checks should cover multiple originating networks and accessibility modes.

Fifth, make documentation executable. A runbook should be tested by the people likely to use it, with current interfaces and permissions. If it cannot be followed under time pressure, it is not a control.

Sixth, preserve accessibility in degraded mode. A resilience plan that restores only the majority channel can exclude users for whom relay or another modality is the primary route.

Seventh, distinguish legal availability security from hostile intrusion. Network security programs should include configuration, capacity and operational continuity, not only adversary defense.

Eighth, publish evidence at the right level. Operators can protect sensitive details while disclosing test scope, independent verification and residual risk. Vague assurances invite either false confidence or speculation.

Finally, define recovery by the public outcome. A platform is not recovered because processes restarted. Emergency access is recovered when calls from relevant networks and modalities are answered and transferred reliably, the backup can sustain demand, public instructions are accurate and evidence has been preserved.

Conclusion

The 25 June 2023 outage turned fallback call routing into an accountability test because every layer of the resilience claim became observable.

Ofcom's enforcement decision established the legal finding and imposed a substantial penalty. BT and government reported corrective work. The remaining public question is not whether anyone responded. It is whether the repaired system has been tested against the exact combination that occurred: ambiguous primary failure, shared susceptibility, an initial recovery mistake, retry-driven demand, accessibility requirements and national call volume.

Accountability follows the controls that can answer that question. BT owns the technical and operational evidence for platform resilience. Government and emergency authorities own system-wide continuity and public communication. Other providers own end-to-end originating-network tests. Ofcom owns regulatory verification and enforcement.

A national emergency-call service should not ask the public to infer resilience from the existence of three nodes and a backup site. It should be able to demonstrate independent failure domains, executable recovery, adequate capacity and verified caller outcomes. That is the difference between redundancy as a diagram and resilience as a public-network fact.

BT's 2023 999 Outage Made Fallback Call Routing a Public-Network Accountability Test