Managed security metrics: what to ask at the service review

Start with the decision the measure supports

Service reviews should help someone decide what to improve, fund, accept or escalate. Before requesting a metric, state the decision it will inform. A count of investigated cases may help explain workload, while a record of unresolved high-priority actions may support management escalation. Neither proves that all important threats were detected. Ask the provider to describe each measure, its evidence source, the period covered and relevant exclusions. A small set of well-defined measures is easier to challenge than a large dashboard whose numbers mean different things to different teams.

Measure coverage before interpreting activity

The number of alerts has little meaning without a view of the systems producing them. Report agreed sources, missing or unhealthy feeds, unsupported environments and known coverage gaps. Distinguish an expected quiet period from a source that has stopped delivering evidence. Track changes to the covered population and explain whether comparisons remain valid. If a newly connected cloud environment doubles the event volume, a higher count may reflect improved visibility rather than worse security. Coverage exceptions should have an accountable owner and a date for the next decision.

Define time intervals precisely

A response-time figure needs a start event, an end event, an operating calendar and an explanation of excluded periods. Receipt of an alert, initial review, customer notification and authorised containment are different milestones. Ask how incomplete evidence or an unavailable approver affects the measurement. Use the contract definitions when assessing a contractual target. Do not compare providers using similar-looking numbers that measure different stages. For procurement, request an example showing the timeline so the operational team can understand what the proposed metric would actually mean.

Sample the quality behind the count

Review a small, appropriately redacted set of cases to see whether the evidence supports the assessment, the business context is present and the next action is clear. Confirm that an escalation reached an owner and that important decisions were recorded. Examine reopened cases and repeated issues as well as successfully closed items. A case marked closed can still leave an unresolved configuration weakness or an action with another supplier. The service review should expose that distinction without circulating confidential investigation material to an unnecessarily broad audience.

Connect the review to an improvement backlog

End the discussion with decisions, owners and dates. Separate work the provider can perform within the existing scope from changes requiring client approval, additional licences or a revised agreement. Check whether earlier actions produced the expected evidence instead of carrying them forward automatically each month. Ask which assumptions have changed and whether reporting should change with them. Management reporting can summarise those decisions while operational teams retain the detail needed to act. The value lies in the completed improvement, not in the visual polish of the monthly slide deck.

For the next procurement discussion, read our related guides on monitoring service evidence and remediation verification. These cover complementary decisions; technical testing still needs its own scope and authorisation.

Prepare your requirements

Use the managed security services RFP builder to select your platforms, describe existing support and review suggested workstreams. You can edit your requirements before sending them through the contact form with an NDA or RFP. Approximate counts and business context are enough initially. Do not include credentials, personal records or live incident evidence. Service hours, delivery capacity and commercial commitments must be agreed in the proposal; submitting a form does not activate a service.