Cross-functional · Playbook 64

SOC alert triage

Every alert enriched, related alerts grouped into one probable incident, and a triage summary drafted before an analyst opens it. Analysts decide every containment step and every escalation, and no high-severity alert is ever closed by the AI.

  • Agents with tools
  • Retrieval (RAG)
  • Human in the loop
  • NCSC guidance
  • NCSC CAF
  • NIS Regulations
  • UK GDPR

At a glance

The problem
Analysts spend most of each alert gathering context by hand, so real attacks wait in the same queue as noise
Typical volume
Around 2,500 alerts a day after SIEM correlation, a few dozen worth investigating, and a handful of incidents a month
Who's involved
SOC analysts and incident leads, the CISO, IT operations, identity, data protection, legal, and the NIS lead where it applies
Pilot
10–12 weeks on a few alert types, after a 3–4 week discovery
Platforms
AWS, Azure, or a sovereign or on-prem stack, alongside your existing SIEM and EDR

An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.

The business problem

A SOC sees thousands of alerts a day from the SIEM, the EDR, email security and the cloud platforms. For each one, an analyst opens four or five consoles: who is this user, what is this machine and how important is it, has this IP or file hash been seen before, what else happened on this host in the last hour, have we had this alert before and what did we decide. Most of an analyst's time goes on gathering that context, not on judgement.

The result is familiar. Low-value alerts are closed in bulk to keep the queue down, related alerts on the same host are worked by different people, and the one that matters waits behind the noise. Notes are thin, so the next shift starts again. When something turns out to be a personal data breach or a reportable incident, the clock has often been running for a day before anyone realises.

AI can do the gathering and the first write-up. But alert content is written by whoever triggered it: a file name, a command line, an email subject or a user agent string can all be chosen by an attacker. The NCSC warns that prompt injection may never be fully fixed. So a triage agent must never be able to close, downgrade or contain anything on its own. It reads, groups and drafts; an analyst decides.

What AI changes

  • Every alert is enriched on arrival: asset owner and criticality, the user's role and recent sign-ins, threat intelligence on indicators, and recent related activity, all from read-only tools.
  • Related alerts on the same user, host or indicator are grouped into one probable incident, with a timeline and the MITRE ATT&CK techniques they suggest.
  • Each group gets a drafted triage summary: what happened, what it might mean, what's missing, a suggested severity with reasons, and the next steps from your own runbooks.
  • Containment options, such as isolating a host or disabling an account, are drafted for the analyst. A workflow carries them out only after the analyst approves, and high-impact actions need the incident lead too.
  • Possible personal data breaches and possibly reportable incidents are flagged early, with the evidence and timestamps, to the people who decide on reporting.
  • The agent can't close or downgrade any alert. It can mark low-severity alerts as likely benign for an analyst to review in bulk, and high and critical alerts always get a full analyst review.

How success is measured

Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.

Time to triage

From alert to an analyst's decision, for high and critical alerts.

ExampleDown by half

Analyst time per alert

Hands-on time spent gathering context, measured on a sample.

ExampleDown by 40–60%

Missed true positives

Alerts the agent marked likely benign that a second analyst, reviewing a weekly sample, found to be real.

ExampleZero accepted; each one reviewed

High-severity alerts closed without analyst review

Checked automatically from the case history.

ExampleZero

Grouping quality

Groups an analyst had to split or merge. Too much grouping hides a second attack.

ExampleTracked weekly, falling

Notifications on time

Personal data breaches and reportable incidents notified within the 72-hour limits, with reasons recorded for any not notified.

ExampleEvery one

UK regulation and controls

