SOC Playbook Template: Steps, Queries and Thresholds

A SOC playbook template is a fill-in structure for one alert type: when it applies, what you need ready, and a short run of steps that each name a tool and carry the query, with a branch and a stated threshold wherever the answer changes what you do next. The blank version below copies into a repo as YAML.

A playbook built from it works when every step is executable, meaning an analyst can run it as written, and decidable, meaning the output tells them what happens next. Everything else in the document is context.

The SOC playbook template

One file per alert type. Fields without a # add comment are the schema our published investigation playbooks use, field names included. The # add fields are ones we recommend on top. Our public pages leave them out because they only make sense inside your environment: who is on call, which licences tier-1 holds, which index names your SIEM uses.

# SOC playbook template: one file per alert type
title: ""                      # the alert as it appears in the queue
owner: ""                      # add: one named person, not a team
last_verified: YYYY-MM-DD      # add: last run against a real closed alert
estimated_time: ""             # e.g. "15-20 minutes"
 
answer_first_summary: >
  Two or three sentences: what this alert usually turns out to be,
  the question that decides it, and the most common verdict.
 
when_you_see_this:             # triggers: 4-6 concrete conditions
  - ""
does_not_apply_when:           # add: cases to route elsewhere
  - ""
 
preparation:                   # add: confirm before the first real alert
  data_sources: []             # index or table names as they exist in YOUR SIEM
  access_needed: []            # licences and roles the investigating tier must hold
  roles:
    investigates: ""           # tier-1, tier-2
    approves_containment: ""   # who may disable accounts, isolate hosts, block IPs
    escalation_contact: ""     # rota or channel, including the out-of-hours route
 
investigation_steps:
  - phase: detect              # add: detect | assess | contain | eradicate | recover
    title: ""                  # the question this step answers
    description: ""            # why it matters, what to read in the output
    tools: []                  # siem | xdr | firewall
    siem_queries:              # one entry per logical question
      - spl: ""
        kql: ""
        lucene: ""
    decision:                  # optional: only where the answer changes the path
      condition: ""            # checkable with the query above, with a number in it
      if_true: ""              # an action, not a mood
      if_false: ""
 
common_mistakes:               # what your senior analyst keeps correcting
  - ""
escalation_criteria:           # conditions, not adjectives
  - ""
related_technique_ids: []      # ATT&CK IDs, e.g. T1110

Four rules for filling it in:

• Fill preparation first. If the data source a step needs is not in your SIEM, you have found a logging gap. File the ticket and stop there.
• One logical question per siem_queries entry. Leave a language empty rather than paste a query nobody has run. An empty field is honest; a plausible query against the wrong field name returns zero rows and looks like a clean result.
• Leave decision out of most steps. Across our fifteen playbooks, 17 of 75 steps carry one: most steps gather evidence, and only a few change the path.
• Update last_verified only after a real run. It is the one field that tells the 3 a.m. reader whether the queries still match your indexes.

The phase values split the lifecycle one level finer than CISA's federal playbooks do, so each step says whether the analyst is still gathering evidence or already acting on it. Post-incident review happens once per incident, after the alert work is done, so it is not a step phase here.

Incident response playbook template vs incident response plan template

Search for an incident response playbook template and most of the first page is organisation-level material: the CISA PDF, vendor PDFs, a template behind a form. They describe how a whole organisation moves through an incident over days. That is useful, and it is a different document from what a tier-1 analyst needs when one alert fires.

Two tests tell you which one you are writing. If it names a regulator, a notification deadline or a communications lead, it is the incident response plan, and it exists once per organisation. If it names an index, a query and a threshold, it is a playbook, and you need one per alert type. The template above is the second kind. The comparison table further down places both next to runbooks and SOAR playbooks.

The document nobody opens

The usual failure looks like this. Someone senior writes twenty playbooks during a quiet fortnight, one per attack technique they could name, and files them in the wiki. Six months later a tier-1 analyst gets a brute force alert at 03:12, opens the brute force document, and finds a paragraph explaining what brute force is, a bullet list saying to review the logs and determine whether the activity is malicious, and a note to escalate if appropriate. They close the tab and ask the person on call.

Nothing in that document was wrong. It was just not a procedure. It was an explanation of a topic wearing the shape of one, and that gap is where most playbook programmes die.

A playbook has one job: compress the distance between an alert appearing and a defensible decision being written, and do it consistently enough that two analysts working the same alert reach the same verdict. Consistency is what makes your handovers survivable and your false positive rate a number that means something.

