1,200 Phishing Reports a Day and a 14-Task Template
Fabrikam Retail has a report-phish add-in feeding Security Incident Response. Users submit about 1,200 emails per day, and every submission creates a security incident. A single response task template fires on all of them and generates 14 tasks, including 'collect forensic image', 'review EDR telemetry', and 'notify legal'. Post-incident review of three months shows only 3% of reports are genuinely malicious; about 60% are obvious marketing spam and 37% are inconclusive but never re-reported. Twenty-two analysts keep up by closing reports quickly. Reported MTTR is 9 days. Containment actions - disabling a user account, quarantining a mailbox - route to a single named security manager for approval, and that manager works one timezone.
1. Design a triage model that keeps every user report auditable but stops 1,200 full incidents per day. Which record gets created, and when?
Read the worked answer
The defect is that intake volume is treated as incident volume, and the response template treats every intake item as a full investigation.
Separate the records. A user report is intake evidence, not an incident. Store it as an intake/report record that captures the reporter, sender, URLs, and attachment hashes. Promote to a security incident only when there is a reason: automated enrichment is positive, the report clusters with a known campaign, or an analyst escalates.
Cluster aggressively. Four hundred reports of the same campaign are one incident with 400 linked intake records. Auditability is preserved by the links, not by the incident count. Normalize the sender domain, the URL, and the subject before clustering, or near-duplicates will not group.
Enrich before a human sees it. Header authentication results, URL and attachment hash lookups against threat intelligence, sender reputation, and prior-report history. Anything that is clean on all four and matches a known spam signature can be closed at the intake record with no incident.
Fix the template. A 14-task template applied unconditionally means MTTR is measuring template design, not response. Task sets should differ by category and severity - a blocked commodity malware attachment does not need a forensic image. Verify how your instance selects templates for a given category before you redesign them; if selection is unconditional today, that is your first change.
The target state: 1,200 intake records, roughly 40-60 promoted incidents, and a template that creates 3 tasks for a commodity phish and 14 for confirmed credential theft.
2. Auto-containment with one approver in one timezone: what is the real failure mode, and how would you redesign approval without losing control?
Read the worked answer
Failure mode. Reports arrive around the clock; the approver does not. Overnight, a confirmed-compromised mailbox stays live for eight hours while the clock runs. The predictable second-order effect is worse: analysts learn the control is unusable, so they ask the manager in chat and act manually, and the approval step becomes theatre with no audit trail at all.
Redesign by blast radius, not by category.
- Low blast, reversible, high confidence: force sign-out of active sessions, quarantine the mailbox, block the sender domain at the gateway. These can auto-execute when a documented confidence threshold is met (for example, credential-harvesting URL confirmed by two independent sources), with a post-action notification to the manager and a one-click rollback.
- High blast or hard to reverse: disable the account, wipe the device, block a business partner domain. Keep human approval, but approve to a group with a delegated authority, plus a time-boxed escalation - if no decision in 30 minutes, the on-call security lead can approve. Name a person and you have named a single point of failure.
Measure the control. Track time from 'confirmed compromise' to containment, and count auto-actions reversed within 24 hours. The reversal count is your false-positive cost; if it rises, tighten the confidence threshold rather than removing automation.
3. Leadership wants one MTTR number for phishing. What do you tell them, and what would you publish instead?
Read the worked answer
A blended MTTR across 1,200 daily reports - 97% of which are not malicious - is an average of the time it takes to close spam. It will move if you change the intake rules, not if you get better at responding. It is also a mean over a heavy-tailed distribution, so a handful of long-running credential-theft cases dominate it.
Publish three things instead:
- Median and P90 time from promotion to containment, split by severity. Promotion is the point where an analyst decided this was real; containment is the point where the risk stopped. That interval is what the team controls.
- Percentage of intake resolved without human touch. This is the automation dividend, and it is the number that justifies the triage redesign.
- Promotion precision and auto-containment reversal rate. If promotion precision is low you are burning analysts on false positives; if reversals are high your automation is acting on bad intelligence. Both are quality signals that MTTR hides.
Keep a rollup for the executive audience, but annotate it with the population and the definition - 'median, P1/P2 promotion to containment, excludes reports closed at intake'. A number whose definition is not written down will be compared against last quarter's differently-defined number, and you will spend the meeting explaining arithmetic instead of risk.