Why cloud DLP is a residency problem

Every security control asks you to trust it with something. Endpoint detection reads process behaviour. A SIEM reads your logs. Data loss prevention asks for more than either: to stop sensitive content leaving, it has to read the content first.

That requirement is unavoidable. It is what DLP is. The question worth asking is not whether inspection happens, but where.

The inspection paradox

Consider what a cloud-delivered DLP product actually does. It sits in the path of your email, your file uploads, your endpoint activity, and it evaluates the content of each against a policy. To evaluate it, it must receive it.

So a customer database that triggers a DLP rule has, by the time the rule fires, already been transmitted to the vendor. The control worked. The data still left your environment.

For most security tooling this trade is reasonable. Telemetry about a process launching is not the same as the contents of a payroll file. DLP is the one category where the thing being inspected and the thing being protected are identical.

What that means under a residency obligation

Data protection frameworks across the region converge on a similar structure: the organisation that decides how personal data is used remains accountable for it, including when a third party processes it on their behalf. Appointing a processor does not transfer the obligation.

Under the GDPR, moving personal data outside the EEA requires a lawful transfer mechanism and, since Schrems II, an assessment of whether the destination's legal environment actually permits the safeguards you have contracted for. Malaysia's PDPA, Indonesia's PDP Law and Singapore's PDPA each impose their own constraints on cross-border transfer and on the accountability of the controller.

None of these prohibit cloud DLP. They do mean that deploying it is a transfer decision, not only a security decision — and one you may have to document and defend.

The practical difficulty is scope. A DLP tool inspects the content most likely to be regulated: customer records, health data, payment details, employee files. You are not exporting a sample. You are exporting the highest-sensitivity subset of everything you hold, continuously, as a condition of the control functioning.

The subprocessor question nobody enjoys

Ask a cloud DLP vendor where inspection happens and you will usually get a region. Ask which subprocessors are involved, in which jurisdictions, and whether classification models are trained on customer content, and the answer takes longer.

These are fair questions and good vendors answer them. But each one adds a dependency you must monitor, re-verify at renewal, and explain to an auditor who is not interested in your architecture diagram.

Four worth asking before signing anything:

• In which specific jurisdictions is content inspected, not merely stored?
• Which subprocessors have access to content in transit, and under what terms?
• Is any customer content retained after a policy decision is made, and for how long?
• Is customer content used to train or improve classification models?

The answers vary more than you would expect.

What self-hosted inspection changes

When the inspection engine runs on infrastructure you control, the transfer never occurs. That is the whole of the difference, and it is structural rather than contractual.

Residency stops being a clause you rely on and becomes a property of the deployment. There is no subprocessor list for content inspection because there is no subprocessor. There is no transfer assessment for this control because there is no transfer. For an organisation that is already self-hosting its SIEM for the same reason, running DLP anywhere else is an odd exception to a settled principle.

It also makes air-gapped environments possible at all. A control that requires outbound connectivity to function cannot operate in a network that has none, which rules out cloud DLP entirely for classified and isolated deployments rather than merely complicating them.

What it costs you

Self-hosted DLP is not free of trade-offs, and pretending otherwise would be dishonest.

You operate it. Patching, capacity, tuning and upgrades are yours. Classification models improve more slowly without a vendor's aggregate visibility across thousands of customers. Coverage of third-party SaaS is genuinely harder when you are not sitting inline in the traffic path — the cloud-native vendors have a real advantage there, and they should be credited with it.

For organisations whose sensitive data lives primarily in a handful of SaaS applications and whose regulator has no objection to cross-border processing, cloud DLP is very likely the right answer. The argument here is narrower: where residency is a binding constraint, the delivery model is not a preference. It decides whether the control is usable at all.

How to evaluate this properly

Start by establishing whether you have a constraint or an inclination. They are different, and teams conflate them constantly.

A constraint looks like a regulator, a contract clause, or a customer commitment that says data of a given class must not leave a given jurisdiction. An inclination looks like a preference for control. Both are legitimate positions, but only the first removes options from the shortlist.

If you have a constraint, filter on deployment model before you look at a single feature comparison. Most of the DLP market is now SaaS, so that filter eliminates the majority of vendors immediately and saves weeks of evaluation on products you cannot deploy.

If you do not, evaluate normally — and be honest with yourself that the residency argument is not the one actually driving the decision.

Where nPro sits

nPro DLP is in development and not yet generally available, so we have deliberately left nPro out of our DLP platform comparison rather than rank a product that does not exist. The fifteen platforms in that table are compared on deployment model, channel coverage and licensing basis.

Our position on the underlying question is not new. nPro's SIEM, XDR and network monitoring engines are self-hosted for the same reason this article describes: the data stays where you put it. nPro DLP will follow the same model when it ships.