The cost is real, and most articles on this subject skip it. Writing one properly means running the searches yourself, finding out which fields your deployment populates, discovering that the field name in the vendor documentation is not the field name in your index, and deciding the thresholds. Then it decays. Detections get tuned, tools get replaced, and every query you wrote quietly stops returning rows. A playbook set is a maintained asset, not a document you finish.

One boundary before we go further. Playbooks run after triage has decided what the alert is. Triage sorts the queue and answers whether something deserves investigation at all. The playbook is what you open once the answer is yes. Blurring the two produces a document that tries to be both a queue-sorting heuristic and an investigation procedure, and is neither.

Four documents that get called the same thing

Search for "SOC playbook" and you get results describing four genuinely different artifacts. They overlap, the vocabulary is contested, and teams lose real hours arguing about it. Here is a split that holds up in practice.

The runbook distinction is the one people fight about hardest, and the honest answer is that the industry has never settled it. Mature teams call everything a runbook; others call everything a playbook. Neither is wrong. What matters is that your shop picks one convention, writes it down where the new hire will find it, then judges each document by a single question: who opens this, and what pressure are they under when they do? An analyst mid-alert and an engineer restoring a broken collector need different documents.

The SOAR playbook is a different animal. It is machine-executed, so it cannot ask for judgement, and its failure mode is silence: it runs, takes a branch nobody anticipated, and closes a ticket that should have been escalated. Automation earns its keep on the enrichment steps at the top of an investigation playbook, the pure lookups. It does not replace the middle of the document, where an analyst weighs two pieces of evidence that disagree.

Where the published examples sit

Three widely cited sources come up whenever someone starts writing playbooks, aimed at three different layers.

CISA publishes a federal incident and vulnerability response playbook set, and its incident response process runs five phases: Preparation, Detection and Analysis, Containment, Eradication and Recovery, and Post-Incident Activities. That is an organisation-level process describing how an agency coordinates itself through an incident. It is not what your tier-1 analyst opens when a single impossible-travel alert fires, and using it as a per-alert template produces a five-phase document about one sign-in.

NIST SP 800-61 is the source of the lifecycle everybody quotes, and this is worth getting right because most published playbook advice has not caught up. The four-phase lifecycle (preparation, detection and analysis, containment/eradication/recovery, post-incident activity) comes from Revision 2, published on 6 August 2012. Revision 3 arrived in April 2025 and supersedes it, under the title "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile". The reframing is the point: incident response is presented through the CSF 2.0 functions rather than as a standalone four-box lifecycle. If your playbook template has a diagram of four phases with a loop arrow, it is quoting a document NIST replaced. Your auditor will notice eventually, and it tells you how much of the surrounding advice was copied rather than checked.

Microsoft publishes incident response playbooks for phishing, password spray, app consent grant, and compromised and malicious applications, plus a separate token theft playbook. This is the vendor-shaped playbook: genuinely good inside that product, precise about which tables and portals to use, and tied to it. If you run that stack, start there and adapt. If you do not, the structure still teaches you something even though every query needs rewriting. Copy the specificity, not the field names.

The anatomy of a step that survives contact

The unmarked fields in the template come from our own collection of complete investigation playbooks, so here is what that schema holds once it is filled in, counted on 28 September 2026.

Fifteen playbooks across six categories. Seventy-five investigation steps, four to six per playbook. Fifty-four carry at least one query, so twenty-one do not: those are the containment, remediation and documentation steps where the work is an action rather than a search. Underneath sit 78 distinct logical queries, each written three times, in SPL, KQL and Lucene, because a playbook whose queries only run in one product has to be rewritten from scratch when the team migrates tools. Across the set: 46 escalation criteria, 60 entries in the "common mistakes" fields, and 26 distinct ATT&CK technique IDs.

Seventeen of the 75 steps carry an explicit decision branch. Fewer than a quarter. Every one of the fifteen playbooks has at least one, but most steps do not.

That is deliberate, and the opposite of what a template-driven writer produces. Force a branch onto every step and you get fake forks that read "if you found something, continue; if not, continue". Real forks are rare. They happen where the answer to one question sends you down a materially different path: a confirmed compromise instead of a failed attempt, a credential-stuffing pattern instead of a single-account attack. Everything else is evidence gathering, and evidence gathering does not branch, it accumulates.

Take that as one corpus, ours, not as an industry benchmark. It still points at where the writing effort belongs: the few steps that actually fork.

The per-step schema is deliberately small:

