Resources · 08

Cyber incident exercise: test decisions before the crisis

Build a realistic scenario that tests coordination, continuity, evidence, communication and service recovery without disrupting production.

Updated 27 October 2026 · 6 min

Illustration · fictional scene

What this guide helps achieve

Clarify who decides under pressure
Test fallback channels
Validate the actual recovery order
Turn gaps into verifiable actions

Quick check

Does the scenario target a precise capability?
Are crisis contacts available offline?
Who can isolate a system?
Which service must return first?
Who informs customers, authorities and partners?

Step-by-step method

01
Define the objective
Select two or three capabilities to test: qualification, decision, containment, continuity, notification or recovery. State what remains out of scope.
Deliverable: mandate and success criteria.
02
Build a plausible scenario
Start from real assets and dependencies. Gradually add outage, conflicting information, external pressure and business constraints without pursuing spectacle.
Deliverable: confidential master scenario.
03
Prepare roles and injects
Name exercise control, observers and participants. Each inject should trigger an observable decision, not merely deliver news.
Deliverable: timeline and inject cards.
04
Run without trapping people
Explain the rules, distinguish simulation from a real incident, protect production and let teams use their normal procedures.
Deliverable: decision and communication log.
05
Debrief twice
Capture observed facts first, then analyse causes, trade-offs and dependencies. Separate documentation gaps, authority gaps and technical issues.
Deliverable: evidenced findings and lessons.
06
Close the gaps
Give every action an owner, date and proof. Replay critical steps or test restoration instead of closing by declaration.
Deliverable: improvement plan and confirmation test.

Worked example

Illustrative situation

An exercise simulates loss of the support tool during an incident. Participants must qualify the signal, reach decision makers outside that tool and decide when to inform affected people.

Decision and expected evidence

The record keeps decisions and timestamps, missing information and three assigned improvements with retest dates.

Management indicators

Indicator	What it measures	First action
Mobilisation time	Time required to assemble essential roles	Fix directories and deputies
Decision time	Delay between a qualified signal and an explicit decision	Clarify thresholds and authority
Recovery order	Services restored according to approved business priority	Align technical dependencies and needs
Actions closed	Gaps fixed with verified evidence	Replay the highest-risk points

Common pitfalls

Writing an over-complex scenario
Assessing individuals instead of the system
Forgetting customers, suppliers and authorities
Producing a report without closure tests

Frequently asked questions

Must an exercise take systems offline?

No. A tabletop exercise tests decisions without real technical action. Restoration or failover tests need a separate safe scope.

Who should participate?

Roles that make a decision or perform a critical action, plus deputies when continuity depends on them.

How long should it take?

Two to four hours often works for a targeted objective, plus preparation, debrief and action follow-up.

Incident, vulnerability or data breach: find the right contact

A CSIRT serves a defined constituency: an organisation, sector or community. Its country and FIRST membership do not establish your eligibility, its availability or the services it offers. Check all three on its official website.

Establish the facts
Check the constituency
Confirm the official channel

Incident on your system

Contact the internal team or provider named in your response plan. Look for a CSIRT covering your organisation when external coordination is needed.

Check who it serves, reporting procedures and operating hours; a public form does not guarantee an immediate response.

Find a CSIRT

Flaw in a third-party product

Check the supplier’s disclosure policy or product security incident response team (PSIRT). The /.well-known/security.txt file may specify a contact, policy and encryption details.

Check the domain, Expires field and policy scope. security.txt does not authorise testing; agree on a channel before sending sensitive evidence.

Understand disclosure

Personal data involved

Involve the data controller and data protection officer, if appointed, alongside the technical response team.

Technical assistance and any regulatory notification are separate processes. Have the applicable authority, conditions and deadlines determined for your situation.

Explore data governance

Prepare a useful first contactTimeline with time zone, affected service and observed facts, kept separate from hypotheses.Known scope and impact, actions already taken and a person authorised to communicate.Redacted summary and agreed sharing channel; no passwords, tokens or complete logs in a public form.

This checklist prepares a conversation; it measures neither incident severity nor resolution. Selections stay on this page and are not sent.

References: FIRST, RFC 9116 and CNIL (French framework). FIRST · CSIRT Services Framework 2.1 RFC 9116 · security.txt CNIL · Violations de données personnelles

Exercise recovery decisions

Six injects to test recovery decisions

Fictional tabletop: a supplier hosts a request-processing service. T+ times are facilitation choices, not regulatory deadlines or service levels. Each card introduces an observation and a decision to explain; no real technical action or communication is executed from this page.

T+0 · Uncertain supplier signal

