Most businesses only think about business continuity in the abstract. Here is what it looks like in practice.

 

It is 8.47am on a Tuesday.

Someone arrives at the office, opens their laptop, and something is wrong. Files are not loading. Systems are slow. Then another member of staff reports the same thing. Then another. Within twenty minutes it is clear this is not a network blip. Something has happened.

What happens next determines everything.

Hour one: the discovery window

 

The first hour after an incident is frequently the most critical and the most poorly used. In organisations without a clear response plan, the typical pattern looks like this: individuals attempt to resolve the problem themselves, colleagues are called, devices are restarted, and time passes waiting for the issue to resolve on its own. Meanwhile, evidence is disturbed, affected systems remain connected to the network, and the scope of the incident continues to grow.

In organisations with a documented response plan, the first hour is different. The person who identifies the problem knows who to contact. That contact knows what steps to take. Affected systems are isolated promptly. The recovery process begins immediately.

The difference between these two scenarios is not primarily about technology or budget. It is about having a clear, documented plan that people have actually read.

Hours two to four: assessment and containment

 

Once an initial response is underway, the priority becomes understanding the scope of the incident. Which systems are affected? Has any data been accessed or exfiltrated? Is the incident still active or contained?

The quality of IT documentation matters significantly at this stage. If your IT team cannot quickly identify which systems are connected, where data is stored, and what the dependencies are between systems, assessment takes considerably longer than it should. Every hour spent on assessment is an hour not spent on recovery.

Containment means preventing the incident from spreading further. This typically involves isolating affected devices from the network, revoking credentials that may have been compromised, and suspending accounts showing anomalous activity. In a ransomware scenario, effective containment can mean the difference between a handful of devices being affected and the entire network.

This is also the point at which your backup strategy is tested properly for the first time. Backups stored separately from the affected environment and regularly tested can be accessed immediately. Backups that have never been tested, were stored on the same network as the affected systems, or have not run recently are considerably less useful.

Hours four to eight: communication and decision-making

 

By mid-morning the organisation is likely operating at reduced capacity or offline entirely. Clients may be noticing. Staff may be unable to work. The decisions made in this window affect the reputational impact of the incident as much as the technical outcome.

Communication planning is one of the most consistently overlooked elements of business continuity. Who informs clients? What is communicated, and with what level of detail? Who is authorised to speak on behalf of the business externally? What information is shared with staff?

Without answers prepared in advance, organisations tend to say nothing while the situation is assessed. In practice, that silence is often interpreted negatively by clients who have no other information to work with. Organisations that communicate proactively, acknowledging the situation honestly and providing a realistic timeline, consistently manage reputational impact more effectively than those that go quiet.

This window is also when regulatory obligations become time-sensitive. Under UK GDPR, where personal data has been involved in a breach, organisations are required to notify the Information Commissioner’s Office within 72 hours of becoming aware of the incident where it is likely to result in a risk to individuals. That clock begins at the point of discovery, not containment. Knowing whether personal data is involved, and who is responsible for making the notification decision, needs to be established well before an incident occurs.

Hours eight to twenty-four: recovery and review

 

With the incident contained and backups accessible, recovery begins. For an organisation with a documented recovery process, tested backups, and clearly defined Recovery Time Objectives and Recovery Point Objectives, this phase is demanding but structured. Systems are restored in a planned sequence. Data is recovered to a known point. Staff return to work.

For an organisation without those foundations, recovery is considerably less predictable. Steps take longer than expected because the process has not been rehearsed. Dependencies emerge that were not anticipated. Data assumed to be backed up may not have been included in the backup scope. The absence of a defined RPO means there is no agreed standard against which to measure recovery.

The post-incident review is as important as the recovery itself. How did the incident originate? What allowed it to develop to the scale it did? Where did the response work as intended and where did it fall short? What needs to change?

Treating every incident as a learning opportunity, rather than something to close as quickly as possible, is what separates organisations that build genuine resilience from those that remain vulnerable to the same failures recurring.

What the first 24 hours reveals

 

A serious IT incident functions as an unscheduled assessment of your organisation’s preparedness. The quality of your backups. The clarity of your documentation. The effectiveness of your team’s response. The robustness of your communication. The maturity of your compliance processes.

Most of these are only tested when something goes wrong. The organisations that respond well did not get lucky. They made deliberate decisions in advance that were not visible until the moment those decisions were needed.

Recovery Time Objective. Recovery Point Objective. Tested backups. Incident response plan. Communication protocol. Regulatory reporting process. These are not purely IT considerations. They are business continuity fundamentals.