SOC Runbook Template: Repeatable Procedures for Common Alerts

When every analyst handles the same alert differently, response times swing, evidence is lost and nobody can tell whether a detection is worth keeping. A SOC runbook fixes the steps for a given alert: what to check, what to collect, when to contain, when to escalate and how to close. This template gives you a runbook standard you can adopt as-is, a fill-in structure for each runbook, and five worked entries for alerts most SOCs see weekly: impossible travel, a leaked non-human identity (NHI) credential or secret, MFA fatigue, malware detection and suspicious OAuth consent. Each entry carries the MITRE ATT&CK techniques it addresses. It is written for SOC managers, detection engineers and analysts, and for the executives who approve containment authority.

How to use this template

• Replace text in square brackets, such as [Organisation], [SOC Manager] and [X minutes], with your own terms, tools and thresholds.
• "Must" is mandatory; "should" is recommended where a documented exception may be justified.
• Sections 1 to 7 are the runbook standard. Section 4.3 is the fill-in structure for each runbook, and 4.4 contains the five starter runbooks. Adapt their product-specific steps to your stack.
• Runbooks sit below your incident response plan and playbooks: a runbook handles one alert type; when it escalates, the plan and playbooks take over. See the Incident Response Guide.

1. Purpose

This standard sets how [Organisation]'s security operations centre (SOC) writes, approves, uses, automates and maintains runbooks, so that common alerts are triaged consistently, contained within agreed times, documented well enough to support investigation, and fed back into detection tuning. It supports NIST CSF 2.0 outcomes DE.AE-02 (adverse events analysed), RS.MA-02 (incident reports triaged and validated) and RS.MI-01 (incidents contained).

2. Scope

• All alerts handled by [the internal SOC] and by [managed detection and response provider] on [Organisation]'s behalf.
• Alerts from [SIEM], [EDR], [identity provider], [cloud security tooling], [secret scanning] and [SaaS security tooling].
• Manual steps and steps automated through [SOAR platform], including steps performed by AI-assisted triage tools.

Major incidents declared under [Incident Response Plan] are out of scope once declared, except that the runbook record forms part of the incident evidence.

3. Roles and responsibilities

4. Policy statements

4.1 Coverage and quality

• Every detection rule that can create an analyst alert must link to a runbook before it is enabled in production. Rules without a runbook run in [monitor-only mode].
• Runbooks must state observable steps (which log, which query, which field), not general advice.
• Each runbook must map to the MITRE ATT&CK techniques it addresses, so coverage can be reported. See the Detection Engineering Guide.
• Runbooks must define closure codes: true positive, benign true positive (expected activity), false positive, and duplicate.

4.2 Containment authority and automation

• Pre-approved containment actions (session revocation, device isolation, credential disablement, app disablement) may be taken by [Tier 2] without further approval on the criteria in each runbook. Actions on [crown-jewel systems and executive accounts] require [Incident Manager] approval.
• Automated steps are introduced in stages: enrichment first, then containment with human approval, then fully automated containment only after [30 days] of results without wrongful action.
• Every automated action must be logged, reversible where possible, and visible in the case record. See the SOAR and Security Automation Guide.

4.3 Runbook structure

Each runbook must contain these fields:

4.4 Starter runbooks

RB-01 Impossible travel

1. Triage: confirm both sign-ins were successful and interactive. Check the IP addresses against corporate egress, VPN and cloud provider ranges; tools such as Microsoft Defender for Cloud Apps already suppress VPN and cloud addresses and compare at country level, so a remaining alert deserves attention.
2. Enrich: device ID and compliance state for each sign-in, user agent, MFA method used, travel records or HR status where available.
3. Look for follow-on activity: new MFA methods registered, inbox rules created (T1564.008 Email Hiding Rules), mailbox access from the new location, new OAuth consents.
4. Contain if not explained within [30 minutes]: revoke refresh tokens and sessions, require password reset, remove MFA methods added during the window.
5. Close: benign true positive with reason (travel confirmed, unmanaged VPN), and add a tuning note if a recurring cause is found.

RB-02 Leaked NHI credential or secret

1. Triage: treat any committed or published secret as compromised, as GitHub's own guidance states. Identify the secret type, the owning system and the NHI it belongs to from [the secrets inventory].
2. Preserve: capture where it was exposed, the commit or paste, first exposure time and who could read it.
3. Contain: rotate the secret and update consuming services, then revoke the old value. Rotating first avoids outages when the provider auto-revokes reported tokens. Follow the Secrets Rotation Runbook Template.
4. Scope: search the provider's audit logs for use of the credential since first exposure, from unknown IPs or for unusual actions such as creating new keys (T1098.001 Additional Cloud Credentials).
5. Escalate: to incident if any unauthorised use is found or if the secret had administrative scope. The Home Depot token exposure shows what happens when there is no route for a reported leak: a GitHub token stayed usable for more than a year. See the Leaked Credential Response Playbook.

RB-03 MFA fatigue

