Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you determine whether data was actually stolen?
Updated
Determine theft from evidence: egress or network logs, cloud access logs, data-staging artifacts, and DLP. Access is not exfiltration. Missing egress logs do not prove no theft. Notification is counsel's legal call. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response), CISA incident-response playbooks, ENISA's Recommendations for a methodology of the assessment of severity of personal data breaches (working methodology for DPAs and controllers — not a statute and not a notification determination), and generic cloud-provider audit-log documentation (each provider publishes its own; this page does not name a vendor as the source of truth). This page does not rank DFIR firms, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. The compromise-vs-breach page on this site is the four-term taxonomy. Not legal advice.
Access is not exfiltration
Audience: the incident lead facing a notification question, counsel directing the work, and the examiner who has to say what the evidence supports. The preserve-evidence page on this site is the capture list those logs depend on. The first-72-hours page on this site is the clock-mapping checklist. The contact-breach-counsel page on this site is the privilege-and-engagement checklist. The when-you-need-dfir page on this site is the retain-or-not tree. This page is the evidence-to-conclusion map: what egress, cloud access, staging, and DLP can support, and what they cannot. It does not rank DFIR firms, does not name any, and does not start a notification clock.
Access is not exfiltration (access ≠ exfiltration). A successful sign-in, a file open, a database SELECT, or a cloud GetObject is evidence that an identity could see or copy data. It is not, by itself, evidence that the data left a boundary you can name. Exfiltration is the later claim: that a copy moved to an attacker-controlled store, across an egress path, or off media you still hold. NIST SP 800-86 treats examination as reconstructing what the evidence supports, with methods and limits written down — guidance, not a statute. CISA incident-response playbooks treat investigation as establishing facts for further investigation and, if applicable, legal use; they do not collapse access into theft. ENISA's personal-data-breach severity methodology is a working assessment aid for DPAs and controllers, not a rule that a notification duty has started. Last verified 7 September 2026. Not legal advice.
- Access, acquisition, exfiltration, and 'personal data breach' are different claims. Some statutes care about access, some about acquisition, some about a confidentiality compromise. Those are legal terms of art. Counsel maps YOUR statute. The compromise-vs-breach page on this site is that taxonomy.
- Write what the evidence supports, what it does not, and which sources you did not have. A gap is a gap. It is not a finding of 'no theft.'
- Preserve first. Rotated flow logs and a rebuilt host cannot later prove a negative. The preserve-evidence page on this site is that order.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
Evidence-to-conclusion mapping
Walk each row with the examiner and counsel. A 'yes' on one row is not a notification determination. A 'no' on one row is not proof that nothing left. Last verified 7 September 2026. Not legal advice.
| Evidence source | What it can support | Limit |
|---|---|---|
| Egress / network logs | That bytes left a named boundary at a named time, to a named destination, on a named protocol or port. Firewall denies and allows, flow records (volume, duration, pair), proxy and DNS queries, VPN session tables, and packet capture if you already had a tap. Correlated with an access event, this is the strongest technical path from 'could take' to 'did send.' | Encrypted payloads hide content; sampled or aggregated flows hide small transfers; DNS-over-HTTPS, cloud-to-cloud copies, and physical media never appear on the path you instrumented. Rotation, missing VPC/subnet coverage, and a 7-day hot store are how this row disappears. Absence of a flow is not proof of no theft if the path was not logged. |
| Cloud access logs | That an identity read, listed, copied, shared, or downloaded an object, snapshot, mailbox, or database in the control plane you log. Object-access logs, admin audit, identity sign-in, and (where the provider writes them) data-event logs can show Get/List/Copy, cross-account sharing, and pre-signed URL issue. Provider audit-log documentation is generic here: each cloud publishes its own event names and retention; this page does not pick a vendor. | A read is access, not exfiltration. Copy-to-another-bucket or another account may land in a different trail than the source. Some APIs do not log payload size or the destination. Retention and disabled data events are documented gaps, not silent 'clean.' A cloud API with no snapshot is a gap on the preserve-evidence list. |
| Data-staging artifacts | That someone prepared a copy for movement: archives (zip, tar, dump), large files in temp or an unusual prefix, compressed database exports, leftover transfer-tool working directories, or a sudden object created then deleted. Staging plus a later egress or cloud-copy event is how 'prepared' becomes 'left.' | Staging is preparation, not confirmed leave. An actor can stream without writing a staging file. Cleanup, reimage, or temp-fs expiry wipes the artifact — which is why the preserve-evidence page on this site captures temp filesystems before reboot. Finding no archive is not a finding of no theft. |
| DLP signals | That a channel you watch fired a policy: a classifier hit on mail, web, endpoint, or cloud-app traffic your DLP actually inspects. A hit plus the destination and the object is support for 'this data went that way on this channel.' | DLP sees only the channels, classifiers, and identities you deployed. Encrypted, unknown, or unsanctioned channels miss. False positives are not theft; missed channels are not proof of no theft. Absence of a DLP alert is evidence about YOUR coverage, not about the estate. |
When egress logs are missing
Missing egress or network logs do not let you conclude that data was not stolen. They let you say only that the evidence you have does not show exfiltration. That sentence is the whole limit. Write it on the timeline. Last verified 7 September 2026. Not legal advice.
- You cannot conclude 'no theft' from a source that was never collected, had already rotated, was sampled below the transfer, or never covered the path (cloud-to-cloud, encrypted DNS, physical). NIST SP 800-86: document the method and the gap. The gap is the record.
- What you may say: 'Firewall, flow, and proxy logs for this window were not retained / not enabled / not in scope. The evidence we have does not show egress of this dataset.' What you may not say: 'Nothing left, because we have no egress logs.'
- Other rows can still support a narrower claim. Cloud access logs can show a copy to another account. Staging artifacts can show a dump was built. DLP can show a hit on a channel it watches. None of those fills a missing egress row; they are different claims.
- Do not invent completeness for a notification form. GDPR Article 33(4), when it applies, allows information in phases; that is counsel's statute, not this page's. Operationally, unknowns stay unknowns. The first-72-hours page on this site is that clock map.
Notification thresholds are counsel's legal determination
Whether you must notify — and whom, and by when — is a legal determination on YOUR facts and YOUR statutes. The incident lead and this page do not make it. Counsel does. This page is not legal advice and does not start a clock.
ENISA's 2013 working methodology for assessing the severity of personal data breaches is an assessment aid for DPAs and controllers (data nature, ease of identification, circumstances of the breach). It is not a statute, not GDPR Article 33 itself, and not a ruling that a duty has started. CISA playbooks and NIST SP 800-86 tell you to involve legal counsel when an incident may have legal ramifications. Mapping is not filing. Last verified 7 September 2026. Not legal advice.
- A technical conclusion of exfiltration is not automatically a notifiable breach. A technical conclusion of access-only is not automatically 'no duty.' US-state, sector, GDPR, and CRA tests differ. Counsel maps the duty.
- The compromise-vs-breach page on this site is the four-term taxonomy. Keep the four claims separate in every statement: compromise of a system, access to data, exfiltration of a copy, and a legal 'breach' under a named statute.
- The contact-breach-counsel page on this site is the privilege-and-engagement checklist. Common practice is counsel-directed DFIR so working papers can sit under attorney-client privilege and work-product — practice, not a ruling that privilege will attach.
- This product does not start a notification clock. A named human still files, if counsel says a duty applies.
Where this shows up in ShipReady Metrics
The signed-in app does not determine whether data was stolen, parse egress or network logs, read cloud access logs, detect data-staging artifacts, consume DLP signals, or start a notification clock. It does ingest security findings (Dependabot, SAST / code scanning, secret scanning, and DAST). Security also has a blast-radius search over captured dependencies — transitive npm when a lockfile was fetched — which is package exposure in YOUR tree, not a finding that data left the estate. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not an exfiltration determination, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. None of those surfaces tells you whether data left.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
NIST SP 800-86 (August 2006), Guide to Integrating Forensic Techniques into Incident Response, remains the current final guide this page cites for examination that states what the evidence supports, working copies, and documenting methods and limits — guidance, not a statute, last verified still final on 7 September 2026. CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks are operational procedures for US FCEB systems; CISA notes other organizations may use them to standardize practice; they include investigation that preserves evidence for further investigation and, if applicable, legal use. ENISA's Recommendations for a methodology of the assessment of severity of personal data breaches (20 December 2013) is a working methodology developed with the Greek and German DPAs for use by DPAs and controllers; it is not a statute, not GDPR Article 33, and not a notification determination. Cloud-provider audit-log documentation is generic: each provider publishes event names, data-event coverage, and retention for its own control plane; this page does not treat any vendor's doc as the source of truth. NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide this cluster cites — guidance, not a statute; responders seek legal guidance when an incident may have legal ramifications.
Frequently asked questions
How do you determine whether data was actually stolen?
From evidence, not assumption. Egress or network logs can support that bytes left a named boundary. Cloud access logs can support that an identity read or copied an object. Staging artifacts can support that a copy was prepared. DLP can support a hit on a channel it watches. Access is not exfiltration. Missing a source is a gap, not proof of no theft. Counsel maps any notification duty. Not legal advice.
Does access mean the data was exfiltrated?
No. Access is not exfiltration (access ≠ exfiltration). A sign-in, file open, SELECT, or GetObject shows opportunity. Exfiltration is evidence a copy left a boundary you can name. Some statutes care about access or acquisition rather than theft; those are legal terms of art. Counsel maps YOUR statute. The compromise-vs-breach page on this site is that taxonomy. Not legal advice.
If we have no egress logs, can we conclude data was not stolen?
No. Absence of egress logs does not let you conclude 'no theft.' You may say only that the evidence you have does not show exfiltration. Write the gap: not collected, already rotated, sampled, or a path you never instrumented. Other sources (cloud copy, staging, DLP) can still support a narrower claim. They do not fill the missing row. Not legal advice.
Who decides whether we must notify?
Counsel, on YOUR facts and YOUR statutes. Notification thresholds are a legal determination, not an IR conclusion and not this page. ENISA's breach-severity methodology is an assessment aid, not a statute. GDPR, US-state, sector, and CRA tests differ. Mapping is not filing. This page does not start a clock. Not legal advice.
Does ShipReady Metrics determine whether data was stolen?
No. The signed-in app does not determine exfiltration, parse egress logs, read cloud access logs, detect staging artifacts, or consume DLP. It does ingest security findings (Dependabot, SAST, secret scanning, DAST) and it does compute blast radius for transitive npm from fetched lockfiles — package exposure, not theft. Compliance → CRA reporting is a ladder from recorded awareness, not a clock this product starts. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from NIST SP 800-86, CISA incident-response playbooks, ENISA's personal-data-breach severity methodology, and generic provider audit-log documentation. Whether data was 'stolen' for a named statute, whether a notification duty applies, and what you may say externally are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.