• title and description: what you are answering and why it matters, in the fewest words that work.
• tools: which surface answers it, one of SIEM, XDR or firewall. This field exists because "check the logs" is the most common way a step fails. Naming the surface forces the writer to admit whether the data is there.
• siem_queries: the same logical question in SPL, KQL and Lucene.
• decision: optional, and when present it is a condition, an if_true and an if_false. All three are mandatory once you open that door. A branch with only a true arm is a suggestion.

At the playbook level: an answer-first summary so a reader knows the shape of the work before committing, a when_you_see_this trigger list, the ordered steps, common_mistakes, escalation_criteria, and related ATT&CK technique IDs. That last field earns its place in aggregate rather than per document. Seeing T1558 on the Kerberoasting playbook tells an analyst little they did not know, but seeing which of the 26 techniques your set touches, and which parts of the ATT&CK matrix it does not, is a coverage conversation worth having.

The two fields teams skip pay off fastest. common_mistakes is where you put what your senior analyst says out loud every time someone gets this alert wrong. On the phishing playbook, that is failing to search for the other recipients, because one user reporting a mail usually means dozens received it. escalation_criteria stops the two opposite escalation failures: the analyst who escalates everything, and the one who quietly closes a real incident at 4 a.m. rather than waking someone up. Write it as conditions. On the ransomware playbook, "domain controller compromise, so the whole Active Directory environment is exposed" is a criterion. "It looks serious" is not.

Filled-in example 1: brute force

Here is the template filled in for brute force, end to end, in the form I would want on screen at 3 a.m. The full version lives at the brute force investigation playbook; this is the reasoning behind its shape.

Triggers. Excessive failed authentications from one source. Simultaneous lockouts across multiple accounts. Hundreds of failures followed by a single success. An IDS or identity-provider alert naming password spraying.

Step 1. Establish scope and source. You need three numbers before anything else: how many failures, from which source, against how many distinct accounts. In Splunk:

index=auth action=failure earliest=-24h
| stats count AS failures, dc(user) AS accounts, values(app) AS apps,
    min(_time) AS first_seen, max(_time) AS last_seen BY src_ip
| where failures > 20
| convert ctime(first_seen) ctime(last_seen)
| sort -failures

The same question against Entra sign-in logs. ResultType is a string column in which "0" means success, per Microsoft's SigninLogs reference, so the comparison needs the quotes:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| summarize Failures = count(), Accounts = dcount(UserPrincipalName),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by IPAddress
| where Failures > 20
| order by Failures desc

If the summarize and dcount pipeline is unfamiliar, our KQL walkthrough covers the operators these searches lean on.

Output shaped like this is what the next step reads:

Simulated example generated by SOCSimulator Research.

Three rows, three different investigations. The first is a classic single-account attack, internal source, half an hour of sustained failures. The second is 88 attempts spread across 61 accounts, which is not brute force at all. The third is somebody back from leave after a password rotation.

Note what the > 20 is doing. It is a starting filter, not a finding, and the number most likely to be wrong in your environment. Derive it: run the aggregation without the where clause for a fortnight and set the floor above your normal noise. A threshold you copied from an article is one you cannot defend in a post-incident review.

Step 2. Did anything succeed? This is the question the whole playbook exists to answer, and the one that gets skipped, because failed-login dashboards are hypnotic and success events sit in a different search.

index=auth src_ip="10.14.22.7" action=success earliest=-24h
| stats min(_time) AS first_success, count AS sessions BY user, app
| convert ctime(first_success)

SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == "10.14.22.7" and ResultType == "0"
| summarize FirstSuccess = min(TimeGenerated), Sessions = count()
    by UserPrincipalName, AppDisplayName

The branch.

Condition: at least one successful authentication from the source IP inside the window, or a success on a targeted account from any new source after the failure burst began.

If true: confirmed compromise, not a failed attempt. Disable or force-reset the account, revoke sessions and refresh tokens, escalate to incident response. The investigation is now about what happened after the success.

If false: no access was gained. Block or rate-limit the source, confirm the lockout policy engaged, finish the documentation. This does not get escalated.

That is what decidable means: the condition is checkable with the query directly above it, both arms exist, and each names an action rather than a mood.

On Windows domain authentication, add one qualifier to the true arm, because not every success is equal. A successful logon type 3 against a logon type 10 is the difference between a network share being touched and somebody sitting on an interactive remote session. Both matter, and they do not get the same 3 a.m. response.

Step 3. Classify the shape. Rows one and two above are different attacks firing the same alert.

index=auth action=failure earliest=-24h
| stats dc(user) AS accounts, count AS attempts BY src_ip
| eval per_account=round(attempts/accounts,1)
| where accounts > 5 AND per_account <= 5