Cross-sector rules are on the UK regulation map.

  • NCSCCyber Assessment Framework v4.0 (August 2025)

    The CAF is the standard NIS regulators use. Version 4.0 raised the bar on security monitoring and on detecting abnormal behaviour, and covers AI-related risk throughout. A triage agent supports objective C (detecting cyber security events) and D (minimising impact). It's also a new system in your estate, so it needs its own access control (B2), logging and a place in your incident response plan.

  • Competent authorities / ICONIS Regulations 2018: incident reporting, where they apply

    Operators of essential services must tell their competent authority about incidents with a significant effect on the essential service without undue delay and within 72 hours of becoming aware. Relevant digital service providers report substantial incidents to the ICO. The agent flags incidents that may meet your thresholds and drafts the facts. A named person decides when the organisation is aware and whether to report.

  • ICOUK GDPR Articles 33 and 34: personal data breaches

    A breach likely to risk people's rights and freedoms must be reported to the ICO within 72 hours of becoming aware of it, and people told without undue delay if the risk is high. Every breach must be recorded, reported or not. The agent flags alerts that touch personal data and drafts the breach record. The DPO decides on reporting. SOC data is also personal data about staff, so do a DPIA and keep it in UK regions.

  • NCSC'Prompt injection is not SQL injection' (8 December 2025) and 'Managing the cyber risk of agentic AI' (interim advice, 20 August 2026)

    Alert text is attacker-controlled input. The NCSC advises limiting impact rather than hoping to block every injection: the agent's own identity, least privilege, short-lived credentials, protected logs and an emergency stop. Here the agent's tools are read-only, containment runs in a separate approved workflow, and the agent's own activity is monitored by the SOC.

  • Government / ETSIAI Cyber Security Code of Practice (DSIT, January 2025) and ETSI EN 304 223 (January 2026)

    A voluntary baseline of 13 principles for securing AI systems, including threat modelling, human oversight and monitoring. Use it to assure the triage agent like any other security tool, and ask the same of any supplier's AI features.

The solution

Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.

SOC alert triage: reference architecture
  1. 01Detection sources

    • Your SIEM
    • Your EDR and email security
    • GuardDuty, via Security HubMicrosoft Sentinel analytics rulesYour own detection rulesCloud detections
  2. 02Intake

    • EventBridge + SQSEvent Hubs + Service BusApache KafkaAlert stream
    • Amazon Security LakeMicrosoft Sentinel data lakeOpenSearchSecurity data lake (optional)
  3. 03Intelligence

    • Bedrock Knowledge BasesFoundry IQ (Azure AI Search)OpenSearch, or PostgreSQL with pgvectorRunbooks and past incidents
    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on Kubernetes, with open-weight models via vLLMTriage agent
  4. 04Orchestration

    • AgentCore GatewayAPI ManagementKong, or your existing API gatewayRead-only enrichment gateway
    • Step FunctionsLogic AppsTemporal, or n8nApproved containment workflow
  5. 05Systems of record

    • SOC case management or your ITSM tool
    • Asset inventory (CMDB) and directory
    • Threat intelligence platform
  6. 06People

    • Person
      SOC analyst: triage decision
    • Person
      Incident lead: containment and escalation
    • Person
      DPO and NIS lead: reporting decisions
  • Cloud or platform service (AWSAzuresovereign / on-prem)
  • AI agent
  • A person decides
  • Your existing systems
  • Outside your organisation

Components, side by side

