Incident Logs and Evidence

An incident log is the timed record of what happened, what was decided, and who decided it, kept while the incident is running. Alongside it, evidence such as system records, alerts, and communications is preserved in a form that can be examined later. Together, the log and the evidence support classification, because they show the facts behind the judgement, reporting, because they supply the content of each phase, and learning, because they let a later reviewer test the root cause against what actually happened. A log reconstructed after the event, however careful, cannot do the same work.

A useful log contains decisions and turning points, not a stream of raw data. It should record when the incident was detected, when the service effect was understood, when escalation happened, what restoration steps were tried and with what result, and when the service returned. It should name the people who took each decision, in role terms where personal names are not needed for the record. It should also record classification decisions and any changes to them, with reasons. Raw system data belongs in the preserved evidence, linked to the log, rather than pasted into it. That separation keeps the log readable, which is what makes it useful when a tired team, a board member, or an authority needs to follow the story quickly.

The log should be kept by someone other than the person leading the technical fix, because a person fixing a fault cannot also write a reliable account of it. In a small firm this may mean that a second person, even one with no technical role in the fix, takes the log keeper role. The log keeper joins the incident calls, notes times and decisions, and asks for clarification when a decision is unclear. That questioning role is valuable in itself, because it forces decisions to be stated plainly enough to be written down. Firms that leave logging to the end of the incident, or to whoever has a spare moment, usually produce a summary of conclusions rather than a record of how those conclusions were reached.

Evidence preservation means keeping the raw material that supports the log, before it is overwritten, rotated, or lost. Alert records, system logs, configuration snapshots, and relevant messages should be captured and stored where they cannot be altered by the ongoing fix. That does not require elaborate forensic tools for every incident, but it does require a habit, which is to secure a copy early, note where it is stored, and record who holds it. Where a third party holds part of the evidence, the firm should ask for its preservation promptly, because the provider's retention cycle will not wait for the firm's review. A gap in evidence discovered months later cannot be repaired, and it undermines the root cause analysis that depends on it.

The log and the report serve different readers and different purposes. The log is a working record, detailed, chronological, and sometimes messy, because it captures uncertainty as it stood at the time. The report is a distilled account, written for an authority or for the board, that selects the facts those readers need and explains them in order. Confusing the two causes problems in both directions. A report that reads like a raw log will baffle its reader, while a log that reads like a polished report has probably been tidied after the event and lost its value as evidence. Keeping the two distinct, with the report traceable back to the log, gives each reader what they need without corrupting either.

After the incident, the log supports three kinds of work. It supports the final report, by providing the chronology and the decision trail. It supports the root cause analysis, by showing the sequence of events against which a proposed cause can be tested. And it supports learning, by revealing where the response was slow, where information was missing, and where a decision was taken on thin evidence. A review that starts from the log will usually find different lessons from a review that starts from memory, because memory smooths over the awkward moments that the log preserves. That is why the log is worth the effort during the incident, even when the team would rather focus only on restoration.