Define a Security Metric Before Discovery

Security metrics invite false agreement. One leader might use response time for first analyst review. Another might use those same words for containment, escalation, or a handoff to an application owner. A number sounds settled before anyone has named the events behind the number. An account executive who repeats a label too soon risks planning discovery around two different ideas.

Treat each metric as a definition exercise. Ask which event starts the clock. Ask which event ends the clock. Ask which records supply each timestamp. Ask who checks a surprising result before leadership sees a report. These questions turn a familiar label into a shared description of work. They also show respect for the security team’s existing process.

Begin with the decision behind the metric. A security leader might use a trend during budget planning. An operations manager might use a similar trend to review staffing coverage. A team lead might use daily counts to choose a queue for attention. The label stays familiar, yet each decision gives priority to a different feature of the number. Ask, “When this result changes, which decision changes?” Request one recent example. A recent decision provides a stronger starting point than a wish for a better dashboard.

In a fictional practice situation, Priya, a security operations manager, tells Jordan, an account executive, “Response time averages ninety minutes, and leadership wants clearer metrics.” Jordan does not treat ninety minutes as a single activity. He asks, “Which event starts those ninety minutes?” Priya answers, “An analyst opens a severe alert.” Jordan follows with, “Which event ends them?” Priya says, “We stop when security sends work to an application owner.” Jordan now knows Priya describes analyst handling, not full remediation.

Scope needs similar attention. Ask whether a report includes every alert or selected severity levels. Ask how duplicate alerts enter the count. Ask whether a weekend alert waits until staffed hours. Ask where a transferred item leaves the measure. A pause during an internal review might make sense. A buyer still needs words for the point where responsibility moves from one group to another. Precision supports a useful later discussion without turning an early call into an audit.

Source records deserve direct questions. An analyst might work in an alert queue, add notes in another system, and receive a closing update through a request process. Ask which system supplies the timestamp leadership reviews. Then ask whether staff correct records after an incident. Try, “When someone corrects a record, who makes the change and how does the monthly report show the change?” Do not assume a single source holds every answer. An incomplete source does not mean poor practice. The gap signals a later discussion with people who know how records join together.

Ask about ownership without assuming a job title. The person who receives a dashboard might differ from the person who checks field definitions. A security program manager might own the meeting. A reporting analyst might know the export logic. An incident lead might understand why a queue pauses overnight. Ask, “Who would help us explain an unexpected shift in this number?” A named person gives the next meeting a purpose. No name signals an internal question worth recording.

Keep the customer’s own words in your notes. Do not turn their definition into an industry phrase. Jordan writes, “Response time begins when an analyst opens a severe alert and ends when security assigns work to an application owner. Report includes weekends. Export source needs review.” The note separates confirmed details from an open point. A later participant sees where the agreement ends and where a question starts.

Use a plain language check before planning a demonstration. Read your note aloud. A listener might ask whether the number includes remediation, handoffs, or every alert. If your note does not answer one of those questions, write an exact follow up prompt. “Better visibility” gives little direction. “Which timestamp marks initial containment for severe alerts?” gives a customer one narrow item to answer and gives you a reason for another meeting.

Different metrics hide different choices. Mean time to respond might refer to acknowledgement, investigation, containment, or closure. Alert volume might change after a detection rule changes, even when the team’s work does not change in the same way. Closure rate might omit reopened work or work moved into another queue. Coverage might refer to assets, identities, applications, or business units. You do not need to correct each label during discovery. You do need to hear when one word carries several definitions.

Return to Priya’s fictional example. Jordan asks which decision leadership expects from the quarterly review. Priya says leaders want to examine after hours coverage. Jordan asks which severe alerts appear in the report and whether a Saturday alert receives the same timing treatment as a weekday alert. Priya says all severe alerts appear, including weekends, and the timer begins at alert creation. She adds one detail: analysts complete initial containment before a different team receives application work.

Jordan asks one more question about the monthly export. Priya says a reporting analyst prepares the file after the final calendar day. Jordan avoids a claim about reporting quality. He says, “I hear a severe alert measure from creation through initial containment, with weekend alerts included. For our next discussion, would the reporting analyst help us review how alerts opened at month end appear in the export?” The request ties a named person to a specific decision instead of asking for broad access or every field from every tool.

Jordan also avoids sensitive detail. He does not request raw incident records. He does not ask Priya to share a full dashboard. He does not promise a report outcome. He finds one decision, one metric, and one boundary needing confirmation. Smaller discovery creates room for a customer to explain real work instead of defending a large request.

Before your next call, select one metric likely to enter conversation. On a blank note, write start event, end event, included population, decision supported, source record, and report owner. Leave room for the customer’s exact language after each prompt. Do not fill any space with assumptions before the meeting. If a customer uses a broad label, ask for one recent record or one recent decision, not a general definition.

In the fictional follow up, Priya brings the reporting analyst. Jordan opens his earlier note and says, “We described response time as severe alerts from creation through initial containment. Our open question concerns month end export timing. Would you walk us through one alert opened on the final day of a fictional June?” The analyst names the alert creation time, the containment time, and the export date. Jordan writes those three values beside his open question, then schedules the next discussion around the one remaining boundary: how transferred application work appears in the leadership view.