Most organisations that own a data loss prevention (DLP) tool run it in monitor-only mode with a handful of pattern rules, generate thousands of alerts nobody reviews, and cannot say whether a single sensitive file has been stopped from leaving. Owning DLP licences is not a maturity level. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to score a DLP programme across six dimensions: governance, data discovery and classification, channel coverage, policy and enforcement, response and operations, and measurement. It is for data protection leads, CISOs and the analysts who run DLP day to day, and it is vendor-neutral. For how DLP works and how to design policies, see the Data Loss Prevention (DLP) Guide; for the wider data security picture, use the Data Security Maturity Model. This page is the DLP scoring tool.
Key takeaways
- The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately for each of the six dimensions.
- Classification sets the ceiling. A programme that cannot say which data is sensitive cannot write precise policies; most stall at Level 2 for this reason.
- Level 3 means enforcement with consent from the business: policies tested in simulation, data owners agreeing block rules, and a triage queue with service levels.
- Level 4 adds context: user and identity risk, exact data matching and fingerprinting reduce false positives so enforcement can widen without breaking work.
- Measure prevented loss and precision, not alert volume: true positive rate, blocked or coached events on top-tier data, and channel coverage show whether DLP works.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | No DLP policy or owner. Some email gateway rules catch card numbers. No data classification scheme in use. Data leaks are discovered by customers, regulators or the press. |
| 2 | Developing | A DLP tool is deployed on one or two channels, usually email and endpoint, in monitor-only mode. Detection relies on built-in patterns. Alerts go to a shared queue with no service level, and false positives are high. A classification scheme exists on paper but few documents carry labels. |
| 3 | Defined | A DLP standard names the data types in scope, owners and approved actions per tier. Classification is applied to the most sensitive repositories. Policies cover email, endpoint, cloud storage and web upload, are tested in simulation, then enforced with warnings, justification overrides and blocks for top-tier data. A triage process with service levels is in place, and HR and legal agree the investigation path. |
| 4 | Managed | Detection uses exact data matching, document fingerprinting and trained classifiers as well as patterns. Policies adapt to user and device risk. DLP events flow into the SIEM and insider risk processes. Generative AI and SaaS channels are covered. Precision and prevented-loss metrics are reported monthly. |
| 5 | Optimised | Labels are applied at creation and travel with data. Most enforcement is automatic and coached, and analysts focus on high-risk cases. Policies are tuned from metrics and incident lessons every quarter, data minimisation reduces what needs protecting, and the programme is re-scored twice a year. |
Capability dimensions
Score each dimension separately and take the lowest as the honest programme level. Coverage of one business unit or one channel scores no higher than Level 2.
| Dimension | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Governance and ownership | No owner, no policy | DLP standard with named data owners per category, approved by legal, HR and the privacy officer | DLP integrated into data governance; owners review policy outcomes quarterly |
| Discovery and classification | No scheme in use | Three or four tier scheme applied to top-tier repositories; sensitive data discovered in major stores | Labels applied automatically at creation and kept through copies; discovery continuous across stores, including SaaS and data platforms |
| Channel coverage | Email gateway rules only | Email, managed endpoints, sanctioned cloud storage and web upload | All channels including SaaS, collaboration, generative AI, APIs and unmanaged devices through access controls |
| Policy and enforcement | Monitor only, generic patterns | Policies tested in simulation; warnings and justification overrides for most tiers; blocks for top-tier data | Risk-adaptive enforcement; precise detection (exact match, fingerprints, classifiers) supports broad blocking with low friction |
| Response and operations | Alerts unread | Triage queue with service levels, written investigation path agreed with HR and legal, user coaching | Automated low-risk handling; analysts work prioritised cases enriched with identity and insider risk context |
| Measurement | None | Alert volume, false positive rate, policy coverage by channel | Prevented loss on top-tier data, precision trend, time to resolve, residual risk by business unit |
Detection methods by level
| Method | Typical level | Strength | Watch out for |
|---|---|---|---|
| Keyword and regular expression patterns | Level 2 | Quick to deploy for structured identifiers | High false positives without validation and proximity rules |
| Labels from classification | Level 3 | Precise when labelling is consistent | Unlabelled data is invisible to the rule |
| Exact data matching | Level 4 | Matches real records from a source system | The match dataset itself must be protected and refreshed |
| Document fingerprinting | Level 4 | Catches copies and derivatives of templates and key documents | Needs curated source documents |
| Trained classifiers | Level 4 to 5 | Finds unstructured categories such as contracts or source code | Requires tuning and periodic validation |
Where identity fits
DLP decisions are increasingly identity decisions. At Level 4, policies take user risk, device compliance and session context into account, so the same upload is allowed from a managed device in a normal session and blocked from an unmanaged one. Non-human identities matter too: service accounts, API integrations and AI agents move large volumes of data through channels that endpoint and email DLP never see. Inventory those flows, restrict the scopes of integration tokens, and monitor bulk exports by service identities. The NCSC's 10 Steps guidance on data security advises treating arbitrary queries over sensitive data as a privileged role and watching for attempted bulk exports. See the Insider Risk Maturity Model for the human side.
Self-assessment questions
Answer yes only if the practice is documented, covers the whole in-scope estate and has run for at least two quarters.
- Governance: Is there an approved DLP standard naming the data types in scope, their owners and the permitted actions per classification tier?
- Governance: Have HR, legal and the privacy officer agreed how DLP events are investigated and what employee monitoring is permitted?
- Classification: Is a classification scheme applied to your top-tier repositories, and can you show the share of sensitive files carrying a label?
- Coverage: Do policies cover email, managed endpoints, sanctioned cloud storage and web upload, including generative AI tools?
- Enforcement: Are new policies tested in simulation or audit mode before enforcement, and are top-tier data transfers blocked rather than only logged?
- Enforcement: Do you use exact data matching or fingerprinting for your most sensitive structured records and documents?
- Operations: Does every high-severity alert get triaged within an agreed service level, with outcomes recorded?
- Operations: Are DLP events correlated with identity and insider risk signals in the SIEM?
- Measurement: Do you report true positive rate and prevented events on top-tier data monthly?
- Improvement: Are policies reviewed and tuned at least quarterly from metrics and incident findings?
Scoring: mostly "no" is Level 1. A tool in monitor mode on one or two channels is Level 2. Yes to every governance, classification, coverage and the first enforcement and operations question is Level 3. Add precise detection, identity correlation and monthly precision reporting for Level 4. Level 5 needs labels at creation, risk-adaptive enforcement and quarterly tuning.
Moving up a level
Level 1 to Level 2
- Appoint a DLP owner and agree a three or four tier classification scheme. The Data Classification Guide covers the design.
- Map where your most sensitive data lives. The NCSC advises knowing what data you hold, where it is and which is most sensitive, and consolidating dispersed copies.
- Deploy DLP on email and managed endpoints in monitor mode to learn real data flows.
Level 2 to Level 3
- Write the DLP standard with data owners, and agree the investigation path with HR, legal and privacy. The Data Loss Prevention Policy Template is a starting point.
- Run every new policy in simulation or audit mode first. Many platforms provide this; for example Microsoft documents a simulation mode in Purview DLP in which actions are not applied, so results can be tuned before enforcement.
- Turn on user-facing policy tips and justification overrides before blocks, so staff learn the rules without lost work.
- Extend coverage to sanctioned cloud storage and web upload, including generative AI services. See the Generative AI Data Loss Prevention Guide.
- Enforce blocks for top-tier data on the highest-risk channels, then widen.
The Samsung ChatGPT source code leak shows why the generative AI channel belongs in the Level 3 scope: staff pasted proprietary code into a public chatbot within weeks of it being allowed, with no attacker involved. Enforced controls on that channel, rather than warnings alone, are the lesson.
Level 3 to Level 4
- Add exact data matching for customer, employee and payment records, and fingerprint key document templates.
- Feed DLP events into the SIEM and the insider risk process, enriched with identity and device context.
- Introduce risk-adaptive policies: stricter rules for high-risk users, unmanaged devices and leavers.
- Cover SaaS-to-SaaS integrations and service accounts that move data in bulk.
Level 4 to Level 5
- Apply labels at creation through templates, default labelling and automatic classification.
- Automate handling of low-risk events (coach and log) so analysts focus on high-risk cases.
- Reduce the protected footprint through retention and minimisation.
- Re-score twice a year and tune policies from measured precision.
Rollback: keep every policy versioned. If an enforced rule blocks legitimate business, revert it to warn or simulation mode, record why, and fix the condition before re-enabling. Small organisations: Level 3 on email, endpoint and the main cloud storage service is a realistic target; use the DLP built into the productivity suite you already license. Large organisations: fund the analyst team and data owner engagement before adding channels.
Metrics by level
| Metric | Introduced at | Why it matters |
|---|---|---|
| Channel coverage | Level 2 | Uncovered channels are open exits |
| Share of top-tier repositories classified | Level 3 | Policies are only as good as the labels |
| High-severity alerts triaged within service level | Level 3 | Shows operations are keeping up |
| True positive rate | Level 4 | Precision is what allows wider enforcement |
| Blocked or coached transfers of top-tier data | Level 4 | The closest measure of prevented loss |
| Override rate with valid justification | Level 4 to 5 | Separates real business need from policy friction |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01, PR.DS-02, PR.DS-10 | Protecting data at rest, in transit and in use |
| NIST SP 800-53 Rev. 5 | AC-4, SC-7(10), SI-4(18), MP-7 | Information flow enforcement, preventing exfiltration, analysing covert exfiltration, media use |
| CIS Controls v8.1 | Control 3 | Data protection: identify, classify, handle, retain and dispose of data |
| UK GDPR | Article 32 | Appropriate technical and organisational measures, with regular testing of their effectiveness |
Common failure patterns
- Permanent monitor mode. Policies never move to enforcement because nobody owns the decision.
- Patterns without classification. Regular expressions alone flood the queue and miss unstructured sensitive data.
- Blocking without warning. Enforcement switched on without simulation or policy tips breaks business processes and triggers blanket exceptions.
- Ignoring machine channels. APIs, integrations and service accounts move bulk data outside endpoint and email DLP.
- Monitoring without agreement. Investigations launched without HR and legal sign-off stall or create employment disputes.
Practitioner checklist
- Name a DLP owner and data owners for each top-tier data category.
- Agree a classification scheme and apply it to top-tier repositories first.
- Score all six dimensions and record the lowest as the programme level.
- Test every new policy in simulation or audit mode before enforcing.
- Use warnings and justification overrides before blocks, then block top-tier data on high-risk channels.
- Bring generative AI, SaaS and service account data flows into scope.
- Route DLP events to the SIEM with identity and device context.
- Report true positive rate and prevented transfers monthly, and re-score twice a year.
Standards and references
- NIST: SP 1800-28, Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
- NIST: Cybersecurity Framework 2.0
- NCSC: 10 Steps to Cyber Security, Data security
- ICO: A guide to data security
- CIS: Control 3, Data Protection
- Microsoft Learn: Learn about data loss prevention
Related NHI Mgmt Group resources: Data Loss Prevention (DLP) Guide · Endpoint DLP Guide · Data Security Maturity Model · DLP Buyer's Guide · Data Classification Guide