# Cases, incidents & playbooks > Case and incident management: audit-logged cases, SLA-clocked incidents with DORA and NIS2 clocks, measured takedowns and playbooks that wait for approval. Source: https://wahukeza.com/platform/workflow 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. 1. 01 ### Declare Severity declared on the case; phases begin with SLA clocks that a sweep job enforces and a notification reports on. 2. 02 ### Classify Where DORA or NIS2 applies, the incident is assessed against the criteria and the reporting clocks start beside the SLA clocks. 3. 03 ### Attach & act Indicators, sessions, artefacts and notes, each attachment hashed and each note audit-logged; playbooks and manual actions do the work. 4. 04 ### Review A post-incident review on the case: what was detected, when, by which sensor, the root cause and the lessons. 5. 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. [Regulatory evidence & audit](https://wahukeza.com/platform/regulatory) case #2291 · regulatoryDORA · Major - Initial notificationmet · filed 3 h 10 min - Intermediate reportat risk · due in 9 h - Final reporton track Illustrative incident. Each later clock starts from the filing time the analyst records. 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. [Brand & fraud protection](https://wahukeza.com/platform/brand-protection#takedowns) takedown #412 · ebanka-prijava.exampleacknowledged registrar Example Registrar LLC (RDAP) abuse contact abuse@example-registrar.example 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 Illustrative request. 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](https://wahukeza.com/platform/mobile) · [Endpoint Response and its four-eyes gate](https://wahukeza.com/platform/endpoint-intelligence) ## Run one incident end to end. Declare, classify, attach, act, review, bundle: on a reference deployment, with a real sensor session as the evidence. [Book a demo](https://wahukeza.com/contact?intent=demo) [Back: enforcement & integrations](https://wahukeza.com/platform/enforcement)