Forcepoint DLP Channels — One Policy Across Every Exit Point

① One policy, many doors — why fragmented DLP fails

The core idea: Forcepoint DLP is one shared policy enforced across many channels, not a separate product per exit point. You write a rule once in the Forcepoint Security Manager — say, a classifier for customer PAN and Aadhaar data — and tick the channels it should enforce: email, web, endpoint, network, cloud.

Why does fragmented, per-product DLP fail? Because each tool drifts. A rule tightened on email never reaches the web proxy; a classifier tuned on the endpoint is stale on the network. Forcepoint compiles one policy and pushes it to every channel, so the same content classifiers (keywords, regex, fingerprinting, machine learning, OCR) and the same incident workflow apply no matter where data tries to leave. One console, one rule set, consistent coverage of the three data states.

② The channels explained — how each exit point plugs in

Each channel is an enforcement point that calls back to the same policy, but each plugs in differently. Email inspects outbound, inbound and internal mail — the network Protector can run as a Mail Transfer Agent (MTA) to block, quarantine or encrypt, or integrate with Forcepoint Email Security. Web / SWG enforces over HTTP/HTTPS/FTP through ICAP to a secure web gateway proxy. The Endpoint agent controls USB, copy/paste, print, screen capture and uploads — even off the corporate network.

The network, cloud and storage channels

The network Protector sits on a SPAN/mirror port or TAP and analyses SMTP, HTTP/S and FTP for data in motion (monitor; it needs ICAP to block web). Cloud / CASB via Forcepoint ONE extends the same policies to SaaS such as Microsoft 365, Salesforce and Box — using the DLP Cloud API (near-real-time, post-event scans of uploads, downloads and shares) or the DLP Cloud Proxy (inline, real-time). Discovery crawls stored data at rest on file shares, SharePoint, databases and endpoints.

③ Mapping channels to data states — and spotting the gaps

The interview-grade move is mapping each channel to the three data states. Data in motion (leaving now): email, web/SWG, the network Protector and the cloud proxy/API. Data at rest (stored): Discovery — both the network crawler and endpoint discovery — plus the CASB API scanning SaaS storage. Data in use (acted on at the device): only the endpoint agent — USB, print, copy/paste and screen capture.

Mapping this way exposes gaps. If you only deploy the Protector, you see data in motion on the wire but you cannot stop a USB copy (that needs the endpoint agent) or find a file sitting in a share (that needs Discovery). If you skip the endpoint, 'data in use' is wide open. The value is the shared policy, but the coverage depends on enabling the right channels for each state.

④ Deploying without gaps or overlap — monitor, block, tune

Deployment is a console workflow. In the Security Manager you open the rule under DATA ▸ Policy Management ▸ Manage DLP Policies and, on the Destination tab, pick exactly which channels enforce it. A classic mistake is enabling the action on the endpoint but leaving the web or email destination unchecked — so the same data leaks by webmail while USB is blocked.

Choose monitor vs block per channel

Start each channel in monitor/audit mode, baseline a week, tune broad classifiers down to fingerprinting (EDM/IDM), then promote true positives to block, quarantine or encrypt. Avoid overlap — don't double-handle the same mail on both the Protector MTA and an Email Security gateway. Confirm the plumbing each channel needs: an ICAP proxy for web blocking, MTA mode for mail blocking, a SPAN/TAP feed for the Protector. Then verify in Reporting ▸ Incidents that each channel raises the incidents you expect.