Forcepoint DLP Architecture — Components, Channels & the Incident Path

① What Forcepoint DLP actually is — one policy, many channels

The single most important idea: Forcepoint DLP is one policy engine that follows your data, not one device. You write a policy once — say, a classifier for customer PII — and the same policy is enforced on email, web uploads, the endpoint, the network and in cloud apps.

Forcepoint frames coverage as three data states. Data in motion is content leaving right now over email, web or cloud. Data at rest is content sitting in file shares, databases, SharePoint, endpoints and cloud storage — found by Discovery. Data in use is action on the endpoint: copy to USB, print, clipboard, screen capture. One console, one set of classifiers, three states.

② The core components — the brain and the classifier

Two central components do the heavy lifting. The Forcepoint Security Manager (FSM) is the web console and database: it holds policies, classifiers, the incident queue, role-based admin and reporting. The Policy Engine is the classification brain — it takes content from any enforcement point, runs the classifiers (regex, dictionaries, EDM, IDM, machine learning, OCR), scores a match and returns a verdict.

Supporting roles you must name

Around those sit the crawlers (Discovery jobs that scan repositories at rest), the fingerprint repository (where EDM/IDM fingerprints live so endpoints can match offline), and system modules for clustering and load. In a larger estate you scale by adding Policy Engines, not by buying a bigger box.

③ Enforcement points — where the policy is actually applied

Enforcement points are where data is inspected and an action is taken. They all call back to the same policy: Email (inbound/outbound mail, often via MTA or the cloud email path), Web / SWG (uploads and posts through the proxy, including over HTTPS once decrypted), the Endpoint agent (USB, print, clipboard, screen capture, local app activity — i.e. data in use), the network Protector (a passive or inline appliance that monitors protocols like SMTP/HTTP/FTP for data in motion), Cloud / CASB (sanctioned SaaS and shadow IT), and the Discovery crawler for data at rest.

The interview line: the value is the shared policy, not any single sensor. A credit-card record is recognised identically whether it leaves by email, web upload or USB — because every channel asks the same Policy Engine.

④ From match to incident — and how to deploy without drowning

When the Policy Engine returns a match, it does not just 'block'. The match is scored, an incident is created in the Security Manager with the matched content, the channel, the user and a severity, then routed to a remediation workflow (notify, encrypt, quarantine, block, or release with justification). Analysts triage from the incident queue; forensics show exactly what matched.

Deploy sanely

Start enforcement points in audit/monitor mode, baseline a week, tune classifiers to EDM/IDM, then promote true positives to block or encrypt. Size by traffic and number of endpoints, add Policy Engines for throughput, and keep one source of truth in the FSM. The failure mode everyone hits is going straight to Block on a broad regex — instant false-positive storm.