Data Exfiltration Scoping: What Was Taken and How Much

After a breach, the hardest question is rarely how the attacker got in: it is what data left, how much of it, and whose it was. Regulators, customers, insurers and the board all need that answer, usually before the evidence is complete, and an answer that is too broad causes needless notifications while one that is too narrow has to be corrected in public. This guide sets out an analytical method for scoping data exfiltration: building the access window, reconstructing what was touched from audit and flow logs, estimating volume, mapping objects to data subjects, and stating the result with honest confidence levels. It is written for DFIR analysts, incident leads and data protection officers. The response steps (containment, eradication, roles) are in the Data Exfiltration Playbook; this page is the analysis that feeds it.

Key takeaways

Scope in three layers. Separate data the attacker could reach, data the attacker accessed, and data that demonstrably left; each layer needs different evidence and supports different statements.
Byte counts bound the answer, they do not define it. Egress volume from flow logs gives an upper limit; object-level audit logs say which records; the two must agree on time and identity before you rely on either.
Know each log's blind spots before you start. Mailbox sync events cover a whole folder, flow logs carry no payload, some database access history lags by hours, and retention may already have expired.
Map objects to people, not just files. Notification decisions turn on the number and categories of data subjects and records, so the scoping output is a deduplicated count of people per data category.
State confidence and update in phases. UK GDPR, as the ICO explains, allows information to be provided in phases; give a bounded estimate with its basis, then refine it rather than waiting for certainty.

The three-layer scoping model

Most scoping errors come from mixing up what an attacker could reach with what they took. Keep three layers distinct throughout the investigation and in every written statement.

Layer	Question	Primary evidence	Typical statement
1. Exposed	What could the compromised identity or host reach?	Effective permissions of every identity the attacker held (users, service accounts, roles, OAuth grants, API keys), network reachability, share and bucket policies	"The attacker had read access to 14 databases and 3 storage buckets."
2. Accessed	What did the attacker actually read, query or download?	Object-level audit logs: storage data events, database access and query history, SaaS and mailbox audit events, file server auditing, EDR file events	"Queries returned rows from 4 tables; 2,310 objects were read."
3. Exfiltrated	What demonstrably left the environment?	Egress flow and proxy logs, cloud transfer and sharing events, staging artefacts (archives, temporary stages), attacker leak-site samples, third-party notifications	"Between 41 and 47 GB left to one external address; the content matches the 4 tables."

When layer 2 evidence is missing, layer 1 becomes the defensible scope for notification. That is why logging gaps translate directly into larger notifications, and why the Forensic Readiness Guide matters before an incident.

Step 1: fix the access window and the identities

Set the window wide: start from the earliest credible indicator (first anomalous sign-in, first use of a stolen key, first malicious process) and end at confirmed containment, including revocation of every token and key, not just the password reset. Widen, never narrow, when new indicators appear.
List every identity used: human accounts, service accounts, workload roles, API keys, OAuth applications and session tokens. Attackers often move from a user to a non-human identity with broader data access, and that identity's activity is part of scope. See the Data Exfiltration Guide for how identity and exfiltration connect.
Separate attacker activity from legitimate use: on shared identities, use session identifiers, source IP addresses, client strings and user agents. Microsoft documents SessionId in mailbox audit records for exactly this purpose.
Check retention immediately: for each log source, note the oldest record available and whether it covers the window start. Export and hash what exists before rolling retention removes it (NIST CSF 2.0 RS.AN-07: incident data and metadata are collected and their integrity and provenance preserved).

Step 2: reconstruct access from audit evidence

Object-level evidence differs by platform. The table lists common sources and the fields that matter for scoping, with their known limits.

Source	Scoping fields	What it proves	Limits to state
Amazon S3 server access logs	`Requester`, `Remote IP`, `Operation` (for example `REST.GET.OBJECT`), `Key`, `HTTP status`, `Bytes Sent`, `Object Size`	Which objects were read, by whom, and whether the full object was returned (compare Bytes Sent with Object Size)	Remote IP may be a proxy; requests whose bucket cannot be determined do not appear; logging must have been enabled before the incident
AWS CloudTrail S3 data events	Event name, principal, bucket and key, source IP	API-level object reads tied to an IAM principal	Data events are not recorded unless configured; see the AWS CloudTrail Guide
Exchange Online `MailItemsAccessed`	`MailAccessType` (Bind or Sync), `InternetMessageId`, `ClientIPAddress`, `ClientInfoString`, `SessionId`, `OperationCount`	Bind: individual messages accessed. Sync: a whole folder downloaded	Sync is folder level, so all items in the folder are treated as compromised; binds in a 2-minute interval are aggregated
Snowflake `ACCESS_HISTORY` and query history	`direct_objects_accessed`, `base_objects_accessed`, `query_id`, `user_name`, `query_start_time`	Tables and columns each query touched, including through views	Up to 3 hours latency, 365 days retention, Enterprise Edition or higher
Microsoft 365 unified audit log (SharePoint, OneDrive)	File access and download operations, user, client IP, object URL	Files downloaded or synced by the attacker's session	Retention depends on licence and policy; check before relying on it
Windows file servers	Object access auditing (event 4663) where enabled, EDR file-read telemetry	Files opened by the attacker's process or account	Often not enabled on data shares; EDR may sample
SaaS applications (CRM, ticketing, code hosting)	Export, report, bulk API and search events; OAuth application identity	Bulk exports and API pulls, often by an integration identity	Audit depth varies by plan; API reads may log per request, not per record

