Incident response tabletop

Import the Incident Response Tabletop pack and run a fictional Lumen.health cross-tenant LLM-leak exercise through all five stages, producing a dated exercise record, scored success criteria, and owned remediation action items.

The Incident response tabletop process flow turns "we have an incident-response plan" into "we exercised our plan, and here is the dated record" — the difference an auditor actually checks. Once installed, it gives your security team a structured workspace that walks one complete tabletop from planning to a signed, filed exercise record.

📦 Download this pack: ir-tabletop-1.0.0.scrydon-pack.tar.gz — import via Settings → Platform → Packs → Catalog → Upload pack, then Install. See all example packs.

This pack is AI-free. It declares zero capability or integration requirements, so it imports and runs in any Scrydon deployment with no LLM or integration configuration. The distribution actions (sending the scenario brief) degrade to a manual "mark distributed" checklist when no email/Slack integration is connected.

What it provides

Artefact	Purpose
Scenario brief	The exercise's setup, roles, inject timeline, and success criteria.
Exercise record	The Scribe's live capture of the timeline and every decision.
Findings + action items	Scored success criteria and owned, dated remediation items.
Filed evidence	The signed record, dated, in your evidence locker.

Compliance mapping

This example produces artefacts mapped to:

ISO 27001:2022 A.5.24 (information security incident management planning and preparation).
ISO 27001:2022 A.5.27 (learning from information security incidents).
SOC 2 CC7.4 / CC7.5 (incident response and recovery).
NIS 2 Art. 21 (testing of incident-handling measures), where in scope.

End-to-end tutorial

By the end of this tutorial you will have imported the Incident Response Tabletop Scrydon Pack, instantiated it for a fictional Lumen.health cross-tenant LLM-leak exercise, run all five stages, and produced a signed exercise record ready to drop into your audit evidence pack.

Priya Ramaswamy (Compliance Lead, Facilitator), Aisha Khan (CISO, Incident Commander), Lukas Berg (Staff Eng, Technical Lead), Tom De Vries (SRE, Scribe), Sofia Marino (Head of CS, Communications Lead), and Anne Verwoerd (DPO, Legal/DPO Liaison) run it together. Lumen.health is a fictional Series-B mental-health SaaS, ~50 staff, ISO 27001 certified, pursuing ISO 42001. All entities, systems, and findings in the demo documents are fictional.

Prerequisites

You have a Scrydon deployment with the agentic surface enabled. Set the following env vars for the import step:

export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"

No system workflows, capabilities, or integrations are required — the pack is entirely human-driven.

Step 1 — Download the pack

Download ir-tabletop-1.0.0.scrydon-pack.tar.gz

mkdir -p ir-tabletop-tutorial && cd ir-tabletop-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/ir-tabletop-1.0.0.scrydon-pack.tar.gz

The pack is ≈ 4 KiB.

Step 2 — Inspect the pack

bunx @scrydon/sdk-authoring pack inspect ir-tabletop-1.0.0.scrydon-pack.tar.gz

Pack:
  Package:  ir-tabletop@1.0.0
  Contents: ontology@1.0.0, process-flow@1.0.0
  Install order: ontology → process-flow
  ontology: ir-tabletop@1.0.0
  process-flow: ir-tabletop (5 stages)

Step 3 — Upload the pack

curl -X POST "$SCRYDON_URL/api/packs/import?organizationId=$ORG_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@ir-tabletop-1.0.0.scrydon-pack.tar.gz"

A 200 response carries the new processTemplateId.

Step 4 — Create a new exercise instance

Browse to $SCRYDON_URL/process-flows. The Incident Response Tabletop card appears under the Security tag. Click New from template and name the instance Q2 2026 IR Tabletop — Cross-Tenant LLM Leak.

The instance opens on the wizard view. The left rail lists the five stages; the right panel walks each task as a scene. Stages are sequential (stageFlow: "sequential"), and each stage has an approval gate — the named persona confirms the stage is done before the next unlocks:

