# Security Alert Triage

Takes a raw security information and event management (SIEM) or endpoint detection and response (EDR) alert and produces a structured triage decision: priority, likely cause, immediate actions, and escalation recommendation. Use it when an alert lands and you need to move fast without missing a step.

## Prompt

## Context
You are a security operations analyst helping triage an alert from a SIEM or EDR platform. The analyst will supply the alert details. Your job is to produce a structured triage note they can act on and record. You do not have visibility into this environment beyond what is pasted below. Do not invent log lines, process names, hostnames, IP addresses, or threat context that the analyst did not supply.

Alert source: [ALERT SOURCE]
Alert name and rule ID: [ALERT NAME AND RULE ID]
Affected host or user: [AFFECTED ASSET]
Timestamp: [TIMESTAMP]
Raw alert detail or log excerpt: [RAW ALERT DETAIL]
Additional context from the analyst (recent changes, known activity): [ANALYST CONTEXT]

## Task
Produce a triage note with these sections:
1. Priority assessment: critical, high, medium, or low. One sentence explaining why.
2. Most likely explanation: the two or three most plausible causes, ranked, based only on the alert detail supplied.
3. Immediate analyst actions: a numbered checklist of the next three to five steps to confirm or rule out each explanation. Be specific to the data supplied.
4. Escalation recommendation: escalate now, monitor and reassess, or close with documentation. One sentence of rationale.
5. Questions for the analyst: what additional data would change the assessment.

## Standards
- Base every statement on the alert detail and context the analyst supplied. Do not reference external threat intelligence, CVE numbers, or attacker techniques unless the analyst provided that information.
- Do not state that a system is compromised or that an attack is confirmed unless the supplied evidence supports that conclusion.
- Do not invent log lines, command lines, hostnames, IP addresses, or file hashes that the analyst did not paste.
- Keep the triage note under 400 words.
- Use plain language. Spell out technical acronyms the first time.
- If a key input field is missing or blank, ask the analyst to supply it before producing the triage note.

## Variables

- ALERT SOURCE
- ALERT NAME AND RULE ID
- AFFECTED ASSET
- TIMESTAMP
- RAW ALERT DETAIL
- ANALYST CONTEXT

## Input checklist

- [ ] The exact alert text or log excerpt from your SIEM or EDR, copied from your own platform, not reconstructed from memory
- [ ] The affected hostname, username, or IP address as it appears in your asset inventory
- [ ] Timestamp and time zone of the alert
- [ ] Any recent changes in the environment relevant to this host or user (patches, new software, account changes)
- [ ] Confirm all technical artifacts (log lines, hostnames, IP addresses, process names) come from your own tools, not from the AI
- [ ] Redact passwords, credentials, personal data, and any information classified or restricted by your org policy before pasting

## Verification checklist

- [ ] Every hostname, IP address, and username in the triage note matches your environment, not an AI-invented value
- [ ] The priority assessment reflects the actual alert severity and your org's threat model, not a generic framework
- [ ] No CVE number or named threat actor appears unless you supplied that context
- [ ] The escalation recommendation aligns with your incident response (IR) plan, not a generic recommendation
- [ ] Immediate actions are achievable with your current tools and access before you forward the note
- [ ] Questions for the analyst reviewed: answer any you can answer yourself before escalating
- [ ] No credentials, PII (personally identifiable information), or restricted data appear in the note as written

## Sample output

Sample output. Generated by AI from sample inputs:

Triage Note -- Northwind Logistics, WEB-APP-03
Alert: Suspicious PowerShell execution (Rule PS-1042) | 2026-06-10 14:32 UTC

1. Priority assessment: High. PowerShell with encoded arguments on a web-facing server is a recognized post-exploitation pattern. No benign explanation is confirmed.

2. Most likely explanations:
a. Automated patch or monitoring agent running a scheduled task (most likely if a maintenance window was active).
b. Adversary lateral movement or command-and-control (C2) activity following a web application compromise.
c. Developer or admin running an ad-hoc script without change control documentation.

3. Immediate analyst actions:
1) Pull the full process tree for WEB-APP-03 from 14:00-15:00 UTC and identify the parent process of the PowerShell instance.
2) Decode the base64 argument string and review the decoded command before taking any other action.
3) Check WEB-APP-03 for outbound connections on non-standard ports in the same window.
4) Review the change management log for authorized maintenance on WEB-APP-03 today.
5) Isolate WEB-APP-03 from the network if the decoded command shows download or execution of remote content.

4. Escalation recommendation: Escalate to senior analyst now if isolation is warranted or if the decoded command is not immediately explainable. Otherwise monitor and reassess within 30 minutes.

5. Questions for analyst: Was a maintenance window active at 14:32? Who has admin credentials on WEB-APP-03? Has this rule fired on this host before?

## Customization notes

Tailor the priority scale to your org's severity definitions if they differ from critical/high/medium/low. For SOC (security operations center) teams with a ticketing system, add a Ticket ID field to the context block so the triage note links back automatically. If your environment uses specific EDR playbooks, paste the relevant playbook step titles into the Analyst Context field and the prompt will align its actions to them. Analysts new to triage can add a step in Standards asking the AI to explain each action in one sentence.

---

From The IT & Cybersecurity Library at vetslearn.com/libraries/it-cyber