SOC alert triage: components on AWS, Azure and a sovereign or on-prem stack
LayerAWSAzureSovereign / on-prem
Alert intakeTake alerts after your SIEM's correlation, not raw logs. Keep each alert's original ID so replays and retries are harmless.EventBridge and SQS, fed by your SIEM's API or webhooks; Security Hub for AWS findingsEvent Hubs and Service Bus, fed the same way; Microsoft Sentinel if it's your SIEMApache Kafka
Security data lake (optional)Only if you need longer look-backs than your SIEM keeps. The agent queries it through fixed, read-only searches.Amazon Security Lake (OCSF format)Microsoft Sentinel data lakeOpenSearch
Enrichment toolsNamed lookups: asset and owner, user and recent sign-ins, indicator reputation, EDR process tree, related alerts in a time window. No free-form queries, no write calls.AgentCore Gateway in front of read-only APIsAPI Management in front of read-only APIsKong or your existing API gateway in front of read-only APIs
Threat intelligenceInclude the NCSC and sector feeds you already receive. Record where each indicator came from.Your threat intelligence platform, or MISP on EC2 or EKSYour threat intelligence platform, or MISP on Azure VMs or AKSMISP (open source) on Kubernetes
Runbooks and past incidents (retrieval)Your approved runbooks and closed incident write-ups, so suggested next steps cite your own procedures.Bedrock Knowledge BasesFoundry IQ, built on Azure AI SearchOpenSearch, or PostgreSQL with pgvector
Reasoning and draftingBoth clouds offer a choice of models, including Claude. Many SOCs keep log data on-prem; open-weight models on your own GPUs make that possible.Amazon BedrockMicrosoft FoundryOpen-weight models served with vLLM on your own GPUs
Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore.Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on Kubernetes
Cloud providers' own security AIUseful for each provider's own estate. Check where prompts are processed and what's shared before turning them on. Security Copilot's data sharing is on by default.GuardDuty and Security Hub for AWS workloads; the GuardDuty investigation agent is in preview (London included)Security Copilot, with prompt evaluation set to the UK and data sharing reviewedNot applicable: use your own models
Containment workflowRuns only an approved action from a fixed list (isolate host, disable account, block indicator), after the analyst's approval is recorded. High-impact actions need the incident lead too.AWS Step Functions, with its own scoped roleLogic Apps, with its own managed identityTemporal or n8n, with its own scoped service account
Link to case managementGroups, summaries and drafts land as notes on the case. Only analysts change status or severity.API Gateway, plus your existing integration platformAPI Management, plus your existing integration platformKong or your existing API gateway, plus your existing integration platform
GuardrailsConfigure them so they don't block malware names and attack strings the SOC needs to see. They help, but the real control is the tool permissions.Bedrock GuardrailsFoundry guardrails (Azure AI Content Safety)Open-source guardrails (e.g. NeMo Guardrails, Llama Guard)
Identity, keys, privileged accessSeparate identities for the agent and the containment workflow. Neither uses an analyst's account.IAM roles for the agent, KMS, Secrets ManagerEntra ID workload identity, Key Vault, Privileged Identity ManagementKeycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM
Monitoring and auditThe agent is a target too. Its tool calls, refused calls and outputs go to the SOC, in storage that can't be altered.CloudWatch, CloudTrail, into your SIEMAzure Monitor, Log Analytics, into your SIEMPrometheus, Grafana, OpenTelemetry, into your SIEM
UK data residencySecurity logs are sensitive. Keep processing in the UK, including any provider AI feature.eu-west-2 (London)UK South / UK WestYour own UK data centre, or a UK provider

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

Hybrid and on-prem

Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.

Stays on-prem

Your SIEM, EDR management, domain controllers and anything that can contain or change a system stay where they are. Many SOCs also keep raw logs on-prem, and that works with this design.

Uses cloud AI

The agent, the runbook index and the drafting can run in a UK cloud region, or on your own GPUs with open-weight models if log data must not leave your estate. They receive alerts and the results of read-only lookups, never credentials.

How they connect

Alerts flow outbound over AWS Direct Connect, Azure ExpressRoute or a VPN. Lookups come back in through one read-only gateway inside your network that decides what can be asked and logs every call. Approved containment actions are pulled from a queue by a worker inside your network.

If the link drops

Analysts work alerts exactly as before, from the SIEM and their own consoles. Alerts queue and are enriched when the link returns, and nothing in detection or response depends on the AI being up.

The agents

What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.

SOC triage agent

May do

  • Read alerts and run approved read-only lookups: asset, user, sign-ins, indicators, EDR process tree, related alerts
  • Group related alerts into a probable incident with a timeline and ATT&CK mapping
  • Search runbooks and past incidents for similar cases
  • Draft a triage summary, a suggested severity with reasons, and containment options
  • Mark low-severity alerts as likely benign for an analyst's bulk review
  • Flag possible personal data breaches and reportable incidents, with the evidence

May not do

  • Close, suppress or downgrade any alert, or change a detection rule
  • Isolate a host, disable an account, reset credentials or block anything
  • Run free-form queries, scripts or commands
  • Contact users, suppliers or anyone outside the SOC
  • Decide on, or submit, a report to the ICO or a regulator
  • Follow instructions found inside alert or log content

Where a person signs offAn analyst makes every triage decision and approves every containment action, and the incident lead also approves high-impact ones such as isolating a server. The DPO and the NIS lead decide on reporting. High and critical alerts always get a full analyst review. The agent's permissions are enforced by the platform's identity and policy controls, the read-only gateway and the separate containment workflow, not by instructions in a prompt.

Middleware and integration

