Two Clocks: Incident Response vs. Business Continuity

You won at noon. Nobody noticed.

The alert comes in at 2:00 a.m. on a Thursday. By 6:00 the response team has isolated the affected hosts. By noon they’ve traced the initial access, killed the persistence, and confirmed the blast radius. Technically, it’s a good outcome — fast detection, clean containment, an adversary who got less than he wanted.

On Friday, orders still aren’t shipping. On Monday, the customer support team is working from a spreadsheet and nobody can tell a client when their portal comes back. Two weeks later, in the board meeting, “we contained it in ten hours” is not the sentence anyone wants to talk about.

Two clocks start at 2:00 a.m. The first one runs on the adversary’s schedule and stops when the threat is out. The second one runs on your customers’ schedule and keeps running until the business is actually working again.

Most organizations have a plan for the first clock. Far fewer have one for the second. And in our experience the second clock is the one that determines what the incident costs you.

That’s the practical difference between incident response and business continuity. Incident response is about the event. Business continuity is about whether the company still functions while the event is happening.

What incident response is actually for

An incident response plan exists to limit harm, establish facts, remove the threat, and restore affected technology safely — while preserving the evidence and decision record that your insurer, your counsel, and possibly a regulator will want later.

It should tell people what to do under time pressure. Who can declare an incident. Who leads containment. Who approves anything that goes outside the building. When counsel, the carrier, law enforcement, customers, or regulators get engaged.

It should also frame the trade-offs, because the hard calls in the first hours aren’t technical. Pulling a production environment offline may stop the spread. It may also stop revenue, or interrupt a safety-sensitive process, or breach an SLA. Somebody has to decide, and “instinct plus seniority” is not a decision framework. A good plan says in advance who owns that call and what information they need to make it.

Build this week: Declaration criteria. One paragraph defining what makes something an incident rather than a ticket, and the name of the person who says so. Teams lose more time deciding whether this is real than they lose containing it.

What continuity is actually for

Business continuity starts somewhere else entirely. Not with malware — with the question of which functions the company cannot stop doing, and for how long.

That’s a business impact analysis, and it’s the foundation. Which services are essential. What they depend on. How long they can be down before the damage becomes structural. A health system prioritizes patient access and clinical communication. A manufacturer prioritizes production scheduling and supplier coordination. A professional services firm prioritizes client communication, document access, and making payroll.

From there the plan has to cover people, facilities, technology, vendors, data, and communications — the whole set, not just the systems. If the core application is down, is there an approved manual process, and has anyone run it since it was written? If a key vendor is the one with ransomware, who calls your customers and how do you track orders in the meantime?

Continuity does not mean everything keeps running. It rarely can. It means you decided in advance what continues, what waits, and who gets the resources. Those are business decisions with financial consequences, which is why they can’t be delegated to IT — and why they tend to stall without an executive sponsor willing to make a call that some department won’t like.

Build this week: Your top five. Five functions that must survive a two-week disruption, with a named business owner and a maximum tolerable downtime for each. It isn’t a BIA. It’s the conversation that reveals whether you can have one.

“We have backups” is not a continuity plan

Disaster recovery restores technology — infrastructure, applications, data, in a defined order, to defined objectives. It’s essential and it is not the same thing as continuity.

This is the answer we hear most often in exercises, and it usually arrives with visible relief: we’re fine, we have backups. Then the follow-ups start. Restore in what order? From where, and how long does that actually take at your real data volume, not the vendor’s benchmark? How do you know the backups are clean? Is your identity infrastructure in the restoration sequence, and is it early enough to be useful? Who authorizes reconnecting a restored system to the network?

The relief tends not to survive the fourth question.

An organization can have perfectly recoverable backups and still lose ten days — because the restoration order was never sequenced, because staff had no interim procedure, because nobody had drafted what to tell customers on day three. Recovering an application does not restore a business process. The people, approvals, vendor relationships, and communications have to come back too, and none of that is in the backup.

The handoff nobody owns

The interesting part of this topic isn’t the definitions. It’s the seam between them, and the seam is where exercises break down.

Here’s the moment, and it happens in nearly every ransomware tabletop we run. The continuity lead needs the customer portal back — support is drowning, the workaround doesn’t scale, a major account is escalating. The security lead can’t certify the environment is clean yet. Both are right. Both are doing their jobs. And the room discovers that no one has decided who breaks the tie, or what evidence would be enough to justify turning it on.

That is a governance gap, not a technical one, and it’s invisible until someone forces the question.

The fix isn’t merging your plans into one enormous binder. It’s giving each one a clear owner, clear activation criteria, and defined handoffs — plus an executive who understands that containment priorities and continuity priorities will genuinely conflict, and whose job is to resolve that conflict with business judgment rather than referee it.

Leadership is tracking different questions across all three efforts at once: Is the threat contained? What’s degraded, and for how long can we run like this? What needs my approval? What are we obligated to notify, under which contract, and by when — HIPAA, PCI-DSS, state breach law, or the customer agreement somebody signed three years ago.

Build this week: A reconnection authority. One line naming who approves returning a system to production during an active incident, and what that person needs to see first.

What we find

Most organizations have an incident response policy because a customer questionnaire or an auditor asked for one. Fewer have tested it with the people who’d actually make the expensive decisions. The pattern repeats on the continuity side: plans that name critical processes without documenting a workable alternative, or that assume a vendor capability nobody has confirmed.

The gaps cluster in predictable places:

• Response contacts are stale, or containment authority is ambiguous
• The business impact analysis predates the current application stack or the last reorganization
• Recovery objectives exist on paper and have never been validated by an actual restoration test
• Legal, communications, HR, and executives don’t appear in exercises until the real thing
• Third-party dependencies are excluded from both plans, despite being the likeliest point of failure

NIST CSF, ISO 27001, and C2M2 are useful for finding these systematically. But framework alignment isn’t the outcome. The outcome is a capability people can use when systems are down and the facts are still moving.

Make someone own each clock

Security leadership owns incident response readiness. Business leaders own continuity requirements for their own functions. IT owns recovery. An executive sponsor owns the conflicts between them, because there will be conflicts and they’re business decisions.

Then document the things generic templates skip: critical applications and data flows, recovery dependencies, emergency contacts, approval authority, communication paths, vendor escalation, and the manual workarounds someone has actually performed at least once.

Then test the plans together, in the same room, with injects that force real decisions. Do you isolate it? Who approves the customer message? Can finance cut checks manually? What if the backup platform is encrypted too? What proof do you need before you reconnect?

And produce something durable from it — an after-action report with prioritized findings, named owners, and dates. That’s what turns an exercise into progress instead of a well-catered afternoon.

Back to 2:00 a.m.

The alert still comes in at 2:00 a.m. You still contain it by noon.

The difference is that while the response team works the first clock, someone is already working the second one — support has an alternate procedure, finance knows what it can process, customers have heard from you, and leadership knows how many days of this the business can absorb before the decisions change.

Containment is the win you’ll describe to your board. Continuity is the one your customers will actually experience.

 

Skøut Advisory helps leadership teams connect incident response, continuity, and recovery — through business impact analysis, plan design, and tabletop exercises that test both clocks at once. Let’s talk.