The 15-20 Tool Reality
The average MSP uses 15-20 different tools. Datto’s State of the MSP research documents the proliferation: RMM platforms, PSA systems, documentation tools, security stacks, backup solutions, network monitoring, and more. Each tool serves a purpose. Together, they create complexity that clients rarely understand.
The tools exist in the MSP’s domain. You see outputs. You don’t see operations. The gap between what you know and what happens creates operational opacity.
The Visibility Gap
Clients typically see less than 10% of the actual data generated by MSP tools. The remaining 90% exists in systems you can’t access, formatted in ways you can’t interpret, telling stories you never hear.
| Data Type | MSP Visibility | Client Visibility |
|---|---|---|
| Real-time alerts | Full | Summary only |
| Historical metrics | Full | Periodic reports |
| Configuration details | Full | Limited to documentation |
| Ticket metadata | Full | Ticket content only |
| Staff activity | Full | Time entries if any |
| Security events | Full | Incident notifications |
The asymmetry isn’t necessarily malicious. MSPs manage complexity you hired them to manage. But opacity creates dependency. You can’t evaluate what you can’t see.
The Tool Dependency Architecture
MSP tools create dependencies that outlast the relationship:
RMM agents. Software installed on every endpoint. Removal requires touching every device.
PSA integrations. Workflows built around specific ticketing system. Changing systems means rebuilding workflows.
Documentation platforms. Runbooks and configurations stored in MSP-controlled systems. Leaving means recreating or losing.
Backup infrastructure. Data lives on MSP-managed backup platforms. Recovery depends on continued access.
Security tools. EDR, SIEM, and firewall management tied to MSP infrastructure.
Each dependency extends exit complexity. The tools that enable service delivery also enable lock-in.
The Supply Chain Risk
Vendor compromises affect thousands of downstream clients instantly. The Kaseya and SolarWinds attacks demonstrated the architecture: one MSP tool compromised, every client using that tool exposed.
| Supply Chain Event | Impact Scope | Recovery Complexity |
|---|---|---|
| Kaseya VSA (2021) | 1,500+ organizations | Weeks to months |
| SolarWinds (2020) | 18,000+ organizations | Months to years |
| ConnectWise ScreenConnect (2024) | Thousands potentially | Variable |
Your security posture depends on your MSP’s security posture. Their tool vendors’ security posture affects both. The chain extends beyond your visibility or control.
Evaluating Tool Stack Risk
Questions to understand your MSP’s tool stack exposure:
What are your core tools? RMM, PSA, documentation, security. Know the names.
What is your tool vendor assessment process? Do they evaluate vendor security, or just features?
How quickly did you respond to Kaseya/SolarWinds? Past behavior predicts future response.
What is your tool patching cadence? Tools themselves need patching.
Do you have contingency plans for tool vendor failure? What happens if their RMM goes down?
The Opacity Problem in Practice
Opacity affects operations in specific ways:
Incident understanding. You know an incident occurred. You don’t know what really happened.
Performance evaluation. You see response times. You don’t see what work actually occurred.
Capacity assessment. You don’t know if resources are adequate or stretched.
Quality verification. You can’t validate that work was done correctly.
Strategic planning. Without full data, planning operates on incomplete information.
Gap doesn’t mean the MSP is hiding problems. It means you lack independent verification capability.
Building Visibility
Increasing visibility requires explicit effort:
Report customization. Request specific metrics beyond standard reports.
Dashboard access. Some MSP tools offer client portals. Request access.
Audit rights. Contract provisions allowing data access requests.
Regular reviews. Deep-dive sessions beyond summary QBRs.
Independent monitoring. Your own tools that validate MSP claims.
Each visibility improvement has cost. MSPs may charge for custom reporting. Independent monitoring requires investment. The value depends on how much uncertainty you’re willing to tolerate.
The Tool Consolidation Trend
MSPs increasingly consolidate onto fewer platforms. The trend has implications:
Reduced complexity. Fewer integration points, fewer failure modes.
Increased dependency. More eggs in fewer baskets.
Vendor power concentration. Platform vendors gain leverage over MSPs.
Innovation constraints. Best-of-breed solutions may not integrate with consolidated platforms.
Consolidation simplifies operations but increases concentration risk. A failure in the consolidated platform affects everything.
The Documentation Dependency
MSP documentation platforms present particular risk. Runbooks, configurations, network diagrams, and procedures live in systems you may not be able to access.
Documentation access strategies:
Regular exports. Periodic copies in standard formats to your control.
Parallel documentation. Maintain your own copies of critical documentation.
Exit provisions. Contract terms specifying documentation format and transfer at termination.
Access verification. Periodically verify you can access documentation in emergency.
The organization that assumes documentation is accessible discovers during crisis that it isn’t.
The Shadow Data Problem
MSP operations generate data about your organization:
Ticket histories. What broke, how often, what was done.
Performance baselines. Normal operating parameters.
Capacity trends. Growth patterns, utilization trends.
Security events. Attempted and actual compromises.
User patterns. Who generates tickets, what kind, how resolved.
This data has value. For planning. For evaluation. For transition. At termination, does the data come with you? Can it be exported? In what format?
Data that you can’t access or extract limits your options even when you have nominal ownership.
The Vendor Within the Vendor
MSP tools often depend on their own supply chain:
Cloud hosting. AWS, Azure, GCP outages affect MSP tools.
API dependencies. Integrations that fail when third parties change.
License dependencies. Tool availability tied to MSP payment status.
Data dependencies. Threat intelligence, updates, signatures from external sources.
Your MSP is stable. Their tool vendor is stable. That vendor’s cloud provider experiences an outage. Your service degrades despite no problem in the visible chain.
Measuring Opacity Risk
Assessment questions:
Can I independently verify my current security posture? If no, opacity is high.
Do I have access to raw data, or only MSP interpretations? Interpretation-only increases dependency.
Could I describe my environment accurately without MSP input? If no, knowledge dependency exists.
What would I know about a breach before the MSP told me? Detection dependency matters.
Could I onboard a new MSP without current MSP cooperation? If no, transition risk is high.
The answers reveal dependency depth. Not all dependency is problematic. Unrecognized dependency is always problematic.
Sources
- MSP tool count: Datto State of the MSP
- Client data visibility: MSP operational analysis
- Supply chain attack impact: Kaseya and SolarWinds incident analyses