Skip to content
PL EN
CYBER RESILIENCE / IR · TABLETOP

Incident response readiness and tabletop exercises

We test whether people, decisions and evidence will work together when time and reliable information are limited.

A document is not readiness. We connect roles, escalation channels, telemetry, regulatory duties and business decisions in a scenario that can be exercised and improved before a real incident.

Discuss a tabletop exercise View public work
TABLETOP
Controlled exercise
RACI
Roles and decisions
EVIDENCE
Evidence sources
AFTER ACTION
Improvement plan
01 / DECISION CONTEXT

When to test readiness

  • 01Ahead of a customer, insurer, NIS2 or DORA requirement.
  • 02After a team, infrastructure, supplier or reporting-process change.
  • 03When an IR plan exists but has not been tested under pressure.
  • 04After an incident, to close gaps in decisions, evidence and communication.
02 / TEST SURFACE

Elements of real readiness

01

Decisions and ownership

We establish who decides and which information supports that decision.

  • Incident classification and ownership
  • Technical, business and legal escalation
  • Emergency contacts and deputies
02

Evidence and actions

We test whether the team can access the data needed to respond.

  • Logs, retention, EDR, IAM and backups
  • Isolation, credential reset and restoration
  • Evidence handling and secure collaboration
03

Communication and resilience

The exercise covers decisions beyond the IT layer.

  • Customers, staff, suppliers and regulators
  • Ransomware, breach, BEC or supplier outage
  • Continuity and return-to-service criteria
03 / DELIVERY

Exercise flow

  1. BR / 01

    Discovery

    We collect architecture, roles, dependencies and critical processes without creating unnecessary paperwork.

  2. BR / 02

    Scenario design

    A realistic timeline, injects and decision points are built around the organisation.

  3. BR / 03

    Facilitated tabletop

    The team works through the scenario, makes decisions and identifies the evidence available at each point.

  4. BR / 04

    After-action review

    People, process and technology gaps are separated, prioritised and assigned to owners.

04 / EVIDENCE STANDARD

Supplier ransomware blocks a critical integration

TABLETOP MODEL / NO CLIENT DATA

The scenario tests decisions made with incomplete information across IT, business and supplier relationships.

This is an example scenario. The exercise causes no outage or production-system changes.

E-1

The first signal is a failed integration rather than a security alert

E-2

The team must establish scope, ownership and a secure communication channel

E-3

A backup exists, but dependencies and keys were never included in a restore test

E-4

The plan adds RACI, decision data, restore testing and return criteria

05 / OUTPUT

Exercise outcome

01
Readiness assessment and dependency map
Included deliverable
02
Scenario, injects and decision log
Included deliverable
03
Updated incident plan and playbook
Included deliverable
04
Gap register with owners and priorities
Included deliverable
05
Leadership report and repeat-exercise plan
Included deliverable
06 / QUESTIONS

Common questions

← All services
01Is this a technical systems test?+

It is not a penetration test. A tabletop tests decisions, roles, information and procedures. It can be paired with a backup, detection or selected technical-control test.

02Who should participate?+

Usually IT, security, a business or executive owner, legal/compliance, communications and a selected supplier. The scenario determines the final group.

03Can the exercise remain confidential?+

Yes. Scope, observations and the report are covered by the agreed rules and NDA.

BR / NEXT STEP

Will the plan work under pressure?

We will select the scenario and participants, then test decisions, evidence and the shortest route to improvement.

Discuss a tabletop exercise
NDA · clear scope · direct communication