The Saturday Morning Test

It is Saturday morning. You get a call.

The systems are down. Nobody can log in. The network is not responding. Customers are waiting. Staff are standing around. And whoever is on the other end of that call is already panicking.

What happens next in your organization tells you everything you need to know about whether you actually have an incident response plan – or whether you just think you do.

The Three Things Every Business Does Wrong

In almost every organization that has not prepared for this moment, the response follows the same sequence. And each step makes the situation worse.

Step one: Call the IT guy.

The IT person – whether that is a managed service provider, an internal employee, or the Accidental Custodian we talked about in a previous article – gets the call. They drop whatever they are doing on a Saturday morning and start working the problem. So far, so expected.

Step two: Yell at the IT guy.

The pressure starts immediately. The owner is stressed. The manager is stressed. Everyone wants to know what is happening, when it will be fixed, and whose fault it is. The IT person is now trying to diagnose a complex technical problem while simultaneously managing the emotional temperature of everyone around them. These are not compatible activities.

Step three: Let the sales team try to fix it.

This is where a recoverable situation starts becoming unrecoverable. Someone who knows a little about computers decides to help. Someone else tries rebooting something. A third person starts poking around in systems they do not normally touch. Everyone is trying to do something because doing nothing feels unbearable.

And the incident just got three times harder to resolve.

Why the Chaos Makes It Worse

Here is what actually happens when untrained people start touching things during an active incident.

You start chasing phantom problems. When multiple people are investigating simultaneously, you end up pursuing issues that have nothing to do with the original failure. A self-inflicted problem – something someone accidentally changed while trying to help – gets mixed into the investigation. Now you are debugging two incidents instead of one, and you do not know which is which.

The logs become worthless. This is the one that keeps security professionals up at night. System logs are the evidence trail. They tell you what happened, when it happened, who touched what, and in what sequence. Every time an untrained person touches a system during an active incident, they are writing noise into that log. By the time a professional sits down to reconstruct the timeline, the evidence has been contaminated. In a security incident, that contamination is not just inconvenient – it can mean the difference between understanding the full scope of the breach and never knowing how far it went.

The noise drowns the signal. Ninety-nine percent of the time, the root cause of an outage is simpler than the chaos around it suggests. But when thirteen people are calling for updates every fifteen minutes, when the sales team is hovering, when the owner is escalating – the person who could actually fix the problem cannot hear themselves think. The pressure that feels like it should speed things up almost always slows them down.

The Chain of Command Nobody Builds Until They Need It

A real incident response plan includes something most organizations have never thought about: a communication structure that protects the people doing the work.

Here is the rule: the person working the incident talks to one person. One designated point of contact receives updates and manages all other communication. That point of contact reports to leadership, to staff, to customers – on a schedule that was decided before the incident happened, not in the middle of it.

Not thirteen people getting updates every fifteen minutes. One person. Every hour, or every two hours, or every ten minutes if the situation is moving fast – but on a cadence that was agreed upon in advance, not driven by whoever is most anxious in the moment.

This does two things. It protects the person doing the technical work from being pulled out of focus every time someone needs to feel like something is happening. And it gives the organization a single, consistent communication thread instead of fifteen different versions of the story spreading in fifteen different directions.

What Ready Actually Looks Like

Here is the distinction that matters most: a prepared business is not one that never fails. It is one that is ready when it does.

The businesses I have seen handle incidents well share one thing in common. When the systems went down, they did not scramble to figure out what to do. They went to the folder.

Printed documents. Physical copies of the incident response plan, the contact list, the communication templates, the vendor escalation paths, the insurance information – stored in a folder that can be photocopied and distributed the moment it is needed. Not in a shared drive. Not in an email. In a physical folder that exists independent of every digital system in the building.

Because here is the problem with a digital incident response plan: when the incident hits, the systems that hold the plan may be the systems that are down.

The businesses that are ready can go back to 1842 if they have to. They can run the operation as if none of the technology existed – on paper, with phone calls, with physical documents, with processes that do not depend on a single connected system being available. Not because that is how they want to operate, but because they planned for the possibility that they might have to.

That preparation is not complicated. It is a folder, a printed plan, a designated decision-maker, and a communication chain that was agreed upon before anyone was panicking.

The Saturday Morning Question

The Saturday Morning Test is simple.

If your systems went down right now – this morning, before business hours, before your IT person was available, before you had time to prepare – what would your organization actually do?

Not what you hope would happen. Not what the plan says should happen. What would actually happen, with the people you have, in the state of readiness you are in today?

If the answer involves calling one person, putting all the pressure on that person, and letting everyone else start touching things – you do not have a plan. You have a habit. And habits do not hold up under the kind of pressure a real incident brings.

The businesses that survive incidents are the ones that built the plan before they needed it, printed it before the systems went down, and practiced it before the Saturday morning call came in.

The folder is ready. The chain of command is clear. The communication cadence is agreed upon.

And if everything fails – if the network is down, if the servers are gone, if nothing digital is available – they can run the business on paper until the lights come back on.

That is what ready looks like. Not the absence of failure. The presence of a plan that works when everything else does not.

—

Kelly Hansen is the author of The IT Dilemma: Why Good Businesses Fail During Cyberattacks, Outages, and Technology Disasters – and How to Prevent It. Have a question about your own environment? Reach out: Contact, or connect with me on LinkedIn.