More than five distinct accounts at five or fewer attempts each is spraying or credential stuffing, and it changes the response. Blocking the source is nearly pointless against an attacker rotating through residential proxies, and the real exposure is a password list rather than one account. Containment becomes a password reset across the targeted set plus a hard look at MFA coverage. The threshold is yours: five is reasonable against a lockout policy set at ten, and wrong if yours is set at three.

Steps 4 and 5. Contain, then document. Neither carries a query, and that is fine. Containment names the firewall action, the identity action, and who is authorised to perform each. Documentation records the timeline, the source, the targeted accounts and the outcome, plus what should change so the alert is cheaper next time.

Five steps. One branch that matters, one classification threshold, two queries per investigative step, and no sentence anywhere that says "investigate further".

Filled-in example 2: impossible travel

Brute force is a volume alert. Impossible travel is a pair-of-events alert, and the same template holds it without a new field. This is the template trimmed to the parts that change. Our published impossible travel playbook adds the device and session queries for steps 2 and 3.

title: "Impossible travel sign-in"
owner: "identity on-call lead"
estimated_time: "10-20 minutes"
when_you_see_this:
  - "Two successful sign-ins for one account from different countries, under 120 minutes apart"
  - "Identity provider risk detection for atypical or unlikely travel"
  - "CASB alert for a sign-in from a country new to this account"
does_not_apply_when:
  - "Both source IPs are corporate VPN or web gateway egress: note the IPs and close as benign"
preparation:
  data_sources: [SigninLogs, "VPN egress IP list"]
  access_needed: ["sign-in log read for tier-1", "session revocation for tier-2"]
investigation_steps:
  - phase: detect
    title: "Which two sign-ins, from where, how far apart?"
    tools: [siem]
    decision:
      condition: "Two successes from different countries under 120 minutes apart, neither from a known egress IP"
      if_true: "Possible credential compromise. Go to step 2 now."
      if_false: "Travel or VPN. Record both IPs and close."
  - phase: assess
    title: "Do the two sessions come from different devices?"
    tools: [siem, xdr]
  - phase: assess
    title: "What did the suspicious session touch after sign-in?"
    tools: [siem]
  - phase: contain
    title: "Confirm with the user out of band, then revoke sessions and reset"
    tools: [siem, xdr]
escalation_criteria:
  - "A new MFA method was registered from the suspicious session"
  - "The account holds admin rights in the identity provider"
related_technique_ids: [T1078]

The step 1 query has to compare each sign-in with the previous one for the same account. In Splunk, streamstats carries the previous row forward:

index=auth action=success user="j.doe@example.com" earliest=-24h
| iplocation src_ip
| sort 0 _time
| streamstats current=f last(Country) AS prev_country last(src_ip) AS prev_ip last(_time) AS prev_time BY user
| eval gap_min=round((_time - prev_time) / 60, 0)
| where isnotnull(prev_country) AND Country!=prev_country AND gap_min < 120
| table _time, user, prev_ip, prev_country, src_ip, Country, gap_min

In KQL, prev() does the same job once sort has serialised the rows. Location in SigninLogs already holds the two-letter country code, so no geo lookup is needed:

SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "j.doe@example.com" and ResultType == "0"
| project TimeGenerated, UserPrincipalName, IPAddress, Location
| sort by TimeGenerated asc
| extend PrevLocation = prev(Location), PrevIP = prev(IPAddress), PrevTime = prev(TimeGenerated)
| extend GapMin = datetime_diff('minute', TimeGenerated, PrevTime)
| where isnotempty(PrevLocation) and Location != PrevLocation and GapMin < 120

Lucene cannot compare one row with the next. Its slot in the template holds the filter, event.category:authentication AND event.outcome:success AND user.name:"j.doe@example.com", and the analyst reads source.geo.country_iso_code down the time-sorted results. Say that in the step description, so nobody on an Elastic stack thinks the pairing happened automatically.

The 120 minutes is a starting value, like the > 20 in the brute force example. Two sign-ins from neighbouring countries an hour apart can be a train journey. Tune it against your own closed alerts and write the number you settled on into the condition.

Six ways a playbook dies

The step that says "investigate". Any imperative that does not name a data source is a hole. "Review the logs", "check for anomalies", "determine whether the activity is malicious". That is the writer handing the hard part back to the reader, which is the opposite of what a playbook is for. The repair is mechanical: for each vague step, ask what you would type, then paste that.

The branch with no threshold. "If the volume is unusual" and "if the behaviour is suspicious" are not decidable. Somebody has to pick the number, and if the playbook does not, each analyst picks a different one silently and your verdicts stop being comparable. When you genuinely do not know the number yet, say so. "Threshold not yet baselined, use judgement and record what you used" is honest and produces the data to fix it. A fake threshold does not.