Plan & Schedule — Facilitator picks the scenario, sets the date and roster, opens the evidence locker.
Brief Participants — distribute the scenario brief; everyone acknowledges.
Run the Exercise — release the injects; the Scribe captures the timeline; the IC drives the response.
Debrief & Findings — score against success criteria; capture owned, dated action items.
Sign-off & Evidence — the IC signs off; the record is filed.

Step 5 — Plan & Schedule

Priya picks SC-A1: Cross-Tenant LLM Data Leak from the IRP tabletop runbook, books a 90-minute slot, and confirms the roster (with a named deputy IC). She adapts the scenario to Lumen.health's real system names and the success criteria she'll score against.

Download 01-scenario-brief.md — the adapted scenario brief: roles, ground rules, the inject timeline, the decision points, and the six success criteria.

The stage's approval gate (approverPersona: "facilitator") clears when Priya confirms planning is done. The next stage unlocks.

Step 6 — Brief Participants

Priya distributes the brief 24 hours ahead (the distribution action; a manual checklist if no email integration is connected), confirms each role is assigned, and states the ground rules: no-blame, decisions are simulated, the clock is real.

Step 7 — Run the Exercise

The 90-minute tabletop. Priya releases the injects on the timeline; Aisha (IC) drives the response and owns the containment call; Tom (Scribe) captures everything.

Download 02-exercise-record.md — the Scribe's live capture: a decision-by-decision timeline (declared SEV-2 at 09:14, escalated to SEV-1 at 09:19, contained org-wide at 09:26, GDPR 72h clock anchored to confirmation at 09:18), a decisions log, and the assumptions the exercise surfaced.

Tom pastes the record into Capture the live timeline, decisions, and assumptions. The promoteToCorpus: "minutes" metadata tags it so the record lands in the instance's knowledge base as meeting minutes.

Step 8 — Debrief & Findings

The team scores the response against the scenario's success criteria and turns every gap into an owned, dated action item.

Download 03-findings-and-action-items.md — 5 of 6 criteria met (the gap: breach-notification drafting speed, not the decision), what went well, and six remediation action items with owners and due dates — including "verify the kill-switch actually stops retrieval, not just the UI" and "pre-stage the GDPR Art. 33 template."

Aisha pastes the findings into Capture findings and action items; Lukas opens the remediation tickets.

Step 9 — Sign-off & Evidence

Aisha (IC) signs off that the exercise is complete and the record is accurate (approval action). Priya confirms the action items are logged and assigned. The signed exercise record + scored criteria + action items are uploaded to the evidence locker (file_upload, accepting .pdf / .docx / .md up to 25 MB).

The instance closes. Priya schedules the Q3 2026 tabletop — keeping cadence is exactly what an auditor checks for A.5.27.

Three error variants worth seeing

Error	How to trigger	What it means
`STAGE_DEPENDENCY_NOT_MET`	Try to open Run the Exercise before Brief Participants is signed off.	Sequential `stageFlow` enforced; you can't run the exercise before the brief is acknowledged.
Approval gate held	Leave the Sign-off & Evidence approval unclaimed.	The instance does not close; the exercise stays "run but not signed" — i.e. not yet evidence. The gate is what makes it an artefact.
`distribution` degraded to checklist	Run on a tenant with no email/Slack integration.	The "distribute the scenario brief" action becomes a manual "mark distributed" checklist; the tutorial still runs end-to-end.

Customising the pack

Your tabletop diverges from the shipped pack in three common places: the scenario (adapt the cross-tenant LLM-leak brief shipped with this pack, or write your own), the roster (you may fold Scribe into the Facilitator for a small team), and the cadence (quarterly drill vs. annual full exercise). Two customisation paths:

Fork the pack in TypeScript. Copy packages/sdk-authoring/src/process-flows/examples/ir-tabletop/index.ts into your own SDK project, edit the personas/stages, change package.id and template.slug to a custom value (e.g. acme-ir-tabletop), bump package.version, and rebuild with bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. Re-upload via /api/packs/import.
Run it as-is and adapt at instance time. Every text field — the scenario brief, the success criteria, the roster names — is filled in per instance. You don't have to fork to run a different scenario; just paste a different brief in Plan & Schedule.

If you fork, change the slug and package.id so your tenant's customisation doesn't collide with this docs example.