The supplier reports an anomaly; a user reports an outage with no confirmed diagnosis.

Roles to involve: Incident coordinator, service owner and supplier manager.
Decision to make explicit: Who verifies the source, assesses impact and decides whether to activate the plan?
Expected evidence: Initial signal, confirmation channel, case owner and next situation update.
Debrief point: Treating a supplier statement as an established cause.

T+12 · Green backup dashboard

The dashboard shows a completed copy but supplies no candidate checks.

Roles to involve: Backup team, incident response and recovery owner.
Decision to make explicit: Which evidence is needed before authorising this copy’s use?
Expected evidence: Candidate check results, origin and acceptance or rejection decision.
Debrief point: Equating job completion with restoration-asset integrity.

T+25 · Conflicting times

Two logs have different times; one omits its time zone.

Roles to involve: Analyst, supplier operator and log keeper.
Decision to make explicit: How can both observations be retained without inventing a timeline?
Expected evidence: Original times, known or unknown zones, collection time and documented reconciliation.
Debrief point: Silently correcting the source time or erasing the contradiction.

T+40 · Rejected candidate

An integrity check finds a problem in the planned candidate. An older copy exists.

Roles to involve: Recovery owner, data owner and incident coordinator.
Decision to make explicit: Who selects another recovery point and accepts the data consequences?
Expected evidence: Reasoned rejection, new candidate, checks and expected service and data impact.
Debrief point: Skipping integrity checks to meet a demonstration schedule.

T+60 · Screen back, journey failing

Roles to involve: Business owner, operations and dependency owner.
Decision to make explicit: Is service usable, degraded or still unavailable under the agreed criteria?
Expected evidence: End-to-end test, blocking dependency, business decision and communicated limits.
Debrief point: Declaring full recovery from one reachable screen.

T+85 · Communication pressure

A public question asks for a definite return time before validation is complete.

Roles to involve: Communications, incident coordination, leadership and critical supplier.
Decision to make explicit: Which approved message states confirmed facts, limits and the next update without promising an unsupported time?
Expected evidence: Message version, approver, intended audience and supplier coordination record.
Debrief point: Presenting a provisional estimate as a verified commitment.

Four questions before closing an exercise observation

Four questions before closing an exercise observation
Question	Evidence of progress	Limit
Was authority clear?	A decision actually made by the expected role, with tested cover.	An organisation chart does not prove the person can be reached.
Was the check performed?	Test evidence and a reviewed result within its scope.	A procedure alone is not execution evidence.
Does the gap have an owner?	Assigned action, local due date and verification criterion.	An overall success percentage does not describe residual risk.
Was the correction replayed?	The same situation rerun after correction with comparable evidence.	Documentary closure does not replace useful verification.

Explore NIST outcomes and the timeline →

Primary references and limits

Identifiers and outcome meanings come from CSF 2.0; SP 800-61r3 adds incident response and recovery recommendations. Evidence tables, times and scenarios are educational, with no client results, certification or actual notification.

NIST · SP 800-61 Rev. 3 · Final · 2025-04-03
Community Profile CSF 2.0 ; remplace / supersedes Rev. 2
NIST · SP 800-61r3 — recommandations détaillées / detailed recommendations · April 2025
Pages imprimées / printed pages 27–29, 34–35 : RS.MA, RS.AN, RC.RP, RC.CO
NIST · Cybersecurity Framework 2.0 · 2024-02-26 · NIST CSWP 29
Appendix A, printed pages 22–23 : official outcome identifiers
NIST · SP 800-184 — Guide for Cybersecurity Event Recovery · Final · 2016-12-22
Recovery planning, playbooks, testing and improvement

References reviewed 2026-10-22

OSINT: evidence preservation

Exercise the preservation dossier too

Inject a copy with a different digest, a missing receipt and a time without a timezone. The goal is to recognise evidence limits and choose the next check.

Test that redacted derivatives retain lineage without replacing the reference object.
Check who can change the object, digest and log together.
Expose gaps in the report instead of filling them with assumptions.

See copy lineage and the eight preservation cases →

Sources reviewed on 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

Explore NIST CSF 2.0 outcomes

Assess preparedness, then improve it

An exercise does not replace risk management. It reveals decisions, dependencies and gaps that can inform preparedness.

ID.IM-02: identify improvements from tests and exercises.
RS.MA: triage, prioritise and coordinate incident management.
RC.RP: examine integrity and functionality of the restored service.
Assign follow-up actions and check their effect without presenting a fictional scenario as a real incident.

Explore outcomes and evidence to examine →

NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22

Official references

References consulted: 22/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.