- Separate authentication, administrative changes, and data access in the evidence map.
- Verify event coverage and retention for the actual tenant and license.
- Generate a safe test event and retrieve it using the incident-response access path.
A user reports an unfamiliar sign-in. The response team can see the authentication event, but cannot establish whether the session read customer files or changed a mailbox rule. "Logging is enabled" has answered only the first investigation question.
Build the collection plan around the decisions an incident will require. Which account acted? What changed? What data was accessed? Can the team distinguish a denied request from a successful operation?
Make an evidence map
Use one row per source, with an owner, enabled event types, retention, export destination, responder access, and a tested query. This example describes questions to verify, not a promise that every provider or license supplies each event:
| Investigation question | Evidence to locate | Common gap to test |
|---|---|---|
| Who authenticated and under which policy? | Identity sign-ins, factor events, policy results | Short native retention or missing workload identities |
| Who changed access or configuration? | Cloud management events, SaaS administration audit | Uncollected tenants, regions, or applications |
| Was sensitive information read or exported? | Object, mailbox, file, or application data-access events | Data events not enabled or insufficient licensing |
| Can the timeline be trusted? | Collector health, source timestamps, delivery records | Delayed export, clock differences, or silent pipeline failure |
Include stable user, application, resource, and tenant identifiers. Display names change and may not be unique. Preserve the original record alongside parsed fields so an investigator can check what the source actually reported.
Check AWS event coverage deliberately
AWS documents management events and data events as different CloudTrail categories. Do not assume management-event collection proves which objects were read. Determine the data-event coverage needed for sensitive resources, configure the relevant selectors, and estimate the volume before broad rollout.
Run an authorized read or configuration change against a test resource. Locate the resulting event and record the identity, action, resource, result, and time. Check additional accounts and regions in scope; a working trail in one account does not prove organization-wide coverage.
Distinguish Microsoft identity logs from workload audit
Microsoft's Entra retention documentation distinguishes Entra audit and sign-in logs from the Microsoft 365 Unified Audit Log. Retention and available records depend on the service and licensing. Verify your tenant rather than copying a single retention figure into a policy.
For mailbox or document investigations, identify the corresponding workload audit records and any prerequisites. Ask whether the event demonstrates access, export, sharing, or merely an administrative setting change. Avoid claiming a missing event proves no access occurred.
Test the route responders will use
Have a responder retrieve the test event with their assigned incident role, not the engineer's unrestricted setup account. Check the time range, export format, correlation fields, and whether raw records remain available. Capture delivery delay and any manual steps.
Then simulate a collection failure safely, for example by testing an alert against a nonproduction source. Decide who investigates a stopped feed. Monitoring only the number of ingested events can miss a source that still sends routine traffic while omitting a needed event category.
Keep retention decisions separate from collection configuration. The retention planning article covers storage tiers and archive retrieval. Before accepting a source as ready, attach a real sample event and successful retrieval result to its evidence-map row.
Map the logging and retention evidence needed to support detection, investigation, and leadership reporting.