The county wants time-in-status numbers that feed MTTR. An IT manager orders a new ITSM tool because Splunk cannot time a notable. Where should the municipal SOC measure that?
Select an answer to reveal the explanation.
Short Explanation
You do not buy a second stopwatch to time a race Splunk already timed. Incident Review Audit and the Analyst Queue stamp when a notable moved status. That time-in-status is a real contributor to MTTR.
Full Explanation
Enterprise Security already timestamps notable workflow; municipal SOCs should measure time-in-status for MTTR-style reporting from Incident Review Audit and Analyst Queue reporting, not by first buying a second ITSM stopwatch. Ordering a new ITSM tool because someone claims Splunk cannot time a notable misunderstands ES audit capability for civic ticket clocks. Measuring only in a paper runbook fails by concept because paper lacks reliable, queryable, and auditable timestamps across shifts. Measuring only in the Risk Analysis dashboard fails by concept because that view is for risk scores, annotations, and contributing risk over time—not the ticket-close workflow clock. Measuring in the Windows Event Log on each clerk PC fails by concept because endpoint logs do not replace notable workflow timestamps maintained in Enterprise Security. Exam caveat: SPLK-5001 expects awareness that Incident Review Audit and queue reporting provide notable timing data for MTTR inputs. Operational check: run Incident Review Audit or equivalent queue reports for status-change times on sample notables, compute time-in-status for MTTR, and only then decide whether an external ITSM integration adds value beyond ES.