What Evidence Should Your MSSP Provide Every Month?

A monthly MSSP report should help the customer make decisions. Too many reports instead prove only that technology generated activity: event volumes, alert totals, ticket counts, and a collection of charts with no clear relationship to risk.

The useful question is not whether the provider was busy. It is whether the service maintained the promised coverage, made defensible investigation decisions, escalated material issues, improved weak areas, and closed the actions agreed with the customer.

This guide sets out a practical monthly evidence pack for an outsourced SOC or managed detection and response service. It can be adapted to the scope and risk of the organisation, then tested through the ServiceSignal MSSP Reality Check.

The seven records to request each month

1. Scope and data-source health

Start with what the service could see. The report should identify required data sources, current ingestion state, significant volume changes, collection failures, blind periods, outstanding onboarding items, and the owner of each gap.

At minimum, ask for:

• the number of required sources expected, connected, healthy, degraded, and missing;
• the duration and business impact of collection failures;
• material changes in log volume or parsing quality;
• new systems or identities awaiting onboarding;
• accepted exclusions, compensating controls, owners, and review dates.

A green platform-health dashboard can still conceal a critical system that was never placed in scope. Compare the report with the customer's asset, cloud, identity, and change records.

2. Detection coverage and validation

Coverage should be described in terms of relevant behaviours and risks, not the total number of enabled rules. Ask what changed, what was tested, what failed, and which important gaps remain.

• new, changed, disabled, or retired use cases;
• validation exercises completed and their results;
• failed tests and the remediation or acceptance decision;
• coverage dependencies affected by missing data;
• planned work mapped to the customer's priority threats and assets.

For high-priority scenarios, a short trace from test action to telemetry, detection, case creation, analyst decision, and escalation is more valuable than a long rule inventory.

3. Alert quality and investigation decisions

Counts need context. The service should explain how alerts became cases, which decisions mattered, and where quality needs attention.

• alerts and cases by relevant category and severity;
• true positive, benign positive, false positive, and unresolved outcomes where those labels are used consistently;
• repeat noisy sources or rules and the tuning action taken;
• sample investigation records showing analyst reasoning;
• quality-review findings, reopened cases, and corrected decisions.

Be careful with a single false-positive percentage. Classification practices differ, and a falling rate can mean better tuning, suppressed visibility, or changed labelling. Review the underlying decisions and trends.

4. Incidents, escalations, and response performance

List material escalations and incidents separately from ordinary activity. Each entry should explain the timeline, decision, customer response, outcome, and any service change that followed.

• time from observable signal to detection, triage, notification, and agreed response;
• whether the priority changed as business context became known;
• handoffs between provider, customer, incident responder, and other suppliers;
• missed targets, communication gaps, and root causes;
• lessons, owners, due dates, and closure evidence.

An average response time can hide the one case that mattered. Review material cases individually, then use aggregate measures to understand patterns.

5. Improvement and controlled change

The pack should show how the service became better, not just how it stayed busy. Changes need a reason, owner, approval path, test result, and outcome.

• detection tuning and new content;
• runbook and escalation changes;
• automation introduced, changed, or withdrawn;
• platform upgrades or service-impacting maintenance;
• improvement backlog movement and overdue items.

Ask the provider to connect each significant change to a risk, incident, quality finding, customer request, or measurable service objective.

6. Service management and operational resilience

Record issues that affect the provider's ability to sustain delivery, including staff transitions, capacity pressure, outages, supplier dependencies, and continuity events.

• service availability and material degradation;
• open problems and repeated incidents;
• key contact or analyst changes and completed handovers;
• capacity risks, backlog age, and quality-control coverage;
• planned changes that require customer action.

This does not require disclosure of sensitive staffing data. It requires enough evidence to understand whether continuity, competence, and service quality are being maintained.

7. Risks, actions, and decisions

Finish the pack with a short decision register. It should be possible to see what remains exposed, who has accepted it, what will change, and when the evidence will be reviewed again.

• new and changed service risks;
• evidence gaps and requests awaiting response;
• actions with one accountable owner and a due date;
• decisions made or required from the customer;
• accepted risks with an expiry or review date.

If the same action appears month after month, require an explicit choice: fund it, reschedule it with a reason, accept the risk, or close it with evidence.

Metrics that look useful but need challenge

For a complete model that separates contractual clocks from operating quality and risk outcomes, use the MSSP SLA and security outcomes guide.

Events processed

A large number may show scale, noisy telemetry, duplication, or pricing exposure. Pair it with data quality, required-source health, and the coverage that depends on those events.

Alerts closed within SLA

This can reward rapid administrative closure. Sample the reasoning and outcome, and separate acknowledgement time from meaningful investigation and escalation.

Mean time to respond

Define the start and end points. Show the distribution and material outliers. Averages conceal cases that waited too long and cases closed automatically in seconds.

Rules enabled

Rule volume says little about relevance, dependencies, validation, tuning, or overlap. Measure tested coverage for priority scenarios instead.

Threats blocked

Clarify what qualifies as a threat, which control blocked it, whether the MSSP influenced the outcome, and whether any further action was required.

A 60-minute monthly MSSP service review

1. First 10 minutes: resolve overdue actions and confirm material scope or business changes.
2. Next 15 minutes: review data-source health, blind periods, and high-priority coverage.
3. Next 15 minutes: examine material cases, missed targets, investigation quality, and lessons.
4. Next 10 minutes: decide the priority improvement work and any risk acceptance.
5. Final 10 minutes: read back decisions, owners, dates, and evidence required before the next meeting.

Send the evidence pack early enough for the customer to review it. A meeting spent discovering unexplained numbers is unlikely to produce good decisions.

What if the provider cannot supply this evidence?

Start proportionately. Agree the smallest useful pack, identify which records already exist, and prioritise evidence for the highest-risk services. Do not accept a permanent substitute of verbal assurance or a new dashboard project with no delivery date.

Record unavailable evidence as a gap, assign an owner, and agree what will demonstrate closure. The fictional ServiceSignal sample report shows how evidence gaps and actions can remain visible alongside a score.

How this fits wider MSP guidance

The NCSC recommends checking security responsibilities, service levels, incident arrangements, logging access, contract terms, and provider transparency when choosing and working with an MSP. A monthly evidence pack turns those expectations into an operating rhythm rather than a one-off procurement exercise.

Use the ServiceSignal methodology to understand how evidence and red flags affect the assessment result, or review the complete MSSP scoring framework before your next meeting.