Security crisis response

Handle an actively exploited vulnerability across six stages — corroborate exploitation, contain on three parallel fronts, and file nine statutory notifications before their clocks expire.

The Security crisis response process flow takes you from "we have a confirmed exploit in the wild" to a closed, filed incident record — six stages, three simultaneous containment fronts, and nine statutory notification clocks, all visible at once on a kanban board. It is built for the moment when the phone rings and someone asks what you are legally required to do in the next 24 hours.

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

Fictional scenario. Meridian Systems, Sint-Aldegonde Hospital Group, the National Digital Infrastructure Agency, and every event, finding, regulatory filing, and person described in this walkthrough are entirely fictional. Nothing here depicts a disclosed security incident, a real company, or a real interaction with any regulator. This example is a starting point for your own deployment, not a record of any real event.

What it provides

What the pack delivers	Detail
Three parallel containment fronts (Stage 3)	Three concurrent task streams run simultaneously once Declare is signed: product containment (isolate and patch the vulnerability, verify the fix), own-environment lockdown (freeze releases, treat the pipeline as untrusted, rotate every pipeline-variable credential, audit artifact provenance across the full exposure window), and evidence-chain integrity (revoke the exposed compliance-platform token, audit the platform's own access log for the exposure window, declare which evidence artefacts are provisionally untrusted, and record re-attestation requirements for each).
Nine statutory notification clocks (Stage 4)	A parallel notification board with one card per obligation — EU CRA Art. 14 (×2), NIS 2 Art. 23 (×2), GDPR Art. 33/34 (×2), grant terms, customer liaison, and reporter update — each carrying a `dueOffsetDays` deadline chip counted from T0. Customers whose own regulatory deadlines depend on your notification are flagged; the operational filing target accounts for their downstream clock.
Root-cause analysis with AI-correction trail (Stage 6)	An optional LLM action drafts the RCA from the incident record. Both the AI draft and the IC's human corrections are preserved — what the AI inferred, what the evidence supports, and what was changed and why. Corrective actions with named owners and due dates close the stage.

Four sample artefacts are linked in the tutorial steps below: a regulatory scope memo, a notification log, an evidence-chain integrity assessment, and the signed RCA with the AI-correction trail.

Compliance mapping

This example produces artefacts mapped to:

NIS 2 Art. 21 (security measures for essential and important entities) and Art. 23 (incident reporting — early warning at T0+24h, notification at T0+72h, final report at T0+30 days).
EU CRA Art. 14 (manufacturer duty to report an actively exploited vulnerability to ENISA — early warning at T0+24h, vulnerability report at T0+72h).
GDPR Art. 33 (notification to the supervisory authority within 72 hours) and Art. 34 (communication to data subjects where required).
ISO 27001:2022 A.5.24 (incident management planning), A.5.25 (assessment and classification), A.5.26 (response), A.5.27 (learning from incidents), A.5.28 (collection of evidence).

AI posture. One action in Stage 6 — the Root-cause analysis draft — calls your configured LLM to draft the RCA from the incident record. That action is optional: if no LLM is configured, the flow marks the draft incomplete and the instance still closes when the IC provides the RCA manually. Every other action is human-driven. This matters when your own pipeline is under suspicion — the flow is designed to complete with no automated capability that might itself be untrusted.

End-to-end tutorial

By the end of this tutorial you will have imported the Security Crisis Response Scrydon Pack, instantiated it for a fictional Meridian Systems incident involving an actively exploited path-traversal vulnerability, run all six stages, and produced a signed, filed incident record ready for your evidence locker and regulator follow-up.

Lena Hartmann (CISO, Incident Commander), Marc Dubois (Head of Security Engineering, Security Lead), Sofia Nkosi (Principal Engineer, Tech Lead), Pieter van den Berg (Engineering Manager, Scribe), Carmen Vidal (Head of Customer Success, Comms Lead), Rachel Stern (Legal Counsel and DPO, Legal/DPO Liaison), Dirk Vermeersch and Ana Ferreira (Customer Liaisons — one per affected customer), and James Whitfield (CEO, Exec Sponsor) run it together. Meridian Systems, Sint-Aldegonde Hospital Group, and the National Digital Infrastructure Agency are fictional entities. All findings, filings, and regulatory interactions described 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 capability or integration configuration is required to run the flow end-to-end. The optional Stage 6 RCA draft requires an LLM integration if you want the AI step; all other actions are human-driven.

Step 1 — Download the pack

Download security-crisis-response-1.0.0.scrydon-pack.tar.gz

mkdir -p scr-tutorial && cd scr-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/security-crisis-response-1.0.0.scrydon-pack.tar.gz

The pack is 8,501 bytes.

Step 2 — Inspect the pack

bunx @scrydon/sdk-authoring pack inspect security-crisis-response-1.0.0.scrydon-pack.tar.gz

Pack:
  Package:  security-crisis-response@1.0.0
  Contents: ontology@1.0.0, process-flow@1.0.0
  Install order: ontology → process-flow
  ontology: security-crisis-response@1.0.0
  process-flow: security-crisis-response (6 stages)

Step 3 — Upload the pack

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

A 200 response carries the new processTemplateId.

Step 4 — Create a new incident instance

Browse to $SCRYDON_URL/process-flows. The Security Crisis Response card appears under the Security tag. Click New from template and name the instance CVD-2026-0012 — Path-Traversal in Artifact Endpoint (Apr 2026).

The instance opens on the kanban view — six stage columns, task cards in each. This is deliberate: three parallel containment fronts and nine active notification clocks must all be visible at once. A wizard would hide concurrent work behind a single-step pane. Stages are sequential overall (stageFlow: "sequential" with approval gates between them), but the work inside Stages 3 and 4 runs in parallel within each stage.

Step 5 — Intake & Verify

Lena (IC) and Marc (Security Lead) take the first stage together. The tasks walk them through acknowledging the reporter, reproducing the proof-of-concept in a controlled environment, pinning the affected versions (3.4.0 through 3.4.2), reserving a CVE, and agreeing a disclosure timeline with the reporter.

The critical action here is Corroborate the exploitation claim — when Marc reproduces the proof-of-concept and records the confirmation, the flow stamps T0 in UTC. Every statutory clock in Stage 4 runs from this moment. Corroboration is also what flips the EU CRA Art. 14 obligation from not-applicable to a 24-hour early-warning requirement: an unconfirmed report does not trigger Art. 14; confirmed active exploitation does.

Marc signs the Stage 1 gate (approverPersona: "security-lead"). Stage 2 unlocks.

Step 6 — Declare & Scope

Lena declares the severity (SEV-1) and the flow moves into regulatory triage. The pivot action — Determine which regulatory hats apply — is where Rachel Stern maps each possible obligation: EU CRA manufacturer, NIS 2 entity, GDPR processor and controller, grant terms. The output is a regulatory scope memo that drives Stage 4.

The stage also builds the affected-customer register. Because customers answer to different regulators — Sint-Aldegonde Hospital Group is a NIS 2 essential entity in Belgium, while NDIA carries contractual grant-term obligations — a dedicated Customer Liaison is assigned per customer. The customer-liaison persona has cardinality many so both Dirk Vermeersch and Ana Ferreira appear on the board simultaneously.

Lena notifies the management body (James Whitfield) that an incident has been declared.

Download 01-regulatory-scope-memo.md — Rachel Stern's regulatory hat assessment: one row per obligation, with applies-yes/no, the clock it starts, and who owns it. Plus the affected-customer register with each customer's own downstream deadline and the Meridian notification deadline that derives from it.

Lena signs the Stage 2 gate (approverPersona: "incident-commander"). Stages 3 and 4 are now ready.

Step 7 — Contain

Stage 3 is stageType: "parallel" — three task templates run concurrently as soon as the stage opens:

contain-product — Sofia Nkosi identifies the vulnerable code path (the artifact-serving endpoint's directory-traversal flaw), builds a patch from an isolated branch, deploys it to a controlled environment for verification, and prepares the production release. She does not deploy to production yet — the release freeze from contain-own-environment is still in effect.

contain-own-environment — The team freezes all Meridian releases and treats the CI/CD pipeline as untrusted until proven otherwise. Every pipeline-variable credential is rotated — not just the compliance-platform token. The artifact provenance audit runs across the full 27-day exposure window: for each build artifact produced since version 3.4.0 was shipped, the team verifies the artifact's supply-chain provenance against the source commit. This audit gate is what lifts the release freeze.

contain-evidence-chain — Marc Dubois revokes the exposed compliance-platform service-account token and reissues a replacement with reduced scope and IP restrictions. He then audits the compliance platform's own log for every API call made using the exposed token during the 27-day window. He assesses whether stored evidence was modified. He declares which evidence is provisionally untrusted — not because modification was confirmed, but because the token held write access and the audit trail cannot exclude it with certainty.

Download 03-evidence-chain-integrity-assessment.md — Marc's Stage 3 assessment: the token's permission scopes, the full audit-log analysis (111 explained calls, 3 anomalous), the hash-verification results, the three artefacts declared provisionally untrusted, and the re-attestation requirements for each.

Step 8 — Notify

Stage 4 is stageType: "parallel" — nine notification tasks run concurrently, each with its own deadline:

Task	Obligation	`dueOffsetDays`
`notify-enisa-early-warning`	EU CRA Art. 14(2) early warning	1
`notify-enisa-vuln-report`	EU CRA Art. 14(2) vulnerability report	3
`notify-nis2-early-warning`	NIS 2 Art. 23(1) early warning	1
`notify-nis2-incident`	NIS 2 Art. 23(4) incident notification	3
`notify-gdpr-authority`	GDPR Art. 33 supervisory-authority notification	3
`notify-data-subjects`	GDPR Art. 34 (if applicable)	—
`notify-customers`	Sint-Aldegonde and NDIA (operational target: T+18h for Sint-Aldegonde)	1
`notify-funding-body`	NDIA grant terms clause 14.2	—
`notify-reporter`	CVD disclosure update to the researcher	—

Each task card on the kanban board shows a deadline chip counting down from T0. Pieter (Scribe) maintains the notification log as the stage progresses.

Customer notification (notify-customers) fires early — T+8h59m rather than the T+18h operational target set in Stage 2. Sint-Aldegonde's own NIS 2 Art. 23 early-warning clock starts from the moment they receive Meridian's notification, not from T0. Filing at T+18h would leave Sint-Aldegonde fewer than 6 hours to brief their security officer and prepare their own early warning. Carmen Vidal sends the notification package at 19:22 UTC on the day T0 is stamped, giving Sint-Aldegonde a full working shift to file before their own deadline.

Download 02-notification-log.md — Pieter's Stage 4 notification log: all nine clocks, their T0-relative deadlines, the actual filed-at timestamps (including the GDPR Art. 33 filing with 6 minutes to spare), and a note on what the customers received and why the notification was sent early.

Step 9 — Remediate & Recover

With Stage 3 complete and all three containment fronts closed, the team shifts to recovery. Sofia builds the production release from a known-clean pipeline — a fresh pipeline runner provisioned after the exposure window, isolated from any environment that touched Meridian's staging cloud subscription. The build artifact is re-signed, and provenance is verified against the source commit before release.

After the patch ships, Carmen confirms that each customer has applied the update and provides upgrade confirmation in writing. Marc runs re-attestation for the three provisionally untrusted evidence artefacts: each is re-produced from its primary source system, hash-verified, and re-uploaded to the compliance platform with a chain-break annotation.

The optional Emerging root-cause read AI action gives the IC a preliminary structural read on contributing causes based on the incident record so far. It is flagged optional — if no LLM is configured, the task is skipped.

After 24 hours of recurrence watch with no new indicators, Lena signs the Stage 5 gate (approverPersona: "incident-commander"). Stage 6 unlocks.

Step 10 — Close, Disclose & Learn

The final stage runs under James Whitfield's gate (approverPersona: "exec-sponsor").

The CVE advisory is published, crediting the independent researcher by name and including a coordinated disclosure timeline. The NIS 2 final report is filed at dueOffsetDays: 30 from T0.

The optional Root-cause analysis draft AI action generates a draft RCA from the incident record, the audit log findings, and the notification log. The IC reviews the draft, corrects any inferences the AI made that the record does not support, and signs the corrected version. The AI draft is not the final RCA — the signed, human-corrected version is.

Corrective actions (eight items in the Meridian example, labelled CA-1 through CA-8) are assigned to named owners with due dates. James signs the management-body sign-off. The incident record is filed.

Download 04-rca-and-corrective-actions.md — Lena Hartmann's signed RCA: the timeline, the causal chain, the detection gaps (including the 20-hour-14-minute CVD-to-T0 lag), the containment gaps, and eight corrective actions (CA-1–CA-8). A visible note explains exactly what the AI draft got wrong and what the IC corrected.

Three error variants worth seeing

Error	How to trigger	What it means
`STAGE_DEPENDENCY_NOT_MET`	Try to open Stage 4 (Notify) before Stage 2 (Declare) is signed by the IC.	Sequential `stageFlow` is enforced: the notification tasks cannot start until the regulatory scope is established. Firing notifications before you know which obligations apply is how deadlines get missed or wrong filings get submitted.
Overdue statutory clock	Leave a `notify-*` task unstarted past its `dueOffsetDays`.	The task card on the kanban board shows a red deadline chip and a `PAST_DUE` status. The instance does not close itself — the obligation is still live and must be filed, with a late-filing note for the regulator.
RCA draft incomplete — no LLM configured	Run Stage 6 on a tenant with no LLM integration.	The Root-cause analysis draft action is marked incomplete (optional). The flow still closes when the IC files a manually written RCA and James signs the exec gate. The optional status is deliberate: your own pipeline may be the suspect, and you should not depend on an automated capability you cannot yet trust.

Customising the pack

Your real incident will differ from the Meridian scenario in three places: the regulatory mix (which of the five hats actually apply to you), the customer roster (how many customer liaisons you need and what each customer's own obligations are), and the clock set (which of the nine notification tasks are live obligations and which are not relevant to your jurisdiction or entity type). Two customisation paths, plus one specific to this pack:

Fork the pack in TypeScript. Copy the source from packages/sdk-authoring/src/process-flows/examples/security-crisis-response/index.ts into your own SDK project, edit the stage templates and personas, change package.id and template.slug to a custom value (e.g. acme-security-crisis), 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. The stage task templates are filled in per instance. You can skip tasks that do not apply, add notes explaining why, and assign personas to the people actually available. You do not have to fork to run a different regulatory set.
Prune the clocks you are not subject to. If you are not a CRA-in-scope manufacturer, remove notify-enisa-early-warning and notify-enisa-vuln-report from Stage 4 rather than leaving them on the board as tasks that will never be filed. An unfiled task with a deadline chip that has expired looks like a missed obligation to anyone reading the instance record. Fork the pack (path 1) and drop the inapplicable notify-* task templates from the Stage 4 definition, or mark them explicitly skipped at instance time with a recorded rationale.

If you fork, change the slug and package.id so your organisation's customised version does not collide with this docs example.