Incident Response Logging: Evidence You Need Before an Incident

During an incident, the first difficult question is often not which tool to use. It is whether the organisation has retained the records needed to explain what happened. A sign-in alert may identify an account and a time, while leaving the subsequent resource access, configuration changes and data movement unresolved.

Incident response logging should begin with investigation questions. This article proposes a retrieval exercise for operations teams. Exact forensic collection methods require a separate decision based on the system, incident and evidential requirements.

Define questions before selecting log sources

Choose a plausible, bounded scenario, such as suspected misuse of a supplier account. List what the incident coordinator needs to establish: when the account authenticated, which session or device was involved, which resource was accessed, what changed and what happened afterwards.

Then identify the record that could support each answer. Avoid assuming that one platform contains the complete sequence. Identity, application and infrastructure records may describe different parts of the same event, using different identifiers and time representations.

This planning matrix describes possible sources and limits; fields differ between products.

Prioritise useful events

Joint guidance from ASD and partner agencies describes four foundations: an approved logging policy, centralised access and correlation, protected storage with integrity controls, and detection aligned to relevant threats. It prioritises useful event types and important systems rather than volume alone. Event logging and threat detection guidance.

For the supplier scenario, begin with the identity system, the remote access service and the supported application. Determine whether a permitted action and a denied action both create a useful record. A storage budget devoted to repetitive low-value events may leave little room for the records needed to explain privileged changes.

Assign an owner to each source. That owner should know how collection is configured, how changes are approved and how a missing feed is detected. The source inventory should also identify the team responsible for interpreting the record; successful ingestion does not guarantee that its meaning is understood.

Test the complete retrieval path

Generate an agreed harmless event using a test identity and synthetic data. Record the expected time, action and target independently. Ask the analyst to locate the event through the normal investigation interface and export the relevant surrounding records.

Measure the time from event creation to availability for analysis. Note whether the analyst needs a special role, a provider support request or an export format that the existing tools cannot read. Repeat retrieval for an older record from the archive so that the exercise covers more than recent searchable data.

Check export limits, pagination, filters and time boundaries. A download that completes successfully may still contain only the first page of results. Record the query and the expected coverage so another reviewer can understand what was requested and what was returned.

Preserve time and identity context

Keep event time, collection time and export time distinct. Document the source time zone and any conversion used in the working timeline. Where clocks differ, record the discrepancy rather than forcing events into an apparently precise order.

Use stable account, resource, session or request identifiers where the system provides them. Display names can change and shared accounts may represent several operators. When a mapping is inferred from adjacent records, label it as an inference and explain the supporting fields.

The exercise should also test a negative result. If the analyst finds no event, inspect collection coverage, filtering and retention before concluding that the action did not occur. An empty search can reflect an absent event, an incorrect query or missing records; the conclusion must preserve that uncertainty.

Protect original records and document handling

Maintain an original export and a separate working copy. Record the source, collector, collection method, time range, collection time and any transformation. Where the approved process uses cryptographic hashes, record them with the relevant file and explain that they support later integrity checks; they do not prove the source event was truthful.

NIST SP 800-86 provides foundational forensic-process context for incident response. It is an older publication and should not be treated as a current cloud-specific collection manual. NIST SP 800-86.

Restrict evidence access and record transfers. Do not paste live tokens, passwords or unnecessary personal data into a general incident channel. Prepare redacted copies for wider distribution while preserving the original under the approved access controls. Any legal or evidential requirements for a particular investigation need their own assessment; a handling checklist cannot guarantee admissibility.

Decide retention from the investigation need

Retention should reflect the relevant risks, investigation needs and applicable rules. Centralised protected storage helps address local overwrite and tampering, while delayed ingestion can delay detection. These issues are addressed in the joint logging guidance.

For each source, document searchable retention, archived retention and the practical retrieval time. Compare the promised period with the oldest record that can actually be recovered. Check whether licensing, storage exhaustion or a configuration change silently reduces availability.

Avoid a universal duration copied from another organisation. Different event types can have different value and sensitivity. The decision should identify who approved the period, why it supports the investigation scenarios and when the decision will be reviewed.

Turn evidence gaps into operational work

NIST SP 800-61 Rev. 3, finalised in 2025, places incident response within cybersecurity risk management and CSF 2.0. Its framing supports treating preparation and improvement as continuing work. NIST SP 800-61 Rev. 3.

Close the rehearsal with specific changes: enable an identified audit category, repair an export permission, document a time conversion or add a missing application identifier. Assign an owner and demonstrate the corrected retrieval path. “Improve the SIEM” does not tell anyone what result is required.

Keep a limitations register alongside the incident timeline. If the available evidence confirms authentication but cannot establish which files were read, say exactly that. This gives decision-makers a defensible account of what is known and what remains unresolved.

Frequently asked questions

Does buying a SIEM provide incident detection?

The platform can support collection and analysis. Detection also depends on useful sources, working rules, coverage and people able to investigate the result.

Do missing logs prove there was no intrusion?

No. They limit the conclusions available from those sources. Document the missing period and seek other appropriate evidence.

Does an outbound connection prove data theft?

No. It confirms the recorded connection details. Establishing content or data access requires additional evidence that the connection record may not contain.

Related reading: Active Directory security, reporting and risk and visibility limits in endpoint protection.

For planning the next steps, see Incident Response: What Executives Need to Know and Defense Evasion: Hiding from Logs and Monitoring.