Your client’s monthly security report shows fewer alerts. That sounds like good news, and it might be. But before you put a green arrow next to the number, there’s a question worth asking: What actually changed?

Did the environment become harder to compromise? Did your team eliminate repetitive noise? Or did a logging integration stop working?

Those possibilities deserve very different conversations. An alert count, by itself, cannot tell your client which conversation to have.

Less activity does not necessarily mean less exposure

WatchGuard’s September 22 release announcing its Global Threat Report offers a useful illustration. In its analysis of the first half of 2026, the company reported a 79% decline in total network attack volume, while novel endpoint malware increased more than 2,000% year over year (WatchGuard).

The company also reported that unique intrusion prevention system signatures increased even as average network attack volume fell, describing broader, lower-intensity probing. These findings come from anonymized, aggregated intelligence from WatchGuard’s own network and endpoint products, not a census of every organization’s security environment.

Network attack detections, endpoint malware observations, and your service desk’s alert queue are different measures. Don’t collapse them into one trend, or assume that any percentage above describes your clients.

The useful lesson is narrower: a falling count is not, on its own, evidence of falling risk. Before treating a quieter dashboard as an improvement, establish what it measures and whether visibility remained intact.

Keep the alert metrics. Change their job.

Don’t respond by abandoning alert reporting or generating more noise. Instead, use alert volume to help explain operational workload, tuning decisions, and changes that need investigation.

For each meaningful drop, check whether monitored assets, log sources, detection rules, exclusions, and reporting periods stayed comparable. Investigate unexpected silence with the same discipline you apply to an unexpected spike.

Then separate two questions in the client report: “What did our tools observe?” and “What evidence shows that your security program is working?”

The first belongs in the operational summary. For the second, build a scorecard around coverage, validation, remediation, and recovery.

Four measures that deserve space in the client scorecard

Control coverage: Are we protecting the agreed scope?

Start with the denominator, not the dashboard percentage. CIS Safeguard 1.1 calls for an accurate, current enterprise asset inventory, while Safeguard 8.2 calls for enabling audit logging across enterprise assets according to the organization’s logging process (CIS Controls Navigator).

For your scorecard, compare the agreed inventory against the controls that should cover it. Don’t let the endpoint console define the entire population it is supposed to protect.

• Endpoint coverage: Report eligible devices with healthy, reporting protection against all eligible devices in scope.

• Identity coverage: Track required MFA enforcement, including privileged accounts and documented exceptions.

• Telemetry coverage: Show which required log sources are reporting and when missing sources were last seen.

Include the measurement date and excluded assets. Make unknown coverage visible rather than quietly treating it as protected.

Detection validation: Would the right activity reach the right person?

Treat “enabled” and “tested” as separate statuses. CIS Safeguard 18.4 specifically calls for validating security measures after penetration tests and adjusting detection capabilities where necessary (CIS Controls Navigator).

Build a proportionate validation program using authorized, safely scoped tests relevant to each client. Follow the chain from the test activity to collected telemetry, the expected detection, ticket routing, and analyst response.

• Test results: Record which scenarios produced the expected outcome and which did not.

• Response validation: Check whether the alert reached the responsible team with enough context to act.

• Unresolved gaps: Assign each failure an owner, corrective action, and retest date.

Define expected behavior before testing, including whether a control should block the activity. A blocked attempt and a missing detection should not be scored interchangeably.

Remediation progress: Which meaningful exposures did we remove?

Lead with risk-prioritized remediation rather than total tickets closed. CISA recommends using its Known Exploited Vulnerabilities catalog as an input to vulnerability prioritization because it identifies vulnerabilities with evidence of exploitation in the wild (CISA).

For each client, combine exploitation information with exposure, business importance, and the agreed remediation process. Separate confirmed fixes from temporary mitigations and accepted exceptions.

• Priority backlog: Show overdue high-priority findings and their age, not just the total backlog.

• Verified closure: Retest or otherwise validate remediation before counting an exposure as resolved.

• Decision ownership: Identify items awaiting client approval, with a named decision-maker and review date.

If a client postpones replacing an exposed, unsupported device, keep that decision visible. A closed service ticket should not make an unresolved exposure disappear.

Recovery tests: Can the business resume?

Report restoration evidence separately from backup job status. CIS Safeguard 11.5 calls for quarterly or more frequent backup recovery testing on a sample of in-scope enterprise assets (CIS Controls Navigator).

Use business requirements to determine the appropriate scope and cadence for each client. When reporting a test, describe exactly what was restored and avoid presenting a single-file recovery as proof that an entire application can resume.

• Test scope: Identify the data, system, or business service restored.

• Business outcome: Compare observed recovery time and data loss with agreed objectives.

• Follow-through: Record failures, dependencies, corrective actions, and retest dates.

Give the client a decision, not just a color

For the next QBR, put those four categories on one page. Show the current result, previous result, supporting evidence, unresolved gap, owner, and next action.

Label partial coverage, stale evidence, and untested controls explicitly. Reserve “validated” for a defined test outcome, not a general promise of safety.

That changes the conversation from “We handled fewer alerts” to “We verified these controls, closed these exposures, and tested this recovery process.” It also gives the client a clear view of what still requires their participation.

Keep the dashboard. Just make it support the security strategy rather than stand in for one.

Frequently asked questions

Q: Do fewer security alerts mean an MSP’s client is safer?

A: Not necessarily; a lower count alone is insufficient evidence of improved protection. Before reporting it as a security gain, verify that monitoring coverage remained intact and identify the change responsible.

Q: What should MSPs report alongside alert volume?

A: Report control coverage, detection test results, risk-prioritized remediation, and recovery test outcomes. Give each measure a defined scope, measurement date, evidence, and owner so clients can understand both progress and remaining work.

Q: Can this scorecard prove that a client cannot be breached?

A: No; use it to communicate the controls and outcomes you have actually verified, not to guarantee future security. Keep limitations and unresolved exposures visible alongside the successes.