During an incident, a log is useful only if it can answer a question. Logs are records of activity, such as sign-ins, file downloads, or configuration changes. Keeping many records does not guarantee that the team can find the right event when it matters.
Understand the idea
Start with a few real questions. Who signed in? What account changed the sharing setting? Was the file downloaded? Map each question to a source, the fields needed, the period kept, and the person who can retrieve it. Include the time zone and whether the record has gaps.
- Question
Define what happened, who acted, and what was reached.
- Source
Find the systems that record those actions.
- Timeline
Preserve records with timestamps, queries, and known gaps.
A practical example
For example, a team suspects that a shared folder became public last week. The administrator can see the current setting but cannot find the change history. A short retrieval exercise would have exposed this gap earlier and allowed the team to enable or retain the right records.
What to do next
- Create an approved test sign-in and a harmless configuration change.
- Find both events using the known account and time window.
- Export them with the fields needed to join identity and system activity.
- Check that another authorized responder can repeat the retrieval when the usual administrator is unavailable.
How to check the result
Test retrieval before an emergency. Ask someone to produce a known test event with its time, account, action, and outcome. Protect the records and avoid collecting passwords or unnecessary personal information.
We have lots of logs. Is that enough for an investigation?
Volume does not establish coverage. Check whether the relevant event types were recorded, retained, and linked to reliable identities and time information.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
