Data loss prevention best practices still leave identity gaps

At a glance

What this is: This is a compliance-focused DLP explainer that finds rule-based data controls are useful but incomplete without stronger access management and auditability.

Why it matters: It matters because practitioners have to govern data exposure through identity, not just content inspection, across service accounts, users, and emerging AI-driven access paths.

By the numbers:

• In 2021, 73% of organizations said preventing data loss and exfiltration is becoming increasingly important to them as cyberattacks become more costly and damaging than ever before.
• In 2021, 98% of businesses had one or more cloud data breaches in the previous 18 months, and 63% of those companies unintentionally exposed sensitive data during that time.
• In 2021, 83% of cloud breaches were access-related.

👉 Read StrongDM's guide to data loss prevention best practices and access control

Context

Data loss prevention is about identifying sensitive information and controlling how it moves, but the model breaks down when access paths are broader than the rules anticipated. In practice, DLP becomes an identity problem as much as a content problem, because the person, service account, or workload touching the data often determines whether controls hold.

That is why DLP sits downstream of IAM, PAM, and NHI governance rather than replacing them. When access is over-broad, poorly audited, or difficult to attribute, content controls can block some leakage but still leave the underlying identity exposure intact.

Key questions

Q: How should security teams use DLP without over-relying on it?

A: Security teams should use DLP as a containment and detection layer, not as the primary access control. The control works best when data is classified, access is already constrained, and alerts are linked back to identity governance. If DLP is carrying the burden of preventing overbroad access, the programme is already compensating for a weaker IAM baseline.

Q: Why do cloud environments make DLP harder to enforce?

A: Cloud environments make DLP harder because data moves through APIs, shared services, and delegated identities that do not fit simple perimeter rules. A file may be stored safely but exposed during retrieval or processing. That means teams need identity attribution, entitlement review, and cloud-specific policy tuning, not just network inspection.

Q: What do security teams get wrong about DLP?

A: The common mistake is assuming DLP can fix excessive access after the fact. In practice, if users, service accounts, or workloads can already reach too much data, DLP becomes a reaction layer with limited context. The better model is to shrink access first and let DLP handle the exceptions that remain.

Q: How do teams know if DLP is actually working?

A: DLP is working when sensitive-data alerts decline without a spike in user workarounds or policy exceptions. Teams should measure how often DLP blocks legitimate collaboration, how quickly alerts are triaged, and whether entitlement reviews show reduced data reach for high-risk identities. A stable control should lower exposure without pushing behaviour underground.

Technical breakdown

How DLP content matching and contextual analysis work

DLP systems typically combine pattern matching, such as detecting credit card numbers or classified files, with contextual analysis that interprets where data is moving and who is using it. That lets the tool decide whether a transfer is normal, suspicious, or out of policy. The model is useful, but it depends on predefined rules and accurate classification. If the policy misses a data type, an application path, or a delegated identity, the control does not see the risk. That is why DLP is strongest when paired with identity-aware access enforcement rather than used as a standalone shield.

Practical implication: map DLP rules to the identities and systems that actually touch sensitive data, not just to file patterns.

Why data in motion, in use, and at rest each need different controls

DLP is usually deployed across three states of data: in motion, in use, and at rest. Data in motion can be intercepted on the network, data at rest can be scanned in storage, and data in use depends heavily on endpoint and application context. These states behave differently, which is why one policy rarely covers them all. Access-related cloud breaches are especially difficult because data may be legitimate at the point of storage but exposed during retrieval, sharing, or delegated use. The governance lesson is that visibility and authorization have to follow the data lifecycle, not sit in separate silos.

Practical implication: validate that each data state has a separate control point, then test the handoff between them.

Why rule-based DLP breaks under modern collaboration and cloud access

Rule-based DLP depends on the team predicting the risky action in advance, which is hard in multi-cloud, BYOD, partner-sharing, and remote-work environments. False positives and blocked workflows often push users toward workarounds, while unexpected exfiltration paths remain outside the policy model. Cloud DLP can flag abnormal transfers, but it still inherits the limits of the underlying access model. In other words, the closer work gets to distributed, delegated, and machine-assisted access, the less confidence teams should place in content rules alone.

Practical implication: treat DLP as a detection and containment layer, then remove excess access that forces exceptions and workarounds.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DLP is a containment layer, not an identity control plane. Rule-based inspection can slow data movement, but it does not answer the question of whether the right identity should have touched the data at all. When access is delegated through service accounts, shared credentials, or opaque cloud permissions, content policy becomes a late-stage check rather than a governance boundary. Practitioners should treat DLP as downstream of identity decisions, not a substitute for them.

