What does a collaboration suite's audit trail prove when a compromised account joined your incident channel?

## What kind of record this is A collaboration platform's audit log is a **control-plane** record: the service writes down the administrative and content-access operations it performed, attributed to the identity whose session requested them. It is not a transcript of what a human saw, and it is not instrumentation of a human at all. Getting that direction right is the whole question. A typical normalised entry carries a timestamp, an actor identity, an action type, a target, a session identifier, and network context such as source IP and user agent. ## What the records genuinely support - **`channel_join` / `channel_leave`**: a session holding that identity's credential was admitted to the channel, and later left. This bounds the window of exposure: everything posted between those two timestamps was available to that session. - **`file_download` / `file_export`**: content demonstrably left the platform to that session. This is the strongest class of entry you will get, because it is an action the service performed on request rather than an inference about attention. - **Session identifiers**: they let you tie several actions to one continuous authenticated session, and often to other activity by the same session elsewhere in the tenant. ## What the records do not support - **That a human read a message.** Most collaboration platforms do not emit a per-message read event at all, and where a view or read-receipt event exists it records that a client fetched or rendered the content. A client can sync a channel's backlog with nobody at the keyboard. "Read" is an inference about a person; the log is about a process. - **That nothing was seen, when there is no download.** This is the mirror error and the more dangerous one. Message text is displayed and cached without generating any event. An adversary sitting in the channel for twenty-nine minutes with no download entry may have every word. - **That the employee did it.** The record attributes to an identity and a session. If the credential was stolen, the named person is a victim, not the actor, and briefing that person's manager as though they did it is a serious mistake with human consequences. - **That the IP tells you who or where.** Source IP and user agent are supplied by the client and are adversary-controlled. They are correlation material - the same egress address appearing on other sessions in the tenant is a useful pivot - not identification. ## The reasoning move you are being tested on The interviewer wants to see you convert a partial log into a **defensible worst case** rather than a comforting best case. The right sentence is: "between 02:41 and 03:10 a session authenticated as this account was a member of the incident channel; I am treating everything posted in that window as known to the adversary, and I can additionally show one document left the platform." That statement is true, useful, and survives someone checking it. The wrong sentence is "they only downloaded one file, so they probably did not see the containment plan" - the log was never capable of ruling that out. ## What you do with the finding First, the conversation moves somewhere the compromised identity cannot follow, and the exposure window becomes an input to planning: anything you said in that window about what you had noticed and what you intended is now adversary knowledge, and a plan that depended on surprise has to be rewritten rather than reused. Second, preserve the evidence early. Audit APIs on SaaS platforms have finite retention, often shorter than the investigation, and export limits that bite when you ask for a wide window in a hurry. Pull and store the relevant slice - including the channel's own message history and file metadata - before it ages out. Deleting the channel to "clean up" destroys the record of what the adversary had access to. Third, be careful how you write it up. "The account joined the channel" is a fact. "The attacker read our containment plan" is a claim your log does not carry, and it will be quoted back to you by an executive, a customer or a lawyer. Write what the record supports and state the assumption separately as an assumption. ## A note on absence If you find no join event for a suspect identity, that is not proof it was never there. Consider whether the tenant's audit plan actually covers that event type, whether the log was collected in the window, and whether an administrative identity could act without generating the entry you are looking for. Absence of a record is a statement about your collection, not about the estate.