In a collaboration-suite audit trail, a departing engineer touched 900 files in their final week, all within their entitlements — what does it support?

## Why entitlement makes this hard Most SaaS file cases have no permission violation in them. The person was allowed to open everything they opened; a technical control was never bypassed; no rule fired. So the evidence is not "they got in" — it is *what kind of access, how much, when, and through which channel*, judged against what that same person normally does. Getting this right matters because the output feeds a process where a person's reputation and job are at stake, and where a sloppy sentence is very expensive. ## Not all access events are equal Collaboration suites record distinguishable operations, and their evidentiary weight differs sharply: | Event | What it supports | |---|---| | Preview / view in browser | The item was rendered; no copy left the tenant | | Download | A copy exists on an endpoint | | Sync-client download | A copy exists on a device, possibly automatic | | Copy or move to a personal or unmanaged location | A copy left the governed area | | Sharing link created, especially external or anonymous | A copy is reachable by someone outside | | Permission grant to an external account | Continuing access after the person leaves | The last three are the interesting ones. Entitlement authorises a person to *use* material; it does not authorise them to make it reachable from outside, and a new external sharing link over a folder of proprietary material is a specific act with a specific record, not an ambient consequence of having access. ## Baseline before volume "900 files" is not a finding. Three baselines turn it into one, or dissolve it: 1. **The person against themselves.** What does a normal week look like for this engineer over the past year? Some roles touch thousands of files routinely. 2. **The person against their peers.** If everyone on the team shows similar activity, the number is a property of the role. 3. **The week against the year.** A burst that begins after the resignation date, or that runs outside their normal hours, is a deviation you can state; a flat continuation is not. State the comparison, not the raw count, and state the window you measured over — an interviewer will ask what your denominator was. ## Machine behaviour that looks exactly like exfiltration This is where careless analysts do the most damage: - **Sync-client re-download.** A rebuilt or newly enrolled laptop re-syncs every folder the user had, generating thousands of download events over a few hours with no human decision behind them. Check the client identity on the events and correlate with device-enrolment records before writing a line about the person. - **Service principals.** Indexing, backup, eDiscovery and data-loss-prevention tooling access files as an application identity, and unfamiliar tooling often looks alarming. - **Delegated and shared access.** An assistant, a shared account or a team drive can attribute activity to an identity that was not driving it. - **Bulk operations.** A single move or restore can expand into per-item events, inflating counts by an order of magnitude. A credible answer names at least two of these unprompted, because ruling them out is what makes the remaining events worth discussing. ## What the trail can never say - **Intent.** Downloading a specification the week before leaving is consistent with theft and with finishing a handover document. The record cannot distinguish them. - **Persistence of the copy.** The trail ends at the tenant boundary. Whether the files are still on a personal device is answerable only by device evidence, if any exists. - **Reading.** A download is a transfer, not comprehension — the same direction-of-claim discipline as everywhere else in this domain. - **Channels it never sees.** A phone photograph of a screen, a printout, or dictation into a personal note leaves no SaaS record at all. A clean trail therefore means "no deviation in this trail over the retained window", never "nothing left the company". ## Writing the finding Separate the layers explicitly, in this order: the records (event types, counts, times, client, device), the comparison (baseline and window), the alternative explanations you tested and eliminated, and only then the assessment, labelled as an assessment. Include what you could not determine. That structure is what lets the finding be re-examined by someone else later, and it is what stops an audit extract from being read as an accusation.