Notifications
Clear all
Topic starter
14/08/2026 6:36 pm
TL;DR: Policy-only DLP keeps missing modern exfiltration because static rules cannot explain intent, context, or novel data movement patterns, according to Orion. Automated data loss indicator analysis shifts detection from “what happened” to “why it happened,” which is where false positives fall and meaningful coverage improves.
NHIMG editorial — based on content published by Orion: data loss indicators and the limits of policy-based DLP
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams detect data exfiltration when policy rules are too rigid?
A: They should combine policy enforcement with behavioural signals such as timing, destination, identity context, and data volume.
Q: Why do static DLP policies fail against modern exfiltration patterns?
A: Static policies fail because they describe allowed events, not the meaning of those events in context.
Q: What do security teams get wrong about DLP?
A: The common mistake is assuming DLP can fix excessive access after the fact.
Practitioner guidance
- Define behavioural exfiltration signals Use identity, destination, timing, and volume as first-class signals for DLP triage instead of relying only on content matches and static destination lists.
- Correlate DLP with IAM telemetry Join DLP events to user role, access scope, device, and location so analysts can tell whether a transfer fits the worker’s normal pattern or signals misuse.
- Add AI workflow coverage to DLP reviews Map the paths data can take through AI tools, browsers, and collaboration channels, then test whether current policies detect those movements without excessive false positives.
What's in the full article
Orion's full blog covers the operational detail this post intentionally leaves for the source:
- How ORION's six-agent model classifies data, maps lineage, and scores risk across source, destination, and identity signals.
- Examples of the data loss indicators the platform uses, including slow-drip exfiltration, role outliers, and suspicious timing patterns.
- How policy support and manual policy enhancement work alongside the automated indicator engine.
- Use-case examples for environments where data moves through AI tools, collaboration channels, and browser-based workflows.
👉 Read Orion's analysis of policy-only DLP and data loss indicators →
Data loss indicators and DLP policy gaps: what teams need to know?
Explore further
14/08/2026 6:43 pm
Policy-only DLP is now a governance debt, not a complete control model. Static rules still have value for deterministic compliance cases, but they cannot keep up with the number of destinations, transformations, and AI-assisted workflows that now shape data movement. The organisation ends up tuning alerts instead of reducing exposure. Practitioners should stop treating policy count as coverage.
A question worth separating out:
Q: Who should own risky data movement decisions when DLP and IAM overlap?
A: Ownership should be shared between security operations, IAM, and data protection teams, with clear escalation paths for exceptional transfers. IAM defines who should have access, while DLP determines whether the movement itself is normal or suspicious. Both functions need the same contextual evidence.
👉 Read our full editorial: Data loss indicators are replacing policy-only DLP controls