Cloud data protection fails first at access attribution. The article’s own figures show that cloud breaches were overwhelmingly access-related, which is a governance signal, not just a technology one. When teams cannot reliably link data use to a specific human, NHI, or workload identity, they lose the ability to enforce accountability or prove control effectiveness. The implication is that access observability has to be designed into the programme, not bolted on after a leak.

Identity blast radius is the more durable risk metric than data movement volume. DLP can count blocked transfers, but that misses the deeper issue of how much data any single identity can reach if policy fails or is bypassed. The real exposure sits in entitlement scope, delegation depth, and over-permissioned access paths. For IAM and NHI programmes, the priority is reducing the amount of data any one identity can legitimately see.

Access reviews only matter when they are anchored to live data paths. Auditing access is useful, but recurring reviews lose value if they do not reflect how data is actually shared, copied, or processed across cloud services and endpoints. The control failure is not the absence of review alone, but the mismatch between review artefacts and operational reality. Practitioners should expect DLP to expose this mismatch, not solve it.

Data loss prevention exposes where identity governance is lagging behind collaboration. Workarounds, false positives, and cross-system exceptions all indicate that policy is compensating for access design weaknesses. That means the programme question is not whether DLP exists, but whether identity controls are narrow enough that DLP is only catching edge cases. Security teams should use DLP signals to re-baseline entitlement scope across human and non-human access.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Our research also shows that enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a broader governance lens, see Ultimate Guide to NHIs , Key Challenges and Risks for how visibility gaps and over-privilege amplify exposure.

What this signals

Identity blast radius is the metric DLP programmes should watch next: when teams only measure blocked transfers, they miss how much data each identity can legitimately reach before policy engages. That is where entitlement scope, delegation depth, and service-account access become the real control variables, especially in cloud and multi-party workflows.

The DLP conversation is shifting from content inspection to governance evidence. Practitioners should expect access review findings, entitlement drift, and exception rates to matter more than raw alert volume, because those signals show whether the security model is aligned with how work is actually done.

Teams that want better outcomes should connect DLP telemetry to identity tooling and incident workflows, then use that feedback to narrow access paths. The result is not perfect prevention, but a smaller and more defensible exposure surface across human and non-human access.

For practitioners

• Classify sensitive data before writing DLP rules Build your DLP policy set from a current inventory of regulated, confidential, and operationally sensitive data, then map each class to the systems and identities that can touch it. If you cannot name the data owner and the access path, the rule will be brittle.
• Tie DLP to identity-aware access controls Use RBAC, ABAC, and PAM controls to limit who can reach sensitive data before DLP has to inspect it. Where service accounts or workloads access protected data, treat those identities as first-class subjects in access policy.
• Review cloud access paths for access-related exposure Focus reviews on the transfer points where cloud data leaves its intended boundary, especially delegated sharing, API-driven retrieval, and partner access. Reconcile DLP alerts with entitlement data so you can see whether the exposure came from excess privilege or policy gaps.
• Reduce the workarounds that defeat DLP Track repeated false positives, blocked collaboration flows, and policy exceptions as programme health signals. If users are bypassing controls to work, your access model is misaligned with how work actually happens.

Key takeaways

• DLP reduces exposure, but it does not replace identity governance or access control.
• Cloud and delegated access make rule-based data protection weaker because the real risk sits in who can reach the data, not only in how it moves.
• Practitioners should shrink entitlement scope first, then use DLP to catch the exceptions that remain.

Key terms

• Data Loss Prevention: Data loss prevention is a set of policies and controls that detect, block, or warn on sensitive data moving in ways the organisation does not allow. It works through classification, rule matching, and context-aware monitoring across endpoints, networks, cloud services, and email channels.
• Data In Use: Data in use is information being actively accessed, processed, or modified by a user, application, or workload. It is the hardest state to govern because policy must follow live identity behaviour, not just storage location or network transit.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or workflows an identity can legitimately reach before a control intervenes. In NHI and access governance, it is a practical measure of entitlement scope and a better risk indicator than raw account counts.
• Access Attribution: Access attribution is the ability to link a data action to a specific human, service account, workload, or agent. It is essential for auditing, investigations, and policy enforcement because controls lose precision when the acting identity cannot be reliably identified.

Deepen your knowledge

Data loss prevention best practices and identity-aware access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning DLP with service accounts, workloads, or privileged access, it is worth exploring.

This post draws on content published by StrongDM: What Is Data Loss Prevention? Best Practices. Read the original.