Incident Response and Recovery

4.1 Understand and support incident response lifecycle

Core idea: incident sequence.

Scenario: A ransomware alert is confirmed on one endpoint and file-share encryption is still spreading.

Practitioner response: Contain the active spread, preserve evidence, escalate through the incident plan, then eradicate and recover from trusted backups.

Concepts to Understand

• preparation: preparation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• detection, analysis, and escalation: detection, analysis, and escalation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• containment: containment is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• eradication: eradication is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• recovery: recovery is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• post-incident activities: post-incident activities is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

4.2 Understand and support forensic investigations

Core idea: forensic handling.

Scenario: Operations wants to log in to a suspected compromised server and remove tools before legal decides whether evidence is needed.

Practitioner response: Preserve snapshots, logs, metadata, and chain of custody before changes alter the evidence state.

Concepts to Understand

• civil, criminal, administrative, and ethical principles: civil, criminal, administrative, and ethical principles is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• first responder responsibilities: first responder responsibilities is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• triage: triage is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• chain of custody: Chain of custody records who handled evidence, when, how it was protected, and whether integrity was preserved.
• scene preservation: scene preservation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• analysis reporting: analysis reporting is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• security policy compliance: security policy compliance is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

4.3 Understand and support BCP and DRP

Core idea: recovery planning.

Scenario: Backups meet RPO, but the identity system and DNS needed for failover have never been tested.

Practitioner response: Test full recovery dependencies against RTO and MTD, not only data restore time.

Concepts to Understand

• emergency response plans: emergency response plans is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• interim and alternate processing: interim and alternate processing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• RTO, RPO, and MTD: RTO is the time target for restoring service. It must include dependencies such as identity, DNS, backups, staff, and procedures.
• backup and redundancy implementation: backup and redundancy implementation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• playbooks, tabletops, DR exercises, and scheduling: playbooks, tabletops, DR exercises, and scheduling is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

identification vs containment vs eradication vs recovery

This comparison is covered through the domain objectives above and the SSCP review sheet.

RTO vs RPO vs MTD

Exam clue: Backups prove RPO only when restores are tested; they do not automatically meet RTO.

backup vs replication

This comparison is covered through the domain objectives above and the SSCP review sheet.

Hot vs Warm vs Cold Recovery Sites

Exam clue: Choose based on RTO/MTD and cost tolerance, not on the most impressive architecture.