Detecting Bulk Export From Systems of Record

The highest-consequence movements start with someone downloading a large extract. The logs usually already exist and nobody reads them.

Most content inspection looks at data after it has left a system. By then it is a file, stripped of the context that made it interpretable.

Watching the export itself is easier, more precise, and available in almost every organisation without buying anything.

Why this is the best signal available

The application knows what the data is. Your CRM knows the export contained 40,000 customer records. A DLP engine inspecting the resulting file has to infer it from patterns, badly.

It knows who and how much. User, timestamp, record count, filters applied. No inference required.

It happens before egress. Detection at export gives you time. Detection at the network boundary gives you a completed action.

No content inspection, no encryption problem, no privacy trade-off beyond what the application already logs.

Where to look

CRM. Export of contacts, accounts, opportunities, pipeline. The single most common target in departure cases.

HR systems. Employee data, compensation, performance records.

Finance and ERP. Customer lists, pricing, supplier terms, unreleased results.

Ticketing and support. Frequently contains customer personal data in volume and is rarely considered sensitive.

Business intelligence and reporting platforms. The most overlooked. A reporting tool with access to everything, an export button, and no monitoring is a common and unremarked exposure.

Source control. Clone and download volume.

Databases directly. Query volume and result set size for anyone with direct access.

What to alert on

Volume against the person's own baseline. Not an absolute threshold — a support agent exporting 200 records is routine, a developer exporting 200 customer records is not.

Volume against the role. Peer comparison within a job function is more meaningful here than organisation-wide.

Breadth. An export with no filters, returning everything, differs from a filtered extract for a specific task.

Timing. Outside working hours, or shortly after a resignation, changes the interpretation of identical activity.

Repetition. Several moderate exports across a fortnight can exceed one large one and stay under every threshold.

First-time export. Someone who has never used the export function using it is worth a look, particularly in a role where it is not routine.

The practical obstacle

The logs exist and are not collected.

Most applications log exports. Most organisations do not ingest those logs into anywhere they are examined. The gap is not technical capability; it is that nobody owns the task of connecting them.

Start with two systems. The CRM and whichever system holds the most sensitive category from your inventory. Ingest their audit logs, establish baselines, alert on deviation.

This is usually a week of work and it covers more real risk than a quarter spent tuning content policies.

Reducing the need for detection

Remove the export function where the business case is weak. Many people have it because it was enabled by default.

Cap export size where the platform allows it. A limit of a few hundred records covers legitimate use and eliminates bulk extraction.

Require justification for large exports, recorded at the time. This changes behaviour and produces evidence simultaneously.

Provide a sanctioned alternative. People export because they need the data somewhere else. A supported integration removes the reason.

The reporting platform problem

Worth stating separately because it is so common.

Business intelligence tools are given broad database access so they can report on everything. Their user base is wider than the underlying systems. Their export is unrestricted. And they are almost never in scope for insider risk monitoring.

If you check one thing after reading this, check who can export from your reporting platform.