Domain 4: Incident Management
Arrow keys or space to move, F for full screen. Read the notes
Incident Management
28 topics · Incident readiness · Business continuity · Disaster recovery · Training and testing · Detection and investigation · Containment and communication · Recovery and review
D4Event vs Incident vs Breach
The vocabulary of incident management: what separates an event from an incident and an incident from a breach, why the distinctions matter legally and operationally, and how incident management differs from business continuity.
Getting the words right
Security teams see millions of events a day. A handful are incidents, and very few are breaches. Using the words precisely decides who gets woken up, which plans start, and when legal deadlines begin.
Three levels
Examples
| Situation | Classification |
|---|---|
| A user mistypes a password twice | Event |
| 10,000 failed logins against one account | Event; possible incident (brute force) |
| Malware found on a laptop and contained | Incident |
| Ransomware encrypts file servers | Incident (major) |
| Attacker exfiltrates customer records | Incident and data breach |
Why the distinctions matter
EscalationIncidents trigger the response plan; events usually don't.
Legal clocksBreach notification deadlines start at awareness.
ResourcesMajor incidents bring in executives, legal, communications.
EvidenceIncidents may need forensic preservation from the start.
ExampleAn analyst sees unusual outbound traffic and records it as an event. A day later, legal learns it was customer data leaving the network. Because the incident was classified late, the company has less than 24 hours left of GDPR's 72-hour window.
Incident management vs continuity
- 1Incident management: detect, contain, eradicate, recover, learn.
- 2Business continuity: keep critical processes running during disruption.
- 3Disaster recovery: restore IT systems and data.
- 4A major incident can trigger all three; the plans must link.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Any observable occurrence | Event |
| Harm or threat to CIA | Security incident |
| Confirmed unauthorised access to protected data | Data breach |
| Why classify quickly | Escalation and legal deadlines |
| Main goal of incident management | Limit damage and restore normal operations |
Key takeaways
- ✓An event is any observable occurrence; most are harmless.
- ✓A security incident is an event or series of events that harms, or threatens to harm, confidentiality, integrity or availability.
- ✓A data breach is an incident where protected data is confirmed to have been accessed, disclosed or lost without authority; it often triggers legal notification duties.
- ✓Clear definitions decide what gets escalated, who is involved and which clocks start, such as GDPR's 72 hours.
- ✓Incident management aims to limit damage and restore normal operations; business continuity keeps critical processes running during major disruption.
- ✓Domain 4 is 29% of the exam: readiness (plans, BIA, BCP, DRP, classification, testing) and operations (detect, investigate, contain, communicate, recover, review).
Exam traps
- !Not every event is an incident, and not every incident is a breach.
- !Calling something a 'breach' too early can trigger legal consequences; involve legal before declaring one.
- !The notification clock usually starts at awareness of a breach, so classification must be quick.
- !Incident response and business continuity are linked but different plans.
Developing the Incident Response Plan
How the security manager builds an incident response plan: its purpose, contents, the life cycle it supports, and how it aligns with business continuity and disaster recovery plans.
Plan before you need it
Incidents happen at the worst times, under pressure, with incomplete information. A plan agreed in calm conditions tells people what to do, who decides, and who to call, so the first hours aren't wasted arguing.
The incident life cycle
What the plan contains
Developing the plan
- 1 Sponsor Senior management commitment
- 2 Inputs Risk assessment, BIA, laws, past incidents
- 3 Draft With IT, legal, HR, comms, business
- 4 Approve Senior management
- 5 Train and test Tabletops, simulations
- 6 Maintain After incidents, tests, changes
Aligning with BCP and DRP
Incident responseInvestigate, contain, eradicate the threat.
Disaster recoveryRestore systems and data, from clean backups.
Business continuityKeep critical processes running meanwhile.
Shared triggersAgree when an incident escalates into BCP/DRP.
ExampleDuring a ransomware attack, the IR team contains the spread while DR restores finance systems from immutable backups and the BCP moves order-taking to manual forms. Because the three plans share a declaration process and contact list, they run in parallel without confusion.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most important phase of incident response | Preparation |
| Who approves the incident response plan | Senior management |
| The IRP must align with… | The BCP and DRP |
| Where to keep plan copies | Accessible offline / out of band |
| When to update the plan | After incidents, tests and significant change |
Key takeaways
- ✓Establishing and maintaining an incident response plan aligned with the BCP and DRP is a CISM task.
- ✓The plan defines scope and definitions, roles and authority, procedures, communication and escalation, tools and resources, and links to BCP and DRP.
- ✓It supports the incident life cycle: prepare, detect and analyse, contain, eradicate, recover, and learn.
- ✓Senior management approves the plan, giving the team the authority it needs during a crisis.
- ✓Preparation is the most important phase: plan, team, tools, contacts and practice before anything happens.
- ✓The plan is tested, reviewed after incidents and exercises, and kept available offline.
Exam traps
- !A plan written during an incident is too late.
- !A plan without defined authority leads to arguments when fast decisions are needed.
- !Storing the only copy on systems an incident could take down makes it useless.
- !The IRP, BCP and DRP must be aligned; a ransomware attack can trigger all three.
Incident Response Team Roles and Authority
Who belongs on the incident response team, what each role does, how teams are structured and staffed, and why authority must be agreed before an incident.
More than a technical team
A serious incident pulls in far more than the security team: lawyers about notification, communications about customers, executives about shutting down revenue-earning systems. The team and its authority are agreed in advance, so nobody has to ask permission at 3 a.m.
Who's on the team
Decide authority in advance
| Decision | Who has authority (example) |
|---|---|
| Isolate an infected server | Incident manager / SOC lead |
| Take a customer-facing service offline | Executive sponsor (or delegate) |
| Notify the regulator | Legal with executive approval |
| Involve law enforcement | Legal and executive sponsor |
| Engage the IR retainer | CISO |
Team models
Equipping the team
- 1Named members and deputies with current contact details.
- 2Out-of-band communication (phones, separate chat).
- 3Tools and access ready: EDR, logs, forensics, cloud consoles.
- 4Retainers: IR firm, legal counsel, cyber insurer hotline.
- 5Training and regular exercises.
ExampleDuring a weekend ransomware attack, the IR team can't reach the CIO, and nobody else knows whether they may shut down the ERP. Six hours pass. Afterwards, the plan names deputies for every role and gives the incident manager authority to isolate any system immediately.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most important thing to define before an incident | Roles, responsibilities and authority |
| Non-technical members of the IR team | Legal, communications, HR, executive sponsor |
| Benefit of an IR retainer | Expert help available quickly in major incidents |
| Contact lists should be… | Current and accessible out of band |
| Who leads the response | The incident manager |
Key takeaways
- ✓Organising, training, equipping and assigning responsibilities to incident response teams is a CISM task.
- ✓The team includes an incident manager, technical responders and business functions: legal, communications, HR, an executive sponsor and external partners.
- ✓Authority must be defined in advance: who can isolate systems, shut down services, call law enforcement or approve notifications.
- ✓Team models: central, distributed, or hybrid with an external IR retainer for major incidents.
- ✓Every role needs a named deputy and up-to-date contact details, including out-of-band channels.
- ✓Equip the team before incidents: tools, access, forensic capability, retainers and documentation.
Exam traps
- !Without pre-agreed authority, containment is delayed while people argue.
- !Incident response isn't only technical; legal and communications are core members.
- !Contact lists stored only in email or chat fail if those systems are compromised.
- !An IR retainer arranged during an incident costs more and arrives later.
Incident Classification and Severity Levels
How incidents are categorised by type and rated by severity, so the right people respond at the right speed, and how classification supports reporting and trend analysis.
Why classify?
Not every incident deserves a midnight call to the CEO, and some do. Classification decides how fast to respond, who gets involved and who must be told. Agreed in advance, it removes guesswork when the clock is running.
Severity levels
What drives severity
Categories
| Category | Examples |
|---|---|
| Malware | Ransomware, trojans, worms |
| Unauthorised access | Compromised accounts, intrusions |
| Data loss or leakage | Misdirected email, exfiltration, lost device |
| Denial of service | DDoS, resource exhaustion |
| Insider misuse | Abuse of legitimate access |
| Physical | Theft of equipment, unauthorised entry |
Re-rate as facts emerge
Severity is a live judgement, reviewed at each update.
ExampleA phishing click on one laptop is logged as Medium. Two hours later, the investigation shows the attacker used the stolen session to access the finance mailbox and set up forwarding rules. The incident is upgraded to High, the CFO is informed, and legal starts assessing notification.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main basis for incident severity | Business impact |
| Why define severity levels in advance | Consistent, timely response and escalation |
| New facts show greater impact | Re-classify and escalate |
| Benefit of consistent categories | Trend analysis and reporting |
| What severity determines | Response time, responders, notifications |
Key takeaways
- ✓Establishing and maintaining an incident classification and categorisation process is a CISM task.
- ✓Categories describe the type (malware, unauthorised access, data loss, denial of service, insider, physical); severity describes the business impact.
- ✓Severity criteria are agreed in advance: data involved, systems affected, scope and spread, business impact, legal and reputational exposure.
- ✓Each severity level sets response times, who responds, who is notified and when to escalate to BCP or DRP.
- ✓Severity is reassessed as facts emerge; incidents can be upgraded or downgraded.
- ✓Consistent categories make trend analysis and reporting possible.
Exam traps
- !Severity is about business impact, not how technically interesting an incident is.
- !Rating an incident once and never revisiting it leads to under-response.
- !Without agreed criteria, different analysts rate similar incidents differently.
- !Vague categories ('other') make trend analysis useless.
Incident Response Playbooks and Decision Trees
How playbooks translate the incident response plan into specific, repeatable steps for common incident types, with clear decision points, owners and escalation.
From plan to first moves
The incident response plan describes the overall approach. Under pressure, responders need something more concrete: for this type of incident, what do we do first, what do we check, and who decides the hard questions? That's a playbook.
A ransomware playbook
What a playbook contains
TriggerWhich alerts or reports start this playbook.
First actionsThe first 15-60 minutes, step by step.
Decision pointsEach with an owner and the criteria.
CommunicationsWho to inform, when, using which templates.
EvidenceWhat to preserve, and how.
Recovery and closeCriteria for returning to normal.
Which playbooks first?
| Incident type | Why prioritise |
|---|---|
| Ransomware | High impact; very likely |
| Business email compromise | Common; direct financial loss |
| Compromised account / credentials | Most common initial access |
| Data loss / exfiltration | Legal notification duties |
| Cloud misconfiguration exposure | Common; fast-moving |
Automation with guardrails
- 1SOAR runs routine steps: enrich alerts, block known-bad indicators, open tickets.
- 2Humans decide high-impact actions: shutting down services, notifications.
- 3Automated containment has limits and an override.
ExampleThe phishing playbook is partly automated: when a user reports a phish, SOAR pulls matching emails from all mailboxes and blocks the sender within minutes. Resetting passwords for users who clicked still needs analyst approval.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Document with step-by-step actions for an incident type | Playbook |
| Which playbooks to write first | Most likely and most damaging incident types |
| Benefit of decision trees | Fast, consistent decisions with clear owners |
| Role of SOAR | Automate routine response steps |
| How to keep playbooks effective | Test in exercises; update after use |
Key takeaways
- ✓The plan sets the framework; playbooks give step-by-step actions for specific incident types such as ransomware, phishing, data loss or account compromise.
- ✓Playbooks include triggers, first actions, containment options, decision points with owners, communication steps and recovery criteria.
- ✓Decision trees make hard choices (shut down? notify? involve law enforcement?) quick and consistent.
- ✓Playbooks are prioritised by risk: write them first for the most likely and most damaging incidents.
- ✓Automation (SOAR) can run routine playbook steps, with humans deciding the high-impact ones.
- ✓Playbooks are tested in exercises and updated after every real use.
Exam traps
- !A playbook can't cover every situation; responders still need judgement and the authority to deviate.
- !Untested playbooks fail on details: wrong contacts, missing access, outdated systems.
- !Automating containment without guardrails can cause outages.
- !Playbooks that ignore legal and communication steps leave the organisation exposed.
Escalation and Communication Plans
How the security manager plans incident communications in advance: escalation paths and timings, internal and external audiences, approved templates, and secure channels that still work during an attack.
Decide who talks, before you need to
In an incident, information is incomplete and pressure is high. Without a plan, executives hear about it from the news, staff speculate on social media, and regulators get notified late. A communication plan decides in advance who is told what, when, how and by whom.
Escalation by severity
Audiences and owners
| Audience | Owner | Typical content |
|---|---|---|
| Executives and board | CISO / incident manager | Facts, impact, decisions needed |
| Staff | Communications / HR | What to do and not do; don't speculate |
| Regulators | Legal / compliance | Required notifications on time |
| Customers and partners | Communications with legal | What happened, impact, what to do |
| Insurer | Legal / risk | Notice per policy terms |
| Media | Designated spokesperson | Approved statements only |
Prepared and protected
TemplatesPre-approved drafts for common scenarios.
SpokespeopleNamed people authorised to speak externally.
Out-of-band channelsPhone bridge, separate chat, printed contact list.
Legal reviewExternal statements checked before release.
ExampleDuring a breach, attackers still have access to corporate email. The response team switches to a pre-arranged secure messaging group and phone bridge, so the attacker can't read the response plan as it unfolds.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who speaks to the media | Designated, authorised spokespeople |
| Email may be compromised | Use out-of-band communication |
| Why pre-approve templates | Faster, accurate, legally reviewed messages |
| Who handles regulator notification | Legal / compliance, with executive approval |
| Basis for escalation timings | Incident severity, defined in the plan |
Key takeaways
- ✓Establishing and maintaining incident communication plans for internal and external parties is a CISM task.
- ✓Escalation paths and timings are defined by severity, so the right people learn in time without debate.
- ✓Communication plans cover internal audiences (staff, executives, board) and external ones (regulators, customers, partners, insurers, law enforcement, media).
- ✓Pre-approved templates and designated spokespeople speed communication and keep it accurate.
- ✓Out-of-band channels are essential: email and chat may be compromised or down.
- ✓Legal reviews external statements; only authorised people speak externally.
Exam traps
- !Staff shouldn't talk to the media or the attacker unless authorised.
- !Using compromised email to coordinate the response tips off the attacker.
- !Escalating too late can miss legal deadlines and leave leaders blindsided.
- !Silence or inaccurate statements damage trust more than prompt, honest updates.
Business Impact Analysis
How the BIA identifies critical business processes, measures how disruption hurts over time, sets recovery priorities and objectives, and maps the dependencies that recovery needs.
What would hurt most, and how fast?
If everything stopped tomorrow, what would you restore first? The BIA answers that question with evidence. It looks at each business process, asks how damage grows the longer it's down, and turns the answers into recovery priorities everyone agrees on.
The BIA steps
Impact grows over time
| Process | 4 hours | 1 day | 1 week |
|---|---|---|---|
| Online payments | Lost sales 200k | Lost sales 1.2m; complaints | Regulator; customers leave |
| Payroll | None | Minor | Staff unpaid; legal breach |
| Marketing website | None | Minor | Moderate reputation |
Criticality and dependencies
ExampleThe BIA shows order processing is critical with an MTD of 8 hours. Mapping dependencies reveals it relies on a payment gateway, the identity service, two key staff who know the batch jobs, and a single label printer supplier. All four go into the recovery plan.
Who provides what
Process ownersImpact, timings, workarounds, dependencies.
ITSystem dependencies and current recovery capability.
Security managerFacilitates; links to risk and incident plans.
Senior managementValidates priorities and objectives.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Primary purpose of a BIA | Identify critical processes and impact to set recovery priorities |
| Main source of BIA information | Business process owners |
| Outputs used to plan recovery | MTD, RTO and RPO per process |
| BIA vs risk assessment | BIA: impact. Risk assessment: threats and likelihood |
| When to update the BIA | Periodically and after major business change |
Key takeaways
- ✓The business impact analysis (BIA) identifies critical processes, the impact of disruption over time, and the resources they depend on.
- ✓It produces recovery priorities and objectives (MTD, RTO, RPO) that drive incident response, BCP and DRP.
- ✓Impact includes financial loss, regulatory penalties, customer harm, reputation and safety, assessed at intervals (hours, days, weeks).
- ✓Information comes from business process owners, through interviews, questionnaires and workshops; senior management validates the results.
- ✓Dependencies (systems, data, people, suppliers, sites) must be mapped, or recovery stalls.
- ✓The BIA is reviewed periodically and after major business change.
Exam traps
- !The BIA is about business impact, not threats; identifying threats is the risk assessment.
- !Process owners, not IT, are the main source of BIA information.
- !IT systems inherit their recovery priority from the processes they support.
- !A BIA that ignores suppliers and key people produces plans that can't be executed.
RTO, RPO, MTD and Recovery Prioritisation
The recovery objectives that come out of the BIA, what each one drives, and how the security manager balances recovery speed against cost.
Two questions after a disaster
The definitions
| Objective | Meaning | Drives |
|---|---|---|
| RPO | Maximum data loss, in time | Backup and replication frequency |
| RTO | Maximum time to restore | Recovery strategy and site |
| MTD | Longest outage before unacceptable harm | Upper limit for RTO |
| SDO | Service level during recovery | Recovery capacity |
| MTO | Longest time in recovery mode | How long alternate arrangements must last |
Finding the right balance
Recovery order
- 1 Foundations Network, identity, DNS, security tools
- 2 Critical apps Lowest RTO first
- 3 Data Restore and reconcile to RPO
- 4 Other services By priority
ExampleAfter a ransomware attack, the team restores the ERP first, as the BIA says, but users can't log in: the identity service hasn't been rebuilt. Four hours are lost. The DR plan is revised to restore identity, DNS and network services first.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Metric that sets backup frequency | RPO |
| Metric that sets the recovery site type | RTO |
| Relationship of RTO to MTD | RTO must be less than MTD |
| RPO of zero requires | Synchronous replication / mirroring |
| How to choose recovery targets | Balance downtime cost against recovery cost |
Key takeaways
- ✓Recovery point objective (RPO): the maximum acceptable data loss, measured in time; it drives backup and replication frequency.
- ✓Recovery time objective (RTO): the maximum acceptable time to restore a system or process; it drives the recovery strategy and site.
- ✓Maximum tolerable downtime (MTD): the longest a process can be down before damage is unacceptable; RTO must be shorter than MTD.
- ✓Service delivery objective (SDO) is the reduced service level acceptable during recovery; maximum tolerable outage (MTO) is how long you can run in that mode.
- ✓Lower RTO and RPO cost more; the best strategy balances the cost of downtime against the cost of recovery.
- ✓Recovery is prioritised by business criticality, respecting dependencies (identity and network before applications).
Exam traps
- !RPO is about data (how far back); RTO is about time (how fast). Don't swap them.
- !An RPO of zero needs synchronous replication; daily backups give up to 24 hours of loss.
- !Shorter isn't automatically better; targets must be justified by the cost of downtime.
- !Restoring applications before the identity service and network they depend on wastes time.
Business Continuity Planning and Strategies
How business continuity keeps critical processes running through disruption: the BCP life cycle, strategies for losing sites, IT, people or suppliers, and how the BCP fits with incident response and DR.
Keeping the business running
The BCP life cycle
Continuity strategies
What the plan contains
- 1Activation criteria and who can declare.
- 2Roles, teams and deputies.
- 3Procedures for critical processes, including manual workarounds.
- 4Contact lists: staff, suppliers, customers, authorities.
- 5Resources needed and where to find them.
- 6How to return to normal operations.
An example
Good strategies combine options across site, IT, people and suppliers.
ExampleA logistics firm loses its main warehouse system for two days. Its BCP switches dispatch to printed pick lists and phone orders (manual workaround), moves the customer service team to work from home (site), and routes urgent deliveries through a partner's depot (supplier). Revenue dips, but no customer order is lost.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step after management commitment | Business impact analysis |
| Who is accountable for continuity | Senior management |
| BCP vs DRP | BCP: business processes. DRP: IT systems and data |
| Standard for business continuity management | ISO 22301 |
| Most important ongoing activity | Testing and maintenance |
Key takeaways
- ✓Business continuity planning (BCP) keeps critical business processes running, or resumes them, after a disruption; DR focuses on restoring IT.
- ✓The BCP life cycle: policy and scope, BIA, risk assessment, strategy, plan development, training, testing and maintenance.
- ✓Strategies cover loss of site, IT, people and suppliers, chosen to meet the BIA's objectives at acceptable cost.
- ✓Senior management is accountable for continuity; process owners own their recovery requirements.
- ✓The BCP aligns with the incident response plan and DRP, with shared triggers and contacts.
- ✓ISO 22301 is the international standard for business continuity management systems.
Exam traps
- !BCP isn't just IT recovery; people, sites, processes and suppliers count too.
- !The first step after management commitment is the BIA, not choosing a recovery site.
- !A plan that's never tested gives little assurance.
- !Plans stored only on systems that may be down are useless; keep copies accessible offline.
Crisis Management and Continuity Governance
How organisations manage a crisis at executive level: the strategic-tactical-operational structure, the crisis team's decisions, and the governance that keeps continuity plans current.
When an incident becomes a crisis
Most incidents are handled by the IR team. A crisis is different: it threatens the organisation itself, its finances, reputation, safety or licence to operate. Decisions then belong to executives, and they need a structure that lets them decide quickly without getting lost in technical detail.
Three levels of response
What the crisis team decides
OperationsShut down services, move to manual, close sites.
MoneyEmergency spending; ransom decisions with legal advice.
StakeholdersRegulators, customers, investors, staff.
ReputationPublic statements, timing, tone.
ExampleA water utility's control system is attacked. The crisis team (CEO, COO, legal, communications, CISO) decides to switch treatment plants to manual operation, notifies the regulator within the hour, and issues a public statement that water is safe, while the IR team investigates.
Continuity governance
- 1Policy approved by senior management.
- 2Named owners for each plan.
- 3Testing schedule tracked and reported.
- 4Plans updated after changes, tests and incidents.
- 5Internal audit reviews the program.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First priority in any disaster | Safety of people |
| Who leads crisis decisions | Executive crisis management team |
| Strategic level of response | Crisis management team |
| Who speaks publicly | Designated spokesperson |
| How to prepare the crisis team | Regular exercises |
Key takeaways
- ✓A crisis threatens the organisation as a whole (finances, reputation, safety, licence to operate) and needs executive leadership.
- ✓Response is organised in three levels: strategic (crisis management team), tactical (incident and continuity coordination), operational (response and recovery teams).
- ✓The crisis team makes business decisions: shutting down operations, paying or not, public statements, regulator engagement.
- ✓Crisis communications protect trust: timely, honest, consistent messages through designated spokespeople.
- ✓Continuity governance assigns ownership, approves plans, monitors testing and ensures plans stay current.
- ✓Safety of people always comes first.
Exam traps
- !Executives shouldn't run technical recovery; engineers shouldn't make public statements.
- !A crisis team that first meets during a crisis performs badly; exercise it.
- !Reputation decisions belong to executives, not to the security team.
- !In any disaster, human safety is the first priority, before systems or data.
Disaster Recovery Planning
How the DRP restores IT systems and data to meet the BIA's objectives: its contents, recovery teams, the link to incident response, and the special challenge of recovering from cyberattacks.
Getting IT back
When systems are lost, the disaster recovery plan is the step-by-step recipe for bringing them back, in the order the business needs, within the time and data-loss limits the BIA set. It's written so a competent stranger could follow it.
What's in the DRP
Recovery teams
Recovering from a cyberattack
Is the backup clean?Attackers may have been inside for weeks; check restore points.
Is the attacker gone?Eradicate before restoring, or they'll return.
Rebuild, don't restoreRebuild critical systems from known-good images.
CredentialsReset passwords and keys; the old ones may be stolen.
ExampleAfter ransomware, a company restores its domain controllers from last night's backup. Within hours the encryption starts again: the attacker's backdoor account was in the backup. The second recovery uses a clean rebuild of identity services and backups verified against the attack timeline.
Keeping the DRP usable
- 1Detailed enough for a competent stranger.
- 2Deputies for every role.
- 3Copies offline and with key staff.
- 4Updated after system changes and tests.
- 5Covers return to the primary site.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Basis for DRP priorities and timing | BIA objectives (RTO, RPO) |
| Main extra risk in cyber recovery | Restoring infected backups or an attacker still present |
| Who can declare a disaster | Authorised people named in the plan |
| DRP relationship to BCP | DRP is part of the BCP |
| Where to keep DRP copies | Offline / offsite, accessible to the team |
Key takeaways
- ✓The disaster recovery plan (DRP) restores IT systems, data and infrastructure within the RTOs and RPOs set by the BIA.
- ✓It covers declaration, teams and roles, contacts, recovery procedures in priority order, resources and backups, and return to normal.
- ✓The DRP is part of the BCP and aligned with the incident response plan, sharing triggers and contacts.
- ✓Cyber recovery differs from natural disasters: backups may be infected, the attacker may still be present, and systems must be rebuilt clean.
- ✓Procedures must be detailed enough for someone other than the usual administrator to follow, and every role needs a deputy.
- ✓The plan is tested, updated after changes and incidents, and kept accessible offline.
Exam traps
- !Restoring compromised systems from infected backups brings the attacker straight back.
- !A DRP only the usual administrator can follow fails when that person is unavailable.
- !The plan must cover returning to the primary site, not just failing over.
- !Who may declare a disaster must be defined in advance.
Recovery Sites: Hot, Warm and Cold
The options for where to recover (mirrored, hot, warm, cold, cloud, reciprocal), how fast and costly each is, and what the security manager checks before relying on one.
Where do we recover?
If the primary data centre or cloud region is lost, systems need somewhere else to run. The options range from a full duplicate running all the time to an empty room with power. The RTO from the BIA decides which the organisation needs.
Site options
RTO drives the choice
| Option | Typical recovery | Cost |
|---|---|---|
| Mirrored / active-active | Near zero | Very high |
| Hot site / cloud standby | Hours | High |
| Warm site / cloud pilot light | Hours to days | Medium |
| Cold site | Weeks | Low |
| Reciprocal agreement | Uncertain | Low |
Checks before relying on a site
DistanceNot exposed to the same disaster (flood, grid, region).
SecurityAt least as strong as the primary site.
CapacityEnough for the SDO; not oversubscribed.
TestedRight to test, and actually tested.
ExampleA bank's commercial hot site serves 40 subscribers in the same city. In a regional flood, all would declare at once and space goes first-come, first-served. The bank moves its critical systems to cloud DR in a different region instead.
Cloud as a recovery site
- 1Pilot light: data replicated, minimal servers ready to scale.
- 2Warm standby: scaled-down copy running.
- 3Multi-region active-active for the most critical services.
- 4Check: capacity guarantees, identity and network access, tested runbooks.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Site operational within hours | Hot site |
| Site with only space and power | Cold site |
| What drives the site choice | RTO from the BIA |
| Weakness of reciprocal agreements | Capacity, compatibility, enforceability |
| Key location requirement | Not exposed to the same regional risk |
Key takeaways
- ✓Site choice is driven by the RTO: the shorter the RTO, the more ready (and expensive) the site.
- ✓Mirrored sites give near-zero recovery; hot sites recover in hours; warm sites in days; cold sites in weeks.
- ✓Cloud DR can act as a hot or warm site depending on how much is kept running, and is now a common option.
- ✓Reciprocal agreements are cheap but often fail on capacity, compatibility and enforceability.
- ✓Recovery sites must be far enough away to avoid the same disaster, and as secure as the primary site.
- ✓Contracts for commercial sites cover capacity, oversubscription, testing rights, duration of use and security.
Exam traps
- !A cold site can't meet a short RTO.
- !A recovery site in the same flood plain or power grid can fail with the primary.
- !Shared commercial sites may be oversubscribed in a regional disaster.
- !A recovery site with weaker security becomes the easiest way in.
Backup Strategies and Cloud DR
How backups and replication meet the RPO, why ransomware changed backup strategy, the 3-2-1-1-0 rule, and how cloud services are used for disaster recovery.
Backups meet the RPO
Backup types
Ransomware changed the rules
The 3-2-1-1-0 rule
Cloud and SaaS
Cloud DRReplicate to another region; pilot light or warm standby.
SaaS dataProvider protects the platform; you may need your own backups.
Separate accountsBackups in a separate cloud account with its own admins.
Test restoresTimed against the RTO, regularly.
ExampleAn attacker with a cloud admin's credentials deletes production databases and their snapshots in the same account. The company recovers because backups were also copied to a separate, locked account with immutable retention, which the stolen credentials couldn't touch.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Metric that sets backup frequency | RPO |
| Best protection for backups against ransomware | Offline or immutable copies, separate credentials |
| Best evidence backups work | Successful restore tests |
| Is replication a backup? | No; it copies errors and ransomware |
| Who protects SaaS data from deletion | Often the customer; check the shared model |
Key takeaways
- ✓Backup frequency and method are driven by the RPO: daily backups mean up to a day of lost data; replication can cut that to minutes or zero.
- ✓Full, incremental and differential backups trade backup time against restore time.
- ✓Replication and RAID aren't backups: they copy deletions, corruption and ransomware instantly.
- ✓Ransomware targets backups first, so at least one copy must be offline or immutable, with separate credentials.
- ✓The 3-2-1-1-0 rule: three copies, two media, one offsite, one offline or immutable, zero errors in restore tests.
- ✓Only a successful restore test proves a backup works; cloud DR still needs tested runbooks and the customer's own backups of SaaS data.
Exam traps
- !'Backup job succeeded' isn't proof that data can be restored.
- !Backups reachable with the same admin credentials as production get encrypted too.
- !SaaS providers protect their platform, not necessarily your data from deletion or ransomware.
- !Keeping backups in the same building or region doesn't protect against site disasters.
Incident Response Training
How the security manager prepares people for incidents: what each audience needs, how responders build and keep skills, and how training links to plans, playbooks and exercises.
Plans don't respond, people do
An incident response plan is only as good as the people who carry it out at 3 a.m. under pressure. Training makes sure everyone, from the receptionist who spots a phishing email to the CEO deciding whether to shut down a factory, knows their part.
Training by audience
Building responder skills
Hands-on labsPractise with the real tools: EDR, SIEM, forensics.
Playbook drillsWalk through each playbook step by step.
Certificationse.g. GIAC incident handling, cloud forensics.
Threat intelligenceLearn current attacker techniques.
Making training stick
- 1Based on the actual plan and playbooks.
- 2Deputies trained as well as primaries.
- 3Refreshed regularly and after plan changes.
- 4Tested through exercises; gaps fed back.
ExampleA post-incident review finds the on-call analyst didn't know how to isolate a cloud server, because training covered only on-premises systems. The team adds cloud containment to the playbooks and runs a lab session for everyone on the on-call rota.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most important training for all staff | How to recognise and report incidents |
| Best way to prepare executives | Executive tabletop exercises |
| Who else needs IR training | Legal, communications, HR, deputies |
| Basis for IR training content | The plan and playbooks |
| How to measure training effectiveness | Exercises and real incident performance |
Key takeaways
- ✓Incident management training is a named CISM topic: plans only work if people know their roles and can perform them under pressure.
- ✓All staff need to recognise and report incidents; responders need technical skills; incident managers need coordination skills; executives need to practise crisis decisions.
- ✓Training is tied to the plan and playbooks, so people learn the procedures they'll actually use.
- ✓Responders keep skills current through hands-on labs, simulations, certifications and threat intelligence.
- ✓New team members are trained before going on call; deputies are trained as well as primaries.
- ✓Training effectiveness is measured in exercises and real incidents, and gaps feed back into the program.
Exam traps
- !Training only the security team leaves legal, communications and executives unprepared.
- !A plan nobody has been trained on fails on the first real incident.
- !Deputies who've never practised can't step in when the primary is unavailable.
- !Training once at onboarding isn't enough; skills fade and threats change.
Testing Plans: Tabletop, Functional and Full Interruption
How incident response, continuity and recovery plans are tested, from checklist reviews and tabletops to simulations, parallel tests and full interruption, and how to plan a test safely.
Why test?
Plans look complete on paper and then fail on details: a phone number that changed, a backup nobody can restore, a decision nobody is authorised to make. Testing finds those details while the stakes are low.
The ladder of tests
Each type in brief
| Test | What happens | Disruption |
|---|---|---|
| Checklist review | Owners check their sections are current | None |
| Tabletop / walkthrough | Team talks through a scenario | None |
| Simulation / functional | Roles and decisions rehearsed; some systems exercised | Low |
| Parallel | Recover at alternate site; production continues | Low |
| Full interruption | Primary shut down; run from recovery site | High |
Running a test
ExampleA ransomware tabletop with IT, legal, communications and two executives runs for two hours. It reveals no agreed authority to shut down the ERP, no offline copy of the contact list, and that the insurer must be called before hiring forensics. All three are fixed within a month.
Scheduling tests
- 1At planned intervals: e.g. tabletops twice a year, technical recovery yearly.
- 2After significant changes: new systems, sites, suppliers.
- 3Scenarios based on current threats and BIA priorities.
- 4Increasing realism as maturity grows.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Least disruptive test | Checklist review |
| Team talks through a scenario together | Tabletop / walkthrough |
| Recovery site runs while production continues | Parallel test |
| Most realistic, most risky | Full interruption test |
| When to define success criteria | Before the test |
Key takeaways
- ✓Testing and reviewing incident management plans at planned intervals is a CISM task; untested plans give little assurance.
- ✓Test types, from least to most disruptive: checklist review, tabletop or walkthrough, simulation or functional test, parallel test, full interruption test.
- ✓Start with low-disruption tests; full interruption only after lower-level tests succeed, with senior management approval.
- ✓Each test has objectives and success criteria (such as meeting the RTO) set in advance, plus pre-test, test and post-test phases.
- ✓Include the business, not just IT: tests prove processes can recover, not just servers.
- ✓Test regularly, after significant change, and with realistic scenarios such as ransomware.
Exam traps
- !A full interruption test should never be the first test.
- !A parallel test doesn't interrupt production; a full interruption test does.
- !A test that finds no problems probably wasn't realistic.
- !Success criteria defined after the test can't show whether it passed.
Evaluating Exercises and Improving Readiness
How to turn exercises into real improvement: observing, debriefing, measuring against objectives, reporting, and tracking fixes until the plan is proven to work.
The point of the exercise
Exercises aren't exams to pass. Their value lies in the gaps they reveal and what changes afterwards. A well-run evaluation turns a two-hour tabletop into concrete improvements, tracked until they're proven.
From exercise to improvement
Readiness metrics
| Measure | Exercise 1 | Exercise 2 |
|---|---|---|
| Time to declare the incident | 95 min | 30 min |
| Time to reach executive sponsor | 3 h | 40 min |
| Critical system restored vs RTO (8 h) | 14 h | 7 h |
| Decisions without clear authority | 4 | 1 |
A blame-free culture
Focus on processWhy did the process let this happen?
Encourage honestyPeople admit confusion only when it's safe.
Celebrate findingsA found gap is a win, not a failure.
Share resultsReport to management with the action plan.
ExampleIn a simulation, the backup administrator couldn't find the decryption keys for offsite backups. Rather than blame the administrator, the review found keys were stored only on the server being restored. Keys moved to an offline vault; the retest a month later restored within the RTO.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most important outcome of an exercise | Identify weaknesses and improve the plan |
| After fixing findings | Retest to verify |
| Who should observe exercises | Neutral observers |
| How to show readiness improving | Metrics across successive exercises |
| A test finds no issues | Question whether it was realistic |
Key takeaways
- ✓The value of an exercise lies in what it reveals and what changes afterwards.
- ✓Neutral observers record times, decisions and problems against the pre-agreed objectives.
- ✓A hot debrief right after the exercise captures fresh observations; a written report follows.
- ✓Findings get root causes, owners, dates and retests, tracked like any other risk.
- ✓Readiness metrics (time to detect, escalate, contain, recover) show improvement over successive exercises.
- ✓Results are reported to management, and plans, playbooks and training are updated.
Exam traps
- !Blaming individuals for exercise failures discourages honest participation; focus on process.
- !Fixing findings without retesting leaves the plan unproven.
- !Exercises with easy, unrealistic scenarios create false confidence.
- !Results not reported to management can't drive investment.
Security Event Detection and Monitoring Methods
How incidents are detected: monitoring sources, signature and behaviour-based detection, the role of people and third parties, and how the security manager measures and improves detection.
Time is damage
Attackers often spend days or weeks inside a network before they act. Every hour they go unnoticed, they reach more systems and data. Detection shortens that window, and it's the part of incident management where investment often pays back most.
Where detections come from
Signature vs behaviour
Making detection effective
CoverageCritical systems, identity and cloud send the right logs.
Use casesDetections mapped to likely attacks (MITRE ATT&CK).
TuningCut false positives to avoid alert fatigue.
TestingSimulate attacks to check detections fire.
ExampleA purple-team exercise runs ten common attacker techniques against the network. Only four trigger alerts; the other six reveal missing logs from domain controllers and cloud consoles. Fixing coverage raises detection to nine of ten at the next exercise.
Measuring detection
- 1Mean time to detect (MTTD).
- 2% of critical assets sending logs.
- 3Coverage of priority ATT&CK techniques.
- 4False-positive rate.
- 5How incidents were first detected (internal vs external).
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main goal of monitoring | Timely identification of incidents |
| Detection method that finds new attacks | Behaviour / anomaly-based |
| Effect of too many false positives | Alert fatigue; real alerts missed |
| Key detection metric | Mean time to detect |
| Breaches mostly reported by outsiders | Detection capability is weak |
Key takeaways
- ✓Developing and implementing processes for timely identification of incidents is a CISM task; the faster an incident is found, the less damage it does.
- ✓Detection sources include SIEM correlation, EDR and network detection, cloud and identity alerts, user reports, threat intelligence and third parties.
- ✓Signature-based detection catches known threats; behaviour and anomaly detection can catch new ones but produce more false positives.
- ✓Coverage matters: critical systems, identities and cloud services must send the right logs.
- ✓Tuning reduces false positives, which otherwise cause alert fatigue and missed real attacks.
- ✓Key metric: mean time to detect (MTTD), along with detection coverage and the source of first detection.
Exam traps
- !Logs that aren't collected or reviewed detect nothing.
- !Too many false positives lead to real alerts being ignored.
- !Learning about a breach from a third party is a sign detection is weak.
- !Signature-based tools alone miss new attacks.
SIEM, the SOC and Event Correlation
The tools and team that turn logs into detected incidents: how a SIEM correlates events, how a security operations centre is organised, and what the security manager must decide about them.
From logs to incidents
Modern organisations produce billions of log entries. On their own, they're noise. A SIEM turns them into a searchable, correlated view, and a SOC turns that view into decisions. Together they're the core of incident management tools and techniques.
How a SIEM works
The SOC
Decisions for the security manager
| Decision | Considerations |
|---|---|
| Build, buy or hybrid SOC | 24x7 needs, skills, cost, control |
| Log sources and retention | Coverage of critical assets; legal retention; cost |
| Use cases | Mapped to top risks and attacker techniques |
| Automation (SOAR) | Which steps to automate; guardrails |
| Metrics | MTTD, MTTR, coverage, false positives |
Correlation in action
Correlation is the SIEM's main value: spotting patterns no single log shows.
ExampleIndividually, three events look normal: a VPN login from abroad, a new mailbox forwarding rule, a large download from the finance share. The SIEM correlates them within ten minutes as one account takeover, and the SOC disables the account before the data leaves.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Primary purpose of a SIEM | Collect and correlate events to detect incidents |
| Why time sync (NTP) matters | So events across systems can be correlated |
| Tool that automates response steps | SOAR |
| SOC is outsourced; who is accountable | The organisation |
| SIEM produces too many alerts | Tune use cases; reduce false positives |
Key takeaways
- ✓A SIEM collects, normalises and correlates logs from many sources to detect incidents and support investigations.
- ✓Correlation links events that look harmless alone, such as a foreign login followed by a large download.
- ✓A security operations centre (SOC) monitors, triages and responds, often in tiers, with threat hunting and incident response above.
- ✓SOAR automates routine steps; humans make the high-impact decisions.
- ✓Options: in-house SOC, outsourced (MSSP/MDR) or hybrid; accountability stays with the organisation.
- ✓Incident management tools and techniques are a named CISM topic: the manager decides coverage, staffing, tuning and metrics.
Exam traps
- !A SIEM without tuning and people produces noise, not detection.
- !Logs stored where administrators can change them aren't reliable evidence.
- !Without time synchronisation, events from different systems can't be correlated.
- !Outsourcing the SOC doesn't outsource accountability or business context.
Threat Intelligence and Indicators of Compromise
How threat intelligence and indicators of compromise feed detection and investigation, why some indicators matter more than others, and how to share intelligence safely.
Clues left behind
Attackers leave traces: malicious files, connections to their servers, odd accounts. Indicators of compromise describe those traces so defenders can find them. Threat intelligence tells you which indicators and techniques are being used right now, and against whom.
IOCs and IOAs
Indicators of compromiseEvidence of a breach: hashes, IPs, domains, file names, registry keys.
Indicators of attackBehaviour in progress: credential dumping, unusual lateral movement.
Use for detectionRules and blocks in SIEM, EDR, firewalls, email.
Use for investigationScope: where else does this indicator appear?
Not all indicators are equal
Using intelligence in an incident
- 1 Find IOC From the first infected host
- 2 Search estate SIEM and EDR for all occurrences
- 3 Scope Which systems and accounts are affected
- 4 Block Domains, IPs, hashes
- 5 Hunt TTPs Same techniques elsewhere?
ExampleAn analyst finds a malicious file on one laptop. Searching its hash and the domain it contacted across all endpoints finds seven more infected machines, including a server. Without that search, containment would have stopped at the first laptop.
Sharing intelligence
- 1Sector ISACs, national CERTs, trusted peer groups.
- 2Traffic Light Protocol (TLP) marks how widely information may be shared.
- 3Legal review before sharing details of your own incidents.
- 4Feedback improves the quality of shared intelligence.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Evidence that a breach may have occurred | Indicator of compromise |
| Hardest indicator for attackers to change | Tactics, techniques and procedures (TTPs) |
| IOC found on one system | Search for it across the whole environment |
| Where to share intelligence | ISACs, CERTs, trusted groups, under TLP |
| Main limitation of IOC blocking | Attackers change indicators easily |
Key takeaways
- ✓Indicators of compromise (IOCs) are evidence that a system may have been breached: file hashes, IP addresses, domains, registry keys, unusual behaviour.
- ✓Indicators of attack (IOAs) focus on attacker behaviour and techniques, and can catch attacks before damage is done.
- ✓The 'pyramid of pain': hashes and IPs are easy for attackers to change; techniques (TTPs) are hard, so detecting TTPs is most valuable.
- ✓Intelligence feeds detection rules, threat hunting, investigation scoping and blocking.
- ✓Sharing through ISACs, CERTs and trusted groups helps everyone; follow traffic light protocol (TLP) and legal advice.
- ✓Intelligence must be relevant and timely; old or irrelevant IOCs create noise.
Exam traps
- !Blocking indicators alone won't stop a determined attacker; they change them.
- !Raw feeds without context create false positives.
- !Sharing incident details externally without legal review can create liability.
- !IOCs found during an incident must be searched for across the whole estate, not just the first system.
Incident Triage and Initial Investigation
How a reported event is validated, classified, scoped and prioritised quickly, and how the investigation that follows establishes what happened while preserving evidence and meeting legal requirements.
The first hour
When an alert or report arrives, the first decisions matter most. Triage decides quickly whether it's real, how serious it is and who needs to act. The investigation that follows builds the facts that every later decision depends on.
Triage
What the investigation must answer
| Question | Why it matters |
|---|---|
| How did they get in? | Close the entry point |
| When did it start? | Which backups are clean; notification timing |
| What did they access or take? | Breach notification; impact |
| Which systems and accounts? | Containment and eradication scope |
| Are they still here? | Containment urgency |
Investigate properly
Record everythingTimeline of events, actions and decisions from the first minute.
Preserve evidenceImage and log before changing systems where possible.
Follow the lawPrivacy, employment law, legal privilege; involve legal early.
Insider casesDiscreet; HR and legal involved; don't tip off the suspect.
ExampleAn alert shows a privileged account copying payroll data at night. Instead of disabling the account immediately and alerting the user, the team quietly preserves logs, involves HR and legal, confirms it's an insider, and then acts, with evidence that holds up at the disciplinary hearing.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step when an alert arrives | Validate it: real incident or false positive |
| Most important record during investigation | Timeline of events, actions and decisions |
| Before changing an affected system | Preserve evidence where possible |
| Suspected insider | Involve HR and legal; secure evidence discreetly |
| New facts widen the scope | Reassess severity and escalate |
Key takeaways
- ✓Triage quickly validates, classifies, scopes and prioritises a suspected incident, then assigns and records it.
- ✓Investigation establishes what happened, how, when, which assets and data were affected, and whether the attacker is still present.
- ✓Investigating and documenting incidents in line with legal and regulatory requirements is a CISM task.
- ✓Keep a timeline and record every action and decision from the start.
- ✓Preserve evidence from the beginning in case of legal action, regulatory reporting or insurance claims.
- ✓Scope widens as facts emerge; reassess severity and escalate as needed.
Exam traps
- !Rebooting or wiping a system during triage can destroy evidence.
- !Investigating only the first affected system misses the rest of the attack.
- !Undocumented actions can't be defended later, to regulators or in court.
- !Investigators shouldn't alert a suspected insider before evidence is secured and HR and legal are involved.
Evidence Preservation, Forensics and Chain of Custody
How the security manager makes sure incident evidence is collected, preserved and handled so it can be used in court, by regulators or by insurers, and when to bring in forensic specialists.
Assume it will be challenged
Incidents can end in court, in front of a regulator, in an insurance claim or at a disciplinary hearing. Evidence that was changed, mishandled or can't be traced will be challenged and may be thrown out. Handling it properly from the start keeps every option open.
Most fragile first
The forensic process
Chain of custody
ExampleAn investigator copies files from a suspect's laptop to a USB stick and opens them to look. Access times change, there's no hash and no custody record. At the employment tribunal, the evidence is excluded. Forensic readiness training would have prevented it.
Forensic readiness
Policy and proceduresWhen and how evidence is collected; who may do it.
Tools and logsForensic tools, write blockers, sufficient log retention.
PeopleTrained internal responders; external forensic retainer.
LegalPrivacy, employment law, cross-border data, privilege.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| What to collect first from a running system | Volatile data such as memory |
| Proving a copy is identical | Matching hash values |
| Record of who handled evidence | Chain of custody |
| Where analysis is performed | On a verified copy, not the original |
| Security manager's role | Forensic readiness; involve specialists |
Key takeaways
- ✓Evidence is preserved from the start whenever legal action, regulatory reporting, insurance or disciplinary action is possible.
- ✓Collect in order of volatility: memory and live state first, then disks, then logs and archives.
- ✓Forensic images are bit-by-bit copies made through write blockers, verified with matching hashes; analysis is done on copies.
- ✓Chain of custody records who collected, handled, transferred and stored each item, and when.
- ✓Evidence handling must be lawful and follow documented procedures (e.g. ISO/IEC 27037) by qualified people.
- ✓The security manager's role is forensic readiness: policies, tools, retainers and trained staff before an incident.
Exam traps
- !Pulling the plug loses memory evidence; let trained responders decide.
- !Analysing the original evidence, rather than a copy, can make it inadmissible.
- !Any gap in the chain of custody gives the other side grounds to challenge evidence.
- !Untrained staff 'having a look' often destroy the evidence they're trying to find.
Containment Strategies: Short-Term and Long-Term
How to stop an incident spreading: fast short-term containment, longer-term isolation and segmentation, and doing it without destroying evidence or causing more harm than the attack.
Stop the spread
Once an incident is confirmed, the first priority is usually containment: limiting how far it spreads and how much damage it does. Speed matters, but so does doing it in a way that keeps evidence and doesn't cause more harm than the attack itself.
Short-term and long-term
Contain, but keep the evidence
Containment by incident type
| Incident | Typical containment |
|---|---|
| Ransomware | Isolate hosts and segments; protect backups; disable spreading accounts |
| Compromised account | Disable or reset; revoke sessions and tokens; check MFA |
| Business email compromise | Remove forwarding rules; freeze pending payments |
| Data exfiltration | Block destinations; cut the access path; preserve logs |
| DDoS | Upstream filtering; scale; rate limiting |
Think a step ahead
- 1Scope first where possible: contain all affected systems together.
- 2Expect the attacker to react: they may escalate or destroy data.
- 3Use out-of-band channels if they may be watching email.
- 4Keep business impact in view; involve owners.
ExampleResponders isolate one infected server, and within minutes the attacker triggers encryption on 40 others they already controlled. In the next exercise, the playbook adds a step: use EDR to identify all hosts with the attacker's tools first, then isolate them all at once.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First priority once an incident is confirmed | Contain it, preserving evidence |
| Why not wipe immediately | Destroys evidence and root-cause clues |
| Better than pulling the power | Network isolation |
| Containment for a compromised account | Disable/reset; revoke sessions and tokens |
| Why plan containment in advance | Speed, with pre-agreed authority |
Key takeaways
- ✓Incident containment methods are a named CISM topic; once an incident is confirmed, containment is usually the first priority.
- ✓Short-term containment stops the spread fast: isolate hosts, disable accounts, block indicators, take exposed services offline.
- ✓Long-term containment holds the line while eradication is prepared: segmentation, temporary clean systems, enhanced monitoring, credential rotation.
- ✓Containment should preserve evidence: isolate rather than wipe; capture volatile data where possible.
- ✓Containment strategies are planned in playbooks, with pre-agreed authority, so they can be applied quickly.
- ✓Watch for attacker reactions: some escalate or destroy data when they notice containment.
Exam traps
- !Wiping and rebuilding immediately destroys evidence and the chance to find the root cause.
- !Pulling the power loses memory evidence; network isolation is often better.
- !Containing only the first known system leaves others compromised.
- !Containment without authority causes delays; agree authority in the plan.
Making Containment Decisions
How hard containment choices are made: weighing the harm of acting against the harm of waiting, who decides, monitoring versus immediate action, and documenting the decision.
No free choices
Every containment option costs something. Isolating a payment server stops the attacker but also stops sales. Waiting to understand the attack keeps sales running but risks more damage. Containment decisions are business decisions informed by technical facts.
What to weigh
Who decides what
| Decision | Decision-maker (typical) |
|---|---|
| Isolate a workstation or server | Incident manager / SOC lead |
| Disable a privileged or executive account | Incident manager, informing the owner |
| Take a revenue-earning service offline | Executive sponsor or delegate |
| Monitor an active attacker instead of acting | Senior management with legal advice |
| Shut down an operational (OT) process | Operations leadership; safety first |
Act now, or watch?
Act immediatelyData is leaving; ransomware is spreading; safety at risk.
Watch brieflyScope unclear; acting early would tip off the attacker and miss systems.
Conditions for watchingSenior approval, legal advice, strict time limit, close monitoring.
Document either wayFacts known, options, decision, who decided, why.
ExampleAn e-commerce site detects card-skimming code at 10 a.m. on its busiest day. Removing it means a short outage. The executive sponsor approves a 15-minute maintenance window immediately: continuing to take payments through a compromised page would breach PCI DSS and harm customers.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main consideration in containment decisions | Balance damage of waiting vs impact of acting |
| Who decides to take a business service offline | Executive sponsor / business owner |
| Monitoring an attacker instead of containing | Senior management decision with legal advice |
| Data is actively being exfiltrated | Contain immediately |
| What to record | Facts, options, decision, decision-maker, reasons |
Key takeaways
- ✓Containment decisions balance the damage of waiting against the business impact of acting.
- ✓Factors: spread and data loss, downtime and revenue, evidence preservation, attacker reaction, safety and legal duties, confidence in scope.
- ✓Business decisions (taking revenue-earning systems offline) belong to the executive sponsor or delegate; technical containment to the incident manager, as the plan says.
- ✓Watching an attacker briefly to understand scope can be justified, but only as a senior management decision with legal advice.
- ✓Every containment decision is documented with its reasons, so it can be explained later.
- ✓When in doubt about safety or legal duties, containment takes priority over convenience.
Exam traps
- !Keeping systems running to avoid disruption while data is actively leaving is rarely defensible.
- !Deciding to 'watch and learn' is a senior management decision, not an analyst's.
- !Undocumented decisions look like negligence afterwards.
- !Containment that's technically perfect but ignores business impact loses management support.
Breach Notification and Regulatory Reporting
What organisations must report, to whom and how fast after a breach, how the security manager builds notification into the plan, and why legal leads the decisions.
The clock is running
Many laws now require organisations to report serious incidents and personal data breaches within days, sometimes hours. Missing the deadline can bring penalties on top of the breach itself. Notification has to be planned before the incident, not worked out during it.
Common deadlines
Who needs telling
Building notification into the plan
- 1 Register All applicable requirements, by jurisdiction
- 2 Triggers Classification criteria that start the clock
- 3 Escalate Legal informed immediately
- 4 Templates Pre-drafted, legally reviewed
- 5 Decide and send Legal leads; executives approve
- 6 Record What, when, to whom, why
Notify with what you know
Most regimes allow an initial notification with incomplete information, followed by updates. Waiting for certainty usually means missing the deadline.
ExampleOn day two of an investigation, the company knows customer records were accessed but not how many. Legal notifies the data protection authority within 72 hours with what's known, explains the investigation is ongoing, and sends two updates as the scope becomes clear.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| GDPR notification deadline | 72 hours from awareness, to the supervisory authority |
| Who decides whether notification is required | Legal counsel, with management |
| Investigation not complete at the deadline | Notify with known facts; update later |
| When the notification clock starts | Usually at awareness |
| Best preparation | Requirements register and pre-approved process in the plan |
Key takeaways
- ✓Laws, regulations and contracts can require notification of regulators, affected individuals, customers and partners within strict deadlines.
- ✓Examples: GDPR (72 hours to the authority), NIS2 (24-hour early warning), DORA (financial sector), SEC (4 business days after materiality), and contract terms.
- ✓The clock often starts at awareness, so fast classification and escalation are essential.
- ✓Legal counsel leads notification decisions; the security manager supplies facts and builds the process into the plan.
- ✓Initial notifications can be made with incomplete information and updated later.
- ✓Records of what was known, decided and notified, and when, are evidence of compliance.
Exam traps
- !Waiting for the investigation to finish before notifying usually misses the deadline.
- !The security manager doesn't decide alone whether notification is legally required.
- !Encrypted data may reduce or remove notification duties, but only if keys weren't compromised; legal confirms.
- !Multinational incidents can trigger several regimes with different deadlines.
External Communications: Customers, Media and Law Enforcement
How an organisation communicates with customers, partners, the media and law enforcement during an incident: principles, spokespeople, timing, and decisions about involving the authorities.
Trust is on the line
Customers, partners and the public forgive incidents more readily than they forgive being misled. Clear, honest, timely communication can protect reputation through a serious breach; confused or defensive communication can destroy it.
Principles
Audiences
| Audience | What they need | Who leads |
|---|---|---|
| Customers | What happened, impact on them, what to do | Communications with legal |
| Partners and suppliers | Impact on shared systems and data | Business owners, security |
| Media | Concise, approved statement | Designated spokesperson |
| Investors | Material impact, disclosures | Investor relations, legal |
| Law enforcement | Evidence and facts to investigate | Legal |
Law enforcement and attackers
Involve law enforcement?Helps investigation; brings publicity. Legal and executives decide.
Contact with attackersOnly through authorised specialists.
Ransom decisionsExecutives with legal and insurer; check sanctions law.
InsurerOften must be told before engaging firms or paying.
ExampleA retailer announces its breach early, says cards weren't affected but emails were, warns of phishing lures and updates daily. Complaints stay lower than at a peer that revised its numbers twice.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who speaks to the media | A designated spokesperson |
| Most important principle in breach communication | Timely, accurate, honest communication |
| Who decides to involve law enforcement | Legal counsel and senior management |
| Staff approached by journalists | Refer them to the designated spokesperson |
| Risk of paying a ransom | No guarantee; may break sanctions laws |
Key takeaways
- ✓External communication protects trust; how an incident is communicated often matters more to reputation than the incident itself.
- ✓Principles: early, accurate, consistent, honest about what isn't known yet, and clear about what recipients should do.
- ✓Only designated spokespeople speak externally; statements are reviewed by legal and communications.
- ✓Customers and partners need practical guidance (reset passwords, watch for fraud); regulators get formal notifications.
- ✓Involving law enforcement is a decision for legal and senior management, weighing investigation support against publicity and disruption.
- ✓Ransom negotiations and payments involve legal, executives, insurers and specialists; sanctions laws may apply.
Exam traps
- !Speculating about numbers or causes, then correcting them, damages credibility badly.
- !Staff comments on social media can contradict official statements.
- !Communicating with the attacker without authority and specialist help is dangerous.
- !Paying a ransom may be illegal if the group is sanctioned, and doesn't guarantee data is deleted.
Eradication, Recovery and Return to Normal Operations
How the attacker and their tools are removed, how systems are restored and validated as clean, and how the organisation safely returns to normal operations.
Clean before you restore
After containment, two jobs remain: get the attacker completely out (eradication) and get the business back (recovery). Doing them in the wrong order, or skipping parts of either, is how organisations end up suffering the same incident twice.
From eradication to normal
Validating before go-live
CleanScans and checks find no attacker tools or IOCs.
Patched and hardenedEntry point closed; baseline applied.
Data intactRestored data reconciled to the RPO; integrity checked.
Business testedOwners confirm the service works for real users.
Returning to normal
- 1Restore in BIA priority order, dependencies first.
- 2Stand down manual workarounds in a controlled way.
- 3Reconcile transactions processed during the outage.
- 4Keep heightened monitoring for weeks.
- 5Owner sign-off before closing the incident.
ExampleAfter a business email compromise, the team removes the attacker's forwarding rules and resets the CFO's password, but forgets the attacker's registered MFA device. Two weeks later the account is taken again. The recovery checklist now includes revoking sessions, tokens and MFA registrations.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| What must happen before restoring systems | Eradicate the threat and close the entry point |
| Common recovery failure | Not rotating compromised credentials |
| How to restore compromised systems | Clean backups or rebuild from known-good images |
| After recovery | Heightened monitoring for the attacker's return |
| Who confirms return to normal | The business owner |
Key takeaways
- ✓Incident eradication and recovery is a named CISM topic: remove the cause, restore services, confirm they're clean, return to normal.
- ✓Eradication removes malware, backdoors, attacker accounts and persistence, and closes the original entry point.
- ✓Credentials, keys and tokens the attacker may hold are rotated; otherwise they simply log back in.
- ✓Recovery uses clean backups or rebuilds from known-good images, validated before returning to production.
- ✓Heightened monitoring continues after recovery, because attackers often try to return.
- ✓The business owner confirms normal operations before the incident is closed; recovery follows BIA priorities.
Exam traps
- !Restoring before eradicating invites reinfection.
- !Fixing the symptom (the malware) without closing the entry point lets the attacker back in.
- !Forgetting to rotate credentials is one of the most common recovery failures.
- !IT declaring 'fixed' isn't enough; validation and owner sign-off are needed.
Post-Incident Review and Root Cause Analysis
How the post-incident review turns an incident into improvement: building the timeline, finding root causes, deciding corrective actions with owners and dates, and reassessing risk.
Don't waste the incident
Every incident is expensive. The post-incident review is how the organisation gets something back: an honest look at what happened, why, and what will change so it doesn't happen again, or is caught sooner next time.
The review
Finding the root cause
Immediate vs root cause
| Level | Example |
|---|---|
| Immediate cause | An employee clicked a phishing link |
| Contributing cause | No MFA on the VPN; alert ignored overnight |
| Root cause | No MFA standard enforced; SOC not staffed 24x7 |
| Corrective actions | Enforce MFA (IT, 30 days); MDR service for nights (CISO, 60 days) |
Running it well
TimingSoon after closure, while memories are fresh (often within two weeks).
ParticipantsResponders, owners, legal, comms, sometimes the supplier.
BlamelessFocus on process and systems, not individuals.
OutputReport to management; tracked actions; updated risk.
ExampleA post-incident review of a ransomware attack finds the entry point was an unpatched VPN appliance flagged three months earlier. The root cause isn't the patch team: critical-patch SLAs didn't cover network appliances. The standard is updated, and appliances join the vulnerability program.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main purpose of a post-incident review | Identify root causes and improvements |
| Technique for root cause analysis | Five whys / fishbone |
| Corrective actions need… | Owners, due dates, tracking |
| Review culture | Blameless, focused on process |
| What else to update after a review | Risk register, plans, playbooks, controls |
Key takeaways
- ✓Post-incident review practices are a named CISM topic; a CISM task is to conduct reviews covering root cause, lessons learned, corrective actions and risk reassessment.
- ✓The review reconstructs the timeline, identifies root and contributing causes, and asks what worked and what didn't.
- ✓Root cause analysis techniques: five whys, fishbone (Ishikawa) diagrams, timeline analysis.
- ✓Corrective actions have owners and due dates, and are tracked to closure like risks.
- ✓The risk register, plans, playbooks and controls are updated; results are reported to management.
- ✓Reviews are blameless, focusing on process, so people speak honestly.
Exam traps
- !Skipping the review means the same incident can happen again.
- !Stopping at the immediate cause (the phishing click) misses the root cause (no MFA, weak detection).
- !Blame-focused reviews make people hide information.
- !Actions without owners and dates rarely get done.
Lessons Learned and Incident Trend Analysis
How lessons from individual incidents become organisational knowledge, how trend analysis reveals patterns no single incident shows, and how both feed back into risk, the program and the plans.
From one incident to many
A single incident teaches specific lessons. Looking across dozens of incidents reveals patterns: the same root cause appearing again, one category rising, one business unit always slower to respond. That's where the biggest improvements come from.
Making lessons stick
CapturePost-incident review reports in a searchable knowledge base.
ShareBriefings for responders, owners and leaders; anonymised case studies for staff.
ActActions tracked to closure; plans and playbooks updated.
VerifyExercises check the fixes work.
Trend metrics
Turning trends into action
- 1Rising category: reassess the risk; adjust controls and training.
- 2Repeat root causes: fix the underlying process.
- 3Slow detection or containment: invest in tools, skills, playbooks.
- 4Overdue actions: escalate through governance.
ExampleQuarterly trend analysis shows phishing-led incidents rising for three quarters, mostly via personal email accessed on work laptops. The security manager reassesses the risk, restricts personal webmail on corporate devices, and refocuses awareness on the new lures. The next quarter, phishing incidents halve.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main benefit of incident trend analysis | Reveals patterns and systemic weaknesses |
| What trends should feed | Risk assessment, program priorities, training, plans |
| Prerequisite for trend analysis | Consistent incident categorisation |
| Lessons recorded but not acted on | Not truly learned; track actions |
| Proactive source of lessons | Other organisations' incidents |
Key takeaways
- ✓Lessons learned are captured, shared and acted on, not just written in a report nobody reads.
- ✓A knowledge base of incidents, root causes and fixes speeds future response.
- ✓Trend analysis across incidents reveals patterns: rising categories, repeat root causes, weak areas, seasonal peaks.
- ✓Incident metrics (time to detect, contain and recover; incidents by category; repeat causes; overdue actions) show whether incident management is improving.
- ✓Trends feed the risk assessment, program priorities, training and plan updates, closing the loop with Domains 2 and 3.
- ✓Lessons from other organisations' incidents are valuable too, and cheaper.
Exam traps
- !Lessons recorded but never acted on aren't lessons learned.
- !Looking at incidents one at a time misses patterns.
- !Inconsistent categorisation makes trend analysis unreliable.
- !Only learning from your own incidents is reactive; learn from peers too.
1 / 243