The key points in 30 seconds
- A DLP metric for the board does not count alerts: it measures the share of exfiltration scenarios that are blocked when you replay them.
- 2 figures are enough: the block rate and the number of scenarios that got out undetected.
- 1 page: trend, open channels, time to fix and decisions requested.
Tuesday, 9:40 am, executive committee. The CISO has 10 minutes, squeezed between the cash position update and the hiring plan. The slide shows DLP alerts going down. The CFO asks: “So we are better protected?” The CISO hesitates, and rightly so: fewer alerts may mean fewer attempts, or a rule switched off by mistake during the last update.
Put simply, a good DLP metric for the board does not count alerts. It measures the share of exfiltration scenarios blocked, replayed at regular intervals, and how that share changes over time. A curve, a few figures and 3 decisions to make fit on one page. With this format, you talk about effectiveness rather than activity.
Why the usual DLP metrics mean nothing to the board
The DLP dashboards you show in committee probably list volumes: incidents, active rules, endpoints covered, false positive rate. These figures describe your tool. They say nothing about your protection.
Yet your executives ask a simple question: “if someone tries to get our data out, do we stop them?”. A rising number of alerts may mean that the DLP works better, that attempts are increasing or that the rules are poorly tuned. In other words, an ambiguous metric is no use for making decisions. The risk itself is anything but ambiguous: in its Annual Review 2025, the UK’s National Cyber Security Centre (NCSC) counted 204 nationally significant incidents between September 2024 and August 2025, against 89 the year before.
We covered this in detail in our article on DLP false negatives. As long as your metric relies on what the tool sees, it does not measure what it misses.
The posture metric: scenarios blocked versus scenarios that got out
So we change the source. Instead of counting what the DLP reports, we measure the outcome of known attempts. We replay a catalogue of scenarios with decoys. Each scenario ends in 1 of 3 states:
- Blocked: the synthetic file did not leave the perimeter.
- Detected, not blocked: the transmission got past the control, but an alert was observed.
- Not detected: the data was observed getting through with no alert identified.
Your main metric becomes the block rate, that is, blocked scenarios divided by valid scenarios replayed: 46 out of 50, for example, gives 92%. The second, more telling for a committee, is the number of scenarios that got out undetected. That is proof. The replay method is described in our guide to data exfiltration testing.
Three rules to keep the metric honest
- A stable catalogue. If you add 10 difficult scenarios in a quarter, the rate falls even though protection has not regressed. Version the catalogue and flag every addition on the chart.
- Weighting by sensitivity. A scenario that exfiltrates a health record does not carry the same weight as a public document. Group scenarios into at least 3 categories: critical, sensitive, internal.
- Frequent replay. An annual measurement is a snapshot. Weekly or monthly, it shows regressions (agent update, migration, new SaaS application).
What belongs on the one-page summary
A single page forces you to choose, and that is the whole point. Here is the structure we recommend, from top to bottom.
| Block | Content | Board question it answers |
|---|---|---|
| Key message | One sentence: trend and main open risk | Are things getting better? |
| Posture curve | Block rate over 6 to 12 months, by data category | Since when, and how fast? |
| Open channels | The 3 to 5 channels through which scenarios still get out | Where is the exposure? |
| Time to fix | Median time between finding and verified block | Is the team fixing things quickly? |
| Decisions requested | Budget, business trade-off, risk acceptance | What do you need from us? |
Presenting channels without exposing technical detail
Your board does not need to know how data gets out. It needs the channel family: personal cloud storage, encrypted web traffic, paste and code-sharing sites, DNS, and, for channels your team tests by other means, outbound email, collaboration tools such as Teams or Slack, or generative AI assistants. Name the channel in business terms (“upload to a personal storage account”) and leave the detail to the technical teams. This document gets passed around: it must not turn into a list of vulnerabilities.
A concrete scenario: the quarter the curve dropped
Diagram · the posture curve
With an alert-based dashboard, you would have seen nothing: the incident volume was stable. The replay shows that several scenarios going through a cloud storage service now get out undetected. Root cause: a workspace was migrated to a new tenant without carrying over the DLP policies. This is a classic case.
On that month’s board page, the CISO writes: “Regression on sensitive data linked to the cloud workspace migration, fix under way, return to the previous level expected within 3 weeks.” The following month, the curve climbs back. The committee sees a team that detects its own regressions, and that is exactly what you want from a metric.
Next step
What would the posture curve of your controls look like?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
From findings to decisions
A metric with no associated action ends up ignored. Prioritise the fix for every scenario that gets out by data sensitivity, channel exposure and the effort required, and show only the top of that list on your board page. On the Enforcis side, upcoming versions will bring contextual, prioritised recommendations, validated by retest.
Regulations push you this way too. Article 20 of NIS2 requires management bodies to approve risk management measures and oversee their implementation. Article 5 of DORA makes the management body responsible for ICT risk. Under ISO/IEC 27001:2022, management review (clause 9.3) already expects measurement results (clause 9.1). In the United States, the SEC’s 2023 cybersecurity disclosure rules require listed companies to describe how the board oversees cyber risk and to report a material incident on Form 8-K (Item 1.05), generally within four business days of determining that it is material. The same page can serve all of these.
For the presentation:
- Start with the trend, never with an isolated figure.
- Own the bad news. An explained dip is more reassuring than a curve that looks too perfect.
- Do not aim for 100% blocking. Some channels involve a business trade-off, and it is up to the board to accept that risk or not.
- To frame a budget, give an external benchmark: $4.99M average cost per breach according to the IBM Cost of a Data Breach 2026 study.
- Keep the same page every month: the comparison is where the value lies.
What to check before your next committee
- The scenario catalogue is versioned and its changes are flagged.
- Scenarios are classified into 3 data categories.
- Replay runs at least monthly, with decoys.
- The 3 states (blocked; detected, not blocked; not detected) are kept separate.
- Each open channel has an owner and a deadline.
- The page ends with an explicit request for a decision.
FAQ
Which DLP metrics are most useful for an executive committee?
The block rate of replayed exfiltration scenarios, how it changes over time, the number of scenarios that got out undetected and the time to fix. Alert and rule volumes remain useful, but for technical management.
What should you tell the board when the block rate drops?
The cause, the fix under way and the date by which you expect recovery. An explained and monitored dip shows that your team detects its own regressions. A curve that is always perfect tends to raise suspicion.
How do you calculate a DLP block rate?
Divide the blocked scenarios by the valid scenarios replayed over the period. 46 out of 50 gives 92%. To keep this figure comparable from one month to the next, version the catalogue and flag every addition on the chart: 10 difficult scenarios added in a quarter lower the rate even though you have not regressed. Also weight results across 3 categories (critical, sensitive, internal). And replay with decoys, as in our article on synthetic data in production.
Is a 100% block rate a realistic target?
Rarely. The goal is measured progress, with residual risks knowingly accepted by management.