Why do clients push back when MSPs report lots of activity?

Why This Matters for Security Teams

Clients push back on activity reports because activity is not the same as risk reduction. A long list of tickets closed, alerts triaged, or hours logged can look busy while leaving the real exposure unchanged. Security buyers want evidence that the service reduced blast radius, improved recovery, lowered privileged access, or prevented downtime. That expectation is consistent with the outcome-based language in the NIST Cybersecurity Framework 2.0, which emphasizes governance and measurable risk outcomes rather than raw operational volume.

This matters even more in identity-heavy environments, where the real issue is often hidden behind apparent productivity. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges. In that context, reporting more activity can unintentionally signal more complexity, not more control. The client may hear “more tickets” and translate that into “more problems,” especially if the report does not connect those tickets to access removal, secret rotation, or attack surface reduction. In practice, many security teams encounter skepticism only after the client has already compared activity volume against a competitor’s clearer outcome story.

How It Works in Practice

Strong MSP reporting shifts from “what was done” to “what changed.” That means tying operational work to a small set of business and security outcomes: fewer exposed secrets, faster containment, reduced privilege sprawl, improved uptime, fewer repeat incidents, and less manual toil for the client. The most credible reports show baseline, current state, and trend, so the client can see movement rather than just motion.

For identity and access services, that can include a short narrative plus a few metrics that answer different questions:

• Risk: how many high-risk accounts were removed, rotated, or re-scoped
• Resilience: how quickly critical systems recovered after an incident or change
• Efficiency: how much manual work automation removed from the client’s team
• Governance: how many exceptions remain open, and why

That framing aligns with current guidance in the Ultimate Guide to NHIs, which treats visibility, rotation, offboarding, and least privilege as lifecycle controls rather than activity metrics. It also fits the message in the NIST Cybersecurity Framework 2.0: outcomes matter when they can be traced to risk reduction and operational resilience.

When MSPs report activity well, they also explain tradeoffs. For example, a spike in tickets after a control rollout may be a sign that an inherited control gap is finally being addressed, not that the team is inefficient. Equally, a low ticket count may reflect under-reporting or poor detection rather than stability. These controls tend to break down when the client environment lacks baseline data, because without a starting point even honest reporting can look like guesswork.

Common Variations and Edge Cases

Tighter reporting often increases overhead, requiring organisations to balance transparency against the time cost of collecting, validating, and explaining the data. That tradeoff is real, especially in smaller MSPs where engineers also handle delivery. The answer is not to omit metrics, but to make the report proportionate and decision-useful.

There is no universal standard for this yet, but best practice is evolving toward a layered report: executive outcomes at the top, operational evidence beneath, and a short appendix for technical detail. Some clients want monthly trends, others want incident-by-incident proof. Regulated customers may also require evidence that supports audit trails, while SMB clients may care more about fewer interruptions and clearer communication. The mistake is to treat every metric as equally persuasive; a flood of detail can obscure the few numbers that actually justify the service.

NHIMG’s Schneider Electric credentials breach is a useful reminder that identity failures usually matter because of downstream business impact, not because the team logged activity around them. For MSPs, the winning report answers three questions plainly: what changed, why it matters, and what risk remains. Where that cannot be shown, clients will default to price, because activity alone does not establish value.

Related resources from NHI Mgmt Group

• What breaks when SOX evidence cannot be traced back to identity activity?
• Suspicious activity report
• How should security teams monitor AI agent activity without disrupting developers?
• How can SOC teams use identity context to improve response to agent activity?