Mailbox scoping method: Microsoft's documented approach is to identify the mailboxes and window, check for sync activity in the attacker's context (same ClientIPAddress and protocol in ClientInfoString), and if any sync matches, treat the whole mailbox as compromised; otherwise use bind records and InternetMessageId to list individual messages. See the Microsoft 365 Tenant Compromise Playbook for the surrounding response.
Database scoping method: pull every query in the window for the attacker's sessions, resolve each to the base tables and columns read, and record rows returned where the platform logs it. In the Snowflake customer breaches, attackers used legitimate client tools to list tables, create temporary stages and copy whole tables out, so stage creation and bulk copy operations were the key scoping evidence. The Snowflake Account Compromise Playbook covers the platform steps.
Collection and staging: archives, temporary stages and unusual large files created in the window (ATT&CK T1074 Data Staged, T1560 Archive Collected Data) are often the best evidence of intent and content. Recover and inventory them before deletion.

Step 3: estimate the volume that left

Volume evidence bounds the scope. It rarely tells you which records left, but it can rule claims in or out: if the attacker claims 2 TB and egress logs show 40 GB, either the claim is false or there is a channel you have not found.

Evidence	What it measures	Use	Caveat
AWS VPC flow logs	`srcaddr`, `dstaddr`, `dstport`, `packets`, `bytes`, `start`, `end`, `action` per aggregation interval (default up to 10 minutes)	Outbound bytes per source and destination over the window	Metadata only, no payload; bytes include protocol overhead and compression changes size
Firewall, proxy and secure web gateway logs	Bytes out per session, destination domain, upload method	Uploads to web services and cloud storage (T1567, T1567.002)	TLS without inspection hides the object; shared destinations such as major cloud storage domains are noisy
Storage and SaaS audit logs	Bytes sent per object request	Sum of object sizes actually returned	Reads are not proof of egress if the reader was an internal staging host
Cloud sharing and copy events	Snapshot sharing, cross-account copies, replication changes	Data moved to an attacker-controlled account without network egress (T1537)	Volume equals the shared resource size; check whether the share was used
EDR network telemetry	Per-process connections and bytes	Ties egress to a tool such as a file-sync utility	Sampling and retention vary; see Detecting Rclone and File-Sync Exfiltration Tooling

Baseline subtraction: compare the window with the same hours in previous weeks for the same hosts. The excess, not the total, is the candidate exfiltration volume.
Compression and encryption: archived text often compresses several times over, so egress bytes can understate the source data volume. State the ratio you assumed, or test it by compressing a sample of the same data set.
Chunking: attackers may split transfers to stay under alert thresholds (T1030 Data Transfer Size Limits) or automate them (T1020 Automated Exfiltration). Sum across all sessions to the same destination.
Reconcile: the volume of objects accessed (Step 2) should be close to or above the egress volume after allowing for compression. A large gap in either direction means a missing channel or a missing log.

Step 4: map objects to data subjects and categories

Notification decisions depend on people and data categories, not gigabytes. Under UK GDPR, the ICO says a report should include, where possible, the approximate number of individuals and personal data records concerned and their categories.

Classify every accessed object: use existing labels and data catalogue entries first; scan objects without labels with the same classifiers used by DLP. See the Data Classification Guide.
Extract identifiers: for structured data, query the same tables and columns the attacker read, limited to the rows returned where logged. For unstructured data, run entity extraction for names, email addresses, national identifiers, payment card and health data.
Deduplicate people across sources: the same customer appears in the CRM export, the email archive and a spreadsheet. Count unique individuals by a stable key, and record how many records exist per person.
Segment by jurisdiction and category: residency drives which laws apply; special categories (health, biometric), financial data, credentials and children's data raise risk. The Breach Notification Laws by Country Guide covers thresholds.
Record credentials and secrets separately: passwords, API keys and tokens in stolen data are both a notification issue and an active threat. Treat every secret found in scope as exposed and rotate it.
Quality check a sample: manually review a random sample of classified objects to estimate the false positive and false negative rate, and adjust the counts with stated error bounds.

Step 5: state the result with confidence levels

Scoping conclusions are estimates. Write them so each figure carries its basis and confidence, and so later updates are refinements rather than reversals.

Confidence	Basis	Example wording
Confirmed	Object-level access logs and egress evidence agree, or the data has been published by the attacker	"Records of 82,400 customers were taken."
Likely	Object-level access logged, egress volume consistent but not object-specific	"Records of up to 82,400 customers were accessed and are likely to have been taken."
Possible	Access within the attacker's reach, but no object-level logging for the period	"Data relating to up to 310,000 customers was accessible and we cannot rule out access."
Ruled out	Complete logging for the window shows no access, or the data was outside every identity's reach	"Payment card data was not accessible to the compromised accounts."

