Start with the questions an investigation must answer
Logging should support decisions. For each important service, define the questions responders may need to answer: which identity acted, what changed, from which device or workload, through which interface, at what time and with what result? Then identify the events and context required. Collecting every available record without a purpose can increase cost while hiding the signals that matter.
Prioritise identity providers, administrative actions, cloud control planes, email, endpoint security, remote access and critical applications. Include business-relevant events such as changes to payment details or privileged workflows where systems can record them safely. Document the expected source, owner, retention and time standard so absence of data is visible rather than discovered during an incident.
Protect the evidence and its route
Logs produced on an affected system may be altered, deleted or made unavailable. Send important records to a controlled central location with access separated from ordinary administration where practical. Protect collection credentials, restrict who can change retention or disable sources and alert on interruptions that create blind spots.
Time consistency matters when events must be reconstructed across identity, cloud and endpoint systems. Use reliable time synchronisation and preserve original timestamps, source identifiers and relevant collection metadata. Retention should reflect investigation needs, legal advice, cost and data minimisation—not an arbitrary default that nobody has tested against plausible response timelines.
Make detections explainable and actionable
A useful detection states the behaviour of concern, the data it depends on, important assumptions, expected false positives and the first investigative steps. Test it with authorised scenarios and known-good activity. A rule that has never produced a comprehensible alert is not proven merely because it is enabled.
Attach context that helps a responder decide: identity role, asset owner, resource sensitivity, recent related activity and the health of the source. Define who receives the alert, when it escalates and what actions are permitted. High alert volume can conceal weak coverage, so review duplicates, stale rules and recurring false positives as engineering defects.
Test the evidence path before an incident
Run short exercises that begin with a question rather than a dashboard. Can the team identify a newly privileged account, a suspicious mailbox rule, a remote administration session or a cloud policy change? Measure how long it takes to locate and interpret the evidence, and record which fields or sources are missing.
Treat source health as part of detection. Monitor ingestion delay, schema changes, disabled audit settings and unexpected volume drops. After incidents and exercises, update both collection and investigation guidance. The objective is not maximum data; it is dependable evidence that lets authorised people make timely, defensible decisions.
What to do next.
- ✓Define the investigation questions for each critical service.
- ✓Prioritise identity, administration and control-plane events.
- ✓Centralise and protect important evidence.
- ✓Monitor source health, time consistency and ingestion delay.
- ✓Document assumptions and first steps for every detection.
- ✓Exercise the evidence path and fund the gaps.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.