Multi-cloud DSPM exposes the governance gap in data security

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cyberhaven's blog post: Multi-cloud DSPM closes the visibility gap created when sensitive data moves across clouds, SaaS and warehouses faster than traditional controls can follow.

Why it matters: It matters because IAM and data security teams need a consistent view of classification, access and lineage or they lose control of where regulated and sensitive data actually sits.

By the numbers:

• The average enterprise operates over 3,000 misconfigured cloud assets across environments at any given time.

Context

Multi-cloud data security is really a governance problem before it is a tooling problem. Once sensitive data moves from one cloud, warehouse or SaaS platform to another, control assumptions break unless classification, access rules and lineage travel with the data. In identity terms, the issue is not only where the data lives, but who or what can still reach it after it moves.

Traditional cloud-native controls were built for their own environment boundaries, so they struggle when data crosses providers and platforms. That creates a genuine identity and access management intersection because overpermissioned service accounts, broad sharing and inconsistent entitlement models often become the mechanism through which data exposure persists across clouds.

Key questions

Q: What breaks when DSPM only covers one cloud?

A: A single-cloud deployment creates blind spots as soon as data moves to another provider, warehouse, or SaaS platform. The posture may look strong in one environment while the same dataset becomes misclassified or overexposed elsewhere. Teams then lose the ability to track risk across the full data lifecycle, which is where most cross-cloud exposure appears.

Q: Why do overpermissioned service accounts increase data exposure in multi-cloud environments?

A: Service accounts often retain access across copies, pipelines and backups even when the data moves into a new risk domain. If those non-human identities are not re-scoped, they can preserve broad access to data that should have different controls in the destination environment.

Q: What are the signs that data governance is failing in a mixed cloud and legacy environment?

A: Common warning signs include unknown data locations, inconsistent classification, unclear access ownership, and ad hoc retention decisions. Teams also struggle when security controls differ across on premises and cloud repositories, creating uneven protection for the same data type. Those conditions usually indicate governance has become fragmented, which increases the chance of data loss, corruption, and avoidable compliance gaps.

Q: What should teams prioritise first in multi-cloud DSPM programmes?

A: Start with datasets that have broad inherited permissions, shared access paths, or machine-to-machine integrations, because those usually create the largest exposure window. Then connect those findings to the identity owners who can actually remove the access or change the workflow.

Technical breakdown

Why multi-cloud visibility breaks down

Multi-cloud visibility fails because each provider and platform exposes different logs, access models and storage semantics. A control that works inside one cloud rarely carries the same meaning when a dataset is copied into another cloud, a warehouse or SaaS application. DSPM closes that gap by aggregating discovery and classification across environments, then normalising the findings so teams can compare exposure consistently. Without that cross-environment view, security teams are always reacting to partial inventories rather than governing the full data estate.

Practical implication: Build discovery across every connected cloud and data platform before you attempt consistent enforcement.

How classification and lineage make DSPM operational

Classification tells security teams what the data is, while lineage tells them where it came from and how it moved. In a multi-cloud estate, those two functions are inseparable because the same file can be safe in one environment and exposed in another after replication or transformation. Lineage preserves context across those moves, which is critical for prioritisation and for understanding whether a copy in a development workspace still inherits production sensitivity. That is what turns DSPM from inventory reporting into governance.

Practical implication: Tie classification labels to lineage so copied data keeps its security context across clouds and warehouses.

Where misconfiguration creates exposure at the seams

Most cloud exposure in these environments comes from seams between platforms, not from a single catastrophic failure. Public buckets, overpermissioned service accounts and unencrypted backup locations are common because each platform’s defaults differ and teams assume the previous policy still applies. The real risk is drift: data moves, permissions do not, and the security team is left with stale assumptions. In practice, DSPM is valuable because it surfaces those seam failures before they become invisible exceptions across AWS, Azure, GCP and SaaS.

Practical implication: Prioritise misconfigurations where data crosses platform boundaries, especially shared storage and backup environments.

Threat narrative

Attacker objective: The objective is to reach sensitive data after it has crossed environment boundaries and become harder to govern consistently.

1. Entry occurs when regulated or sensitive files move from controlled storage into a new cloud, warehouse or SaaS platform that security did not fully govern.
2. Credential or access abuse follows when overpermissioned service accounts or broad sharing allow more users and systems to reach the copied data than intended.
3. Impact is exposure of sensitive data across environments, with security teams losing the thread of classification, location and entitlement as the data estate expands.

Breaches seen in the wild

• Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.
• Cyberhaven Chrome extension breach 2024: A phished OAuth consent gave attackers Chrome Web Store publishing rights and a malicious Cyberhaven extension update reached about 400,000 users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-cloud data security is now an identity governance problem as much as a storage problem. Once data copies into multiple clouds, the decisive control question becomes which identities, service accounts and shared workflows can still reach it. Classification without entitlement governance leaves organisations with labels but no enforcement path, so data security posture becomes a paper exercise rather than an operational control.

Cross-cloud lineage is the missing control plane for modern data governance. The hard problem is not discovery alone, but preserving data context after it is copied, transformed or replicated. That context determines whether access decisions, retention rules and compliance obligations still make sense after the move, which is why lineage belongs in the governance model and not just in analytics.

Overpermissioned machine access remains the quiet amplifier in multi-cloud exposure. Service accounts and automation often survive cloud transitions unchanged, even when the data they can reach has moved into a different risk domain. That is where IAM and DSPM intersect most sharply: data visibility tells you what exists, but entitlement review tells you whether the wrong workload can still reach it.

Multi-cloud DSPM is exposing a classification trust gap. Organisations often assume a label applied in one environment will retain operational meaning everywhere else. It will not, unless the classification scheme, access model and lineage logic are consistent across clouds, SaaS and warehouses. Practitioners should treat that mismatch as a governance defect, not a reporting inconvenience.

Security teams should expect posture tooling to shift toward data movement governance. The article points to a market where static scans matter less than continuous context across endpoints, clouds and SaaS. That trajectory validates the need for controls that can follow data, not just inspect storage, and it raises the bar for IAM teams responsible for non-human access into distributed data estates.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: Cloud Workload Identity Guide

What this signals

Multi-cloud governance will keep failing if teams treat each cloud as a separate control island. The practical response is to manage classification, access and lineage as one data control problem across clouds, warehouses and SaaS. That means IAM teams need to care about where machine identities can follow data, not just where the data is stored.

Cross-cloud lineage is becoming a security requirement, not an analytics convenience. When data copies into development, analytics or third-party platforms, the security team needs to know whether the original sensitivity and entitlement assumptions still hold. That becomes even more urgent because 28% of secrets incidents now originate outside code repositories, in Slack, Jira and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.

Seam-level exposure is the dominant pattern to watch. The highest-risk failures are the transitions between providers, not the individual clouds themselves, so remediation should focus on replication paths, backup stores and shared automation rather than isolated scan results. Practitioners who govern those seams will have a materially better chance of keeping posture aligned with reality.

For practitioners

• Establish discovery-first multi-cloud coverage Connect cloud environments in read mode first, inventory where sensitive data actually lives, and delay enforcement until the dataset is understood.
• Normalise classification across providers Use one classification scheme for AWS, Azure, GCP, data warehouses and SaaS so the same data type receives the same governance treatment wherever it lands.
• Track lineage across data movement Trace copies, transformations and replications so security teams can see how production data becomes development data or SaaS-resident data.
• Review overpermissioned service accounts Prioritise non-human identities that can still reach replicated data after it has crossed cloud boundaries, especially automation tied to backups and analytics pipelines.
• Prioritise seam-level remediation Address exposed buckets, backup stores and cross-cloud replication paths before isolated findings inside a single cloud, because that is where control assumptions usually fail.

Key takeaways

• Multi-cloud DSPM addresses a governance gap created when sensitive data moves faster than traditional cloud security tools can track.
• The core failure is inconsistent classification, access control and lineage across AWS, Azure, GCP, SaaS and warehouses.
• Practitioners should treat cross-cloud data movement, overpermissioned service accounts and seam-level misconfiguration as the highest-priority risks.

Key terms

• Multi-Cloud DSPM: Multi-cloud DSPM is the use of data security posture management across two or more cloud providers, SaaS platforms and cloud-adjacent repositories. It gives security teams one view of sensitive data discovery, classification, access risk and remediation priorities across environments that otherwise expose different control models.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Classification Drift: Classification drift is the gradual mismatch between a system's labels and the real sensitivity of the content as files change over time. It happens when documents are edited, copied, or repurposed faster than the model or rules are updated, creating gaps between visibility and actual protection.
• Seam exposure gap: The blind spot created when two separate governance systems each inspect only part of an agent workflow. It is a structural boundary issue, not a tuning problem, and it shows up when attribution, policy enforcement, or incident review stops at the product seam.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course if your programme needs a sharper view of machine identity, IAM and secrets management.