“The cloud logs show no access” is too broad unless the report identifies the service, operation, event category, account, region, time range, and retained source. Use a narrower evidence question: whether a particular operation was recorded in a collection configured to capture that operation during the relevant period.
Map the visibility before searching
AWS CloudTrail concepts distinguishes management, data, network activity, and Insights events, as well as event history, trails, and event data stores. Default event coverage differs from an assumption that every object read is logged. Record the source type and its configured selectors. Current documentation can change; retain the applicable configuration and consult the examined service's CloudTrail integration documentation.
Create a scope row for each account and region involved. Include collection start, oldest retained record, event selectors, destination, export method, and known omissions. Organization-level arrangements do not eliminate the need to verify which accounts and periods were actually represented in the supplied export.
Preserve the query as evidence of scope
Retain the original service-generated files or export together with query parameters, filters, pagination, collection times, and collector identity. A console screenshot usually establishes less scope than a preserved export and its request record. Note access restrictions and whether the collecting account could see every relevant source. Keep the raw JSON even if analysis uses a spreadsheet or normalized event platform.
CloudTrail files are not an ordered execution trace. Compare event time, delivery or ingestion context, identifiers, and related activity without using line order as proof of sequence. Keep duplicated representations linked rather than silently counting them as independent corroboration.
Trace credentials before naming a person
The CloudTrail userIdentity reference describes different identity types and session context. An assumed-role session and its issuer answer different identity questions. Preserve the principal identifier, account, ARN, session fields, source information, and any relevant authentication records. Friendly names alone are weak joins because they may describe roles or user-controlled session labels.
Compare the event with identity-provider or session-issuance records where available. Ask whether the action came from automation, a service, delegated access, or temporary credentials. A credential-associated event does not independently prove who controlled that credential at the time. An IP address also needs network context before it becomes a device or location claim.
Use a coverage matrix
| Claim | Required supporting context |
|---|---|
| No matching object-access event found | The relevant data-event coverage and retained destination. |
| A role made a request | Original identity and session fields, not only a display label. |
| An operation succeeded | Service-specific event semantics and outcome fields. |
| A person performed the action | Independent attribution beyond the credential record. |
Ordinary causes of absence include unselected event categories, collection outside the retention interval, an unsearched account, and an incomplete export. Record which alternatives were checked and which remain unresolved.