Dodgy Dave downloads the customer list and calls it working from home¶
Dave works for a subscription business and has legitimate access to customer records. During his notice period he exports the most valuable accounts, uploads the file to personal cloud storage and offers it to a competitor. Dave's defence is prepared early: the login was authorised and the folder was called “home working”. The systems record what he actually did.
Dave uses the front door¶
Dave's staff account STF-2841 is authorised to view individual customer records for support work. It is not authorised for bulk marketing exports. During his final week, he searches repeatedly for high-value subscribers and selects fields unrelated to any support ticket.
Insider misuse can involve a person abusing access they genuinely possess. Authorised access does not make every action legitimate, and a valid employee account does not remove the need to prove who used it.
STF-2841 exporting these records through session SES-62A4Still open who controlled the session, the purpose of the export and whether the data left company controlThe export becomes a completed transfer¶
File-creation records show EXP-4410 written to Dave's assigned laptop as priority_customers_q3.csv. Endpoint telemetry records the file being packaged and browser upload UP-8821 completing to a personal cloud account. The cloud provider preserves the object identifier, account and completed upload size.
File access or copying does not alone prove data theft. Creating an archive does not prove exfiltration. Here, the completed cloud event and matching file hash address the next proposition: the exported customer file left the managed laptop and arrived in an account outside company control.
EXP-4410.NB-114 writes the CSV with matching row count.UP-8821.OBJ-9044.Evidence showing a transfer completed is more powerful than a large outbound-traffic number. Export ID, file hash, byte count and cloud object join the business data to the destination event.
Dave's “home working” folder has no work account¶
The cloud account is registered to Dave's personal recovery email and paid using his card. It is accessed from the same browser profile on laptop NB-114. A valid company session and a personal destination now form a strong line of enquiry, but an employee account still does not identify the employee who acted by itself.
EXP-4410 and matching cloud object OBJ-9044 were created through the recorded staff and browser sessions.Dave's regular multifactor approval is recorded at session start, building access-control evidence rather than proving intent. Office camera and badge records place him at the assigned desk; no remote connection or shared-account event appears. Those are positive corroborative facts, not merely the absence of another suspect.
The customer list applies for a second job¶
Messages on Dave's personal account attach a sample of ten rows to a competitor contact under reference DL-208. The recipient replies with a proposed payment per converted customer. A later payment carries the same reference. Unauthorised disclosure requires evidence of what was shared and to whom; the sample hash matches records within EXP-4410.
The competitor's account is a separate line of enquiry. Receipt of a sample and a referenced payment can corroborate Dave's purpose while raising questions about request, knowledge and agreement. The incident should not be flattened into “Dave downloaded too much”.
The alert arrives late but remains useful¶
A data-loss rule flags the personal-cloud destination after the security team updates its detection policy. The alert is not proof of the incident; it identifies the source events that require review. Those events independently establish the targeted searches, export, completed upload, sample communication and benefit.
Dave deletes the local CSV. Cloud, application, endpoint and recipient records retain their own histories. A later deletion event may support concealment, but the case does not rely on promising that deleted files can always be recovered.
