DLP and cloud migration: why and how to retest your controls

A cloud migration changes the real paths that data takes: new egress points, new workstations, new identities, new SaaS services. A DLP configured for the old information system can therefore keep showing active rules while no longer seeing part of the traffic. Retesting the DLP after a migration means replaying exfiltration scenarios with synthetic data on the new architecture, to prove what is still blocked or detected.

Why a migration breaks DLP without making a sound

DLP almost never fails visibly after a migration. No alert reports that a control has gone blind. The consoles stay green, the policies show as “enabled”, and the dashboard still displays the same number of rules. The problem lies elsewhere: the rules apply to traffic that no longer exists, and the new traffic goes past them.

What actually changes, and what it breaks

Here are the most frequent breakages. None of them is exotic. All of them are easy to miss in a migration schedule focused on availability.

Scroll the table →

The last point is underestimated. A DLP that relies on classification loses its ability to decide if the metadata does not survive the transfer. The link between the two is explained in why DLP depends on data classification.

The trap of project exceptions

Every migration produces exemptions. A group excluded from the policy to unblock a synchronisation. A service account allowed to copy everything to the new storage. A rule switched to audit mode because it was blocking the cutover. Each one is justified at the time. Together, they form a passage that nobody monitors.

The change in the responsibility model

Moving to the cloud, part of the control passes to the provider, and part stays with you. The SaaS provider’s DLP is not configured on your behalf by default. The native policies (Purview, Google Workspace, CASB) have to be written, targeted and tested.

A concrete scenario: a mid-sized company moving to Microsoft 365

Take a mid-sized industrial company (ETI) that is leaving its file servers for SharePoint and OneDrive, rolling out remote working across the board and replacing its on-site proxy with direct Internet egress. Before the migration, its network DLP inspected web uploads and its email DLP blocked technical drawings sent as attachments.

After the cutover, several things changed without anyone explicitly deciding them:

• remote workstations no longer go through network inspection;
• a technical drawing can now be shared by external link from OneDrive, without ever passing through email;
• the “engineering” group was excluded from a policy during the data migration;
• the new workstations received the agent, but with a default policy.

On paper, the “technical drawings” rule still exists. In practice, only one of the four channels is still covered. Only an active test on the new environment can establish this before an incident.

The six-step revalidation plan

Revalidation must be planned as a work package of the migration project, not as a later audit. Here is the order that works.

1. Map the new egress paths. List the real egress points: direct egress from sites, mobile workstations, cloud subnets, authorised SaaS services. Compare with the pre-migration list.
2. Revisit the DLP rule inventory. For each rule, note the channel it covered and check whether that channel still exists. Orphaned rules are to be rewritten or removed.
3. Purge the project exceptions. Review every exclusion, audit mode or privileged account created during the cutover. Remove it, or assign an owner and a deadline.
4. Prepare representative synthetic data. Build decoys that look like your sensitive data (formats, patterns, labels) without containing any of it. The method is described in testing exfiltration in production with synthetic data.
5. Replay the scenarios channel by channel. Endpoint, web, email, SaaS sharing, server traffic. For each one, record three distinct results: blocked, detected without blocking, passed without a trace.
6. Prioritise and fix, then retest. Rank the gaps by data sensitivity and ease of exploitation. Fix the most serious first, then replay the same scenarios to prove the fix.

For the general testing method, independent of the migration context, refer to the guide how to test your DLP and find out whether it really blocks.

To check before declaring the migration complete

• Every identified egress point is covered by at least one tested control.
• The DLP agent is present and up to date on the new estate, with the right policy.
• External sharing and guest sharing on SaaS storage are tested with decoys.
• Outbound email rules have been replayed after the cutover.
• Outbound traffic from IaaS workloads is filtered and tested.
• No project exception remains without an owner and a date.
• The SOC actually receives the alerts generated by the tests, in the new tooling.

Why a one-off test is not enough

A cloud migration rarely ends on a clean date. Waves follow one another, new SaaS services arrive, the provider’s policies evolve. A test carried out on the day of the final cutover becomes obsolete at the next wave. Good practice is to replay the same scenarios at regular intervals and after each significant change, to track the posture over time rather than photograph it once. The choice between continuous validation, pentest and red team is discussed in this dedicated article.

To place this approach in its overall context, the reference page on data exfiltration testing presents the definition, the method and the stakes.

Frequently asked questions