---
{
  "title": "Data exfiltration",
  "summary": "Distinguish accessing, staging, and transferring information.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "MITRE ATT&CK: Get started",
      "url": "https://attack.mitre.org/resources/"
    },
    {
      "title": "MITRE ATT&CK: Exfiltration tactic",
      "url": "https://attack.mitre.org/tactics/TA0010/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Separate access from transfer

Data exfiltration is the unauthorized transfer of information out of an intended control boundary. The boundary might be an organization, a cloud tenant, a protected application, or a restricted environment. The central question is what information moved, through which route, under whose authority, and to a destination that was not permitted to receive it.

Collection, staging, and exfiltration are related but distinct. Reading a document establishes access; placing documents in an archive may establish preparation; an external transfer establishes movement. An investigation should avoid collapsing those stages into one claim when the available evidence supports only part of the sequence.

## Follow a fictional document incident

An academy notices an unusual export from its learner-management platform. The export record shows that a staff identity requested a report containing student contact details. A later proxy record shows an upload to an external storage service from the same workstation.

Those events deserve investigation, but a close timestamp does not prove that the exported report was the uploaded file. The team looks for supported relationships: file identifiers, endpoint activity, application export details, destination account information, and transfer records. Depending on the services, encryption or limited logging may prevent inspection of the transferred content.

If the evidence establishes only the export and an unexplained upload, report that accurately. A statement that the report was definitely stolen requires stronger linkage than a suspicious coincidence.

## Identify the actual control boundary

External destinations are not automatically unauthorized. An approved partner may receive a defined dataset under a business process. Conversely, copying information to an actor-controlled account within a familiar cloud provider can be unauthorized even though the provider itself is widely used.

Check the destination account or recipient, the permitted purpose, and the dataset involved. Review whether the identity had legitimate access but exceeded its allowed use. [[authorization]] and data-handling policy help explain why an apparently successful application action may still be a security incident.

Containment may involve revoking a sharing link, restricting an account, blocking a transfer route, or working with the destination provider. Preserve useful records before making changes where practical. Restricting future transfer does not retrieve information already received by another party.

## Practice evidence-based language

Create a timeline containing a document read, archive creation, and network upload. For each event, write what it demonstrates and what it cannot demonstrate. Then remove the upload record and revise the conclusion.

Use [[data-staged]] and [[archive-collected-data]] to understand preparation, and [[incident-reporting]] to distinguish confirmed transfer from suspected exposure. The strongest report explains the information at risk, the supported sequence, and the remaining gaps without overstating certainty.

## Related concepts

- [[cloud-storage-security]]
- [[network-forensics]]