The Day Cybersecurity Needed a Telephone Tree

There is a particular kind of silence that appears during a technology incident. The machines are still making noise—fans, alerts, failed logins, unavailable services—but the people who need to make decisions do not yet share a story about what is happening.

In November 1988, the early internet encountered that silence at scale. The Morris worm spread through a network that was small by modern standards but already too distributed for one institution to understand. Machines slowed or stopped. Messages were delayed. Different organizations saw different pieces of the same event.

Before the incident

Computer security was already a subject of research, but incident response was not yet a mature operating discipline. A vulnerability could be studied by experts. A distributed event required experts to find one another, decide what they were seeing, and communicate while the network was unreliable.

That distinction matters. Prevention is about reducing the chance of a bad event. Response is about reducing confusion after the event begins.

The communication problem

NIST’s history of cyber risk management explains that the worm made incident-response planning a significant concern because organizations wanted a way to communicate if another worm spread. The problem was not merely that computers were infected. It was that the normal route for asking for help was part of the affected environment.

This is why early response work involved contact lists, shared reporting, technical coordination, and eventually formal organizations. The telephone tree may sound primitive, but it captures the core requirement: a reliable way to make the next decision when the primary system is unavailable.

Why this still matters

Modern businesses have more communication options than the organizations affected in 1988. They also have more dependencies. Email, identity, file storage, phones, cloud applications, remote access, and vendor portals may all rely on one another.

More tools do not automatically create more resilience. Sometimes they create more ways for a team to become uncertain about which channel is authoritative.

The small-business version

A useful incident plan does not need to be dramatic. It needs a named decision-maker, a backup communication method, a current vendor contact, a prioritized list of systems, and a short description of what “good enough to resume” means.

The plan should also be exercised. A table-top conversation can reveal that the emergency contact list is stored behind the login that just failed, or that two vendors each believe the other owns the recovery step.

The lesson of the worm is not that technology is fragile. It is that coordination is part of technology. When the systems are under pressure, the organization’s ability to communicate becomes one of its most important controls.