Phased updates: the ICO notes that UK GDPR allows required information to be provided in phases where a full investigation is not possible within 72 hours of becoming aware, as long as there is no undue delay. Notify on time with the "possible" figure and its basis, then update.
Keep a scoping register: one row per data set with layer reached, evidence, confidence, record count, subject count and categories. It becomes the source for regulator updates, customer letters and the breach record that UK GDPR requires for every breach, notified or not.
Peer review: have a second analyst re-run the key queries before figures go to regulators or the board (NIST CSF 2.0 RS.AN-03, RS.MA-02).

Choosing the scoping depth

Small incident, good logging: object-level reconstruction of every access is feasible within days. Aim for "confirmed" on every data set.
Large estate or long dwell time: prioritise data sets by sensitivity and by evidence of bulk access, and accept "possible" for low-sensitivity sets, documented in the register.
Logs missing or expired: scope by reachability (layer 1) and say so. Do not infer absence of access from absence of logs.
Extortion with samples: attacker samples confirm specific data sets but not the full volume; use them to anchor which sources were taken, and the volume evidence to bound how much.
Third-party or SaaS breach: the provider holds much of the evidence. Request object-level logs for your tenant in writing and record what was and was not provided.

Detection and measurement

Scoping quality depends on telemetry that has to exist before the incident. Measure readiness with these indicators:

Object-level logging coverage: share of data stores holding confidential or personal data with object-level read auditing enabled and retained for at least the organisation's assumed dwell time.
Egress visibility: share of outbound paths (internet gateways, proxies, cloud egress) producing flow or session logs with byte counts.
Time to first bounded estimate: hours from incident declaration to the first scoping register entry with a "possible" figure; test it in exercises.
Revision rate: how far later updates moved the subject count. Large upward revisions point to missing evidence sources.
Classification coverage: share of sensitive data stores with labels or catalogue entries, which decides how fast Step 4 runs.

Retention periods for the logs above are set out in the Log Retention Requirements Map.

Common failure patterns

Treating no logs as no access: if object-level logging was off, the scope is what the identity could reach, not zero.
Scoping one identity: attackers pivot to service accounts, API keys and OAuth applications with wider data access; their activity is in scope too.
Counting files instead of people: a regulator asks how many individuals; a count of 12,000 files does not answer it and duplicates inflate any naive conversion.
Ignoring mailbox sync semantics: treating a Sync event as one message, rather than the whole folder, understates scope.
Using egress totals as the answer: bytes out include protocol overhead and normal traffic; without baseline subtraction and object reconciliation they mislead in both directions.
Waiting for certainty before notifying: regulators expect timely phased information; a late but precise report can still breach the 72-hour expectation.

Framework mapping

Framework	Reference	Where it applies
NIST CSF 2.0	RS.AN-03 Analysis to establish what has taken place and the root cause	Steps 2 to 5
NIST CSF 2.0	RS.AN-07 Incident data and metadata collected, integrity and provenance preserved	Step 1 evidence preservation
NIST CSF 2.0	RS.MA-02 Incident reports are triaged and validated	Peer review of figures
NIST SP 800-53 Rev. 5	IR-4 Incident Handling; AU-6 Audit Record Review, Analysis, and Reporting	Log analysis and reconstruction
MITRE ATT&CK	T1074 Data Staged, T1560 Archive Collected Data, T1530 Data from Cloud Storage, T1213 Data from Information Repositories, T1114.002 Remote Email Collection	Collection evidence (layer 2)
MITRE ATT&CK	T1041, T1048, T1567.002, T1537, T1020, T1030	Egress evidence (layer 3)
UK GDPR (ICO guidance)	72-hour notification, approximate numbers of individuals and records, phased information, breach record	Step 5 statements

NIST SP 800-61 Rev. 3 (April 2025) frames incident response as part of CSF 2.0 risk management and is the reference for how scoping fits into the wider response.

Practitioner checklist

Open a scoping register at incident declaration with one row per data set and the three layers.
Fix the access window from the earliest indicator to full token and key revocation.
List every identity the attacker used, including service accounts, roles, API keys and OAuth grants.
Record the oldest available record for each log source and export and hash logs before retention expires.
Reconstruct object-level access per platform, applying each log's documented semantics (for example mailbox Sync covers a folder).
Bound egress volume with flow and proxy logs, subtract baseline and reconcile with accessed volume.
Classify accessed objects, deduplicate individuals and count subjects by category and jurisdiction.
Treat every credential or secret found in scope as exposed and rotate it.
Assign a confidence level and basis to every figure, and have a second analyst re-run key queries.
Send phased regulator updates that refine the bounded estimate rather than reverse it.

Standards and references

Related NHI Mgmt Group resources: Data Exfiltration Playbook · Data Exfiltration Guide · Cloud Forensics Guide · Forensic Timeline Analysis Guide

Data Exfiltration Scoping Guide: Working Out What Data Was Taken and How Much