Claude Prompts for SOC Analysts: Triage, Timelines and Reports
Defensive prompts for alert triage notes, incident timelines, policy drafts, tabletop scenarios and report writing. Redact hostnames, IPs and personal data before you paste.
In short: This page contains 30 copy-paste ready prompts, organized into 6 categories with a description and pro tip for each. The first 5 prompts are free instantly, no signup needed. Drafted with AI writing assistance and checked against our editorial policy.
Alert Triage
5 promptsEDR Alert Triage Table
1/30✨ What it does
Turns one raw EDR alert into a table that separates what the alert shows from what could explain it innocently. Check every row marked [VERIFY] against the console before you change the alert status.
Here is an EDR alert from my console: [ALERT TEXT]. MITRE ATT&CK technique ID I already logged: [TECHNIQUE ID OR NONE]. If I gave a technique ID, add it to the row it relates to. Add no other ID. If I wrote NONE, leave the ID out and add no technique ID anywhere. Do not invent a technique ID. Build a table with the columns Field, What it shows, Benign explanation, Needs checking. Use one row per field in the alert, 8 rows at most. Use only what the alert says. Benign explanation is a hypothesis, so label it as one. If a field I need is missing, write [VERIFY] in the cell. Last line: escalate, keep watching or close, with the reason in 15 words or fewer. Identifiers in this paste are already labels (HOST-A, USER-A); leave them as they stand.
Pro tip: Paste the alert text exactly as the console shows it, with identifiers already redacted.
False Positive Checklist
2/30✨ What it does
Gives a short yes or no checklist for deciding whether an alert is noise from a normal process. Work through it in order and write the answers in the ticket so a second analyst can repeat them.
Act as a checklist builder for a SOC analyst. The alert is [ALERT NAME] from [EDR PRODUCT], raised on a [ASSET TYPE] during [TIME WINDOW]. What is normal for this asset: [NORMAL ACTIVITY FOR THIS ASSET]. If that line is blank, mark the related check [VERIFY] and do not invent a baseline. Give 7 yes or no checks that could show the alert is a false positive, such as a known admin tool, a scheduled job or a planned patch window. Each check ends with the field to look at. Number the checks 1 to 7.
Pro tip: Paste approved admin tools and scheduled jobs into the normal activity line.
Five Questions Before Escalating
3/30✨ What it does
Runs a short interview that gets the facts out of the analyst before a decision. Read the verdict aloud to your shift lead, and confirm the [VERIFY] facts in the console before you escalate.
Ask me exactly 5 questions, one at a time, to decide whether [ALERT NAME] goes to the incident queue. Wait for my answer after each question. If an answer is unclear, treat that fact as unknown and tag it [VERIFY]. After my fifth answer, write a verdict of under 80 words and name the one piece of evidence that would change it. Do not invent facts about my environment; any fact you still need goes in the verdict as [VERIFY]. Keep the verdict to one short paragraph.
Pro tip: Answer with facts you can see in the console, not with what you suspect.
Rank Three Open Alerts
4/30✨ What it does
Puts three open alerts in a defensible 1-2-3 order and gives the reason for the top pick. Use it to decide the queue, then check the ranking with your shift lead.
I have three open alerts in my queue: [ALERT 1], [ALERT 2] and [ALERT 3]. Rank all three in 1-2-3 order, with one line each on the reason. Rank on risk to the business and how fast it could spread, using only the details I wrote here. If a detail for one alert is missing, write [VERIFY] beside it and do not invent a severity. After the 1-2-3 list, give 60 words on why number 1 comes first. Identifiers in what I pasted are already labels like HOST-A and USER-A; do not change them.
Pro tip: Give each alert one line of context, such as the asset role, not the full log.
Numbered Checks for a Login Alert
5/30✨ What it does
Produces a numbered list of checks for a suspicious sign-in, each tied to one log source. Run the checks in order and stop when one answers the question clearly.
Give me numbered checks, 8 at most, for a failed then successful sign-in alert on the account [ACCOUNT LABEL] from the network range [NETWORK LABEL]. Prefer log sources that appear in [TOOLS AVAILABLE]. Do not invent a log product I never named; if a useful source is missing from that list, still add the step and tag it [VERIFY]. Each step names one log source and the one question it answers. Use no commands and no tool syntax. Keep [ACCOUNT LABEL] unchanged in every step.
Pro tip: List your real tools in the brackets so the steps match what you can open.
Incident Timelines
5 promptsIncident Timeline Table
6/30✨ What it does
Converts scattered notes into a sorted table with a confidence column for each event. Check each [VERIFY] row against the log before the timeline goes into the ticket.
Here are my raw notes: [RAW NOTES]. Convert them into an incident timeline table with the columns Time (UTC), Event, Source, Confidence. Sort the rows by time, with one event per row. Mark any row whose time or source I did not give as [VERIFY] rather than inventing a time. I swapped real hosts and users for labels like HOST-A and USER-A; do not restore the original names.
Pro tip: Write times in UTC when you take the notes, so the table needs no conversion.
Critique This Timeline Draft
7/30✨ What it does
Scores a timeline draft on completeness, ordering and sourcing, then rewrites its three weakest rows. Compare the rewritten rows with the logs before you replace the original.
Critique this timeline draft and score it from 1 to 5 on completeness, ordering and sourcing. Score completeness on missing event types, not on time gaps. Then rewrite the 3 weakest rows. Draft: [PASTE TIMELINE DRAFT]. Do not invent events or times to fill a missing event type; mark each missing type as [VERIFY]. The draft already uses HOST-A and USER-A in place of real names; leave those labels as written.
Pro tip: Paste the draft as it stands, weak rows included, so the gaps show up.
Timeline Gap Check
8/30✨ What it does
Lists the silent stretches in a timeline and the type of log that could fill each one. Pull those logs before you treat the timeline as complete.
Read this incident timeline: [TIMELINE]. List every silent stretch longer than [GAP MINUTES] minutes. For each gap, suggest the type of log that could fill it (for example mail trace or sign-in log). If my text does not show that log exists in my environment, add [VERIFY] after it. Do not name a product I did not mention; do not invent a source. Output a numbered list, one gap per item, 8 items at most. Do not add events to the timeline itself. Leave HOST and USER labels as I wrote them.
Pro tip: Set [GAP MINUTES] to the longest pause your playbook still treats as normal.
Phishing Report Timeline
9/30✨ What it does
Fills a five-step phishing timeline from your notes and marks every missing time. Check each line against the mail trace and the sign-in log before you close the report.
Fill in this template using only my notes. Template: Reported at ___, first click at ___, mailbox search at ___, account reset at ___, message removed at ___. My notes: [PHISHING NOTES]. Write the completed template as five lines. If a time is not in my notes, write [VERIFY] in its place and do not invent one. The paste uses labels such as HOST-A and USER-A in place of real names; keep them.
Pro tip: Keep the template order fixed so every phishing report reads the same way.
Compare Two Timeline Versions
10/30✨ What it does
Lists the events that differ between two timeline versions and says which source to trust. The trust column is a starting point, so confirm it against the raw logs before you merge.
Compare two versions of the same incident timeline. Version A is [VERSION A] and version B is [VERSION B]. List every event that appears in one version but not the other, in a table with the columns Event, In A, In B, Which to trust and why. Do not invent events. If the sources do not show which version is right, write [VERIFY] in the trust column. Keep every HOST-A and USER-A label exactly as I pasted it; do not expand them back to real identifiers.
Pro tip: Name the source of each version, such as the SIEM export or the analyst notes.
Containment and Response
5 promptsContainment Options Compared
11/30✨ What it does
Sets two containment choices side by side with what each stops and who each one affects. The table helps the incident lead decide, but the business owner must confirm the impact column.
I need a side by side of two containment options for [AFFECTED HOST LABEL]: isolating the host from the network, and disabling the account [ACCOUNT LABEL] for [TIME WINDOW]. Give a table with the columns Option, What it stops, Who it affects, How to reverse it. Keep each cell under 15 words. Use only the facts in my notes: [CONTEXT NOTES]. Do not invent business impact; write [VERIFY] wherever my notes do not say who depends on the host. Host, user and address values in my paste are already labels; leave HOST-A and USER-A as written.
Pro tip: Fill the context notes with the owner of the host, so the impact column is real.
Containment Checklist for Ransomware
12/30✨ What it does
Produces a ten-item containment checklist with an owner role for each step. Walk it with the incident lead and tick items only when the evidence is in the ticket.
Build a containment checklist of 10 checkbox items for a suspected ransomware event on [SYSTEM TYPE], in the order a responder would take them. Each item names an owner role, such as SOC lead or IT admin. Backup and isolation facts I already know: [BACKUP AND ISOLATION FACTS]. Mark any item that depends on a fact I did not give as [VERIFY] and do not invent backup status or isolation state. This is defensive only: no steps to run malware, no steps to evade detection.
Pro tip: Paste backup status and isolation state into [BACKUP AND ISOLATION FACTS] before you run it.
Stalled Response Troubleshooter
13/30✨ What it does
Matches each stalled symptom to a likely cause and the check that would confirm it. Run the checks in the list order and record each result in the ticket.
My containment has stalled. Symptoms, one per line: [SYMPTOMS]. Environment labels: [ENVIRONMENT LABELS]. For each symptom, write a numbered item with three parts: symptom, cause, check. Base each cause only on the symptoms I gave, call it a hypothesis, and write [VERIFY] where my text does not support it. Do not invent a cause that my symptoms do not hint at. I already swapped hostnames and users for labels such as HOST-A and USER-A; leave those labels as they are.
Pro tip: Describe what you see on screen, not what you think the cause is.
Shift Handover Note
14/30✨ What it does
Turns four short notes into a handover that the next shift can act on. Read the [VERIFY] lines aloud at the handover so nobody assumes a missing owner.
Fill this handover template with my notes only. Open incidents: [OPEN INCIDENTS]. Contained so far: [CONTAINED]. Waiting on: [WAITING ON, WITH OWNER]. Next check due: [NEXT CHECK AND TIME]. Keep the whole note under 150 words. For anything I did not give, write [VERIFY] and do not invent an owner or a time. Real hostnames and people are already replaced with HOST-A and USER-A style labels; keep those labels.
Pro tip: Put the owner next to every waiting item, or it will be lost at shift change.
Five-Day Recovery Plan
15/30✨ What it does
Plans the five days after containment with one focus and one exit condition per day. Revisit the plan each morning and move a day forward only when its exit condition is met.
Plan the five days after containment for [SYSTEM LABEL] following the incident in [INCIDENT SUMMARY]. Day 1 to Day 5, one line each: Focus, Check, Exit condition. Keep each line under 25 words. Do not invent a recovery time or a backup date; if my notes lack them, write [VERIFY] in that day's Exit condition. I already replaced real hosts and users with labels; do not expand HOST-A or USER-A back to identifiers.
Pro tip: Set the exit conditions as checks you can verify, such as a clean scan result.
These prompts give you the what. Tutorials give you the why.
Learn when to use extended thinking, how to build Claude Projects, and workflows that compound. The library keeps growing.
Reports and Lessons
5 promptsLessons Learned Critique
16/30✨ What it does
Scores a lessons-learned draft on tone, cause and ownership, then rewrites its three weakest sentences. Keep the rewrites only where the facts in your ticket support them.
Read my lessons-learned draft below and score it on blame-free language, root cause clarity and actions with owners. Then list the 3 weakest sentences and rewrite each one. Draft: [LESSONS DRAFT]. Do not invent root causes or owners; if my draft does not name them, mark the spot [VERIFY]. Keep every HOST and USER label in the draft exactly as I pasted it.
Pro tip: Write the draft in plain sentences first, then run the critique.
Executive Summary in 120 Words
17/30✨ What it does
Writes a 120 word summary covering what happened, the impact and what is still open. Check every figure and date against the ticket before the summary leaves the security team.
Draft a 120 word executive summary of [INCIDENT NAME] for the leadership team. My notes: [INCIDENT NOTES]. Cover what happened, what is contained and what is still open, using only [INCIDENT NOTES], and the business effect in [BUSINESS EFFECT]. Do not invent a cost, a number of affected records or a date; write [VERIFY] wherever my notes do not give one. Plain English, no tool names. Use CUSTOMERS or STAFF as labels, never names.
Pro tip: Give the business effect in your own words so the impact line stays accurate.
Ticket Closure Note
18/30✨ What it does
Writes a five-line closure note covering event, evidence, action, residual risk and who accepted it. Check every [VERIFY] line against the ticket before you close it.
From [TICKET NOTES], write a ticket closure note of 100 words at most. Use five labelled lines in this order: what happened, evidence reviewed, action taken, residual risk, who accepted it. Put only facts from my notes on those lines. If a line is not in my notes, write [VERIFY] on that line rather than inventing the fact. Keep any HOST or USER labels unchanged. Stay defensive: no exploit steps and no evasion language.
Pro tip: Paste the ticket comments, not the full log dump, so the five lines stay short.
Action Items Table
19/30✨ What it does
Converts findings into an action table with a type, an owner role and evidence for each item. Track the table in the post-incident review and close an item only when its evidence exists.
Convert the findings in [FINDINGS LIST] into an action table with the columns Action, Action type (detection, containment or process), Owner role, Due (as I give it), Evidence of done (a ticket link or a rule screenshot). Use at most 8 rows and one action per row. Do not invent owners or due dates; if I did not give one, write [VERIFY]. Do not add technical steps beyond what the findings already state. I already replaced names and hosts with labels such as HOST-A and USER-A; leave them as written.
Pro tip: Write the evidence column as a ticket link or a rule screenshot a second person can open.
Root Cause in Plain Words
20/30✨ What it does
Writes three plain paragraphs on the cause, the miss and the fix that would catch it. Compare the paragraphs with the review notes, since the cause is only as good as the evidence behind it.
Explain the root cause of [INCIDENT NAME] in plain words for a new analyst, in 3 short paragraphs of under 60 words each. Use only my notes: [ROOT CAUSE NOTES]. Do not invent a root cause or a vulnerability ID; if my notes do not name one, write [VERIFY]. Cover the cause, why it was missed and what would catch it next time. Leave out exploit details entirely. The paste already uses labels such as HOST-A and USER-A; keep them unchanged.
Pro tip: Describe the cause in terms of controls, such as missing alerting, rather than attack method.
Policy and Awareness
5 promptsAcceptable Use Policy Draft
21/30✨ What it does
Fills a five-section acceptable use policy from your rules and marks any missing rule or date. Send the draft to your policy owner and legal reviewer before anyone signs it.
Fill this policy template for a [ORGANISATION TYPE] with my wording only. 1 Purpose: [PURPOSE]. 2 Scope: [WHO IT COVERS]. 3 Rules: [RULES I WANT, ONE PER LINE]. 4 Reporting: [WHO TO CALL]. 5 Review date: [REVIEW DATE]. Keep each section under 60 words. If a rule or date is missing, write [VERIFY] and do not invent one. The result is a draft for our policy owner and legal review, not legal advice.
Pro tip: List the rules you already enforce, not the ones you wish you had.
Phishing Awareness Email
22/30✨ What it does
Drafts a 120 word staff email that explains the lure, the clicked case and the reporting route. Check the lure description against the real message before you send it to everyone.
I need a 120 word email to all staff at [ORGANISATION] about the phishing lure described in [LURE DESCRIPTION]. Say what to look for, what to do if someone clicked using [STEPS WE ASK CLICKERS TO TAKE], and who to report to at [REPORT CHANNEL]. Use a friendly, direct tone with no blame. Do not invent a real incident detail or a deadline; write [VERIFY] wherever I did not give one. Do not name any real person who clicked.
Pro tip: Describe the lure in one sentence, the way a colleague would receive it.
Password Policy Options
23/30✨ What it does
Sets out three password and sign-in options with the trade-off for users, then picks one for your setup. Test the chosen option with a small group before it becomes the rule for everyone.
Give three options for a password and sign-in policy for [ORGANISATION SIZE] staff who use [DIRECTORY LABEL] for sign-in. Do not invent what my identity system supports; if I did not tell you, mark it [VERIFY]. Each option gets one line on what it requires and one line on the trade-off for users. Then pick one for my case in 50 words and say why. Output the three options as a numbered list, then the pick as a short paragraph.
Pro tip: Check which controls your identity system supports before you choose an option.
Quarterly Access Review Checklist
24/30✨ What it does
Gives a nine-line checklist for reviewing who can reach one application each quarter. Keep the signed checklist with the access records so the next review starts from the same list.
List a 9 item checklist for a quarterly access review of [APPLICATION LABEL]. Context: [REVIEW CONTEXT]. Do not invent a review cycle, an approver's name or a stale threshold; use [STALE AFTER DAYS] for stale access and write [VERIFY] for any approver role the context does not give. Cover who checks what, what counts as stale access, and what to do with each finding. Each item is one line that starts with a verb.
Pro tip: Export the user list first, then run the checklist against that export.
Vendor Questionnaire Gap Check
25/30✨ What it does
Flags vague, missing or contradictory questionnaire answers and lists the follow-up question for each. Send the follow-ups to the vendor in writing and keep their replies with the file.
Here are the vendor's answers to our security questionnaire. Flag every answer that is vague, missing or contradicts another answer. Output a table with the columns Question, Problem, Ask the vendor. Vendor answers: [VENDOR ANSWERS]. Do not invent what the vendor does or which certifications it holds; write [VERIFY] where my text does not say. I already swapped staff names for role labels; keep those labels.
Pro tip: Paste the answers next to their questions so the contradictions are easy to spot.
Most people use 10% of Claude. Tutorials unlock the rest.
AI Academy: hands-on tutorials on Claude, ChatGPT, Midjourney, and many other AI tools. New tutorials are added regularly.
Tabletop and Detection
5 promptsFive-Inject Tabletop Exercise
26/30✨ What it does
Builds a five-part tabletop exercise where each numbered inject ends with two discussion questions. Run the injects in order and write each decision in the exercise log.
Design a five part tabletop exercise on [SCENARIO] for a team of [TEAM SIZE]. Each part is a numbered inject: a short message the facilitator reads aloud, followed by two discussion questions. Keep each inject under 60 words. The scenario is defensive: show what the team sees and decides, with no attack techniques or tool details. Do not invent company systems; use [SYSTEM LABEL] placeholders and mark [VERIFY] anything I did not name. Use team roles, not personal names.
Pro tip: Use your real escalation roles in the brackets so the exercise tests your own chain.
Tabletop Debrief Interview
27/30✨ What it does
Interviews the facilitator through five debrief questions, then writes four bullets for the exercise log. Share the bullets with the attendees and fix any [VERIFY] line before the next exercise.
Interview me with 5 questions, one at a time, to run a debrief after our tabletop on [SCENARIO]. Wait for each answer before you ask the next. Then write the debrief as 4 bullets: what worked, what slowed us, the decision we must write down, and one owner role for it. Do not invent answers; if I skip a question, put [VERIFY] in the bullet it would have fed. Keep team members as roles, with no names.
Pro tip: Hold the debrief within a day of the exercise, while the decisions are still clear.
Detection Idea in Plain Words
28/30✨ What it does
Explains a detection idea as four signals, the noise each one brings, and a tuning question. Use the table to plan a rule with your detection engineer, not as a rule to deploy.
Describe in plain words the detection idea for [BEHAVIOUR TO WATCH FOR]. My log sources: [LOG SOURCES]. Do not invent log fields; if my log sources are not named in [LOG SOURCES], write [VERIFY] in the Signal cell. Output a table with the columns Signal to watch, Why it matters, Likely noise, Tuning question. Use 4 rows. Keep each cell under 18 words. No queries, no code and no notes on evading detection.
Pro tip: Name the behaviour you want to catch, not a specific attack tool.
Tune a Noisy Rule
29/30✨ What it does
Lists four likely causes of noise from a rule and a test question for each. Test one cause at a time, and record the change so you can roll it back if real alerts disappear.
My detection rule [RULE LABEL] fires about [ALERTS PER DAY] times a day, and most of the alerts are benign. Base each cause only on the rule description I gave: [RULE DESCRIPTION]. Call it a hypothesis, and write [VERIFY] where my text does not support it. Do not invent a cause my description does not hint at. Give me the 4 most likely causes of that noise. For each cause, give one tuning question to test with my team. Use a numbered list, one line per cause.
Pro tip: Count the alerts for a week before you tune, so the change is based on numbers.
Junior Analyst Quiz
30/30✨ What it does
Creates five multiple choice questions that separate a real alert from a harmless look-alike. Have a senior analyst check each answer against your own policy before the quiz goes to new starters.
Set 5 multiple choice questions that teach a junior analyst to tell [ALERT TYPE] from a benign look-alike. Reference text: [VENDOR DOC OR POLICY]. Each question has 4 options, one correct answer and a 25 word explanation. Stay on defensive reasoning and do not describe attack methods. Do not invent vendor facts or dates in the explanations; write [VERIFY] where an answer needs a fact from [VENDOR DOC OR POLICY]. Output the 5 questions as a numbered list.
Pro tip: Use alerts from your own past cases, with identifiers removed, for the look-alikes.
Free tool
Prompt Optimizer
Turn a rough idea into a structured, professional AI prompt.
Frequently Asked Questions
Prompts are the starting line. Tutorials are the finish.
A growing library of hands-on tutorials on ChatGPT, Claude, Midjourney, and many other AI tools. New tutorials are added regularly.
7-day free trial. Cancel anytime.
Related guides