Keep security logs ready for an investigation

Security logs are useful when a team can find the right event, explain its context and preserve it for review. Start by choosing the questions an investigation must answer, then verify collection, retention and access for each source. Buying storage or enabling a dashboard completes only part of that work.

For a business decision-maker, the practical choice is what evidence must remain available, who will retrieve it and what the arrangement will cost. For the practitioner, the task is to prove the route from a known activity to a usable record. The workflow below is Mimir's recommended approach, illustrated with current Microsoft documentation. It is not a report of testing in a customer's environment.

Start with an investigation question

Choose a business process and describe the incident you would need to understand. For example: who changed a supplier's payment details, which administrator granted access to a shared resource, or whether an unfamiliar sign-in was followed by a sensitive action. These are hypothetical investigation questions, not incidents Mimir has observed.

Joint guidance from ASD's ACSC, CISA and partners recommends an approved logging policy, prioritised events, secure central collection and defined retention. The guidance also explains that useful event selection depends on the environment and the risk being examined. Event logging guidance.

Mimir recommends making a small evidence register for the chosen process. Record the service, event category, accountable owner and the decision the evidence supports. For security logs relating to an identity incident, connect the sign-in record to subsequent activity where the systems provide matching identifiers. Our discussion of identity attacks and MFA gaps gives context for that wider sequence.

Give each unanswered question an explicit gap rather than assuming a security product already covers it.

Trace how security logs reach investigators

Write down where an event is created and how it reaches the location investigators will use. Include the source configuration, connector or agent, filtering rules, destination and the identity responsible for collection. Confirm the exact event category, since a successful connection does not prove that every relevant activity is included.

Azure Monitor's data collection rules illustrate this distinction. Depending on the supported collection path, a rule can specify sources, schema, transformations and destinations. Microsoft describes the rule as configuration, not a destination through which telemetry flows. Destination retention and table settings remain separate. Data collection rules.

For security logs, Mimir recommends checking a known event at both ends of the route. If it exists in the source but not the destination, inspect the category selection, permissions, transformation and delivery status before rewriting the search. Keep the event identifier and original timestamp where available.

Review changes to these settings as changes to the evidence you will have later. A filter that saves storage may also remove the record needed to answer the original question.

Record retention separately for each service

Avoid a single statement that “Microsoft keeps our logs” without naming the service, record type and licence. As checked on 5 November 2026, Microsoft lists seven days for Entra ID Free audit and sign-in activity reports, and 30 days for Entra ID P1 and P2. Expired data does not return when a licence is upgraded unless it was previously archived. Entra retention.

Those reports are separate from the Microsoft 365 Unified Audit Log managed through Purview. Purview Audit Standard's current default is 180 days. Audit Premium's one-year default covers specified workloads and appropriately licensed users; custom retention policies can take precedence. It is not a blanket one-year promise for every user and event. Purview retention policies.

Mimir recommends recording the effective policy and entitlement against each source, including any exported copy. Set the required period from the business investigation need and applicable obligations, with the responsible owner approving it. No duration in this article is a universal retention recommendation.

Review security logs already available before changing settings. Record what history exists, what will expire and which gaps cannot be recovered.

Check how older records are retrieved

In Azure Monitor, analytics retention and long-term retention have different access paths. Microsoft documents search jobs for Analytics data beyond analytics retention and for relevant older Basic data, while Auxiliary data remains queryable throughout its total retention period. Check the specific table plan instead of applying one rule to the workspace. Azure retention.

A search job is asynchronous and writes matching results to a new table. Microsoft documents charges associated with scanned data and ingested results, with a cost estimate before execution. Search jobs.

Mimir recommends proving an older-record retrieval before calling security logs available for investigations. Record the role required, search steps, expected cost approval and how the result will reach the responder. Obtain current prices for the selected region and service; this article provides no subscription quotation or retrieval-time guarantee.

Storage capacity and a workable investigation procedure should be budgeted together.

Protect the evidence and the people in it

The joint logging guidance recommends restricting access and protecting records against unauthorised modification or deletion. It also recognises that logs can contain sensitive information. Central collection needs its own protection rather than relying entirely on the source device. Secure storage guidance.

Mimir recommends separating routine search access from permissions to change collection, shorten retention or delete records. Identify a second authorised person who can retrieve evidence when the usual administrator is unavailable. Test that person's actual role, including any approval step required for an export.

Treat exported security logs as controlled material. Use a restricted case location, record who created the export and preserve the original alongside any working copy. Avoid posting raw records in broad support channels. Decide which identifiers are needed for an investigation before widening collection to include additional personal or business information.

A file checksum can help detect a later byte change, but it does not prove that the original event was truthful or complete. Evidence quality still depends on the source and the documented collection route.

Notice when collection stops

A quiet dashboard needs interpretation. Mimir recommends monitoring expected sources and recent arrival times, alongside errors reported by collectors and connectors. Set an expected reporting pattern for each source. A low-activity system needs a different test from a service that normally emits events continuously.

Azure Monitor documentation distinguishes event creation, client collection and upload, network transit and service processing. These stages can add different delays. Treat a published latency description as context, not as a guarantee for your configuration. Ingestion timing.

For security logs used in time-sensitive response, document who investigates a missed reporting expectation and how they are contacted. The check should be able to reach them even when the main reporting view is unavailable. Test an approved, harmless interruption in a suitable environment before relying on the escalation route.

Preserve event time and collection time as separate fields where the platform supports them. Record timezone conventions so an investigator does not mistake a delayed arrival for a later business action. Recheck parsing after a source changes its format.

Rehearse a retrieval with a known event

Mimir recommends a controlled exercise using an approved account and a harmless action that the chosen service documents as auditable. Write down the expected event before performing the action. Avoid changing production permissions merely to create a test record when a suitable test resource can answer the same question.

Ask the responder to find the event with their normal investigation access. In Purview, Microsoft requires the appropriate Audit Logs or View-Only Audit Logs roles to search; access to other administration areas does not replace that requirement. Audit search permissions.

Capture the source, account or object identifier, activity, event time, arrival time where available, search scope and result. Confirm that the export retains the fields needed to explain what happened. Try a retained older event as a separate check; finding today's activity does not demonstrate historical retrieval.

If the search returns nothing, record an unresolved gap. Check whether the event was generated, collected, retained and included in the searcher's scope. An empty result does not establish that the activity never occurred.

This exercise checks the selected evidence route. It does not validate every threat detection or replace a specialist investigation. Likewise, a backup restore drill tests a different capability: restoring usable business data.

Give the remaining gaps an owner

Close the exercise with a decision record rather than a screenshot of a successful search. List what worked, what remains unavailable, the consequence for the business question and the person responsible for each correction. Agree a review date when the system, collector, licensing or retention policy changes.

Mimir recommends prioritising missing evidence for important decisions before collecting more low-value events. For security logs that remain outside the agreed coverage, make the limitation visible to the people expected to respond. Do not describe a logging platform as a complete incident-response service unless responsibilities and operating arrangements support that claim.

This workflow needs adaptation for operational technology, safety-critical systems and environments where testing could disrupt essential work. Use the relevant system specialists and approved procedures there. It also does not prescribe a legal retention period or guarantee evidential admissibility.

The useful outcome is a documented, repeatable way to obtain security logs for an agreed question, with known access, retention, retrieval costs and gaps. That gives both the business owner and the responder something concrete to review.