LLM Triage for Mid-Market SOCs: From Hours to Minutes
A 50-person SOC drowns before it fights. ENISA's 2024 Threat Landscape flagged alert fatigue as a top-three factor in delayed incident response across EU mid-market operators (ENISA Threat Landscape 2024).
LLM Triage for Mid-Market SOCs: From Hours to Minutes
A 50-person SOC drowns before it fights. ENISA’s 2024 Threat Landscape flagged alert fatigue as a top-three factor in delayed incident response across EU mid-market operators (ENISA Threat Landscape 2024). Mid-market means 5-15 analysts, one SIEM licence per revenue bracket, and a queue that never empties by end of shift. LLMs sitting between the SIEM and the analyst change the arithmetic — not by replacing judgement, but by pre-writing the first 80% of the ticket.
Where the hours actually go
Watch a Tier-1 analyst on a Tuesday. They receive a Splunk or Elastic alert, pivot to the endpoint console, check the user’s group memberships in AD, cross-reference the destination IP against threat intel, and only then write the first line of the ticket. That sequence takes 12-25 minutes per alert. Multiply by the daily queue and the shift ends before the queue does.
Under the NIS2 Directive, essential and important entities carry a 24-hour early-warning obligation for significant incidents (Directive (EU) 2022/2555, Art. 23). If triage eats sixteen hours, the reporting window has already closed before the analyst has even confirmed containment.
The pattern that works
An LLM enrichment layer subscribes to the SIEM event bus, pulls context (asset owner, recent authentications, threat-intel hits, MITRE ATT&CK mapping), and returns a structured triage note. The analyst reads a paragraph, not fifteen tabs.
soc_llm_enrichment:
input_queue: siem.alerts.raw
context_sources:
- ad_graph
- edr_timeline_15min
- ti_lookup_ip_hash
- asset_owner_cmdb
output_fields: [summary, mitre_ttp, suggested_action, confidence]
retention_days: 365 # NIS2 audit trail
The output arrives in the same pane the analyst already uses:
2026-09-08T09:14:22Z aegis.enrich alert_id=A-8842
summary="Kerberoasting attempt against svc-sql01 from HR laptop LT-3391"
mitre_ttp="T1558.003" confidence=0.87
suggested_action="Isolate LT-3391; rotate service account"
Below is the flow we ship to clients running under NIS2 scope, adapted from patterns discussed on our Aegis pillar.
What separates this from a chatbot bolt-on
Two things. First, the LLM never touches raw PII outside the perimeter — enrichment runs on-prem or in a sovereign region, respecting GDPR Art. 32 processing-security obligations (Regulation (EU) 2016/679). Second, the audit trail is first-class: every suggestion carries the model version, prompt hash, plus evidence links, aligned with NIST CSF 2.0 DE.AE and RS.AN functions (NIST CSF 2.0).
The mistake we see most in vendor pitches is treating the LLM as an autonomous responder. It should not be. It writes the first draft; the analyst still owns the verdict. That distinction is what keeps you defensible when a regulator asks who decided to isolate the endpoint at 03:14. We build these pipelines the same way we build orchestration for other high-stakes processes — approval-driven and evidence-preserving, boring in the good way.
Curious how this maps to your alert volume and NIS2 posture? Walk it through with our team on the Aegis engagement page.