Writing Incident Response Prompts That Actually Speed Up Triage

In the fastest quarter of intrusions, attackers now reach exfiltration in 72 minutes. That's down from 285 minutes the year before, according to Unit 42's 2026 Global Incident Response Report covering 750+ incident response engagements across 50 countries. Your triage process needs to be faster than that, and most three-person security teams can't sustain that pace manually.

Structured prompts won't replace your analysts. But they will give a small team the processing capacity that used to require eight people. Dropzone AI customers report alert reviews dropping from roughly an hour to four minutes each. The difference isn't magic -- it's constrained, well-designed prompts that do one job and do it well.

Here's what actually works.

The Problem With "Paste Logs Into ChatGPT"

Most people's first instinct is to dump a raw log file into an LLM and ask "what happened?" You'll get a confident-sounding narrative that might be completely wrong.

LLMs don't search logs. They predict plausible text. An unconstrained prompt analyzing authentication logs will happily invent IP addresses it never saw, assign attribution to threat groups based on vibes, and present the whole thing as fact.

The fix isn't avoiding LLMs for IR. It's constraining them so tightly that hallucination has nowhere to hide.

Five Rules Before You Write Any IR Prompt

1. Chunk your input. Stay under 2,000 log lines per query. Break large dumps into logical segments (by time window, by source, by host), analyze each chunk, then summarize across chunks.

2. Demand structured output. Every response should include specific fields: severity assessment, IOCs found, MITRE ATT&CK mapping, recommended next steps, confidence level, and citations pointing to specific log lines.

3. Force uncertainty flagging. Explicitly tell the model to say "insufficient data" instead of guessing. This is the single most important guardrail you can add. An LLM that says "I don't know" is infinitely more useful than one that confidently sends you chasing a phantom.

4. Role-stack the analyst. "You are a SOC analyst experienced in alert triage AND a threat hunter familiar with MITRE ATT&CK" forces the model to evaluate from multiple angles instead of defaulting to one perspective.

5. Never send real PII or internal IPs to public models. Use local or private instances for actual incident data. Your prompt templates should be ready for either context.

Prompt 1: Log Triage and Alert Prioritization

This is your first-pass prompt. Feed it a batch of alerts or log entries and get back a ranked assessment.

The Prompt:

You are a senior SOC analyst performing initial alert triage. You have 15 years of experience with enterprise SIEM platforms and are familiar with MITRE ATT&CK.

Analyze the following log entries and classify each alert into one of four categories:
- CRITICAL: Likely true positive requiring immediate investigation
- HIGH: Suspicious activity that needs analyst review within 1 hour
- LOW: Likely benign but should be documented
- FALSE POSITIVE: Explain why this is benign

For each alert, provide:
1. Classification (CRITICAL/HIGH/LOW/FALSE POSITIVE)
2. One-sentence justification citing specific log fields
3. MITRE ATT&CK technique ID if applicable
4. Confidence level (HIGH/MEDIUM/LOW)
5. If confidence is LOW, state exactly what additional data you need

If you cannot determine the nature of an alert from the provided data, classify it as HIGH and state what is missing. Do NOT guess.

Log entries:
[PASTE LOG BATCH HERE]

Why This Works: The explicit classification tiers force structured thinking instead of narrative. The confidence field with the "do NOT guess" instruction creates an escape valve for ambiguity. Requiring specific log field citations makes hallucinated analysis easy to catch -- if the model references a field that doesn't exist in your logs, you know immediately.

Expected Output:

Alert: Failed SSH login from 203.0.113.47 (47 attempts in 2 minutes) Classification: CRITICAL Justification: 47 failed attempts from a single external IP in 120 seconds indicates automated brute force against sshd, confirmed by auth.log pam_unix(sshd:auth): authentication failure entries. ATT&CK: T1110.001 (Brute Force: Password Guessing) Confidence: HIGH

Alert: DNS query to akamaiedge.net from workstation-12 Classification: FALSE POSITIVE Justification: akamaiedge.net is a legitimate Akamai CDN domain. The query volume (3 requests) is consistent with normal web browsing. No DGA characteristics in the domain name. Confidence: HIGH

Prompt 2: IOC Extraction

Once you've identified alerts worth investigating, you need indicators of compromise pulled into a structured format your tools can ingest.

The Prompt:

You are a threat intelligence analyst extracting indicators of compromise from security logs. Extract every IOC present in the following data and categorize them.

For each IOC found, provide:
- Type: IP address / Domain / URL / File hash / Email address / User agent / Registry key / File path
- Value: The exact IOC as it appears in the logs
- Context: The log line or entry where this IOC appears (quote it exactly)
- First seen: Earliest timestamp in the provided data
- Last seen: Latest timestamp in the provided data
- Assessment: KNOWN MALICIOUS / SUSPICIOUS / BENIGN / INSUFFICIENT DATA
- Basis for assessment: Why you assigned that rating. If you are unsure, say so.

