A proxy shows 40 GB to a sanctioned file-sync host and the provider's audit trail names the files — what does that prove?

## Three sources, three different facts A slow exfiltration through a sanctioned enterprise file-sync client is deliberately quiet: a few hundred megabytes a day into a linked account the organisation does not control, for six weeks, over a protocol and to a hostname that thousands of legitimate users hit every day. Nothing spikes, nothing is unfamiliar, and the two sources you have each answer only part of the question. **The egress proxy** records the connection, not the conversation. For a TLS session it has the connect target or the TLS server name, the client address, the authenticated user where proxy authentication is in place, timestamps, and bytes sent and received. It has **no payload**. That is not a configuration gap you can close after the fact; it is what the record is. So the proxy establishes that bytes moved, in which direction, to which host, over which period — a volume-and-destination fact. It cannot name a file and cannot describe a single byte of content. **The provider's SaaS audit trail** records the operations the service performed on named objects: the event type, the object name or id, the acting account, the client or device identifier, the source address, the timestamp, and often the size. It has no contents either — a provider logging every byte of every file would be storing a second copy of your data. So the audit trail establishes *which objects* an account touched and *when*. **The source repository** is the third source and the one candidates forget. A sync client copies; it does not move. The originals are almost always still there. Once the audit trail has given you object names or ids, you can go to the originals and determine what those specific documents contained, and therefore which categories of personal data and roughly which data subjects are in play. That is the whole shape of the determination: volume from the proxy, object identity from the SaaS trail, content from the originals. Lose any one of the three and the picture has a hole in it that the other two cannot fill. ## Reconciling the two record sets, and what a mismatch means The first analytic step is a reconciliation. Sum the sizes in the audit trail across the window and compare with the proxy's byte counts for that host. They will not match exactly — TLS and protocol overhead, chunking, retries, compression, and other legitimate traffic to the same hostname all move the number — but the *shape* should agree. A material excess of proxy bytes over accounted-for objects means something moved that the audit trail did not record, which is a scoping problem, not a rounding error. A material shortfall means the audit trail is capturing activity that did not traverse this path, which usually means another egress route or another client. Interviewers like this step because it is where a candidate shows they treat two sources as things to be cross-checked rather than two views of a single truth. ## What the records do not let you say - **They do not prove a person acted.** An audit event proves the service accepted a request bearing that account's credential from that client. Whether it was the named employee, someone with their session token, or an automation using their credential is a separate question answered from authentication and device evidence. - **They do not prove intent.** The same records are produced by a legitimate backup, a departing employee taking their own project folder, a sanctioned migration and a deliberate staging operation. - **They do not prove the contents left intact.** If the originals show the documents were encrypted, or if the sync happened at a layer where the client encrypted before upload, what reached the destination differs from what the originals say — and the location of the key becomes part of the finding. - **They do not extend past retention.** A six-week drip against a two-week proxy retention means the earliest and most important part of the window is simply gone. Say so; do not silently scope the incident to the window you happen to still have. ## The facts that move this from unusual to unauthorised Movement alone determines nothing on a sanctioned client. What upgrades the finding is context: the destination account is outside the corporate tenant; the client is linked to a personal identity; the device is unenrolled; the objects fall well outside the account's normal working set; the retrievals continue after the employee's last working day; or the source address belongs to a session the user cannot account for. Each of those is a separate check with its own source, and together they turn *data moved* into *data was taken by a party who should not have had it*. ## Where this leaves the determination At the end of the join you can normally say: these named objects were retrieved by this account to a destination we do not control, over this window, totalling roughly this volume; the originals show these objects contained these categories of personal data relating to approximately this many people; and here is the part of the window our retention no longer covers. That is a determination made on an incomplete picture — which is the normal case — and it is defensible precisely because each clause is tied to the source that actually supports it.