Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Testing Plans: Tabletop, Functional and Full Interruption
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. One CISM task is to test and review incident management plans at planned intervals, using methods such as tabletop, checklist and simulation.
The ladder of tests
| Test | What happens | Disruption |
|---|---|---|
| Checklist review | Owners check their sections are current and complete | None |
| Tabletop / walkthrough | The team talks through a scenario together | None |
| Simulation / functional test | Roles and decisions are rehearsed; some systems or procedures exercised | Low |
| Parallel test | Systems recovered at the alternate site while production continues | Low |
| Full interruption test | The primary site is shut down; operations run from the recovery site | High |
Start at the bottom. A full interruption test comes only after lower-level tests succeed, and only with senior management approval.
Running a test
- Pre-test: objectives, scope, scenario and success criteria (for example, “ERP restored within the 8-hour RTO”), agreed in advance, with approvals.
- Test: run it; observers record times, actions and problems.
- Post-test: return systems to normal; clean up test data.
- Evaluate and fix: compare results with the criteria; update plans; retest failures.
Include the business, not just IT. Tests should prove that processes recover, not only servers.
Example. A 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
- at planned intervals, for example tabletops twice a year and technical recovery tests yearly
- after significant changes: new systems, sites or suppliers
- with scenarios based on current threats and BIA priorities
- with increasing realism as the program matures
A test that finds no problems probably wasn’t realistic.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Least disruptive test | Checklist review |
| The team talks through a scenario together | Tabletop / walkthrough |
| The recovery site runs while production continues | Parallel test |
| Most realistic and most risky | Full interruption test |
| When to define success criteria | Before the test |
In short
- 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.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The ladder of tests
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.
1 / 9