In a breach determination, what is the difference between personal data being exposed and being accessed?

## The two words do different jobs **Exposure** describes a *state* of the environment. A control failed, and personal data became reachable by someone who should not have been able to reach it: a storage container flipped to public, a file share inherited a permission from a parent folder, a mailbox rule forwarded messages to an outside address, a leaver's account kept working, a sanctioned file-sync client was linked to an account the organisation does not control. Exposure can usually be proven from configuration and change history alone — you can show what the permission was, and from when. **Access** describes an *act*. Someone or something actually retrieved the data. Access is proven from a record trail, and the useful records are the ones that log reads rather than administration: a download or `file.retrieved` event in a SaaS provider's audit trail, an object-read entry in a cloud control-plane log where data-event logging was switched on, a database audit record of the statement that returned the rows, a proxy session tying an account to bytes leaving for a destination. Notification frameworks are written around access, or a reasonable likelihood of it, rather than around exposure alone. Exposure is common and often harmless; it is retrieval by the wrong party that puts a person at risk. So the investigative question is never simply *was it exposed* — that is the easy half — but *did anyone take it, and if I cannot say, why can I not say*. ## Three outcomes, not two - **Access established.** A retrieval record ties an actor to specific objects. This is the strongest position and it is also the one that lets you scope: the record names what was taken. - **Access excluded.** You have telemetry covering the entire exposure window, you can show it was enabled and complete for that window, and it shows no unauthorised retrieval. This is the rarest outcome, because it requires proving a negative about your own logging. - **Access cannot be excluded.** Exposure is proven, and the read-level telemetry that would answer the retrieval question was never enabled, was rolled off by retention, or has gaps. This is the ordinary outcome, and it usually has to be treated as duty-triggering: the organisation cannot resolve its own uncertainty in its own favour. Candidates who only offer the first two outcomes are the ones who get caught. The interviewer's follow-up is always some version of *and if there are no read logs at all?* ## Absence of a record is not absence of the act The direction of the claim matters. A log proves what it recorded. It proves nothing about what it did not record unless you can independently show that the event, had it happened, would have been written down. Before you say *no evidence of access*, answer four questions: was the source logging at all across the window; did it log **reads** or only management operations; was retention long enough to cover the window — a six-week slow drip outruns a fourteen-day buffer; and are there collection gaps where the shipper or the sensor was down. There is a wording difference here that survives later scrutiny and one that does not. *We found no evidence of access* invites the reader to conclude nothing happened. *Our telemetry over this window cannot establish whether the data was retrieved* says what you actually know. The second sentence is the honest one, and it is the one you can still stand behind when scope grows. ## What retrieval evidence looks like in practice Take a slow exfiltration through a sanctioned enterprise file-sync client — a corporate document repository drip-feeding into a linked account the organisation does not control, a few hundred megabytes a day for six weeks so nothing spikes. The provider's audit trail carries retrieval events naming file objects, an actor account, a device and a source address. Those events *are* access evidence for those objects: a copy left for a store you cannot reach. You will never observe a human reading them, and you do not need to — once a copy sits somewhere you cannot recall it from, treating the contents as accessed is the defensible position. Note also what an investigator records without drawing the legal conclusion: whether the copies were encrypted, and whether the key travelled with them. That fact materially changes the risk assessment, and it is a fact you can establish. ## Not every movement is an intrusion The same sync client is used legitimately by the whole company, so movement alone determines nothing. An employee backing a project folder up to a personal account is an unauthorised disclosure with a very different profile from an adversary staging data. A red-team exercise, a sanctioned bulk migration, or an administrator doing exactly the job they were hired for can all produce an identical record shape. A determination therefore has to establish that the destination and the actor were unauthorised — not merely that data moved. ## Write the determination down while you make it The output is a short, dated record: what was exposed, over what window, what telemetry exists across that window, what it shows, what remains unknown, and what new fact would change the answer. That record is what you will be asked to defend months later, and it is the thing that makes a later correction look like an investigation working rather than an organisation changing its story.