The SIEM stays the source of alerts and the case tool stays the system of record. Alerts are copied onto a queue with their original IDs. If the agent is slow or down, alerts reach analysts exactly as they do today; the agent adds notes when it catches up.

Every lookup goes through a read-only gateway inside your network. Each tool is a named query with a fixed scope and a rate limit, so enrichment can't overload the SIEM during an incident. Raw alert fields are passed to the model as clearly marked data, and the analyst always sees the original evidence next to the summary.

Containment is a separate path. The analyst approves an action in the case tool, an event is raised, and the containment workflow checks the approval and runs one action from a fixed list with its own scoped identity. Rules outside the model decide the minimum review: high and critical alerts can't be marked benign, whatever the model says.

Process and people

  • The SOC manager owns the agent's runbook index, prompts and tool list, with change control. Security architecture reviews every new tool before it's added.
  • Analysts can split or merge a group, change the suggested severity and reject a summary with one action, and each correction is fed back.
  • A second analyst reviews a weekly sample of alerts the agent marked likely benign, and every miss is investigated.
  • Red-team tests for the agent: alerts with injected instructions in file names, command lines and email subjects, run before go-live and after every change.
  • Clear owners for reporting decisions: the DPO for personal data breaches, the NIS lead for NIS incidents, with the 72-hour clock started by them, not by the tool.
  • Analysts keep their skills: rotate who works without the drafts, and train new analysts on raw alerts first.

Delivery plan

  1. 3–4 weeks

    Discovery

    Measure today's alert volumes, time to triage and time per alert. Pick three to five high-volume alert types. Agree the read-only tool list and containment boundary with security architecture.

  2. Gate · must be true to passBaseline measured, tool list approved, DPIA started, reporting owners named.

  3. 10–12 weeks

    Pilot

    Enrichment, grouping and summaries in shadow mode for the chosen alert types. Analysts work as normal and compare.

  4. Gate · must be true to passMissed true positives and grouping errors within agreed limits, all injection tests contained by the platform, SOC manager signs off.

  5. 4–6 weeks

    Production

    Summaries and likely-benign marking live for the pilot alert types, with containment drafts and the approved containment workflow.

  6. Gate · must be true to passSupport model in place, analysts trained, agent logs monitored by the SOC, emergency stop tested.

  7. Ongoing

    Scale

    More alert types, longer look-backs through the data lake, and the same pattern for threat hunting notes and post-incident reviews.

  8. Gate · must be true to passEach new alert type passes the same shadow gate; each new tool passes its own security review.

Roles and RACI

Who is responsible, accountable, consulted and informed, by activity
ActivityCISOSOC managerSolutions architectI can fill thisTechnical PMI can fill thisEngineersI can fill thisSecurityI can fill thisDPO
Business case and benefitsAccountableResponsibleConsultedConsultedInformedConsultedInformed
Target architecture and tool boundaryInformedConsultedAccountable and ResponsibleConsultedConsultedConsultedInformed
Containment approval rulesAccountableResponsibleConsultedInformedInformedConsultedInformed
DPIA and reporting ownersAccountableConsultedConsultedInformedInformedConsultedResponsible
Build and SIEM and case integrationInformedConsultedAccountableResponsibleResponsibleConsultedInformed
Injection and permission testingInformedConsultedResponsibleConsultedResponsibleAccountableInformed
Go-live decisionAccountableResponsibleConsultedResponsibleInformedConsultedConsulted
Run, monitor and improveInformedAccountableConsultedConsultedResponsibleConsultedInformed

Business case and benefits

CISO
A · Accountable
SOC manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
I · Informed
Security
C · Consulted
DPO
I · Informed

Target architecture and tool boundary

CISO
I · Informed
SOC manager
C · Consulted
Solutions architect
A/R · Accountable and Responsible
Technical PM
C · Consulted
Engineers
C · Consulted
Security
C · Consulted
DPO
I · Informed

Containment approval rules

CISO
A · Accountable
SOC manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Security
C · Consulted
DPO
I · Informed

DPIA and reporting owners

CISO
A · Accountable
SOC manager
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Security
C · Consulted
DPO
R · Responsible

Build and SIEM and case integration

CISO
I · Informed
SOC manager
C · Consulted
Solutions architect
A · Accountable
Technical PM
R · Responsible
Engineers
R · Responsible
Security
C · Consulted
DPO
I · Informed