Important constraints:
- Only extract IOCs that are explicitly present in the provided data
- Do NOT infer or generate IOCs that are not in the logs
- If an IP or domain could be legitimate infrastructure, mark it INSUFFICIENT DATA rather than SUSPICIOUS
- Output as a markdown table

Logs:
[PASTE RELEVANT LOG SEGMENT HERE]

Why This Works: The "quote it exactly" requirement for context is your hallucination tripwire. If the model fabricates an IOC, the quoted context won't match your logs and you'll catch it in seconds. The INSUFFICIENT DATA option prevents the model from labeling everything suspicious just to look thorough.

Prompt 3: Timeline Reconstruction

This is where you chain results. After triage and IOC extraction, you need the sequence of events laid out so a human can follow the attack path.

The Prompt:

You are an incident responder reconstructing an attack timeline from security logs and prior analysis. Your job is to establish the sequence of events with precision.

Using the provided log data and IOC analysis, construct a chronological timeline of the incident.

For each event in the timeline:
1. Timestamp (exact, from logs)
2. Source system/log
3. Event description (one sentence, factual)
4. MITRE ATT&CK technique
5. Confidence: CONFIRMED (directly observed in logs) / INFERRED (logical conclusion from available evidence) / GAP (time period with no log coverage)

Rules:
- Every CONFIRMED event must cite the specific log entry
- INFERRED events must explain what evidence supports the inference
- Identify and explicitly call out gaps in log coverage -- periods where you have no visibility
- Do NOT fill gaps with speculation. Mark them as GAP and state what logs would be needed
- End with a "What We Don't Know" section listing unanswered questions

Prior IOC analysis:
[PASTE IOC RESULTS]

Log data:
[PASTE CHRONOLOGICALLY SORTED LOGS]

Why This Works: The three confidence tiers (CONFIRMED, INFERRED, GAP) prevent the model from building a seamless narrative that papers over missing data. Real incident timelines have holes. Forcing the model to acknowledge gaps gives the analyst an honest picture of what's known versus what's assumed. The "What We Don't Know" section is the most valuable part of the output -- it tells you where to look next.

Expected Output:

02:14:33 - 02:16:41 | auth.log | CONFIRMED 47 failed SSH password attempts for root from 203.0.113.47. Automated brute force attack. ATT&CK: T1110.001 (Brute Force: Password Guessing)

02:16:41 - 02:17:05 | GAP 24-second gap between last failed login and first post-compromise activity. No successful authentication log entry found. Needed: complete auth.log for this window, check if log rotation occurred.

02:17:05 | audit.log | CONFIRMED Execution of hidden binary at /tmp/.x11-unix/.cache by uid 0. ATT&CK: T1059.004 (Command and Scripting Interpreter: Unix Shell)

What We Don't Know: - How the attacker gained root access (no successful auth log found between brute force and code execution) - What /tmp/.x11-unix/.cache contains (no file hash available in provided logs) - Whether lateral movement occurred (no network flow data provided)

Chaining Prompts Into a Workflow

These three prompts work best as a pipeline, not standalone. Run triage first to filter noise. Feed the critical/high alerts into IOC extraction. Feed the IOCs and relevant logs into timeline reconstruction.

Each prompt does one job with constrained scope. That's not a limitation -- it's the design. Agentic IR systems like Vigil (an open-source AI SOC built on multi-agent architecture) use this same pattern: triage agent, investigator agent, MITRE mapping agent, response agent. Each with a focused prompt and defined handoff points.

You don't need an agent framework to start. Run these manually, verify the outputs, and build trust in the process before automating anything.

The Guardrail That Matters Most

82% of detections in CrowdStrike's 2026 data were malware-free. Attackers used stolen credentials and legitimate tools. That means your prompts can't just look for known-bad indicators. They need to catch behavioral anomalies -- an admin account authenticating at 3 AM from a country where you have no employees, or a service account suddenly running PowerShell commands it's never run before.

The prompts above handle this because they don't rely on signature matching. They ask the model to reason about context, flag uncertainty, and identify gaps. That's closer to how a skilled analyst actually thinks.

But remember: an LLM that says "this is fine" doesn't mean it's fine. It means the model didn't find evidence of a problem in the data you gave it. Always treat LLM triage as a first draft that a human reviews and approves before any containment action is taken.

Start With One Prompt, Not Three

Pick the prompt that matches your biggest bottleneck. If your team drowns in alerts, start with triage. If you're slow to pull IOCs from logs, start there. Run it against a recent incident you've already closed so you can compare the AI output to what your team actually found.

Adjust the prompt based on your log formats, your tooling, and your team's workflow. These templates are starting points, not finished products.

If your team wants to build IR prompting skills hands-on, connect with Kief Studio on Discord or schedule a training session. We run workshops on exactly this kind of applied prompt engineering for security teams.