Microsoft 365 Incident Response Plan

Most small and mid-sized organisations do not need a giant incident response manual for Microsoft 365.

They need a plan that works when a mailbox starts sending junk, a risky sign-in appears from somewhere strange, or someone notices a document was shared far wider than intended. In that moment, the value of the plan is not elegance. It is whether the next ten actions are clear.

NCSC's incident guidance makes the same basic point in broader terms: incident response needs defined processes, roles, and supporting capabilities. Microsoft says much the same from the product side. Incidents need owners, status, comments, and evidence. Both are really describing the same thing - structure under pressure.

The four scenarios to plan for

For Microsoft 365-heavy SMEs, these usually matter most:

Scenario	First thing you need to know
Mailbox compromise	What was sent, forwarded, read, or delegated
Privileged account compromise	What changed in the tenant and how much access the account had
Data exposure	What was shared, who accessed it, and whether access persists
Endpoint-linked compromise	Which user, which device, and whether tokens or sessions are still active

You can cover a lot of ground with those four.

First 30 minutes

Keep this section brutally practical.

1. Name one incident owner.
2. Set a simple working severity.
3. Preserve the evidence you already have.
4. Revoke active sessions for affected users where appropriate.
5. Reset credentials or block sign-in where needed.
6. Review recent sign-ins and suspicious locations.
7. Check mailbox rules, forwarding, and delegation.
8. Review audit activity over the relevant timeline.
9. Contain the endpoint if device compromise is suspected.
10. Start a running incident log.

The order matters a bit, but not as much as discipline does. One owner, one timeline, one source of truth.

What to log as you go

You do not need a fancy ticketing flow to begin with. You do need a usable record.

Time	Action	Owner	Evidence
09:12	User sign-in blocked	IT	Admin action note or screenshot
09:18	Sessions revoked	IT	Entra action record
09:24	Mailbox forwarding reviewed	IT	Mail settings output
09:39	Audit search exported	IT	CSV or saved search result
09:50	Staff comms approved	Management	Message copy

If someone else had to pick up the incident halfway through, could they understand this table in two minutes? That is the standard.

Do not improvise the comms side

One thing smaller teams under-rate is communications control.

Decide in advance:

• Who tells staff what happened.
• Who speaks to customers or suppliers if needed.
• Who decides whether legal, insurance, or regulatory escalation is required.
• Where off-system communication happens if the main tenant is part of the problem.

You do not need to over-engineer this. You just do not want five people sending five different messages while the technical picture is still forming.

The minimum Microsoft 365 capabilities behind the plan

The plan is only as good as the tools behind it.

• Access to Entra sign-in data.
• Access to Purview Audit or equivalent audit sources.
• Ability to investigate mailbox behaviour.
• Ability to review incidents and alerts in Defender where licensed.
• A known process for isolating or containing endpoints.

If any of those are missing, note that in the plan honestly. A modest plan with clear gaps is still useful. A perfect-looking plan built on assumptions is not.

References

• NCSC: Incident management
• NCSC: Plan your cyber incident response processes
• Microsoft Learn: Responding to a compromised cloud email account
• Microsoft Learn: Manage incidents in Microsoft Defender