They should prioritise DLP when the main risk is not storage compromise but disclosure during processing, prompting, or retrieval. If business users, SaaS tools, service accounts, or AI agents must see the original value, then the decisive control is what happens around the data flow, not just how strongly the data is protected at rest.
When DLP Should Beat Stronger Tokenization or Encryption
Prioritise DLP when the control problem is exposure in use, not just exposure at rest. Tokenization and encryption are strongest when you can keep sensitive values hidden from the people and systems that handle them. DLP becomes the better first control when legitimate workflows still require the original data to be viewed, copied, searched, prompted, or exported.
DLP is also the control that aligns best with modern data flows. Business users, SaaS apps, service accounts, copilots, and retrieval pipelines can all create disclosure paths even when storage is well protected. In that situation, the practical question is not only “can the data be stolen from a datastore?” but “can it leave the approved boundary in a readable form?”
For AI-enabled environments, the same logic applies to prompts, embeddings, generated output, and connector traffic. If the sensitive value must be present for the system to function, stronger cryptography alone does not prevent an authorised process from disclosing it. That is why a DLP programme often needs to sit alongside access control, content inspection, and egress governance rather than behind them.
Where Strong Cryptography Still Wins
Tokenization and encryption should remain the default when the main objective is to reduce the value of stolen storage, backups, disks, databases, or logs. They are especially strong when the application can operate on substitutes or wrapped values, because the real secret never needs to be broadly exposed during ordinary processing.
That means the right choice is often architectural, not competitive. If the workflow can be redesigned so downstream consumers do not need the original value, cryptography gives you a cleaner reduction in blast radius than DLP alone. If the workflow cannot be redesigned, DLP becomes the control that addresses the residual disclosure risk left after storage protection is already in place.
In practice, teams should avoid treating DLP and encryption as interchangeable. Encryption protects confidentiality of the asset; DLP tries to govern its movement, rendering, and sharing. When the risk is a human, SaaS, or agent seeing sensitive content in the clear, the two controls solve different problems.
Choosing the Control by Data Flow, Not by Storage
The decision point is whether the sensitive value must be visible to an active processor. If the answer is yes, then the strongest protection is usually to combine minimisation, tokenization where possible, and DLP where visibility is unavoidable. If the answer is no, keep the original value hidden and let cryptography do more of the work.
Enterprise AI Copilot Security Guide is useful here because it frames the problem around over-sharing, connectors, and agent behaviour rather than storage alone. That is the right mental model for deciding when DLP has to carry more of the burden.
For broader control planning, CIS Controls v8 reinforces the need to pair data protection with account management, audit logging, and secure configuration. ISO/IEC 27001:2022 Information Security Management is also relevant because it treats access control, authentication, and cryptography as part of a larger governance system, not as a substitute for one another.
Risk and Threat Considerations
When sensitive data must remain readable for processing, the main risk is disclosure through authorised paths. That includes users pasting values into prompts, SaaS tools rendering records, service accounts exporting data, or agents retrieving information and exposing it in output or logs. Strong encryption can leave that exposure untouched if the data has to be decrypted for use.
Failure mechanism: The control fails when confidentiality is assumed to be preserved simply because the data is encrypted at rest, while the actual disclosure happens after decryption during processing, prompt handling, retrieval, copy-out, or connector activity.
Impact: The result can be inadvertent leakage of regulated, customer, or operationally sensitive content through legitimate workflows, with a wider blast radius than a storage-only compromise because the exposure can repeat across people, tools, and automation paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | DLP, tokenization, and encryption are all data protection controls for sensitive information in use and at rest. |
| Recommendation — Prioritise data protection safeguards that match the data flow and exposure path. | ||
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Encryption and tokenization are primarily at-rest confidentiality measures for stored data. |
| SC-13 — Cryptographic Protection | Cryptographic protection underpins tokenization and encryption schemes used to reduce disclosure risk. | |
| SI-4 — System Monitoring | DLP depends on monitoring and inspection of data movement, exfiltration, and disclosure paths. | |
| Recommendation — Encrypt sensitive stored data when storage compromise is the main concern. Apply cryptographic protection where data can remain hidden from processing systems. Monitor data flows and alert on unauthorized disclosure or transfer. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptography protects stored sensitive data when disclosure is mainly a storage problem. |
| A.8.12 — Data leakage prevention | DLP directly addresses disclosure during processing, sharing, and transfer. | |
| Recommendation — Use cryptography to limit exposure where plaintext is not required. Implement leakage prevention controls on channels that can expose readable data. | ||
Practitioner Guidance
What to prioritise: Classify the data by how it is used, not only by where it is stored. If the workflow requires human-readable access, prioritise DLP for the channels that can disclose the value, then use tokenization or encryption to reduce the impact of theft from storage and backups.
What to verify: Confirm which actors, applications, and agents actually see the original value in production. If a team cannot prove where cleartext appears, it is usually overestimating the protection provided by encryption and underestimating the value of DLP.
Decision rule: If the sensitive value must be visible in order to complete the task, treat DLP as the control that governs exposure during use. If the value can be replaced, hidden, or delayed, push harder on tokenization or encryption first, because they remove more risk with less reliance on monitoring.
Practitioner takeaway: The right control is the one that reduces the most likely disclosure path, and for active data use that is usually DLP first, with cryptography used to constrain everything that does not need to be seen.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org