The plan on the shelf
Plenty of businesses technically have an incident response plan. It was written years ago, possibly for an insurance application, and it describes a world of servers in a cupboard and a virus on a PC. It names people who have left. The one certainty about it is that on the day something actually happens, nobody will open it.
Meanwhile the incidents that actually arrive in a modern business look like this: a supplier emails to say your account sent them a strange invoice. A member of staff calls because files on the shared drive have unfamiliar extensions. Someone in accounts approved a sign-in prompt at 2am without thinking. The common thread is that they all begin inside Microsoft 365, in identity and email, and the plan on the shelf has nothing to say about any of it.
NIS2 turns this from an embarrassment into an exposure, because the directive does not just ask you to respond well. It asks you to respond on a clock.
What the law actually requires
Two parts of NIS2 meet here. Article 21 requires incident handling as one of the mandatory security measures: a real capability to detect, analyse, contain and recover. And Article 23 sets the reporting obligation for significant incidents, and it is staged, which is the detail most coverage still gets wrong. An early warning within 24 hours of becoming aware. A fuller incident notification within 72 hours. An intermediate update if the authority asks. A final report one month after that notification. Where a significant incident is likely to affect what you provide to your customers, telling them promptly is part of the job too.
An incident is "significant", in the directive's terms, when it causes or can cause severe operational disruption or financial loss, or affects others by causing considerable damage. You will notice that deciding whether an incident crosses that line is itself work, and it is work the 24-hour clock is already running against.
What a real plan contains
Not fifty pages. A plan that works is short enough to be used at speed by frightened people. It answers six questions in advance.
Who notices? Every plan silently assumes detection, and this is where plans fail first. Name the alerts that exist in your tenant, and the human who receives each one, including at weekends. If the honest answer is that no alerts are configured and nobody is named, the plan is fiction and this is the first thing to fix.
Who decides? One named person, with a deputy, empowered to declare an incident, judge it significant or not, and spend money out of hours. Committees do not meet inside 24 hours.
Test that answer now, with three questions. Which specific alert, ticket or log entry starts your clock, and which named person is allowed to declare it? In the last real incident, how long was it, measured rather than remembered, between the first signal and someone saying this is an incident? And who declares if the signal arrives at 2am on a Sunday? A watched tenant with nobody named to declare produces no more awareness than an unwatched one.
What do we do first? The first hour's moves, written as steps, for the three or four scenarios you are actually likely to meet: a compromised account, ransomware on the files, a fraudulent payment attempt, data leaving that should not have. Contain first: cut the account's sessions, isolate the device, stop the sync. Most of the levers are in the tenant; the plan should name where yours are, and whether your licences include them.
Who do we tell, and when? The CSIRT or competent authority your country designates, and the 24-hour early warning, drafted as a skeleton in advance with blanks to fill. Your insurer, whose policy probably requires prompt notice. Affected customers, whose own NIS2 obligations may make your incident theirs. Nobody thinks clearly about wording at 3am; do the thinking now.
What do we keep? Evidence. Sign-in logs, audit logs, mail traces, copies of the malicious message. The final report must set out the type of threat or the likely root cause; teams that wiped and reinstalled on day one find they have destroyed the answer.
How do we get back? Restore paths and their owners, which for Microsoft 365 means knowing exactly what your backup covers and having actually tested a restore.
The implication
The staged clock quietly rewrites what "having a plan" means. A plan that exists but is not connected to detection cannot start inside 24 hours, because the clock starts on awareness and an unwatched tenant is not aware. A plan that exists but has never been rehearsed will burn its first day on questions the paper should have answered. Under NIS2, both failures happen in front of the authority you report to, and both are visible afterwards in the timeline your final report has to reconstruct.
Where to start
Write the one-page version first: the six answers above, on a single sheet, with names and phone numbers. The first draft is an afternoon's work, and it embarrasses the fifty-page shelf plan on day one.
Then connect it to reality: turn on the tenant alerts that matter, route them to the named people, and check they fire. Then rehearse once, on a tabletop, with the actual people: a compromised account on a Friday afternoon, walk it through, note where the plan lied to you, fix it. An hour of rehearsal buys more capability than another ten pages would.
Then put a date in the diary to do it again next year, because plans rot at the speed people change jobs.
This is work we do with clients, and the pattern repeats: the plan is the easy part, the wiring of detection to named humans is the real project, and the rehearsal is where the confidence comes from. A business that has done these three things does not fear the 24-hour clock. It has already run against it once, in private, when nothing was burning.