From alert to lessons learned, end-to-end.

Ingest

Goal: get every alert worth looking at into a single queue.

Your SIEM, EDR, email gateway or a shell script posts JSON to /api/v1/ingest/alert, authenticated with an organisation app token sent as Authorization: token mlab_app_.... That token can create alerts and nothing else, so the credential you hand to a detection rule is not a credential to your case data.

On ingest, ir.mlab.sh:

• Reads the field names your tool already uses. Splunk's search_name, Elastic's rule.name and Sentinel's AlertName all land in the title.
• Normalises severity from words, P1-P5 or a risk score, and files the product name as a filterable tag.
• Deduplicates on the dedup_key you send, or on your external_id. A redelivery returns the alert that already exists.
• Classifies the observables in the payload, up to 100 per alert, keeping anything it cannot type as custom rather than dropping it.
• Enriches automatically, for every observable type you routed to an automatic source.

Output: a clean, deduplicated, enriched alert in the triage queue.

Triage

Goal: decide, fast, what is real and what is noise.

The triage queue is the analyst's main workspace. Filters scope by severity, source, status and age. Every alert carries its merged enrichment verdict before anyone opens it, so the first question, "is this indicator known bad", is already answered.

Every alert leaves triage with an explicit decision:

• False positive or benign. Closes the alert and feeds the false positive rate on the dashboard.
• True positive, linked to a case that already exists. Same investigation, more evidence.
• Escalate to a new case. Observables, severity and source travel with it.

Output: an alert that is either closed with a reason or attached to a case.

Investigate

Goal: build the picture. What happened, when, what was touched, who did it.

Cases are the unit of investigation. Each one has:

• A task list, optionally seeded from a case template so the same investigation always starts with the same steps.
• A timeline recording every status change, comment, evidence upload, observable and ATT&CK technique, append-only.
• An observables panel with the merged verdict from every enabled source, and the other alerts and cases the same indicator appears in.
• An evidence drawer for screenshots, PCAPs, logs and exports, hashed with SHA-256 and MD5 on the way in. Files live on your volume.
• Notes and custom fields defined by your organisation, for whatever your process needs that ours did not anticipate.

SLA deadlines count down by severity, and the case records when somebody actually picked it up: the first assignment, the first status change, or a commander being named.

Output: a case with enough evidence to decide whether this is an incident.

Respond

Goal: run the incident, and start the regulatory clock before it starts itself.

When a case turns out to be more than one investigation's worth of trouble, it is linked to an incident: an incident commander, a responder team, a TLP level, and the five NIST phases from identification to lessons learned.

Classification is where the obligations appear:

• Category, attack vector, root cause and service impact, with a restoration timestamp.
• A regulatory framework: DORA, NIS2 or RGPD. Assigning one creates every notification it requires with the deadline already calculated.
• Personal data fields when RGPD applies: data subject count, categories, DPO notification, and the risk assessment that decides whether Art. 34 applies.
• Estimated and actual cost, so the incident has a number attached to it when the review comes round.

Webhooks fire as the incident moves, into Slack, Discord, Teams or your own endpoint. Playbooks can be triggered by the same events to do the mechanical parts.

Output: a coordinated response, and a notification calendar nobody had to remember.

Close & review

Goal: close cleanly, then make the next one cheaper.

Resolution requires a verdict and a root cause where one applies. The case produces a printable dossier at /c/report/<uuid>, or a PDF through the API for a ticketing system or a scheduled job. The report carries the timeline, the observables, the evidence list, the ATT&CK mapping, the service level actually achieved, and the regulatory notification position when the case belongs to an incident.

After closure:

• A post-incident review opens on a five-day clock, with a cold review at 180 days. Each NIST phase is scored, and feedback can be left anonymously.
• Action items carry a category, a priority, an assignee, a due date and the change request that implemented them.
• Anything the incident revealed can be filed in the risk register and linked back to it.
• Metrics roll into the dashboards: MTTD, MTTR, false positive rate, triage funnel, SLA compliance, and the sources generating the most noise.

Output: a closed incident, a report, a register entry, and a shorter queue next month.