Skip to content

FRM Exam Part II · Case Study: Cyberthreats and Information Security Risks

Incident Response, Resilience and Recovery for Cyber Risk

Updated 11 October 2026 · Fact-checked

Incident response is the planned process a firm follows to detect, contain, eradicate and recover from a cyber incident, and to communicate and learn from it. Resilience is the ability to keep critical services running within set tolerances. RTO is the maximum time to restore a service; RPO is the maximum acceptable data loss, measured in time.

Understand Incident Response, Resilience and Recovery

A cyber incident is an event that harms the confidentiality, integrity or availability of systems or data. You cannot prevent every attack. So a bank plans for the day controls fail. That planning has three linked parts: incident response, business continuity and resilience.

Incident response is the tactical playbook. A common sequence is: prepare, detect and analyse, contain, eradicate, recover, and review lessons learned. Preparation comes first. It means defined roles, tested playbooks, logging, contact lists and decision authority. Containment limits spread (for example, isolating infected servers). Eradication removes the cause (malware, compromised accounts, exploited weakness). Recovery restores systems safely and checks they are clean.

Business continuity and disaster recovery keep critical business services running or bring them back. You start with a business impact analysis. It identifies critical services and sets recovery targets. RTO (recovery time objective) is how long a service can be down. RPO (recovery point objective) is how much data you can afford to lose, expressed as time since the last good copy. A one-hour RPO needs backups or replication at least hourly. Tight RTO and RPO cost more, so you set them by criticality.

Resilience goes further than recovery. It asks whether the firm can keep delivering critical operations through disruption, within an impact tolerance (the maximum disruption the firm will accept). It uses scenario testing of severe but plausible events, including those that hit third parties. Cyber events differ from fires or floods: backups can be corrupted and the attacker may still be inside, so recovery needs immutable or offline backups and clean-room restoration.

Communication matters as much as technology. Firms need clear internal escalation to senior management and the board, plus timely contact with regulators, customers, law enforcement and providers. Poor or late communication turns a technical event into a reputational and regulatory one. After the incident, a post-incident review feeds lessons back into controls, plans and testing.

Key formulas to remember

Incident response lifecycle
Prepare → Detect and analyse → Contain → Eradicate → Recover → Learn
Order matters. Containment comes before eradication, and recovery only after the threat is removed.
RTO
RTO = maximum tolerable time to restore a service after disruption
A time-to-restore target. It drives choices such as hot, warm or cold standby.
RPO
RPO = maximum tolerable data loss, measured as time back to the last good copy
Backup or replication interval must be no longer than the RPO.
Impact tolerance
Impact tolerance = maximum disruption to a critical service the firm will accept
A resilience concept. Recovery targets should sit inside it.
Relationship check
Backup interval ≤ RPO; actual restore time ≤ RTO ≤ impact tolerance
Use to test whether a design meets its targets.

How to solve Incident Response, Resilience and Recovery questions

Use this method for any scenario question on response, recovery or resilience.

  1. 1Identify the stage: preparation, detection, containment, eradication, recovery or review.
  2. 2Identify the critical service and what is affected: availability, integrity or confidentiality.
  3. 3Decide the priority action for that stage. Containment usually comes before restoring, and eradication before full recovery.
  4. 4If recovery targets appear, separate time (RTO) from data loss (RPO) and compare design values to the targets.
  5. 5Check communication needs: escalation, regulators, customers, third parties.
  6. 6Consider resilience: impact tolerance, testing, dependencies and backup integrity.
  7. 7Eliminate options that skip a stage, ignore governance or treat prevention as enough.
  8. 8Pick the option that is timely, proportionate and consistent with the firm's plan.

Quickest way: Stage, target, then communication

When to use it: When you have about a minute per question and the options look similar.

  1. Name the stage in the scenario.
  2. Pick the answer that fits that stage in the standard sequence.
  3. If you see time or data loss, map time to RTO and data loss to RPO.
  4. Prefer answers with tested plans, escalation and learning over one-off fixes.
  5. Reject answers that say the incident is solved by prevention alone or that delay informing decision makers.

