What should MSPs measure when they combine DSPM and ITDR?

Why This Matters for Security Teams

When MSPs combine dspm and ITDR, the risk is not lack of data or lack of alerts. The risk is measuring the wrong thing. Data posture tools can inventory sensitive content, while identity threat detection tools can surface suspicious activity, but neither proves whether an identity can actually reach the data, under what conditions, and with what degree of privilege. That gap matters because access is what turns exposure into compromise.

For MSPs, the meaningful metric is effective access: which identities can open sensitive data, which permissions are inherited through role design or policy drift, and which detections represent active misuse versus normal operational noise. That framing aligns with guidance in the NIST Cybersecurity Framework 2.0, which emphasizes coordinated governance, protection, detection, and response rather than isolated telemetry. It also matches NHIMG research in the Ultimate Guide to NHIs, where weak visibility into service accounts and excessive privilege are recurring failure points.

In practice, many security teams discover the real problem only after a customer asks who could have accessed the data, rather than through intentional measurement of effective access.

How It Works in Practice

Effective measurement starts by joining three views: data classification, identity entitlements, and threat signals. DSPM tells the MSP what sensitive data exists and where it lives. ITDR tells the MSP when identities behave abnormally. The combined metric is whether those identities can actually reach that data, and whether the resulting access path is defensible under policy.

That requires more than counting alerts. MSPs should measure:

• identity-to-data reachability for sensitive repositories, including service accounts, API keys, and privileged sessions
• policy-driven exposure, such as permissions granted by inheritance, misconfigured groups, stale roles, or overly broad service access
• detected misuse, including impossible travel, abnormal query patterns, privilege escalation, and access outside expected task windows
• remediation speed, meaning how quickly risky access is removed after a signal is confirmed

This is where identity governance and data posture reinforce each other. NHIMG notes that only 5.7% of organisations have full visibility into service accounts in its Ultimate Guide to NHIs, which makes identity-centric measurement essential, not optional. A data alert without identity context can be noise. An identity alert without data context can be a false positive. Together, they answer whether sensitive content is exposed, reachable, and being touched in a suspicious way.

Operationally, MSPs should map findings to the customer’s control objectives, then report trends such as reachable sensitive objects, number of identities with standing access, and percentage of critical alerts that led to containment. The guidance works best when identities, data stores, and detection pipelines are normalized across tenants. These controls tend to break down in multi-cloud environments with inconsistent tagging and fragmented identity sources because effective access becomes hard to calculate reliably.

Common Variations and Edge Cases

Tighter measurement often increases operational overhead, requiring organisations to balance visibility against tenancy complexity and customer reporting burden. That tradeoff is real for MSPs managing many environments, because the same metric can mean different things across cloud platforms, directories, and data stores.

There is no universal standard for this yet, but current guidance suggests separating three classes of results: exposure that is expected and policy-driven, exposure that is excessive but not yet exploited, and exposure that reflects active misuse. That distinction matters because alert volume alone can make a healthy environment look dangerous, while dormant exposure can remain invisible if no one is checking reachability.

Edge cases include read-only analytics identities, break-glass accounts, and third-party integrations. Those accounts often look risky in raw DSPM output but may be acceptable if they are time-bound, monitored, and tightly scoped. The right question is not whether the identity exists, but whether its effective access matches the business purpose and the customer’s tolerance for exception handling. Current best practice is to report exceptions separately so customers can see what is intentional versus what needs remediation.

For MSPs, the most useful evidence is a control narrative, not a dashboard screenshot: which sensitive assets are reachable, which identities justify that reach, and which detections show the control is actually working.

Related resources from NHI Mgmt Group

• What do teams get wrong when they measure DSPM success?
• Why do recertification programmes fail when they are only run periodically?
• How should security teams combine DSPM and DLP in modern data environments?
• What should organisations measure if they want to know fraud controls are working?