Data Loss Prevention

Protecting information where it is actually used: what exists, where it lives, who can reach it and what should happen when someone tries to take it out.

When it makes sense

When the worry is what goes out

A DLP strategy doesn't start in the admin console. It starts by answering a handful of uncomfortable questions about what information you hold and how it moves, and in many organisations that part hasn't been done.

Once those decisions are made, the technology executes a strategy defined beforehand. The other way round you end up with a pile of rules nobody dares switch to block mode, because nobody knows who they will land on.

Information leaves and nobody notices

There is no way to know what has been shared outside, with whom or through which channel. The first anyone hears of it is after the fact.

A client is asking for it

A contract, a security questionnaire or an external assessment asks about data loss controls and there is nothing in place.

There are rules and they don't apply

Someone configured DLP policies at some point, they have been in alert mode ever since, and nobody dares turn them on properly.

What's included

The decisions before the tool

This is the work that separates a rollout which lasts from one that gets switched off within three months.

What information and where

The inventory that almost never exists and without which nothing can be protected.

  • What information the organisation holds
  • Where each type lives
  • How it is classified today
  • Which information needs the most protection

Who and how

The map of access and movement, which is where the surprises turn up.

  • Who has access to each kind of information
  • How it is shared inside and outside
  • Which channels it moves through
  • Which behaviours have to be controlled

Implementation

Taking it to the platform, normally Microsoft Purview.

  • Design of the policies
  • Rollout in phases, alert mode first
  • Tuning against the real false positives
  • Moving to block mode whatever warrants it
How I work

How it is rolled out without breaking the business

The risk of a badly planned DLP isn't that it fails to protect: it is that it stops people working and ends up switched off.

  1. Discovery

    What information exists, where it lives and how it circulates today. What actually happens gets looked at, not what the procedure says.

  2. Criteria

    What gets protected, at what level and what happens when someone tries to take it out. These decisions are made with the business, not only with IT.

  3. Alert

    Policies deployed without blocking anything, to measure the real noise and tune before anyone is left unable to work.

  4. Block

    Moving to block mode whatever warrants it, in phases, with a clear procedure for legitimate exceptions.

What you get

What stays built and documented

A DLP stays alive: the exceptions and the reasoning matter as much as the rules.

  • Inventory of the information and its classification
  • Protection criteria by type of information
  • Policies designed and deployed
  • Record of the tuning done in the alert phase
  • Procedure for handling exceptions
  • Operating documentation for your team

Scope of the serviceThe project ends with the policies tuned, the exception procedure defined and your team operating them with the documentation to do so; day-to-day watching of the alerts stays on your side. It builds on data protection compliance and helps sustain it, but it is an information security project rather than a GDPR programme.

Frequently asked questions

What people usually ask before engaging

Is this just configuring Microsoft Purview?

Purview is the usual platform because it tends to be in the licence already, but configuration is the last phase and not the first. What takes the work is deciding which information matters, who should reach it and what happens when someone tries to take it out. A tool doesn't make those decisions.

Will it stop people working?

Not if it is rolled out in phases. Everything goes in first in alert mode, blocking nothing, long enough to see the real noise and tune. Only what warrants it moves to block, and with a procedure for legitimate exceptions, which do exist.

Do we need to classify everything first?

No, and waiting until everything is classified is the surest way never to start. You begin with whatever would hurt most to lose —what a client would ask for, what would sink a contract— and widen from there. Full classification is a consequence of the project, not a prerequisite.

Which licence do I need?

It depends on your plan. You can check it in the Purview licensing simulator before we even speak. There is a fair amount of DLP available in mid-tier plans; the finer capabilities do require higher ones, and it is worth knowing which before deciding.

Does it cover a USB stick or WhatsApp?

It depends on the channel and on what your licence and your device estate cover. Some of it is controlled technically and some isn't, and that boundary is worth knowing from the start rather than discovering later. Whatever the tool doesn't cover gets worked on through training and culture.

How to assess your environment

To connect these controls with identities, applications, data and exceptions, read the Microsoft 365 security assessment guide. It explains which evidence to review and how to prioritise improvements.

Where to go next

Let's talk

Could you say today what information you hold and where it is?

If the answer is "more or less", that is exactly the starting point. Tell me what you are worried about going out and which channels you work through, and we will see whether what you need is a DLP project or something simpler.

I reply personally within 24 working hours · No commitment