Blog
They wrote no evidence. The log said 200.
At 03:06 Priya reads a 200 on customers/2026-10-18.csv from 01:40 UTC. The key is still Active. Marcus waits for a full inventory. The scribe writes that there is no evidence.
At 03:06 on 19 October 2026, Priya S (on-call, platform) reads a CloudTrail line on the bridge. At 01:40 UTC, s3:GetObject returned HTTP 200 for s3://prod-exports/customers/2026-10-18.csv, 412 MB. The access key is export-reader-2019. The nightly export job uses a different key, export-job-current, from 198.51.100.10. This call came from 203.0.113.44. The runbook row for export-reader-2019 says deactivated 3 March 2026. The IAM console at 03:06 shows the key Active. The plan says: if CloudTrail shows s3:GetObject with HTTP 200 on a production customer export, by a key other than export-job-current, name the object and the key, treat that object as read, and do not write that scope is unknown. At 03:11 Marcus T (incident commander) says one file is not enough to tell customers anything, and he wants a full inventory before anyone writes that data left. He tells Sam O (communications) not to draft. He does not ask Priya to disable the key. At 03:18 the scribe writes that scope is still being assessed, and that there is no evidence of exfiltration.
A weak record of those twelve minutes reads:
Scope still being assessed. No evidence of exfiltration. No customer impact confirmed.
A strong one reads:
19 October 2026, 03:06 to 03:22. Incident-response tabletop. Seats: Marcus T (incident commander), Priya S (on-call, platform), Sam O (communications). Dana K (legal) was not on the call. Inject at 03:06: CloudTrail shows s3:GetObject HTTP 200 at 01:40 UTC for s3://prod-exports/customers/2026-10-18.csv, 412 MB, key export-reader-2019, source 203.0.113.44. The export job uses export-job-current from 198.51.100.10. Runbook says export-reader-2019 was deactivated 3 March 2026. IAM console shows the key Active. Plan: name the object and the key, treat that object as read, and do not write that scope is unknown. At 03:11 Marcus says one file is not enough to tell customers anything, and he wants a full inventory first. Sam does not draft. Nobody disables the key. At 03:18 the scribe writes that scope is still being assessed and that there is no evidence of exfiltration. Facilitator stops the sitting before anyone treats that sentence as the finding. Nothing was disabled. No customer was told. Follow-up: Priya disables export-reader-2019, or writes why the console still shows Active, by 2 November 2026. Dana writes whether a customer-notice draft starts from this one object, by the same date. If she starts one, it is not sent from this file.
Both notes say the room looked at scope. Only the second shows a 200 on customers/2026-10-18.csv at 01:40 UTC, and that export-reader-2019 was still Active at 03:18. The first costs you the file. On the night this is real, that object has already been read, the same key is still Active for the next object in prod-exports, and a reader in March thinks you had not yet decided that anything was read. The customer notice never starts.
Still assessing is a decision
Marcus is trying not to overclaim. The plan already told him what a 200 on this object is. Waiting for a full inventory leaves the key Active and keeps Sam's draft from existing. No evidence of exfiltration is the opposite of the line Priya read out loud.
What happens after the object has a name, and the rule that the draft is not sent, is the customer-notice post. This sitting stops at the name. A triage summary that invents a different cause is a different miss, in the summary post. Write the 200 on its own lines before anyone edits a sentence to customers.
One read is not the bucket
A 200 on customers/2026-10-18.csv is that object. It is not a finding that every object in prod-exports was read, and it is not a copy you have seen in someone else's hands. A list, a 200 on one object, and a dump you can point at are three lines. The cloud credential family in the scenario library already asks the room to separate a list, a read, and confirmed exfiltration. The failed AssumeRole in that same family is a different minute: the actor missed a role. This minute is a 200 you already have. Write the 200. Leave the rest unknown on purpose, on their own lines, so unknown does not swallow the object you named.
What the packet records
Write the read in the free evidence template: the plan sentence, the 01:40 GetObject, the key still Active, Marcus's decision at 03:11, that Sam did not draft, and that nobody disabled the key. Hang the inject on the cloud credential family, and do not fold the 200 into an isolate note from a ransomware sitting. Put the file in the evidence index on the row for that exercise, with the date and the owner, so the next questionnaire finds the object you actually named.
If the plan has no sentence for when a read of a customer export starts a notice clock, run the free plan self-check before the next sitting. It asks whether notification deadlines are written down and where they come from. A plan that only says assess scope will produce this scribe line every time.
The record shows that these named people had a 200 on customers/2026-10-18.csv and still wrote that there was no evidence of exfiltration. It does not show that export-reader-2019 was disabled, that any other object was read, or that a customer was told anything.
Bottom line: write the object and the 200. No evidence is the smoothed version. The packet has to show the file the key already read.