Most organisations have an incident response plan. Far fewer have one that gets opened during an incident. The document exists because an auditor asked for it, it runs to forty pages, and at 2am when the finance director's mailbox is sending invoices to the client list, nobody reads forty pages.
A plan that works has a different shape.
The bulk of a typical plan explains what ransomware is. Nobody needs that during an incident. What people need are decisions that are painful to make under pressure, made calmly in advance:
An overlooked failure: the contact list lives on the file share that is now encrypted, and the escalation tree is in a mailbox nobody can reach. Keep an offline copy — printed, or in a separate tenant — with mobile numbers for the response team, your insurer's hotline, your MSP's out-of-hours line, and legal counsel.
The same applies to the plan itself. If it is only in SharePoint, it is only available when SharePoint is.
Under pressure, drafting a customer notification takes hours and produces something legal will rewrite. Pre-approved skeletons — for staff, customers, and a holding statement for media — reduce that to filling in specifics. They also prevent the well-meaning improvised update that creates liability.
Technical responders are the obvious part. The roles that get missed are the scribe who maintains a timestamped log of actions taken, and the single point of contact who shields responders from status requests. Without a scribe, the post-incident review and any insurance claim are reconstructions from memory. Without a coordinator, your best engineer spends the incident answering "any update?".
You do not need to take production down to test a plan. A two-hour tabletop exercise — a scenario, the response team in a room, and someone injecting complications — surfaces most gaps. The predictable findings: the contact list is stale, nobody is certain who declares an incident, and the backup restore estimate is optimistic.
Run one annually, and after any significant change to the environment or the team. Write down what failed; that record is more valuable than the plan itself.
If your plan cannot be actioned from its first two pages, it is documentation rather than a plan. Put the decision tree, the contact list and the first ten actions at the front. Everything else is an appendix.
SegueIT provides incident response support as part of managed security, including out-of-hours escalation across our India and Australia operations. Learn more about our security services.