Cloud and SaaS Data Movement

Most data movement in a modern organisation happens between cloud services, and most DLP programmes were designed for a perimeter that no longer carries the traffic.

The blind spot

A file shared from your corporate cloud storage to an external address never crosses your network. There is no packet to inspect, no endpoint operation to observe. It happens entirely between the user's browser and the provider.

The same is true of a document made public by link, a folder shared with a personal account, or data exported from one SaaS platform directly into another.

Network DLP sees none of it. Endpoint DLP sees the browser session and not the action inside it.

What actually gives visibility

API-based inspection of the platforms themselves. Connecting to the provider's API to enumerate files, permissions and sharing state, and to watch the audit log. This is the only route that sees what is actually happening.

The platform's own audit logs. Frequently already available and rarely examined. Who shared what with whom, when, and whether the link is public. For most organisations this is the highest-value untapped source in the entire programme.

Cloud access security tooling, which sits between users and services and applies policy at that layer.

What to look for

External sharing. Any file shared outside the organisation. Volume alone is a starting point; sharing of files from sensitive locations is the useful version.

Public links. A link accessible to anyone with the URL, with no expiry. These accumulate silently over years, and most organisations have thousands they are unaware of.

Personal account access. Corporate documents opened by, or shared with, a consumer account.

Bulk download. Someone syncing or downloading an entire repository. Visible in the platform's audit log and rarely alerted on.

Ownership on departure. Files owned by a leaver, particularly shared ones. When the account is deleted, either the files vanish or the sharing persists without an owner — both are problems.

Third-party app grants. A user authorising an external application to access their corporate mailbox or drive. This is a genuine and underwatched exfiltration path, and it looks like nothing at the network layer.

Shadow IT

The services nobody sanctioned but people use: a project team on an unapproved collaboration tool, a designer on a personal file service, a department that bought a SaaS product on a card.

Discovery first. Network logs and expense data both reveal this. Most organisations find several dozen services they did not know about.

Then triage. Some are harmless, some hold customer data. Rank by what they contain, not by policy violation.

Then provide an alternative. Blocking a service people rely on without a sanctioned replacement moves the activity somewhere less visible. The usual reason for shadow IT is that the approved tool is inadequate, and that is worth knowing.

Configuration is a control

A substantial share of cloud data exposure is not exfiltration at all. It is a storage bucket set to public, a shared folder inherited by a departed contractor, a default sharing setting that permits anyone with a link.

Periodic review of sharing state finds more real exposure than most detection rules. Run it quarterly against the sensitive categories in your inventory.

Restrict default sharing. Changing the default from "anyone with the link" to "specific people" prevents more incidents than any alert.

The practical priority

If a programme has capacity for one new thing, ingesting the audit logs from the main cloud platforms and reviewing external sharing is usually the highest return available.

It requires no agent, no inspection, no privacy trade-off beyond what the platform already records, and it covers the route where the volume actually is.