Network Data Security explained: DLP at the network layer

Network Data Security is Purview's newest way to stop sensitive data reaching apps you don't control: generative AI like ChatGPT, Gemini and Claude, cloud storage like Dropbox and Google Drive, personal webmail, online forms, and social media. It inspects the traffic at the network layer, as the request leaves the device.

That placement is the whole point. Endpoint DLP watches the device (clipboard, file save, USB, print). Edge for Business DLP watches one browser. Network Data Security watches the wire, so it catches sensitive data leaving through any browser or operating system - Firefox, Chrome, Safari, a native app - not just Edge. If your users live outside Edge, this is the layer that covers them.

It reuses the classifiers you already have. The same sensitive information types and sensitivity labels that drive your other Purview policies drive this one, so you are extending existing classification to a new channel, not rebuilding it.

Network Data Security is not a standalone product you switch on. It plugs a network security tool into Purview, and there are two options:

1. Microsoft Entra Global Secure Access (GSA) - Microsoft's own secure edge, configured through GSA Content policies. Currently in preview.
2. A non-Microsoft SASE or secure browser - Zscaler, Netskope, Palo Alto, Island, Menlo and others, connected through the new Security Store inside the DLP solution. Generally available or preview depending on the partner.

The licensing splits along the same line. The GSA path needs either Microsoft 365 E7 per seat, or Purview E5 (or equivalent) plus Entra Internet Access. The SASE path needs Purview E5 plus the pay-as-you-go billing model. Either way, pay-as-you-go must be configured before you create any policy - the option to enforce on the network doesn't appear in the wizard until it is.

You configure it with one of two policy types, or both:

• A collection policy discovers and classifies traffic, so you can see what is being shared before you block anything. It works asynchronously - it is for monitoring.
• A DLP policy enforces in real time, with Audit only or Block actions.

Both work across four activities: text sent, file uploaded, text received, and file downloaded to or from a cloud or AI app. Text sent includes a raw prompt typed into ChatGPT, so this catches the leak Endpoint DLP never sees: the user who pastes a customer list straight into a chat box.

One recent change worth knowing: GSA now inspects text and prompts, not just files. Its Scan with Purview action (preview) covers both file and text content, and only the older basic content policy is limited to file types. Earlier guidance that GSA was file-only is out of date.

Coverage is broad. You can target any of the 35,000+ apps in the Defender for Cloud Apps catalogue, or an adaptive app scope like all generative AI apps that stays current as new apps appear.

Network Data Security bills on a pay-as-you-go meter called requests. A request is each network call a device or browser makes to a website or API - the responses don't count. High-traffic users generate a lot of requests, so scope your policies to the apps and people that matter rather than everything.

The one exception: while the GSA path is in preview, policies enforced through GSA don't incur charges. You still have to configure pay-as-you-go to create the policy, but you won't be billed for GSA enforcement during the preview. The SASE path is billed from day one.

A few limits to plan around:

• It is still maturing. The GSA path is in preview, and the whole solution only inspects HTTP and HTTPS traffic for now.
• B2B guests are not covered. If a guest in your tenant sends data to ChatGPT, you cannot see or block it here - the same blind spot as the browser DLP paths.
• GSA needs the client. The Global Secure Access path only protects devices that are Entra-joined or hybrid-joined and running the GSA client, with Scan with Purview set on the content policy and a matching inline web DLP policy in Purview.
• Give it time to warm up. Allow up to 24 hours for policies to reach the network tool, and up to 30 minutes for activity to show in Activity Explorer after that.

Discover before you block. Start with a collection policy so you can see what is actually being shared with unmanaged apps, then add a DLP policy to enforce once you know the shape of the traffic. Blocking blind produces false positives and erodes trust.

Let DSPM for AI do the first draft. In DSPM for AI, the recommendation Extend insights into sensitive data in AI app interactions creates a one-click default policy - DSPM for AI - Detect sensitive info shared with AI via network - that you can then tune like any collection policy. It is the fastest way to get visibility.

Plan it alongside the browser paths. Network Data Security is one of several ways to stop inline data leaks, and picking the right combination is the hard part. The Inline Web DLP Planner maps your scenarios to the right enforcement path - Edge, network, or managed app - and estimates the pay-as-you-go cost before you touch the portal.