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 control works. The data still left.

By the time a DLP rule fires on a customer database, the database has already been transmitted to the vendor. For most security tooling that 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 the frameworks actually require

None of these prohibit cloud DLP. All of them make deploying it a transfer decision rather than only a security decision, and one you may have to document and defend.

The practical difficulty is scope. A DLP tool inspects exactly 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.

Four questions before you sign

Ask a cloud DLP vendor where inspection happens and you will usually get a region. These four take longer to answer, and the answers vary more than you would expect.

Each answer adds a dependency you must monitor, re-verify at renewal, and explain to an auditor who is not interested in your architecture diagram.

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.

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 isolated deployments rather than merely complicating them.

What it costs you

Self-hosted DLP is not free of trade-offs. 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, and the cloud-native vendors deserve credit for that.

Constraint or preference?

Before comparing a single feature, establish which of these you actually have. Teams conflate them constantly, and only one removes options from the shortlist.

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.