Common mistakes in Incident Response, Resilience and Recovery

  • Mixing up RTO and RPO.

    Both are time values, so they look alike.

    Fix: RTO is how long you can be down. RPO is how far back your data can go. Ask: restore time or lost data?

  • Restoring systems before containing the threat.

    Pressure to bring services back quickly feels natural.

    Fix: Contain and eradicate first. Restoring into a compromised environment lets the attacker return.

  • Assuming backups are always safe.

    Backups work well for hardware failure and disasters.

    Fix: In cyber events, backups can be encrypted or corrupted. Look for offline or immutable copies and integrity checks.

  • Treating business continuity and resilience as the same thing.

    Both deal with disruption.

    Fix: Continuity restores operations after disruption. Resilience is the wider ability to deliver critical services within impact tolerance, including third-party dependencies and testing.

  • Ignoring communication in the answer.

    Candidates focus on technical steps.

    Fix: Include escalation to the board, regulator and customer notification, and consistent messaging.

  • Skipping the post-incident review.

    The incident seems over once systems are back.

    Fix: Lessons learned feed controls, plans and tests. Finish every response with a review.

Worked examples

Example 1

A bank's payment system has an RTO of 2 hours and an RPO of 15 minutes. Its database is backed up every 30 minutes, and a test restore took 3 hours. Which statement is correct?

Show the solution
  1. Check RPO: the backup interval is 30 minutes, so up to 30 minutes of data could be lost.
  2. 30 minutes is greater than the 15-minute RPO, so the RPO is not met.
  3. Check RTO: the test restore took 3 hours, which exceeds the 2-hour RTO.
  4. So both targets fail.

Answer: Neither target is met. The backup interval (30 min) exceeds the RPO (15 min) and the restore time (3 hours) exceeds the RTO (2 hours). The bank needs more frequent backup or replication and faster restoration.

Example 2

A bank detects ransomware encrypting servers in its trading operations. Systems are still spreading infection. Which action should the response team take first: restore from last night's backup, isolate affected systems, publish a customer statement, or run the post-incident review?

Show the solution
  1. Identify the stage: the threat is active and spreading, so the team is at detection and containment.
  2. Restoring now would put clean data into an environment still under attack.
  3. A customer statement matters, but it follows an initial assessment and escalation and does not stop the spread.
  4. A post-incident review belongs at the end of the lifecycle.
  5. Isolating affected systems limits the damage and protects other services.

Answer: Isolate the affected systems (containment). Then eradicate the threat, restore from verified clean backups, communicate with stakeholders and hold the review.

Exam tips

  • Questions often give numbers: backup interval, restore time, RTO, RPO. Compare them directly.
  • Read the stage in the scenario. The correct answer usually matches the next step in the lifecycle.
  • Watch for options that suggest paying a ransom, or restoring before containment, as the first move. These are rarely the best answer.
  • For resilience questions, look for impact tolerance, severe but plausible scenario testing and third-party dependencies.
  • Link this topic to operational resilience and business continuity in the operational risk section; the same concepts appear in both.

Practice questions from Case Study: Cyberthreats and Information Security Risks

Incident Response, Resilience and Recovery in other exams

The same ground in other exams, if you are preparing for more than one or want another angle on it.

Incident Response, Resilience and Recovery: frequently asked questions

What is the difference between RTO and RPO?

RTO is the longest time a service can be down before the impact is unacceptable. RPO is the longest period of data loss you can accept, measured back from the incident to the last good copy. RTO is about downtime; RPO is about data.

What are the main steps of an incident response plan?

A common sequence is preparation, detection and analysis, containment, eradication, recovery and post-incident review. Communication and escalation run through all stages. Exact labels vary by framework, but the order of ideas is consistent.

How is cyber resilience different from cyber security?

Cyber security focuses on preventing and detecting attacks. Cyber resilience accepts that some attacks will succeed and aims to keep critical services within impact tolerance and recover fast. It adds testing, continuity planning and communication.

How do banks build cyber resilience?

They identify critical services, set impact tolerances and recovery objectives, and keep tested response and recovery plans. They use protected backups, test severe but plausible scenarios, manage third-party dependencies and learn from incidents.