A ransomware attack hits on Friday at 17:30. The IT admin's phone rings. No one knows who to call, what to disconnect, or what to tell the authorities. By Monday, the damage has compounded because every hour of inaction allowed lateral movement through the network.
This scenario repeats itself across European SMEs every week. The organizations that survive with minimal damage are not the ones with the most expensive tools — they are the ones that had a plan.
Why Most SMEs Don't Have a Plan
The most common reason is the belief that incident response planning is something for large enterprises. The second most common reason is not knowing where to start. Both are solvable.
NIS2 now requires incident notification within 24 hours for organizations in scope. Without a pre-built response process, meeting that deadline is nearly impossible. But even outside of regulatory requirements, the business case is clear: organizations with tested incident response plans contain breaches 74 days faster on average, according to IBM's Cost of a Data Breach Report.
The Minimum Viable Incident Response Plan
You do not need a 200-page document. You need answers to six questions, written down, accessible offline, and reviewed quarterly.
1. Who Decides?
Define an incident response lead — typically the IT manager or an external security partner. Define who authorizes critical decisions: disconnecting systems, engaging external forensics, notifying customers. During an active incident, decision authority must be clear and pre-delegated.
2. Who Do We Call?
Maintain a physical (printed) contact list:
- Internal incident response lead
- External IT security partner or MSSP
- Legal counsel with data protection expertise
- Cyber insurance provider's claims hotline
- BSI reporting contact (for NIS2-regulated entities)
- State data protection authority (for GDPR-reportable incidents)
During an incident, email and internal chat may be compromised. Phone numbers and out-of-band communication channels must be documented in advance.
3. What Do We Disconnect?
Pre-identify which systems can be isolated without halting business-critical operations entirely. Know where your network segmentation points are. Know how to disable external VPN access, revoke OAuth tokens, and force sign-out of all M365 sessions. These are not decisions you want to make for the first time under pressure.
4. What Do We Preserve?
Evidence preservation is critical for forensic analysis and legal proceedings. Do not reimage machines before forensic images are taken. Do not delete logs. Do not change passwords for compromised accounts before capturing sign-in logs and audit trails. Document every action taken from the moment the incident is discovered.
5. Who Do We Notify?
GDPR requires notification to the supervisory authority within 72 hours if personal data is affected. NIS2 requires notification within 24 hours for significant incidents. Your plan should include pre-drafted notification templates with blanks for incident-specific details.
6. How Do We Recover?
Define your recovery sequence: which systems come online first, how do you verify they are clean, and what is the criteria for declaring the incident resolved. Test your backup restoration process before you need it — the worst time to discover your backups are corrupted is during recovery from ransomware.
Testing the Plan
An untested plan is a hypothesis. Conduct a tabletop exercise annually: gather the response team, present a scenario, and walk through the response step by step. You will find gaps. That is the point.
The exercise does not need to be elaborate. Two hours, a realistic scenario, and honest discussion about what would actually happen is sufficient. Document the findings and update the plan.
The M365 Connection
Your Microsoft 365 tenant is both the most likely attack vector and the most critical evidence source. Audit log retention (90 days by default in E3, 180 days in E5) defines how far back you can investigate. If you are on Business Premium with 30-day retention, consider whether that is sufficient for your risk profile.
Conditional Access logs, sign-in logs, and Unified Audit Logs contain the forensic data you need. Ensure they are enabled, accessible, and that someone in your organization knows how to read them.
Book a consultation to build an incident response plan tailored to your organization and M365 environment.