Incident Response, Business Continuity, and Disaster Recovery

To understand these three concepts, you first need to recognise they are not the same thing, but they work together like a three-stage safety net.

First, let’s define each term clearly.

An incident is any event that could disrupt or harm an organisation’s information or systems. This could be a phishing email that an employee clicks, a server that crashes, or a hacker breaking into a network. Incident Response (IR) is the immediate, short-term process of detecting the incident, containing the damage, eradicating the threat, and recovering back to normal. Think of it as the fire brigade arriving at a small kitchen fire. They do not worry about rebuilding the kitchen; they just put out the fire and stop it spreading to the rest of the house. The CRISC exam tests the IR lifecycle: preparation, detection and analysis, containment and eradication, and post-incident activity (lessons learned). Risk management influences IR by helping the organisation decide which incidents to prepare for (the ones with the highest likelihood and impact).

Business Continuity (BC) is the capability of the organisation to continue delivering its most critical products or services at an acceptable level after a disruptive event. It is not about stopping the bad thing; it is about keeping the business running despite the bad thing. The plan for this is called a Business Continuity Plan (BCP). In our fire example, BC means the employees who are not fighting the fire move to a conference room and keep processing customer orders on laptops. BC relies on a Business Impact Analysis (BIA), which identifies which business functions are most critical and what resources (people, systems, facilities) they need to survive a disruption. Risk management feeds the BIA by providing data on what threats could cause those disruptions and how likely they are.

Disaster Recovery (DR) is a subset of Business Continuity. It specifically focuses on recovering IT infrastructure and systems after a major disaster that makes the primary site unusable. A disaster is an event that causes large-scale damage – a flood in the server room, a ransomware attack that encrypts all servers, a fire that destroys the data centre. The DR plan (DRP) details how to restore operations at an alternate site (like a backup data centre in another city) and how to get the data back from backups. The exam distinguishes between different types of backup sites:

The choice between these sites depends on the Recovery Time Objective (RTO) – how quickly you need the systems back – and the Recovery Point Objective (RPO) – how much data you can afford to lose (e.g., if your last backup was 24 hours ago, you could lose a whole day’s transactions). The organisation cannot afford the most expensive option for everything, so risk management helps prioritise: the most critical systems get a hot site with a low RTO and RPO, while less critical ones might use a warm or cold site.

Here is a simplified workflow showing how these plans interact:

The CRISC exam emphasises that risk management is the glue holding these three together. Without a risk assessment, the organisation would not know which threats to prepare for, what ‘critical’ even means, or how much to spend on backup sites. The risk professional’s role is not to write the BCP or DRP themselves but to ensure it is based on a sound risk assessment and to integrate risk considerations into every step of the planning and testing cycle.

Testing is another key exam topic. Plans are useless if they are never practised. Regular exercises – from simple tabletop discussions (where managers talk through a scenario) to full-scale simulation drills – reveal gaps, outdated contact lists, and incorrect assumptions. The test results then feed back into the risk management process to update the risk register and treatment plans.

Meet Maria, a risk manager at a mid-sized online retail company called ShopFast. The company has one primary data centre in a coastal city, and it processes about 10,000 orders per day. The Chief Information Security Officer (CISO) asks Maria to review the company's Incident Response, Business Continuity, and Disaster Recovery plans and integrate them with the existing risk management framework. Here is what Maria actually does.

First, Maria holds several interviews with department heads (IT, warehouse, customer service, finance). She asks them: “What are your biggest fears that could stop us from shipping orders for more than a day?” The IT team mentions a ransomware attack or a major server failure. The warehouse manager is worried about a fire in the warehouse. Maria records all these as potential risks in the risk register.

Next, Maria facilitates a Business Impact Analysis (BIA). She asks each department to estimate, for every critical process (like order processing, payment handling, customer support), what would happen if it were down for 1 hour, 4 hours, 24 hours, and 1 week. She collects data on the financial loss, reputational damage, and regulatory fines for each timeframe. She discovers that if payment processing is down for more than 2 hours, the company loses £50,000 per hour in revenue. She also finds that the order management system has an RTO of 4 hours – the business can survive without it for that long, but no longer. The RPO for the payment system is 15 minutes – the business can only afford to lose 15 minutes of transaction data.

Based on these risks and BIA findings, Maria recommends which systems get the most expensive protection. She proposes that the payment system be replicated in real-time to a cloud environment in a different region (a hot site). The order management system gets an intermediate solution (a warm site, with servers ready but data loaded from backups every 4 hours). The warehouse inventory system, which can survive a 24-hour outage, gets a cold site. Maria documents these risk treatment decisions in a report and presents them to the executive team for approval.

She then works with the IT security team to design the Incident Response plan. She ensures the plan includes specific triggers (e.g., “if more than 50 customers report a failed payment, treat this as a major incident”). She also makes sure the IR plan has a clear escalation path: first the IT helpdesk, then the security analyst, then the CISO, then the CEO for the most severe events. Maria insists that every incident is logged and that a post-incident review (lesson learned) is mandatory within 48 hours.

Maria’s role does not end with writing the plans. She schedules a tabletop exercise every quarter. In one exercise, the facilitator announces: “A fire has been detected in the main server room. All servers in the data centre are offline. What do you do?” The IT director immediately calls the DR hot site provider, while the customer service director announces the shutdown on the website. During the exercise, they discover that the DR contact list for the hot site provider is six months out of date – the phone number no longer works. Maria records this as a finding and updates the risk register, adding a control: the contact list must be verified monthly.

Finally, Maria prepares a quarterly risk report for the board. She includes a summary of the top threats, the status of the BCP/DRP tests, and any identified gaps. For example, the board learns that the ransomware risk rating increased after a test revealed that backups could not be restored within the required RTO. This prompts the board to authorise a budget for an improved backup solution.

In summary, Maria’s job is to make sure that when a crisis hits, the organisation is not panicking. Every decision – from which system gets a hot site to how often backups are tested – is traceable back to a risk assessment. The CRISC exam wants you to see this same logical chain: risk drives the plan, plans drive the exercises, and exercises drive the risk updates.

Key actions an IT professional does in this area: