Business Continuity & Incident Management interview questions

• Business continuity (BC): keeping critical business functions running during and after a disruption — people, processes, facilities, suppliers and technology. ISO 22301 is the main standard.
• Disaster recovery (DR): restoring IT systems, infrastructure and data after a disruption. DR is a subset of BC focused on technology.
• Incident response (IR): detecting, containing, eradicating and recovering from security incidents (e.g. malware, data breach).

They connect: a major cyber incident may trigger IR, then DR to restore systems, under the overall BC and crisis management plan.

A BIA identifies critical business processes and the impact over time of their disruption. It typically determines:

• Impacts (financial, operational, regulatory, reputational, patient/customer safety) at different time intervals.
• Maximum Tolerable Period of Disruption (MTPD, also called maximum tolerable downtime).
• Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
• Dependencies: systems, people, suppliers, facilities and data.
• Minimum resources needed to resume.

The BIA drives continuity strategy and DR investment.

• Recovery Time Objective (RTO): the target time to restore a process or system after disruption.
• Recovery Point Objective (RPO): the maximum acceptable amount of data loss, measured in time — e.g. an RPO of 1 hour means backups or replication must allow restoring to no more than 1 hour before the incident.
• Maximum Tolerable Period of Disruption (MTPD): the point after which the impact becomes unacceptable. RTO must be shorter than MTPD.

Shorter RTO and RPO usually mean higher cost (e.g. real-time replication vs nightly backups), so they should be justified by the BIA.

NIST SP 800-61 has long described the incident response lifecycle as:

1. Preparation: policies, plans, roles, tools, training, contact lists.
2. Detection and analysis: identify, validate, classify and prioritise incidents.
3. Containment, eradication and recovery: limit damage, remove the cause, restore normal operations.
4. Post-incident activity: lessons learned and improvements.

SP 800-61 Revision 3 (2024) re-frames incident response around the NIST CSF 2.0 functions, but the lifecycle above is still widely used. Other models (e.g. SANS PICERL) are similar.

A BCP documents how the organisation will continue critical activities during and after a disruption. Typical contents:

• Scope, objectives and the critical activities covered (from the BIA).
• Roles and responsibilities, including the crisis or incident management team and deputies.
• Activation criteria and escalation steps.
• Recovery strategies and workarounds for each critical activity (alternate site, manual processes, alternate suppliers).
• Contact lists, communication plans and resources needed.
• Testing, maintenance and review arrangements.

ISO 22301 sets requirements for a business continuity management system.

A tabletop exercise is a discussion-based session where the team walks through a realistic scenario and talks about how they would respond, without touching live systems.

• A facilitator presents the scenario in stages (injects), such as 'the attackers now threaten to publish data'.
• Participants explain decisions, roles and communications.
• It reveals gaps in plans, contacts, decision rights and coordination.
• It ends with an after-action report and improvement actions.

• 3-2-1: keep at least 3 copies of data, on 2 different media or storage types, with 1 copy off-site.
• Many now extend it to 3-2-1-1-0: one copy offline or immutable, and zero errors after restore verification.
• Immutable backups cannot be changed or deleted for a set period, even by administrators, which protects them against ransomware and malicious insiders.
• Backups must be tested by actual restores. An untested backup is only a hope.

1. Thank the user. Fast reporting is what you want, so never punish someone who reports.
2. The security team checks whether credentials were entered or a file was run.
3. If credentials were entered: reset the password, revoke sessions, check MFA prompts and mailbox rules, and review sign-in logs.
4. Search for the same email in other mailboxes and remove it.
5. Block the sender and malicious URLs.
6. Record the incident and use it (anonymised) in awareness.

Common test types, from least to most disruptive:

• Plan review / checklist: owners review the plan for accuracy.
• Tabletop exercise: discussion-based walkthrough of a scenario with key decision makers.
• Simulation / functional exercise: practising specific procedures under realistic conditions.
• Parallel test: recovery systems are brought up alongside production.
• Full interruption test: production is actually failed over (highest assurance, highest risk).

After each test, document results, gaps and actions, and update plans. Test at least annually and after significant changes.

• Event: any observable occurrence in a system or network (e.g. a failed login).
• Incident: an event or series of events that actually or potentially jeopardises confidentiality, integrity or availability, or violates security policy.
• Breach (data breach): an incident that results in unauthorised access to, disclosure, or loss of protected data, typically triggering legal notification analysis (e.g. HIPAA, GDPR, DPDP).

Not every incident is a breach, and the legal definition of 'breach' varies by law, so legal and privacy teams should be involved in the decision.

GRC is usually not the hands-on technical responder, but plays important roles:

• Making sure the incident response plan, roles and escalation paths are followed.
• Supporting the breach/notification assessment with legal and privacy (regulatory timelines, contractual notification duties to customers).
• Tracking decisions and evidence for regulators, auditors and insurers.
• Coordinating third-party notifications and obligations.
• After the incident: running lessons learned, updating the risk register, tracking corrective actions and reporting to leadership.

Purpose: understand what happened and why, and improve — not to assign blame.

• Hold it soon after the incident while details are fresh.
• Include all involved teams and relevant third parties.
• Build a timeline; identify what went well, what didn't, and the root causes (technical, process and people).
• Agree specific, owned, dated actions (e.g. new detections, playbook updates, training, control changes).
• Track actions to closure and feed findings into the risk register and future exercises.

• The incident response team (technical) handles detection, containment, eradication and recovery of the incident.
• The crisis management team (executive) handles the strategic impact: business decisions, stakeholder and media communication, legal and regulatory matters, customer impact and resources.
• They connect through a defined escalation path and a regular briefing rhythm.
• Not every incident is a crisis. Activation criteria decide when the crisis team is convened.

• Plan: purpose, scope, definitions and severity levels, roles (incident commander, technical lead, communications, legal, GRC), escalation, communication rules and evidence handling.
• Playbooks: step-by-step guides for common incident types, such as ransomware, BEC, data leakage, lost devices, DDoS and insider threats.
• Contacts: internal, external (forensics retainer, insurer, legal counsel, regulators, law enforcement).
• Notification matrix: which laws and contracts require notification, to whom and by when.
• Post-incident review and plan maintenance.

Forensic readiness means preparing in advance so that evidence can be collected and used effectively after an incident:

• Keep enough logs, for long enough, and protect their integrity (centralised, time-synchronised, tamper-resistant).
• Define how evidence is preserved, with chain of custody.
• Have a forensics retainer, ideally pre-approved by the insurer.
• Train first responders not to destroy evidence (for example, by wiping and rebuilding a machine too early).

• Validate both sides: is 4 hours a real business need (payroll runs monthly, so maybe 48 hours is fine near the payroll date), and is IT's 3 days based on a recent test?
• Discuss with the process owner what happens at each point: 4 hours, 1 day, 3 days, especially near payroll dates.
• If the gap is real, present options with costs: faster recovery architecture, manual workarounds (re-run the previous month's payroll), or accepting the risk.
• Record the agreed RTO and the decision, and retest.

1. Report quickly: the employee reports to IT/security and police; get a police reference.
2. Check the device status: was it encrypted, was MFA required, when did it last check in? Trigger remote lock or wipe.
3. Revoke sessions and reset credentials stored on the device.
4. Assess the data: what was stored locally, how sensitive, how many people.
5. Decide on notification. If the device was fully encrypted and the key was not compromised, many laws treat the data as protected (for example HIPAA's encryption safe harbour), but document the assessment.
6. Learn: is local storage of sensitive data necessary? Are encryption and MDM compliance enforced on every device?

• First, make sure production is safe and restore normal operations if the test affected them.
• Record exactly what failed, when and why. A failed test is valuable information, not a disaster.
• Run a short lessons-learned session with IT and business owners.
• Create corrective actions with owners and dates, and update the risk register (recovery capability is weaker than assumed).
• Schedule a retest, and inform governance of the result and the plan.
• Do not report it as a 'partial success' to leadership. Be honest about what it means for RTO.

• The BIA and supplier mapping should already identify critical suppliers and single points of failure.
• Activate the continuity plan for that dependency: alternate suppliers, emergency stock, mutual aid with other facilities.
• Communicate with clinical leaders about what is affected and for how long.
• Afterwards, review supplier diversification, stock levels and financial monitoring of critical suppliers (a TPRM link).

BCM is not only about IT. Supply chain disruptions are a common real-world continuity event.

• ISO 22301 provides the full business continuity management system: context, BIA and risk assessment, strategies, plans, exercising, evaluation and improvement.
• ISO 27001:2022 control 5.29 covers information security during disruption, and 5.30 (ICT readiness for business continuity) requires ICT readiness to be planned, implemented, maintained and tested based on business continuity objectives.
• Practically, the BIA sets RTO and RPO, and IT must prove its DR capability meets them through testing.
• One integrated programme avoids two inconsistent sets of recovery targets.

This is a business and legal decision for leadership, not a GRC or IT decision, but GRC prepares the decision framework:

• Legal: sanctions rules (paying a sanctioned group may be illegal), local laws and law enforcement guidance.
• Practical: payment does not guarantee decryption or deletion of stolen data, and may mark you as a repeat target.
• Insurance: policy terms, insurer involvement and approval.
• Recovery alternatives: are backups intact and how long will restore take?
• Patient safety and critical service impact.

Decide the principles in advance, in calm conditions, and document the decision during the incident.

• Support the incident commander. Do not run the technical response yourself.
• Start the decision log and the regulatory clock tracker (which laws, which authorities, which deadlines).
• Make sure patient safety is escalated: clinical leaders activate downtime procedures.
• Bring in legal counsel, the insurer and the forensics retainer through the agreed channels.
• Prepare short, factual updates for executives and the board at a set rhythm.
• Ensure evidence preservation is part of containment decisions.
• Track third parties affected or involved (vendors, HIE connections, customers).

• Explain the risk of announcing too early: if new facts appear (more data affected, attackers still present), the organisation loses credibility and may face regulatory criticism.
• Recommend factual, accurate wording: what is known, what is being done, and when the next update will be given.
• Check what notifications have been made and whether the public statement is consistent with them.
• Define 'resolved' with the IR team: containment confirmed, eradication validated, monitoring in place.
• Involve legal and communications in final wording.