Incident response readiness usually lands on the boardroom agenda only after a real breach has happened. In Microsoft 365 and Azure environments, I regularly find that the audit trails an investigation would depend on simply aren't there. Just as often, break-glass accounts and contact chains exist on paper but have never been tested. Being ready means having technical log retention, mailbox forensics and practical emergency procedures in place together. Without that, you're relying on hope.

Default retention periods are shorter than most people expect

Unless you actively extend it, log retention in the cloud is very short. With a P1 or P2 licence, Microsoft Entra ID keeps sign-in and audit logs in the portal for only 30 days. If a breach goes unnoticed for weeks, that doesn't help you. The Microsoft 365 Unified Audit Log retains data for 180 days as standard, and even that can fall short for slow, advanced attacks. Defender XDR advanced hunting data is often available for only 30 days (depending on licence and workload). Exchange mailbox audit is now on by default, but the MailItemsAccessed action, which matters most here, is limited by both licensing and retention. I cover the important details in Purview Audit MailItemsAccessed: Better mailbox forensics.

Practical tip: Default settings can give you a false sense of security. Check regularly which log types and retention periods you actually need for incident response, and set up alerts before data ages out.

Microsoft maintains current guidance on audit log retention and Entra ID log retention. Both pages are worth bookmarking.

Your key logs belong in Log Analytics or Sentinel

If you take incident response seriously, you need to centralise logs in Log Analytics or Microsoft Sentinel. Entra sign-in and audit logs can be streamed to a Log Analytics workspace through Diagnostic Settings in the Entra portal (Monitoring → Diagnostic settings), and they should be. That gives you retention beyond the portal defaults and lets you hunt with KQL at the moment you need it. The Unified Audit Log and Defender XDR can be exported too. Be aware, though, that mailbox and Defender data at scale often requires E5 licensing (or add-ons).

The diagram below shows how these core sources feed into a logging setup built for incident readiness:

flowchart TD
  EntraLogs["Entra Logs"] --> LogAnalytics["Log Analytics"]
  AuditLog["M365 Audit Log"] --> LogAnalytics
  DefenderLogs["Defender XDR Logs"] --> LogAnalytics
  MailboxAudit["Mailbox Audit"] --> LogAnalytics
  LogAnalytics --> Sentinel["Microsoft Sentinel"]

Figure: Typical log forwarding and central collection for incident response in Microsoft 365 and Azure.

Once everything is in one place, you can use KQL in Microsoft Sentinel, in the Log Analytics workspace or in advanced hunting in the Defender portal to look for suspicious authentications or signs of token theft.

Readiness also depends on break-glass accounts, contacts and retainers

The technical side covers only half of it. Organisation counts just as much. If admin accounts are compromised, you need break-glass accounts that actually work (not blocked by Conditional Access or MFA), a current contact tree with every escalation number, and ideally an IR retainer with a specialist firm agreed in advance. I can't count how often I've found break-glass access blocked by well-meant policies or never properly tested. The only fix is a real, documented fire drill at least once a year.

Your contact list needs more than your IT admins. Include out-of-hours contacts such as Microsoft Premier support, IR partners, privacy and data protection leads, and executives. If you haven't worked out how to escalate to Microsoft support before a crisis, do it now. Microsoft's incident response overview is a useful reference for what to expect once the clock starts running.

Tabletop exercises play out a Microsoft 365 compromise

Over the last year, tabletop exercises have gone from rare to routine for many of my clients, and they open everyone's eyes every time. I recommend running a realistic scenario at least once a year, for example a breached global admin account. These elements have worked well in the exercises I've run:

  • A privileged Entra account is compromised
  • No working MFA or CA bypass on break-glass or recovery accounts
  • Audit and Defender XDR logs are needed, but don't go back far enough
  • Your main comms (Teams, mail) are out of action
  • You need to escalate to Microsoft support immediately

You find out very quickly whether your playbooks work without your usual infrastructure, and whether the key people know what they're supposed to do.

I see preparation as the best protection

Incident response readiness isn't only a concern for large companies or regulated industries. In the cloud, speed of response decides a lot, and that speed depends on whether your logs, contacts and practised procedures are ready. Each hour lost to missing logs, untested break-glass access or unclear escalation paths is an hour the attacker gains. If you get log retention, automated forwarding and tested playbooks right, you're already ahead of most organisations. You'll also sleep better.