Use SOC Metrics to Start an Operational Conversation

SOC metrics often arrive as a dashboard screenshot or one complaint. Alert count rises. Urgent cases wait too long. Coverage looks uneven. A number creates interest, yet a number alone does not explain an operating problem. Before comparing measures or proposing a service, ask what decision a leader hopes to make. The answer gives the metric a job.

Start by naming the measure in customer words. Ask how the team labels the measure, where they see the measure, and who receives updates. A label such as response time often describes several clocks. One person measures time from alert creation to analyst acknowledgement. Another measures time from triage to a customer contact. A third uses a report covering selected cases. Write the customer definition before discussing performance.

Ask who owns the measure. Ownership means more than a name on a dashboard. Find who validates data, who reviews the result, and who changes a process when the number moves. A SOC manager reviews daily workload. A security leader uses a monthly view for staffing discussion. An operations partner owns a handoff stage affecting the result. Each person sees a different part of the measure, so invite relevant people into a review.

Ask what action follows a change. “If this measure rises next month, what would your team decide?” is direct. The answer often reveals a staffing discussion, severity review, workflow change, or no planned action. No action does not make a metric useless, yet signals a need to learn why leaders watch the number. A consultant who learns the decision avoids a polished presentation with no connection to customer operations.

Severity definitions deserve attention before comparison. A customer often calls an alert urgent because a system assigned a label. Another customer applies urgency after analyst review. Some teams change severity during an investigation. Ask when the label is assigned, who changes the label, and which cases appear in the metric. Small wording differences change a trend meaning. Do not describe two measures as comparable until the customer confirms scope and calculation.

Data source questions matter too. Ask which tools or queues feed the reported number, which records stay outside the view, and whether a manual step changes final count. A metric based on one queue sometimes leaves out work handled elsewhere. A weekly report sometimes excludes cases still open at a cutoff. Those details decide what a leader sees when using the number to guide a team.

Consider a fictional practice situation. Jordan, an MDR consultant, meets with LumaMart, a fictional retailer. The security director shares a chart showing urgent alerts waiting longer for acknowledgement. Jordan does not call the trend a staffing failure. He asks, “What decision would this measure help your team make?” The director says leadership wants to know whether after hours coverage needs a change before a seasonal sales period begins.

Jordan asks for the metric definition. The SOC manager explains urgent alerts enter the chart when a rule assigns severity at creation. The timer stops when an analyst acknowledges the case. The chart includes alerts from two monitored environments, while a third environment uses a separate queue. Jordan records those facts without drawing a conclusion. He asks whether the separate queue affects the coverage question. The manager says yes, because after hours work moves between queues when volume rises.

The next question focuses on workflow. Jordan asks who watches alerts after normal business hours, who receives a handoff, and where an urgent case sits while people decide ownership. The manager describes an on call rotation and a handoff note at the end of each shift. The operations lead says handoff notes vary by analyst. Jordan hears two topics: coverage timing and handoff consistency. He keeps them separate rather than saying one service change solves both.

Jordan suggests a review agenda with a defined purpose. The team will validate the urgent alert definition, map every queue included or excluded, review two recent after hours cases, and name the decision owner for coverage. He asks the customer to select cases and invite the person responsible for the third queue. The examples stay grounded in customer records while operational choices stay with customer leadership and suitable specialists.

Metric reviews fail when a consultant chases a lower number without asking whether the number supports good work. Alert count might rise because source coverage changed. A response measure might move because teams changed a definition. A closure measure might look faster because a queue excludes complex cases. Do not infer maturity, quality, or risk from one chart. State customer confirmed facts, name unknown calculation parts, and tie interpretation to one decision.

Use a decision record after every metric discussion. Include measure name, plain language definition, source or queue, time period, named owner, decision supported, and open questions. Separate observed facts from suggested follow up. “Two queues appear in the weekly chart” is an observed fact. “Review the third queue before changing coverage” is a follow up. This record makes a later meeting easier because attendees see why each question exists.

Expect disagreement between teams. A security leader wants a metric for executive oversight. A SOC manager needs a measure useful during a shift. An operations lead cares about a handoff stage neither report captures. Do not force one measure to serve every audience. Ask each person, “What action do you need from this view?” Show where answers overlap and where separate measures need separate review. This stops a broad reporting debate from blocking an urgent operating question.

When a buyer asks how another organization measures performance, avoid presenting outside practice as a rule. Bring attention back to buyer definitions and choices. Say, “Before we compare approaches, let us confirm which decisions your leaders need this measure to support.” When a customer seeks technical detail or service scope, capture the question and involve a suitable specialist. A clear boundary prevents claims unsupported by customer data.

DealSpeak coaching review works best when a call summary names measure, definition, owner, decision, and follow up. A vague summary such as “Discussed response time” loses operating context. In the fictional LumaMart example, Jordan writes: urgent acknowledgement time starts at rule assigned severity and ends at analyst acknowledgement. The current chart excludes a third queue. The security director owns the coverage decision. The next review uses two selected after hours cases. Those notes allow a reviewer to assess discovery quality without inventing an outcome.

For practice, choose a fictional dashboard with one measure. Write a definition using customer terms. Name a data source, an owner, a decision, and two unknowns. Write four questions for a first call, including one about a workflow stage outside the chart. In a role play, have your fictional security director raise a concern about after hours coverage. Write a meeting invitation for the queue owner and ask them to bring one recent case from a Friday evening. Put “review handoff path” in the invitation agenda, then use the case record to map who touched the alert at each stage.