Forcepoint DLP Discovery — Finding & Remediating Data at Rest

① What 'data at rest' discovery is — and why it matters

Inline DLP watches data that is moving or being used right now. Discovery is the other half: it goes looking for sensitive content that is just sitting there — old project exports on a file share, customer records in a database, a PST full of contracts on a laptop. The job is three steps: scan the data at rest, classify it against your policies, and optionally enforce an action on what breaches.

Why it matters: stale, forgotten sensitive files are where breaches come from. A spreadsheet of PAN and bank details on an openly-shared folder is a quiet liability until Discovery flags it. Two components do the work: the on-prem crawler performs network discovery, and Forcepoint DLP Endpoint performs endpoint discovery — and crucially, Discovery reuses the same classifiers and fingerprints as inline DLP, so you are not re-authoring policy.

② Choosing targets — network, endpoint and cloud

There are three flavours of discovery, each with its own task wizard. Network discovery is run by the crawler and reaches file shares, SharePoint (on-prem and online), Exchange (on-prem and online), IBM Domino servers, databases (SQL Server, Oracle, etc.) and Outlook PST files. Endpoint discovery uses the DLP Endpoint agent to scan local drives on managed Windows and macOS devices — even offline, with no server connection needed. Cloud discovery scans sanctioned SaaS such as Office 365 / SharePoint Online, OneDrive and Box.

What each target needs

Each network task takes targets, credentials, file filters, classifiers and a schedule. Cloud discovery has prerequisites you must name: the Cloud Applications license, the DLP Cloud Applications service connected, and the apps defined in the Forcepoint CASB portal. You build all of these under Policy Management ▸ Discovery Policies.

③ Scheduling, file filters and incremental scans

A naive scan of a multi-terabyte share every night is a non-starter. File Filtering is how you scope a task so it only touches relevant, changed data. Filter by type (e.g. *.doc;*.xls;*.pdf, with an Except list), by size (larger or smaller than X), and by age — Within a period, More than N months old, or a From…To date range — so re-scans only re-read recently modified files.

Full-scan triggers and timestamps

On the endpoint Advanced page you also choose when a full scan fires: Only on policy update, On policy update or fingerprinting classifier update, or Always. Enable Preserve original access time so the scan does not change a file's last-accessed timestamp and mislead backup or archiving tools. For precision, Discovery can use fingerprinting: PreciseID Files fingerprints files, directories and SharePoint, while PreciseID Database fingerprints DB tables, views and CSVs — and only partial hashes are stored, never the original data.

④ Remediation — from audit to action, done safely

Finding a breach is half the job; the action plan decides what happens next. The safe default is audit only — log the incident and review it in Reporting ▸ Discovery. From there actions escalate: apply a file label (Microsoft Information Protection or Boldon James), encrypt or apply rights/DRM, copy, move/quarantine (often leaving a tombstone note), or delete.

Cloud actions and scripts

Cloud remediation offers Permit, Safe copy, Quarantine, Quarantine with note, Unshare external and Unshare all. For network and endpoint, you Run a remediation script — a Python script that receives each incident as an XML file and performs the copy/move/encrypt/delete/notify logic. Endpoints need the Python language interpreter installed to run scripts. The failure mode everyone hits is jumping straight to delete or quarantine before reviewing in audit — you destroy or hide files that turn out to be false positives.