The step that needs a tool tier-1 cannot reach. The playbook says to pull the packet capture, and the analysts who work this alert have no licence for the capture platform. Or it says to block at the perimeter, and only the network team can do that, and they are not on call. Access and authority are part of the step. If one requires a licence, a role or a phone call, say who and how, or the procedure stalls at exactly the step that mattered.

The playbook nobody has run since the SIEM migration. The quiet killer. The index was renamed, a sourcetype changed, a field sits one level deeper, and every search returns zero rows. Zero rows is worse than an error, because it looks like a clean result. An analyst who follows a broken playbook to a wrong "nothing found" conclusion learns not to trust the folder, and that lesson generalises to every other document in it.

The document that duplicates the incident response plan. Somebody adds regulatory notification timelines to the ransomware playbook, then to the exfiltration playbook, then to the business email compromise one. Now the requirement lives in four places, three of which will go stale. Governance content belongs at the plan layer, and the playbook links to it.

Coverage counted in documents. A team reports "we have thirty playbooks" and feels covered. Rank last quarter's closed alerts by rule name and you usually find a short head and a long tail, with the thirty documents distributed by what felt important rather than by what fires. A DNS tunneling playbook is worth having and is not what your queue is made of. Write coverage as a percentage of alert volume served, not a count of files.

How to write your first one

In order, starting from data you already have.

1. Pull the alert volume. Last quarter, closed alerts grouped by detection rule name, sorted descending. If you can get median handling time too, multiply the two and sort by that: the cost of a rule is volume times minutes.
2. Take the top rule, not the scariest one. The instinct is to write the nation-state scenario first. Resist it. The rule at the top of that list is the one your team works while tired, and it is where consistency is worth the most.
3. Copy the template and write the triggers before the steps. Filling when_you_see_this with every condition under which the playbook applies is what stops it turning into an essay about the attack type. If you cannot write four or five concrete triggers, the scope is wrong.
4. Write the ending next, then work backwards. What are the possible verdicts? True positive, benign true positive, false positive, escalate. Once the endings are fixed, each step becomes a question that narrows between them, far easier to write than a list of things to check.
5. Run every step yourself on a real closed alert, and paste what you typed. Not what the vendor documentation calls the field. What your deployment returned.
6. Put a number on every branch. If you cannot defend it, mark it unbaselined and open a ticket to measure it. Do not invent one to look finished.
7. Have someone else run it cold. Give a colleague the playbook and an alert they have not seen, and watch without helping. Every hesitation is a defect. Half an hour of this catches more than any review round.
8. Ship it before it is finished. A playbook at eighty percent that gets used beats a perfect one still in draft, because contact with real alerts is what tells you which parts were wrong.

Keeping them alive

Ownership first: one named person per playbook, not a team and not a distribution list. Shared ownership means the query breaks and everybody assumes somebody else noticed.

Then stop reviewing on a calendar. Annual reviews catch drift eleven months late and turn into a signature exercise. Review on events instead, and only a handful are worth wiring up:

• The detection logic behind the alert changed. New rule, new tuning, new threshold: the playbook that reads its output is now suspect.
• A tool was migrated, replaced or renamed, or field and index names moved. Every query in the affected playbooks needs re-running, not re-reading.
• An escalation path changed. New on-call rota, new IR provider, a role that no longer exists.
• A real incident went sideways in a way the playbook did not anticipate. The lesson usually goes into the post-incident report and never into the procedure.

What makes those triggers cheap is storing playbooks where the detections live. If the rule and the procedure that services it sit in the same repository, changing one prompts changing the other in the same review. That is the detection as code argument applied one layer up: the rule is versioned, so the response to it should be too. A wiki page has no diff, no reviewer, and no way to tell you it went stale.

Last, measure the right thing. Not the number of playbooks: what share of last month's closed alerts had one covering them, and how often the analyst opened it. The first tells you where to write next. The second tells you whether what you wrote is any good, and if it is low, the answer is almost never that analysts need reminding. The document failed the executable-and-decidable test and they found that out the hard way.

Writing the document is the easy half. A playbook is a claim about your environment, and environments move: the query that returned rows in March returns nothing in September because somebody renamed an index and told the wrong channel. So the useful test is whether an analyst who has never seen this alert can open it at 3 a.m., run every step as written, and come out with a verdict they can defend in the morning. If they cannot, it is a topic explainer with numbered headings, and no amount of formatting fixes that.