Act · Cases, incidents & playbooks
From a suspicious indicator to a verifiable evidence bundle.
Cases group the work. Incidents put a clock on it and, where DORA or NIS2 applies, the regulator’s clock too. Playbooks do the repetitive parts and wait for a person on anything consequential. Takedowns close the loop with the registrar. Everything is audit-logged and the bundle at the end is hashed.
Cases
The unit of analyst work.
Indicators and context
Add indicators from any list with bulk actions; the case carries their relations, sessions and artefacts with them.
Audit-logged timeline
Notes, status changes and attachments with actor and time. The timeline is the record, not a chat.
Priority, status, owner
The fields that matter, kept in the URL so a case view is a link you can paste into a ticket.
Export
A case exports with its evidence for the client, the SIEM or the ticketing system.
Incident lifecycle
Declared severity, phases with clocks, a review and a hashed bundle.
01
Declare
Severity declared on the case; phases begin with SLA clocks that a sweep job enforces and a notification reports on.
02
Classify
Where DORA or NIS2 applies, the incident is assessed against the criteria and the reporting clocks start beside the SLA clocks.
03
Attach & act
Indicators, sessions, artefacts and notes, each attachment hashed and each note audit-logged; playbooks and manual actions do the work.
04
Review
A post-incident review on the case: what was detected, when, by which sensor, the root cause and the lessons.
05
Bundle
A hashed evidence bundle, including any regulatory notification drafts: the artefact you hand to a client, an auditor or a supervisor, verifiable later.
Regulatory classification
The regulator’s deadline, on the same incident.
Enable DORA, NIS2 or both, and a declared incident gains a regulatory section: the criteria answered, a deterministic Major or Significant outcome naming what triggered it, and the reporting stages with their due times (DORA’s 4-hour initial notification, NIS2’s 24-hour early warning and what follows). Admins are alerted when a stage is at risk or overdue; the notification drafts are pre-filled from the case and recorded when you file them. The platform never files for you.
- Initial notificationmet · filed 3 h 10 min
- Intermediate reportat risk · due in 9 h
- Final reporton track
Takedowns
The notice is drafted from the evidence on file. A person sends it.
Raise a takedown from a case. RDAP fills the registrar and abuse contact; the notice and a hashed evidence pack are built from the indicators, screenshots and records already attached. The analyst sends it; replies thread onto the request; reminders follow only if the sender armed them; the next rung of the escalation ladder is drafted, not sent. Verification watches the target and proposes completion when it goes down; the analyst closes. Time-to-takedown is measured per provider and month.
- registrar
- Example Registrar LLC (RDAP)
- abuse contact
- [email protected]
- evidence pack
- screenshot · page extract · CT · RDAP · DNS · HTTP · sha256:7d0e…a41c
- history
- Sent by an analyst 2026-11-04 · reply received 11 h later · Netcraft report filed
- verification
- Target down observed 2026-11-05 09:20 → completion proposed, awaiting analyst
Automated Playbooks
Enough automation to remove the toil, not enough to surprise you.
A trigger, conditions and ordered actions from a closed set of nine. No scripts and no arbitrary code. Actions with consequences produce a draft or a proposal, or wait for an approver, who can approve from the phone.
| action | does |
|---|---|
| enrich | Run enrichment on the indicator. |
| tag | Add a tag to the indicator. |
| add-to-case | File the indicator into a case: one case, not a hundred. |
| notify | Send to an alert channel. |
| call-webhook | Post to a webhook you configured. |
| open-ticket | Open a Jira Cloud or ServiceNow ticket from the case (waits for approval). |
| open-takedown | Create a takedown draft (never sends it). |
| endpoint-respond | Propose an endpoint action (never executes it). |
| share-to-group | Label for a sharing group (waits for approval). |
Guard rails
Every run stored, every approval recorded.
run history
Runs are records
Every run is stored with its inputs and each action’s outcome; the approval ledger goes into the auditor evidence pack.
approval · expiry
Approval by someone else
Gated actions wait for an approver who is not the author; unapproved runs expire rather than linger.
/m
Approve from the phone
Gated playbook runs and proposed response actions can be approved or rejected from the mobile decision board, with step-up sign-in for the most consequential.
dry-run · rate caps
Test, then bound it
Run against recent events without side effects and read what would have happened; per-playbook caps mean a runaway rule cannot open a thousand tickets.
Mobile approvals and notifications · Endpoint Response and its four-eyes gate
Run one incident end to end.
Declare, classify, attach, act, review, bundle: on a reference deployment, with a real sensor session as the evidence.