DLP remediation: prioritising the fixes after a test

DLP remediation consists of turning the findings of a leak prevention test or audit into concrete fixes, ranked in order of urgency. Good prioritisation combines three criteria: the sensitivity of the data that was able to get out, the exposure of the channel used and the effort needed to fix it. The expected deliverable is not a report, it is a ranked list of actions that your teams can execute on Monday.

Why most DLP remediation plans fail

The problem is rarely a lack of findings. After a data exfiltration test, you often have dozens of results: an email rule that does not fire, an upload to personal storage that gets through, a DNS channel that nobody monitors. The problem is the order.

Three failings come up again and again:

• Dealing with findings in order of appearance. The first finding in the report is not the most serious. It is simply the first one tested.
• Dealing with the easy ones first. You fix the ten easy rules, show a flattering closure rate, and the channel that lets the customer file out stays open.
• Dealing with technical severity alone. A “critical” rating on a channel that never carries sensitive data mobilises the team for nothing.

Useful prioritisation takes the business context into account. It answers a single question: which fix reduces the risk of a real leak the most, for the effort available this month?

The three sorting criteria

1. Data sensitivity

The first criterion is the nature of what was able to get out during the attack scenario. A decoy imitating an HR export, health data or industrial secrets does not weigh the same as a decoy imitating a sales brochure. This criterion assumes that your classification exists and is applied: without it, the DLP does not know what to protect (see why DLP depends on data classification).

A simple scale is enough: 3 for regulated or strategic data (sensitive personal data, financial data, intellectual property), 2 for confidential internal data, 1 for everyday internal data.

2. Channel exposure

The second criterion measures how accessible and how widely used the channel is. A channel that any workstation can use without privileges (browser to a sharing service, outbound email) is more exposed than a protocol that requires administrator rights. Ask yourself three questions:

• How many users or machines can use this channel?
• Are special privileges needed to use it?
• Does the SOC see anything when the transfer takes place, even if it is not blocked?

That last point matters a great deal. A transfer that is not blocked but raises an alert is handled differently from a transfer that is completely silent. Silence is the worst case, the one described in the article on DLP false negatives.

Scale: 3 for a channel open to everyone and silent, 2 for a channel that is open but detected, or restricted but silent, 1 for a channel that is restricted and detected.

3. Remediation effort

The third criterion is effort. Changing a threshold in an existing policy takes an hour. Deploying an endpoint agent across a heterogeneous estate takes a quarter. Rate the effort from 1 (low, a rule change) to 3 (high, a project with a budget, an architecture change or change management).

The prioritisation grid

Calculate a risk score (sensitivity × exposure, from 1 to 9), then cross it with the effort. The table below gives the decision rule.

Scroll the table →

Two rules complete the grid. A finding with a risk of 9 never waits, whatever the effort: if it cannot be fixed quickly, it gets a compensating measure (temporary block, dedicated SOC alert, restriction of the group concerned). And every accepted risk is written down, dated and signed by a manager. A risk accepted verbally is not accepted, it is forgotten.

A concrete scenario: five findings, one list

Take a mid-sized industrial company (ETI) that has just replayed a series of scenarios with synthetic data. Five findings stand out.

1. A decoy of technical drawings gets out through a browser upload to personal storage, with no alert. Sensitivity 3, exposure 3, effort 1 (the URL category already exists in the proxy, it is just not blocked). Risk 9, low effort: P1, this week.
2. A decoy customer file leaves as an encrypted email attachment, the rule does not inspect it. Sensitivity 3, exposure 3, effort 2 (define how encrypted archives are handled, inform the business teams). P1, this month. For the detail of email-side tests, see Email DLP: how to test your rules.
3. An HR decoy copied to a USB stick from workstations without a DLP agent. Sensitivity 3, exposure 2 (only part of the estate), effort 3 (agent deployment). Risk 6, high effort: P2 with an interim measure, for example blocking removable storage by group policy on those workstations until the agent is in place.
4. A transfer to a generative AI service raises an alert but is not blocked. Sensitivity 2, exposure 2, effort 1. Risk 4: P2.
5. A decoy of an everyday internal document goes through an uncommon network channel, detected by the SOC. Sensitivity 1, exposure 1, effort 2. P4: monitor.

The final list fits in five lines, each with an owner, a deadline and a closure criterion. Nobody needs an 80-page report to execute it.

What each action must contain

A badly written remediation action takes you back to square one. Check that each line contains:

• the finding in one sentence, from the defender’s side (channel, type of data, behaviour observed: blocked, alerted, silent);
• the expected fix, worded as a result (“the upload is blocked and alerted”) rather than as a vague task (“review the rule”);
• a named owner, not a team;
• the deadline from the grid;
• the interim measure if the deadline is more than a month away;
• the closure criterion: which scenario to replay to prove that the fix works.

Tracking remediation over time

Prioritisation is not an annual exercise. Rules drift, applications change, a migration opens new paths. A reasonable rhythm: review the list at each series of replays, re-rank what has changed, and track two simple indicators, the number of open P1 findings and the average time between detection and proof of correction. Those two figures speak to senior management far better than a compliance score.

Frequently asked questions