Incident Response and Business Continuity

Every organisation faces things that go wrong. A power cut, a ransomware attack, a server crash, a flood in the data centre. Two separate but tightly linked disciplines exist to handle these possibilities: incident response and business continuity. Although they work side by side, they solve different problems. Incident response is the immediate, technical handling of a security incident. Business continuity is the strategic, organisation-wide capability to keep essential functions running during and after a major disruption. Let's break both down.

An incident is any violation or imminent threat of violation of an information security policy, acceptable use policy, or standard security practice. The key word is “violation.” A power outage that only affects non-critical systems is an event, but if it knocks out a customer-facing payment portal and exposes data, it crosses the line into an incident. Incident response (IR) is the structured process the organisation follows to detect, contain, eradicate, and recover from such incidents. The most widely referenced framework is NIST SP 800-61 Revision 2, which outlines a six-phase lifecycle. - Preparation: This phase happens before anything bad occurs. It includes creating an incident response policy, building an incident response team (IRT), defining roles, acquiring tools (forensic software, secure communication channels), and running exercises. - Detection and Analysis: Here, the organisation monitors systems and networks for indicators of compromise — unusual outbound connections, unexpected privilege escalation, malware alerts. When a potential incident is detected, analysts must determine whether it truly is an incident and, if so, how severe it is. Triage is critical. - Containment: Once a real incident is confirmed, the immediate goal is to stop it spreading. This might mean disconnecting a compromised server from the network, disabling a compromised user account, or isolating a network segment. Containment can be short-term (e.g., pulling a cable) or long-term (e.g., applying a patch before bringing the system back). - Eradication: After the threat is contained, the team removes it entirely. That could involve deleting malware, closing backdoors, resetting all affected passwords, and reimaging machines from known-good sources. Eradication must be thorough; leaving any trace lets the attacker return. - Recovery: Systems and services are restored to normal operation. This step includes restoring data from clean backups, monitoring intensely for any sign of re-infection, and gradually returning user access. Recovery timelines are driven by business priorities, not technical convenience. - Post-Incident Activity: After the dust settles, the team conducts a lessons-learned review — sometimes called a post-mortem — to identify what went well, what went poorly, and how the plan can be improved. This phase is mandatory for organisational learning.

Business continuity, on the other hand, answers a bigger question: “How does the organisation keep functioning when a disaster stops normal operations?” A disaster is an event that causes widespread, prolonged disruption — for example, a hurricane destroying the primary office, a successful ransomware attack that encrypts the entire server fleet, or a pandemic that prevents staff from being on site. Business continuity planning (BCP) is the process of developing and documenting a business continuity plan (BCP) that ensures critical business functions can continue during and after a disaster. A closely related term is disaster recovery planning (DRP), which focuses specifically on restoring IT infrastructure and systems. Think of the BCP as the umbrella that covers entire business processes — people, facilities, supply chain — while the DRP is the IT-centric piece underneath.

BCP starts with a business impact analysis (BIA). The BIA identifies which business processes are truly critical — those whose interruption would severely damage the organisation — and for each one, it quantifies two numbers: the Recovery Time Objective (RTO) and the Recovery Point Objective (RPO). RTO is the maximum amount of time a process can be down before the organisation suffers unacceptable harm. RPO is the maximum amount of data that can be lost, measured in time (e.g., “we can afford to lose two hours of transactions”). These numbers drive everything else: how fast you must recover, which alternative sites you need, and how often you must replicate data.

The BCP itself documents strategies for maintaining operations. Common strategies include: a hot site (a fully equipped, ready-to-go facility with live data), a warm site (equipped with hardware but needing data restoration), a cold site (an empty building with power and cooling but no equipment), and a mobile site (a trailer with pre-installed gear). The DRP details the technical steps to restore servers, databases, and networks at the chosen recovery site.

Both incident response and business continuity rely on regular testing. A tabletop exercise gathers the key players around a table to talk through a scenario without moving equipment. A walkthrough adds a physical element — the team actually travels to the recovery site and verifies that the steps in the plan work. A full-scale simulation or parallel test runs operations at the recovery site alongside the primary site without impacting real business. These tests uncover gaps that no amount of paper review will reveal.

Why do these disciplines exist in their current form? Before formal IR and BCP frameworks, organisations reacted chaotically. Every incident was a fire drill with no pre-assigned roles. Downtime lasted days because nobody had prioritised recovery. The modern approach replaces guesswork with documented, measurable, and rehearsed procedures, dramatically reducing downtime and financial impact.

Picture a mid-sized e-commerce company called FreshCart that sells groceries online. On a busy Monday morning, a staff member clicks a phishing link and unleashes ransomware that quietly encrypts files on the order-processing server. Within the hour, the warehouse management system also shows scrambled data. The security operations centre (SOC) gets an alert from endpoint detection software. This is an active security incident.

The incident response team lead immediately declares the incident and pulls out the IR playbook. Step one is containment: the affected server and two connected workstations are isolated from the network by disabling their switch ports remotely. The SOC analyst makes a forensic image of the RAM and disk of the infected server before anything changes. Simultaneously, the communications lead notifies the Chief Information Security Officer (CISO) and legal department, because customer data might be involved.

Containment stops the bleeding, but FreshCart cannot ship orders. The business continuity manager triggers the BCP. In the BIA, “order fulfilment” had an RTO of four hours and an RPO of one hour. The disaster recovery team springs into action. FreshCart uses a warm site arrangement with a cloud disaster recovery service. They spin up a replica environment in the cloud using the last clean backup taken 45 minutes ago — well within the RPO. DNS is redirected so that the e-commerce front end points to the cloud-based order-processing system.

Back at the main site, the IR team moves into eradication. They identify the ransomware strain, confirm it was delivered via email, and block the sender. All passwords in the affected department are reset. The encrypted machines are reimaged from a gold standard image. The security team runs a vulnerability scan to ensure no open backdoors remain.

Recovery proceeds in phases. The cloud order system runs for two days while the physical data centre is fully sanitised and rebuilt. Then customers are seamlessly transitioned back. The post-incident review reveals that a two-factor authentication prompt would have stopped the initial compromise. The BCP is updated to include that as a quick-win control. Through the whole event, FreshCart lost no more than 35 minutes of data and suffered only a brief period of slower order processing, because the plans were rehearsed monthly and every person knew their role.