A SOC receives many similar phishing-report alerts. Analysts handle them differently, causing missed IOCs and inconsistent containment. The team wants repeatable handling for this alert type without automating full response. Which control should the analyst recommend?
Select an answer to reveal the explanation.
Short Explanation
Think of a runbook like a laminated recipe in the kitchen: you follow the same steps so the dish comes out the same. If you let every analyst wing it, the containment and evidence will drift. Documented procedures keep common alerts fast, consistent, and reviewable.
Full Explanation
A runbook is a documented, step-by-step procedure for a recurring alert type, and it is the best fit when the goal is repeatable human-led response. It normally includes triage questions, validation steps, containment actions, evidence collection, escalation thresholds, and closure criteria. By codifying those steps, a SOC reduces analyst-to-analyst variability, speeds common alert handling, and creates a baseline that can later be refined or automated. A dashboard that shows phishing-report volume is useful for awareness and trend monitoring, but it does not tell the analyst what to do next when a specific alert arrives. A ticket routing rule can direct work to a queue, yet routing alone does not standardize triage, containment, or evidence handling, so inconsistency remains. An automated scoring model may improve prioritization over time, but it does not provide the documented human procedure needed here and may obscure why a report was handled a certain way. Exam caveat: when the stem asks for consistency and repeatable response to common alerts, choose documented procedures before dashboards, routing, or models. Operational check: review ten recent phishing alerts and confirm the runbook specifies IOC extraction, mailbox containment, user confirmation, and evidence retention.