Preparation, Playbooks, and Escalation
Key Takeaways
- Preparation defines roles, contacts, tools, authority, and procedures before an incident occurs.
- An incident response plan and a computer security incident response team (CSIRT) are established during preparation, not during a crisis.
- Playbooks provide repeatable steps for common incident types such as phishing, malware, lost devices, and account compromise.
- Severity levels drive escalation: they decide urgency, who is notified, and which management approvals are required.
- A beginner responder should follow the playbook, document every action, and escalate when impact or required authority exceeds their role.
Preparation Before the Incident
Incident response succeeds or fails before the first alert. Preparation means the organization has already decided who responds, how they communicate, what tools they use, what evidence they preserve, and who has authority to take disruptive actions. A beginner analyst may not write the plan, but must understand why it exists and how to follow it.
Two artifacts are created during preparation and tested heavily on the CC exam. The incident response plan (IRP) is the formal document defining scope, roles, severity criteria, and procedures. The computer security incident response team (CSIRT) is the named group — often mixing security, IT, legal, human resources, and communications — that executes the plan. Both must exist before an emergency; you cannot assemble a team mid-ransomware.
Preparation also covers contact lists, on-call schedules, logging coverage, asset inventories, backup procedures, and basic tools. A plan nobody has practiced is only a document, so teams run tabletop exercises: a facilitator walks the CSIRT through a scenario (a compromised payroll account, say) and validates decisions without a real outage.
Playbooks
A playbook is a step-by-step guide for one common incident type. It does not replace judgment; it gives a known starting point so responders are not inventing steps under stress.
| Playbook | Common first questions |
|---|---|
| Phishing | Who received it, who clicked, were credentials entered? |
| Malware | Which hosts are affected, is it spreading, what process or file is suspicious? |
| Lost or stolen device | Was it encrypted, can it be remotely locked or wiped, what data was stored? |
| Account compromise | What logins occurred, are sessions active, were mailbox or MFA settings changed? |
| Data exposure | What data, who accessed it, what notification rules may apply? |
Escalation and Severity
Escalation is not failure — it routes a decision to someone with the correct authority and skill. A help desk technician may disable an account but cannot approve taking a revenue system offline. An analyst may collect logs but needs legal approval to contact law enforcement. A communications manager owns public statements because inaccurate messages can increase harm.
Escalation depends on severity, which weighs business impact, data sensitivity, number of systems affected, attacker activity, regulatory obligation, and public visibility. A simple ladder helps beginners decide:
| Severity | Example | Typical escalation |
|---|---|---|
| Low | One blocked malware file, no execution | Analyst handles, logs ticket |
| Medium | Single account compromise, contained | Notify IR lead |
| High | Active ransomware across multiple servers | Activate CSIRT, notify management immediately |
| Critical | Confirmed breach of regulated data | Engage legal, privacy, executives, possibly regulators |
Scenario: Suspicious Email to Finance
A finance clerk reports an email appearing to come from the CFO requesting an urgent wire transfer, with an attachment and an external reply-to address — a classic business email compromise. A prepared team follows the phishing playbook: preserve headers, check whether others received it, search email-security logs, block the sender or domain, and ask finance whether any transfer occurred. Escalation triggers if money moved, credentials were entered, executives are impersonated, or many users received it.
The analyst must not mass-email the company with dramatic wording; users need accurate instructions through approved channels, not rumors.
What Beginners Should Do
Know the boundary of your role. Follow the playbook. Record what you observed, when, and what action you took. Preserve evidence before making changes when practical. Escalate when the incident touches sensitive data, critical systems, many users, legal obligations, physical safety, or actions beyond your authority.
How Preparation Connects to Business Continuity
The CC exam pairs incident response with business continuity (BC) and disaster recovery (DR) in the same domain, so it expects you to see the connection. Preparation produces the artifacts all three rely on:
| Artifact | Purpose | Owner |
|---|---|---|
| Incident response plan (IRP) | Steps to detect, contain, and recover from incidents | Security / CSIRT |
| Business continuity plan (BCP) | Keep critical functions running during disruption | Business units |
| Disaster recovery plan (DRP) | Restore IT systems and data after major loss | IT operations |
| Tested backups | Provide a clean restore point for recovery | IT operations |
Two recovery metrics frequently appear. The recovery time objective (RTO) is the maximum acceptable time to restore a function. The recovery point objective (RPO) is the maximum acceptable amount of data loss, measured in time — an RPO of one hour means backups must be no older than one hour. A responder who restores from a backup that violates the RPO may bring back stale or already-compromised data, so preparation includes choosing and testing backups that meet these targets.
Beginner Exam Focus
On the exam, the best answer uses a prepared process: identify, document, contain, coordinate, and communicate through correct channels. Watch for traps where a single person acts far beyond their authority, skips the plan, or pays a ransom without management approval. The disciplined, escalate-when-appropriate answer almost always wins.
What is the main purpose of an incident response playbook?
A help desk technician finds evidence that ransomware is spreading across multiple file servers. What should happen next?
Which activity is created during the preparation phase so a team can execute coordinated response later?