Data Exfil Detection Gaps
Twelve Transfers. Eleven Gigabytes. All Below the DLP Threshold. No Alerts.
6 min read · 31 July 2026 · Security
A pharmaceutical company's clinical trials data vendor had deployed a DLP solution configured to alert on data transfer events exceeding defined thresholds , one gigabyte for outbound transfers to external destinations, five thousand files for bulk file transfers, and any transfer to known malicious IP ranges. The thresholds had been set based on operational analysis of normal data transfer patterns in the vendor's environment , the typical size of legitimate data transfers between the vendor and their customers or partners. During a sophisticated attack targeting the pharmaceutical company's clinical trial data, the attacker , who had been operating in the vendor's environment for eighteen days , began exfiltration using a deliberate fragmentation technique. Each transfer event was nine hundred and ninety megabytes , ten megabytes below the one-gigabyte threshold. Twelve transfer events over a six-hour period moved eleven point eight gigabytes of clinical trial data to an attacker-controlled cloud storage account. Each event was individually below every DLP threshold. The DLP system detected all twelve transfers. It classified none as exfiltration. The combined volume , nearly twelve gigabytes in six hours , was anomalous relative to the vendor's normal transfer patterns. The DLP system evaluated transfers individually rather than as a session aggregate. Session-level anomaly detection did not exist in the deployed configuration.
What are Data Exfiltration Detection Gaps, Really?
Data exfiltration detection gaps are the limitations in a security programme's ability to identify when data is being transferred outside the organisation by an attacker , gaps that arise from threshold calibration, detection architecture, and the specific exfiltration techniques that attackers use to circumvent configured detection. DLP solutions are the primary tool for detecting data exfiltration, but they have inherent architectural limitations that sophisticated attackers exploit: threshold-based rules that create below-threshold exfiltration windows, per-event evaluation that misses session-aggregate anomalies, and detection coverage gaps for specific exfiltration channels.
The threshold evasion technique is the most commonly exploited exfiltration detection gap. DLP thresholds are set based on what constitutes an anomalously large single transfer in the organisation's normal environment. Attackers who understand the threshold can fragment their exfiltration into events that are individually below the threshold , each event appears to be a legitimate transfer of normal size, but the aggregate over a session or time period represents a significant data exfiltration. Per-event evaluation without session aggregation cannot detect this pattern regardless of how well the per-event thresholds are calibrated.
The exfiltration channel coverage gap is the secondary detection limitation. DLP solutions monitor specific data transfer channels , typically email, web upload, USB, and specific cloud storage services. Attackers who use channels outside the DLP's monitoring scope can exfiltrate data without generating any DLP events. DNS exfiltration , encoding data in DNS queries , bypasses DLP solutions that do not monitor DNS traffic. Cloud service exfiltration through legitimate services that are not in the DLP's monitored scope, such as collaboration platforms or code repositories, may also bypass DLP detection.
- Below-threshold fragmented exfiltration , multiple small transfers aggregating to large exfiltration
- Per-event evaluation without session aggregation , DLP missing combined volume patterns
- DLP threshold calibrated for single-event anomaly but not session-level anomaly
- Exfiltration channel not in DLP scope , DNS, collaboration platforms, code repositories
- Cloud-to-cloud exfiltration bypassing endpoint-focused DLP
Why this matters
Data exfiltration detection gaps matter for TPRM because DLP is the primary evidence in post-breach investigations about whether data was actually exfiltrated and in what volume , and a DLP system that evaluated twelve transfers individually without detecting session-level exfiltration provides no evidence of a breach that an investigator or regulator needs. A vendor whose DLP correctly detected but incorrectly classified twelve transfers as below-threshold has DLP that functioned as designed and produced no breach detection , and no forensic evidence of the actual exfiltration event.
The GDPR breach risk assessment dimension is specific. HIPAA and GDPR breach notification requirements depend on establishing whether data was actually accessed or exfiltrated , the breach risk assessment requires evidence about the probability of data exposure. A vendor whose DLP did not classify the transfers as exfiltration has no direct evidence of the exfiltration in their DLP logs. The forensic reconstruction of twelve below-threshold transfers as an aggregated exfiltration event may be possible from other log sources, but the absence of DLP exfiltration classification significantly complicates the breach evidence picture.
Where most teams get this wrong
The most consistent failure is assessing DLP deployment without assessing session aggregation capability. Per-event threshold detection is the standard DLP configuration. Session aggregation , detecting when the combined volume of multiple below-threshold events is anomalous , requires specific configuration that many DLP deployments do not include.
- DLP deployment confirmed without session aggregation assessment
- Threshold calibration tested for single events but not fragmented exfiltration
- Exfiltration channel coverage not verified , which channels are monitored
- Cloud-to-cloud exfiltration detection not assessed
- DNS exfiltration detection not verified
What good looks like
Mature exfiltration detection programmes combine per-event DLP thresholds with session aggregation analytics, monitor all relevant exfiltration channels including DNS and cloud-to-cloud transfers, and conduct regular adversarial testing of the exfiltration detection with below-threshold fragmentation techniques.
- Session aggregation detection , combined volume across time window triggers alert
- Below-threshold fragmentation testing , adversarial testing of DLP with fragmented transfers
- DNS exfiltration monitoring , DNS traffic analysed for data encoding patterns
- Cloud-to-cloud exfiltration coverage , collaboration platforms and code repositories monitored
- Exfiltration channel inventory , all potential channels assessed for monitoring coverage
Tooling
DLP , Symantec DLP, Microsoft Purview, Forcepoint DLP
Modern DLP platforms provide session aggregation capabilities that detect combined transfer volumes across multiple events. For TPRM practitioners, asking whether the vendor's DLP is configured for session-level anomaly detection , not just per-event threshold detection , provides a specific aggregation capability question.
Network Traffic Analysis , Darktrace, ExtraHop
Network traffic analysis platforms detect exfiltration through behavioural anomaly detection rather than threshold rules , identifying abnormal communication patterns, unusual data volumes to new destinations, and protocol anomalies consistent with exfiltration techniques. For TPRM practitioners, asking whether network traffic analysis complements DLP for exfiltration detection provides a specific coverage enhancement question.
Governance challenges
The governance challenge with exfiltration detection is the false positive calibration problem. Session aggregation thresholds that are set too low generate alert fatigue from legitimate bulk transfers. The governance resolution is baseline calibration , establishing what constitutes anomalous session-level volume based on observed normal patterns, then applying thresholds that catch attacker fragmentation while minimising false positives for legitimate bulk transfers.
- Ask about session aggregation capability in DLP , per-event only or session-level
- Ask about below-threshold fragmentation testing , has the DLP been tested with fragmented exfiltration
- Ask about DNS exfiltration monitoring
- Ask about cloud-to-cloud exfiltration coverage
- Ask for exfiltration channel monitoring inventory
If you are a small team
Ask your highest-risk vendor one specific question about their DLP: if an attacker transferred your data in twelve separate events of nine hundred and ninety megabytes each over six hours , each event below your DLP threshold but collectively representing almost twelve gigabytes , would that activity have generated an alert? The answer reveals whether session aggregation exists in the DLP configuration. If the answer is no, the below-threshold fragmentation technique is a known exfiltration gap in their environment.
- Ask the specific scenario: twelve events below threshold, twelve gigabytes total, alert?
- If no: ask about session aggregation configuration
- Ask about DNS exfiltration monitoring
- Ask about cloud-to-cloud exfiltration coverage
What to require
Ask directly:
"Is your DLP configured for session-level aggregation , detecting when multiple below-threshold transfer events combine to exceed an anomalous volume over a time window , or does it evaluate each transfer event independently against per-event thresholds?"
Expect as evidence
- DLP session aggregation configuration confirmation
- Below-threshold fragmentation testing results
- Exfiltration channel monitoring inventory
- DNS exfiltration monitoring confirmation
A vendor who confirms DLP deployment with configured thresholds should be asked whether the configuration includes session aggregation. Per-event thresholds detect single-event exfiltration. Session aggregation detects fragmented exfiltration. Both require specific configuration. Both require specific confirmation.
How to evidence it
- DLP session aggregation configuration records
- Fragmentation technique testing records
- Exfiltration channel coverage documentation
- DNS exfiltration monitoring records
Key Takeaway
Twelve transfers. Eleven gigabytes. All below threshold. No alerts. The DLP detected every transfer and classified none as exfiltration , because each event was ten megabytes below the threshold the attacker had researched and deliberately calibrated against. The DLP was correctly deployed and correctly configured. The configuration created the gap. Session aggregation detects what per-event threshold misses: the combined volume across multiple below-threshold events that individually look normal but collectively represent an exfiltration event. Ask for the scenario answer. Configure the session aggregation. Test with the technique.
Speak to It™
The term you nodded along to, explained in ninety seconds, so you can speak to it professionally. It is how most readers find these articles.
Join the Association