Tabletop de réponse aux incidents

Importez le pack Tabletop de réponse aux incidents et exécutez un exercice fictif Lumen.health de fuite LLM inter-tenant à travers les cinq stages, en produisant un compte rendu d'exercice daté, des critères de réussite notés et des actions de remédiation assignées.

Le process flow Tabletop de réponse aux incidents transforme « nous avons un plan de réponse aux incidents » en « nous avons exercé notre plan, et voici le compte rendu daté » — la différence qu'un auditeur vérifie réellement. Une fois installé, il offre à votre équipe de sécurité un espace de travail structuré qui guide un exercice sur table complet, de la planification jusqu'à un compte rendu signé et archivé.

📦 Télécharger ce pack : ir-tabletop-1.0.0.scrydon-pack.tar.gz — importez via Paramètres → Plateforme → Packs → Catalogue → Téléverser un pack, puis Installer. Voir tous les packs d'exemple.

Ce pack est sans IA. Il ne déclare aucune exigence de capacité ni d'intégration : il s'importe et s'exécute dans n'importe quel déploiement Scrydon, sans configuration LLM ni intégration. Les actions distribution (envoi du briefing de scénario) se rabattent sur une checklist manuelle « marquer comme distribué » lorsqu'aucune intégration e-mail/Slack n'est connectée.

Ce qu'il fournit

Artefact	Objectif
Briefing de scénario	La mise en situation de l'exercice : rôles, déroulé des injects, critères de réussite.
Compte rendu d'exercice	La capture en direct, par le scribe, de la chronologie et de chaque décision.
Constats + actions	Les critères de réussite notés et des actions de remédiation assignées et datées.
Preuve archivée	Le compte rendu signé, daté, dans votre coffre de preuves.

Correspondance de conformité

Cet exemple produit des artefacts rattachés à :

