Why do DLP programs fail when organisations add more cloud and SaaS tools?

Why DLP breaks as cloud and SaaS expand

Traditional DLP assumes the risky moment is a file leaving a perimeter or an email carrying sensitive content. In cloud and SaaS estates, the more common failure is identity-driven sharing: a document is copied into a workspace, accessed by an app connector, or moved through an automation path that never resembles classic exfiltration. That is why programmes built only around gateways and endpoints lose sight of the real exposure. Current guidance suggests the control plane has to follow identity, not just content.

This is visible in incidents such as the Snowflake breach and the Salesloft OAuth token breach, where access paths and tokens mattered more than simple file movement. The practical lesson aligns with the NIST Cybersecurity Framework 2.0: protect the asset, the identity, and the workflow together, not in isolation.

In the 2026 Infrastructure Identity Survey by Teleport, only 44% of organisations said they had policies to manage AI agents, even though 92% agreed governance is critical, showing how quickly controls lag behind new movement patterns. In practice, many security teams discover that DLP has failed only after a SaaS connector, not a user, has already replicated the data.

How cloud sharing, connectors, and automation evade legacy DLP

Legacy DLP is strongest when it can inspect a known path, apply a rule, and block a transfer. Cloud and SaaS break that model because the same data can be shared through native links, embedded apps, API calls, sync clients, and automation tools. The exposure often happens after the initial upload, when permissions broaden, tokens persist, and downstream services inherit access. That is why DLP must be paired with identity controls, especially Azure Key Vault privilege escalation exposure cases and secret-led access paths.

Practitioners should think in terms of control reach:

• Map where data is stored, copied, shared, and indexed across SaaS.
• Inventory service accounts, OAuth apps, API keys, and connector tokens that can move data without user interaction.
• Apply policy at the identity and workload layer, not only at the file edge.
• Use NIST Cybersecurity Framework 2.0 to connect data protection with access governance, logging, and response.

The strongest programmes also treat secrets as high-risk pathways. The BeyondTrust API key breach and DeepSeek breach show how exposed credentials and embedded secrets can turn ordinary integrations into data-loss channels. These controls tend to break down when SaaS sprawl is unmanaged because no single DLP policy can see every connector, token, and downstream copy operation.

Where the standard answer breaks down in real environments

Tighter DLP often increases friction, requiring organisations to balance stronger inspection against productivity, false positives, and shadow IT. That tradeoff is especially sharp in collaboration-heavy environments, where blocking sharing can push users toward unsanctioned tools. Best practice is evolving, and there is no universal standard for this yet, but most mature programmes now combine DLP with CASB-style discovery, least privilege, and token governance rather than relying on content rules alone.

Edge cases matter. A SaaS-to-SaaS integration may never trigger a classic DLP alert because the transfer is authorised, even though the resulting data copy is broader than intended. Similarly, automation platforms can propagate files or records at machine speed, making manual review ineffective. Organisations that assume a human user sits behind every access decision also miss the risk created by compromised credentials, as seen in the Codefinger AWS S3 ransomware attack and the 230M AWS environment compromise.

For that reason, current guidance suggests tying DLP to lifecycle controls for secrets, connectors, and service identities, then validating those controls against actual SaaS flows rather than policy intent. In cloud-first estates, DLP usually fails not because it is absent, but because it is watching the wrong boundary.

Related resources from NHI Mgmt Group

• Should organisations prioritise SaaS cleanup before expanding access controls?
• Why do compliance programs fail to stop identity-based breaches?
• How should security teams handle local accounts in cloud and SaaS apps?
• How should security teams prioritise NHI remediation in cloud environments?