1. Triage: count push requests per user in [10 minutes]; a burst of denied or unanswered prompts with a correct password is the signal. In Microsoft Entra ID, a user's "Report suspicious activity" creates a risk detection of type userReportedSuspiciousActivity and sets the user to high risk.
2. Contact the user through a known channel, not by replying to the prompt source. Confirm whether any prompt was approved.
3. Contain: block sign-in or force password reset, revoke sessions, and review MFA methods registered recently; in the Cisco breach the attacker enrolled new MFA devices after a push was approved.
4. Close and harden: confirm number matching is in force (Microsoft enables it for all Authenticator push notifications) and raise phishing-resistant MFA for the user's role. See the MFA Fatigue and Bypass Guide.

RB-04 Malware detection

1. Triage: was the file blocked, quarantined or executed? Review the alert story and process tree: parent process, command line, network connections, child processes.
2. Preserve: collect an investigation package (autoruns, processes, connections, event logs) before remediation where the EDR supports it.
3. Contain if executed: isolate the device. Use selective isolation where full isolation would break proxy connectivity, and note that some EDRs lift isolation automatically (Microsoft Defender for Endpoint after seven days).
4. Scope: search for the hash, domain and command line across the estate, and check for credential theft from the browser (T1555.003 Credentials from Web Browsers) on the user's sessions.
5. Close: classify true or false alert; for line-of-business false positives, create a suppression rule with an owner and expiry.

RB-05 Suspicious OAuth consent

1. Triage: in Microsoft 365 search the audit log for "Consent to application" and check IsAdminConsent. Review app name, publisher verification, reply URL domain age and requested scopes (Mail.*, Files.*, Directory.AccessAsUser.All are high risk).
2. Scope: list all grants for the app and whether ConsentType is AllPrincipals (tenant-wide). Allow for audit log latency of up to 24 hours.
3. Contain: disable the app rather than deleting it, so it cannot obtain new tokens and cannot be re-consented, then revoke its grants and the users' sessions.
4. Harden: restrict user consent to verified publishers and low-impact permissions and enable the admin consent workflow. The Cyberhaven breach shows that consent grants issue tokens without triggering MFA. See the SaaS and OAuth App Governance Guide.

5. Exceptions

An analyst may depart from a runbook when following it would cause clear harm, for example isolating a device that runs a safety-critical process. The departure must be recorded in the case with the reason and reviewed by [SOC Manager] within [2 working days]. Detections enabled without a runbook require a time-limited exception approved by [SOC Manager]. Recurring exceptions mean the runbook needs updating.

6. Compliance and monitoring

• Percentage of production detections with a linked, in-date runbook (target: [100%]).
• Median time to triage and time to contain per runbook, against SLA.
• False positive rate per runbook; any rule above [X%] for two months is reviewed for tuning or retirement.
• Percentage of cases closed with a valid closure code and evidence attached.
• Number of automated actions reversed as wrongful (target: zero).

[SOC Manager] samples [10] closed cases per month for runbook adherence and reports results quarterly.

7. Review and approval

• Each runbook is reviewed at least every [6 months], after any incident where it was used, and when the underlying tool or log source changes.
• Findings from post-incident reviews must update affected runbooks within [30 days]. See the Post-Incident Review and Root Cause Analysis Template.
• This standard is owned by [SOC Manager], approved by [CISO] on [date], version [1.0], next review [date].

Implementation guidance

Rolling it out

1. Rank alerts by volume and risk: pull 90 days of closed cases and write runbooks first for the ten alert types that cause most work or most incidents.
2. Write and test on history: walk each draft runbook through three past cases, including one true positive, and fix steps that analysts could not follow.
3. Pilot with one shift: run new runbooks for [two weeks] with one team, measure triage time and closure quality, then roll out.
4. Automate enrichment, then containment: follow 4.2. Keep a manual fallback in every automated runbook and a switch to return to approval mode.
5. Feed back: monthly, review closure codes per rule with the runbook owner and retire or tune noisy detections. See the Alert Triage Guide.

Small SOC or MDR versus large SOC

A small team or one relying on MDR should keep runbooks short, focus on the identity runbooks above, and agree in the MDR contract which containment actions the provider may take. A large SOC needs version control for runbooks, ATT&CK coverage reporting, and automation tested in a staging tenant before production. See the SOC Guide and AI SOC Guide for where AI-assisted triage fits.

Where identity fits

Four of the five starter runbooks end in an identity action: revoking sessions, rotating a secret, resetting MFA or disabling an app. Containment is only fast if the SOC knows who owns each human account, service account, API key and OAuth app. See the Identity Incident Response Playbook.

Common failure patterns

• Runbooks as wiki pages nobody updates: steps refer to retired consoles and analysts improvise.
• Containing before preserving: reimaging or deleting an app removes the evidence needed to scope the incident.
• Closing on the user's word: "yes, that was me" is not enough for an impossible travel alert followed by new inbox rules.
• Deleting rather than disabling malicious OAuth apps: another user can consent again.
• Automating containment without a reversal path: a noisy rule then locks out executives during a busy period.

Framework mapping

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE ATT&CK: Multi-Factor Authentication Request Generation
• MITRE ATT&CK: Steal Application Access Token
• Microsoft Learn: App consent grant investigation
• Microsoft Learn: Defender for Cloud Apps anomaly detection policies
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings
• Microsoft Learn: Take response actions on a device
• GitHub Docs: Resolving alerts from secret scanning

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: SOC Guide · SOAR and Security Automation Guide · Incident Response Guide · Alert Triage Guide