ISO 27001:2022 A.5.24 (planification et préparation de la gestion des incidents de sécurité de l'information).
ISO 27001:2022 A.5.27 (tirer des enseignements des incidents de sécurité de l'information).
SOC 2 CC7.4 / CC7.5 (réponse aux incidents et reprise).
NIS 2 Art. 21 (test des mesures de gestion des incidents), lorsqu'applicable.

Tutoriel de bout en bout

À la fin de ce tutoriel, vous aurez importé le Scrydon Pack Tabletop de réponse aux incidents, instancié pour un exercice fictif Lumen.health de fuite LLM inter-tenant, parcouru les cinq stages et produit un compte rendu d'exercice signé, prêt à intégrer votre dossier de preuves d'audit.

Priya Ramaswamy (Responsable Conformité, Facilitateur), Aisha Khan (CISO, Commandant d'incident), Lukas Berg (Staff Eng, Responsable technique), Tom De Vries (SRE, Scribe), Sofia Marino (Responsable CS, Responsable communication) et Anne Verwoerd (DPO, Liaison Juridique/DPO) le déroulent ensemble. Lumen.health est un SaaS fictif de santé mentale en série B, ~50 personnes, certifié ISO 27001, en cours de certification ISO 42001. Toutes les entités, systèmes et constats des documents de démonstration sont fictifs.

Prérequis

Vous disposez d'un déploiement Scrydon avec la surface agentic activée. Définissez les variables d'environnement suivantes pour l'étape d'import :

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

Aucun workflow système, capacité ou intégration n'est requis — le pack est entièrement piloté par des humains.

Étape 1 — Télécharger le pack

Télécharger 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

Le pack pèse ≈ 4 Kio.

Étape 2 — Inspecter le 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)

Étape 3 — Téléverser le 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"

Une réponse 200 porte le nouveau processTemplateId.

Étape 4 — Créer une nouvelle instance d'exercice

Rendez-vous sur $SCRYDON_URL/process-flows. La carte Incident Response Tabletop apparaît sous le tag Security. Cliquez sur New from template et nommez l'instance Q2 2026 IR Tabletop — Cross-Tenant LLM Leak.

L'instance s'ouvre sur la vue wizard. Le rail de gauche liste les cinq stages ; le panneau de droite déroule chaque tâche comme une scène. Les stages sont séquentiels (stageFlow: "sequential"), et chaque stage comporte une porte d'approbation — le persona nommé confirme que le stage est terminé avant que le suivant ne se débloque :

Plan & Schedule — le Facilitateur choisit le scénario, fixe la date et le roster, ouvre le coffre de preuves.
Brief Participants — distribuer le briefing de scénario ; chacun en accuse réception.
Run the Exercise — déclencher les injects ; le Scribe capture la chronologie ; le Commandant d'incident pilote la réponse.
Debrief & Findings — noter par rapport aux critères de réussite ; consigner des actions assignées et datées.
Sign-off & Evidence — le Commandant d'incident signe ; le compte rendu est archivé.

Étape 5 — Plan & Schedule

Priya choisit SC-A1 : Fuite de données LLM inter-tenant dans le runbook des exercices sur table, réserve un créneau de 90 minutes et confirme le roster (avec un Commandant d'incident adjoint nommé). Elle adapte le scénario aux vrais noms de systèmes de Lumen.health et aux critères de réussite qu'elle notera.

Télécharger 01-scenario-brief.md — le briefing de scénario adapté : rôles, règles du jeu, déroulé des injects, points de décision et les six critères de réussite.

La porte d'approbation du stage (approverPersona: "facilitator") se libère lorsque Priya confirme que la planification est terminée. Le stage suivant se débloque.

Étape 6 — Brief Participants

Priya distribue le briefing 24 heures à l'avance (l'action distribution ; une checklist manuelle si aucune intégration e-mail n'est connectée), confirme l'attribution de chaque rôle et énonce les règles du jeu : sans reproche, décisions simulées, l'horloge est réelle.

Étape 7 — Run the Exercise

L'exercice sur table de 90 minutes. Priya déclenche les injects sur la chronologie ; Aisha (Commandant d'incident) pilote la réponse et porte la décision de confinement ; Tom (Scribe) capture tout.

Télécharger 02-exercise-record.md — la capture en direct du Scribe : une chronologie décision par décision (SEV-2 déclaré à 09:14, escaladé en SEV-1 à 09:19, confinement à l'échelle de l'org à 09:26, horloge RGPD 72h ancrée à la confirmation à 09:18), un journal de décisions et les hypothèses que l'exercice a fait remonter.

Tom colle le compte rendu dans Capture the live timeline, decisions, and assumptions. La métadonnée promoteToCorpus: "minutes" le marque pour que le compte rendu atterrisse dans la base de connaissances de l'instance en tant que minutes de réunion.

Étape 8 — Debrief & Findings

L'équipe note la réponse par rapport aux critères de réussite du scénario et transforme chaque lacune en une action assignée et datée.

Télécharger 03-findings-and-action-items.md — 5 critères sur 6 atteints (la lacune : la rapidité de rédaction de la notification de violation, pas la décision), ce qui a bien fonctionné, et six actions de remédiation avec responsables et échéances — dont « vérifier que le coupe-circuit arrête réellement la récupération (retrieval), pas seulement l'UI » et « pré-préparer le modèle d'Article 33 RGPD ».

Aisha colle les constats dans Capture findings and action items ; Lukas ouvre les tickets de remédiation.

Étape 9 — Sign-off & Evidence

Aisha (Commandant d'incident) signe pour attester que l'exercice est terminé et que le compte rendu est exact (action approval). Priya confirme que les actions sont consignées et assignées. Le compte rendu signé + les critères notés + les actions sont téléversés dans le coffre de preuves (file_upload, acceptant .pdf / .docx / .md jusqu'à 25 Mo).

L'instance se clôt. Priya planifie l'exercice Q3 2026 — tenir la cadence est exactement ce qu'un auditeur vérifie pour l'A.5.27.

Trois variantes d'erreur à observer

Erreur	Comment la déclencher	Ce qu'elle signifie
`STAGE_DEPENDENCY_NOT_MET`	Tenter d'ouvrir Run the Exercise avant que Brief Participants ne soit approuvé.	`stageFlow` séquentiel appliqué ; impossible de lancer l'exercice avant que le briefing ne soit acquitté.
Porte d'approbation bloquée	Laisser l'approbation de Sign-off & Evidence non réclamée.	L'instance ne se clôt pas ; l'exercice reste « réalisé mais non signé » — c'est-à-dire pas encore une preuve. La porte est ce qui en fait un artefact.
`distribution` rabattue en checklist	Exécuter sur un tenant sans intégration e-mail/Slack.	L'action « distribuer le briefing de scénario » devient une checklist manuelle « marquer comme distribué » ; le tutoriel se déroule tout de même de bout en bout.

Personnaliser le pack

Votre exercice diverge du pack livré à trois endroits courants : le scénario (adaptez le briefing de fuite LLM inter-tenant livré avec ce pack, ou écrivez le vôtre), le roster (vous pouvez fusionner le Scribe et le Facilitateur pour une petite équipe) et la cadence (exercice trimestriel vs exercice annuel complet). Deux voies de personnalisation :

Forker le pack en TypeScript. Copiez packages/sdk-authoring/src/process-flows/examples/ir-tabletop/index.ts dans votre propre projet SDK, modifiez les personas/stages, changez package.id et template.slug pour une valeur personnalisée (p. ex. acme-ir-tabletop), incrémentez package.version, et reconstruisez avec bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. Réimportez via /api/packs/import.
L'exécuter tel quel et adapter au moment de l'instance. Chaque champ texte — le briefing de scénario, les critères de réussite, les noms du roster — se remplit par instance. Vous n'avez pas à forker pour exécuter un scénario différent ; collez simplement un autre briefing dans Plan & Schedule.

Si vous forkez, changez le slug et le package.id pour que la personnalisation de votre tenant n'entre pas en collision avec cet exemple de la documentation.