Injection and permission testing

CISO
I · Informed
SOC manager
C · Consulted
Solutions architect
R · Responsible
Technical PM
C · Consulted
Engineers
R · Responsible
Security
A · Accountable
DPO
I · Informed

Go-live decision

CISO
A · Accountable
SOC manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
I · Informed
Security
C · Consulted
DPO
C · Consulted

Run, monitor and improve

CISO
I · Informed
SOC manager
A · Accountable
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
R · Responsible
Security
C · Consulted
DPO
I · Informed

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

Option A

Lead the architecture

If there's no architect on the programme, I'd own the design end to end: the alert pipeline, the read-only enrichment boundary, the separate containment path, the integration with your SIEM and case tool, and the gates. I'd work closely with your SOC manager and report to your programme board.

Option B

Support your architect

If your partner or your own team already has an architect, I'd take on the agent, its tool gateway and the integrations under their lead, and give them a second senior opinion on privileged access and on how the design holds up when the alert itself is the attack.

Where this goes wrong

  1. Goes wrong

    A malicious file name tells the agent the alert is a test, and it closes it.

    How the design avoids it

    The agent has no tool to close or downgrade alerts, rules outside the model set the minimum review, and injection tests run before go-live.

  2. Goes wrong

    The agent is given an analyst's SIEM account, with rights to edit rules and suppressions.

    How the design avoids it

    Its own identity, read-only named queries through a gateway, and the account reviewed like any other privileged one.

  3. Goes wrong

    Grouping hides a second, separate attack inside a noisy incident.

    How the design avoids it

    Analysts can split groups, splits are measured, and critical assets are never grouped away.

  4. Goes wrong

    Analysts start trusting the summary and stop reading the evidence.

    How the design avoids it

    Evidence shown beside every summary, a weekly second review, and regular work without the drafts.

  5. Goes wrong

    The 72-hour clock for a breach report started days before anyone noticed.

    How the design avoids it

    Early flags to named owners, with timestamps, and the owners decide when the organisation became aware.

On the horizon

Changes already announced or under way that affect this design. More in the UK horizon scan.

  1. Late 2026–2028
    The Cyber Security and Resilience Bill is going through Parliament. As introduced, it adds an initial notification within 24 hours and a full report within 72 hours, with the NCSC told at the same time as the regulator, and brings managed service providers and data centres into scope. Detail follows in secondary legislation.

    Build reporting thresholds and timers as configuration, and make the agent's draft hold the facts a 24-hour notice will need. If an outside provider runs part of your SOC, check its new duties.

  2. Next CAF version
    The NCSC has said it is developing the next version of the CAF to align with the Bill.

    Map the triage agent and its controls to CAF v4.0 now, so the next update is a review, not a rebuild.

  3. 31 March 2027
    Microsoft Sentinel will no longer be supported in the Azure portal, only in the Defender portal.

    If you use Sentinel, build the agent's integration against the APIs and workflows that carry on after the move, not the Azure portal experience.

  4. Formal guidance expected
    The NCSC says formal guidance will replace its interim advice on managing the cyber risk of agentic AI (August 2026).

    Build to the interim advice now: the agent's own identity, least privilege, protected logs and a tested emergency stop.

  5. 2028
    The NCSC's post-quantum cryptography milestone: a full migration plan by 2028.

    Record the cryptography on the alert feeds, the gateway and the private links, and choose components where it can be updated.

Questions to ask your partner or vendor

Good answers are specific. Vague answers to any of these are worth following up.

Copy them into your next supplier meeting

  1. Can the agent close, downgrade or suppress an alert, or contain anything? How do you prove it can't?
  2. What happens when the alert text contains instructions aimed at the agent? Show us your tests.
  3. How will you measure missed true positives on our alerts, not a benchmark?
  4. Where are our logs and prompts processed, including by any provider's built-in AI features?
  5. Who decides on breach and NIS reporting, and what will the draft give them, from where?
  6. What does it cost to run per thousand alerts, at our volume?

Planning something like this?

Whether you need someone to lead the design or to support the architect you already have, let's talk it through.

Sam Naseem
Sam NaseemBirmingham, UK · UK & Europe
Available now