A support account viewed 11,000 customer records in one afternoon — which innocent explanations must you eliminate?

## Why you enumerate first The expensive mistake in a case like this is not reaching the wrong verdict; it is reaching a verdict first and then collecting evidence that agrees with it. Once "insider taking customer data" is written in the channel, every later artefact gets read in that light and the benign explanations never get tested — they simply go unmentioned. Enumerating the alternatives *before* you rank them forces each one to declare what would kill it, which is the only structure that produces a report someone can attack without it falling apart. ## The hypotheses that are actually alive here All of these produce the same shape in the application's audit log — a large number of `record.view` rows on one account in a short window. | Hypothesis | Observation that would rule it out | |---|---| | An automation or reconciliation job using the account's API token | Requests carry a browser session cookie and a browser user agent, with irregular human-scale gaps | | The credential is shared, or sits in a team runbook | Only one session id and one source address, and it matches the engineer's usual client and network | | A list or search screen that prefetches the full record for every result | Views are not clustered behind a small number of search requests, and each has a distinct navigation path | | A report or export whose scope widened after a recent role grant | No entitlement change in the identity provider's change record before the window | | Authorised bulk work — data-quality sweep, migration, an announced exercise | No ticket, change record, or project asked for it, and no other engineer ran the same pattern | | Ticket-driven support work at unusual volume | The viewed customer ids do not correspond to any open case | Notice that most of the discriminating observations come from *outside* the account's own activity: a change record, a ticket queue, another engineer's history. Evidence drawn only from the same account tends to be circular — it describes the pattern again rather than explaining it. ## Cadence and client identity do the most work If you can only ask one thing, ask how the requests were made. Eleven thousand records in an afternoon is roughly one every second and a half sustained — possible for a person clicking through a list screen that prefetches, and implausible as deliberate reading. Fixed inter-request intervals, a non-browser user agent, an API token, or a source address belonging to infrastructure rather than an office or VPN pool all point at a program. That does not close the case; it *moves* it. The question becomes who owns that program and whether the access was authorised — a different investigation, sometimes a benign one, occasionally worse, because an automation quietly using a human's credentials is its own finding. ## Benign true positive is a real verdict A benign true positive is activity that genuinely happened, genuinely matches the rule, and is genuinely authorised. It is not a false positive: the detection was right about the behaviour and wrong about nothing. Closing this case as "the engineer ran an approved data-quality sweep under a ticket" is a correct and complete outcome, and it should be recorded as such, because the next analyst who sees the same pattern needs to know the difference between "we saw this and it was fine" and "this rule is noisy". ## Volume proves volume The single most common weak answer treats the number as the finding. Eleven thousand is a *prompt*, not a conclusion. It establishes that the access was far outside the account's normal range — which is what makes it worth an hour of someone's time — and nothing about intent, retention, or whether the data left. Intent in particular is almost never visible in telemetry; you can sometimes observe things *consistent* with it (access outside working patterns, records with no ticket, activity that stops the moment a query is asked), but the artefact that shows intent directly is usually a message, a document, or an interview, not a log. ## What you write down End with three separated lists: what was observed, what those observations are consistent with (plural — keep the surviving alternatives visible), and the specific test that would discriminate between the survivors, with how long it takes. That is a report a reviewer can act on, and it is also the version that does not embarrass you when the answer turns out to be a forgotten migration script.