IR plan development, scenario playbooks, tabletop exercises, and retainer advisory support — the capability built before the incident happens, so the response when it does is measured rather than reactive.
Most IR plans are written once, approved, and filed. They describe roles and responsibilities that made sense at the time of writing, reference contact details for people who have since left, and outline escalation paths that nobody has ever followed under pressure. The plan exists. Whether the business could actually execute it during a real incident is an untested assumption.
The failures in incident response are almost never technical. They are organisational — nobody knew who was responsible for the decision to notify customers, the legal team had never been part of an IR exercise and spent two hours debating disclosure obligations while the clock ran, the executive team had no communication template and improvised a statement that created more problems than it solved.
The companies that respond well to incidents are not the ones with the longest IR plans. They are the ones that have practised — where the decisions that need to be made under pressure have already been made in a low-stakes environment, the escalation paths have been tested, and everyone involved knows their role before the call starts.
The plan had been approved eighteen months earlier. It named an incident commander who had left, a legal contact who had changed firms, and a PR agency relationship that had ended. During a real incident, the first forty minutes were spent establishing who was actually responsible for what. The plan had been maintained for compliance. It had not been maintained for use.
The scenario was a ransomware attack with potential customer data exposure. Thirty minutes into the exercise, it became clear that the CISO assumed legal would advise on notification thresholds and legal assumed the CISO would make the determination. Neither had read the relevant data protection obligations in the context of the business. The tabletop cost an afternoon. The gap it found would have cost weeks in a real incident.
The backup process was documented and running. The restoration process had never been tested end-to-end. During the incident, the first restoration attempt failed due to a configuration issue introduced eight months earlier. The second attempt took six hours longer than the playbook assumed. The playbook described what should happen. Nobody had checked whether it matched what actually would.
The gap between having an IR plan and being ready to respond is not a documentation gap. It is a practice gap. The decisions that need to be made in the first hours of an incident — who to notify, what to contain, what to communicate — are made better when they have been made before, under lower stakes, with the right people in the room.
A document is not a capability. A capability is a tested plan, a set of practised playbooks, a team that has made decisions together under simulated pressure, and an advisor they can reach when the real thing happens.
An incident response plan and a set of scenario-specific playbooks written to reflect how the business actually operates — its technology stack, its team structure, its regulatory obligations, and its most likely threat scenarios. Not a template. Not a generic framework document.
A facilitated exercise that puts the right people — technical leads, legal, communications, and executive leadership — through a realistic incident scenario. The goal is not to simulate a perfect response. It is to surface the gaps, misalignments, and untested assumptions that will cause problems in a real incident before they cause problems in a real incident.
When an incident happens, the first call goes to someone already familiar with the business — the environment, the technology, the team, the regulatory context. Not a cold introduction to a breach response firm at midnight. A retainer arrangement provides priority advisory access, agreed response times, and a relationship established before the pressure is on.
A structured review conducted after an incident or a tabletop exercise to capture what worked, what failed, what was not in the plan, and what changes the business needs to make. Post-incident reviews are where the plan matures — every incident is a test, and every test should produce an updated, more accurate capability.
The engagement starts with understanding the business — its technology, its team, its regulatory obligations, and its realistic threat scenarios. It ends with a capability the business owns and can maintain.
A review of the existing IR plan and playbooks against the current operating environment — technology stack, team structure, external relationships, and regulatory obligations. Most IR plans fail this review not because they are wrong but because they are stale. A plan written for the business eighteen months ago describes a different business. The review establishes the gap between what the plan says and what the business can actually do.
Week 1The IR plan and scenario playbooks are developed in collaboration with the technical, legal, and communications leads who will be executing them — not written in isolation and handed over. Escalation paths are confirmed. Decision authorities are agreed. External contacts are verified. A plan that the team helped write is a plan the team understands. A plan that was sent to them is a plan they will read for the first time when the incident starts.
Weeks 2–4A facilitated tabletop exercise using a scenario calibrated to the organisation's specific threat model — not a generic ransomware scenario that could apply to any business. Technical and non-technical participants are in the same room. The scenario is designed to surface the cross-functional gaps that technical-only exercises miss. The goal is to find the gaps before the incident does. The exercise report documents what was found and what needs to change.
Week 5The plan is updated based on the tabletop findings. The retainer structure — access, response times, and escalation path — is agreed and documented before the engagement closes. The annual review date is calendared. An IR capability without a maintenance schedule is a plan that will drift. The first annual review is the most important commitment the engagement produces — it is what turns a tested plan into a sustained capability.
Week 6The organisations that benefit most from this engagement are not necessarily the ones facing the most immediate threat. They are the ones who have recognised that an untested IR plan is not a capability — it is a liability waiting to be tested under the worst possible conditions.
The plan exists. It was approved. It has never been run as an exercise, the escalation contacts have never been tested out-of-hours, and the legal and communications teams have never been in the same room for an IR scenario. The plan describes a response. Whether it would actually work is unknown — and unknown is the wrong state to be in before an incident that forces the answer.
The business has changed. New cloud infrastructure, new team members, new third-party dependencies, new regulatory obligations. The IR plan still references the previous architecture, the previous team structure, and the external contacts from the previous engagement. A plan that does not reflect the current business is not a plan for the current business — it is a plan for a company that no longer exists.
Both frameworks require documented incident response procedures, evidence of testing, and mechanisms for post-incident review. Auditors test not just whether the plan exists but whether the right people have been trained, whether exercises have been conducted, and whether lessons from previous incidents or exercises have been incorporated. A plan created for the audit will satisfy a Type I. Evidence of a functioning capability is what Type II requires.
The incident happened. The response worked, partially. The gaps were visible — the wrong people were notified first, the communication went out before legal had reviewed it, the containment playbook did not account for the cloud environment. The post-incident review identified what failed. This engagement rebuilds the capability around what was actually learned — not what a template assumes.
The engagement closes with a capability — not a document set. The plan has been tested, the playbooks reflect the actual environment, and the retainer is in place before it is needed.
A complete IR plan with current escalation contacts, confirmed decision authorities, and verified external relationships. Updated after the tabletop exercise to reflect what was actually learned. Specific to the business as it operates today — not adapted from a template.
Step-by-step playbooks for the scenarios most relevant to the business — written around the actual technology stack, the actual team, and the actual regulatory obligations. Including communication templates pre-drafted for customers, regulators, board, and media.
A documented report of the tabletop exercise findings — the decisions that were made, the gaps that surfaced, the misalignments between technical and non-technical teams, and the specific plan updates required. Evidence of testing that satisfies auditor requirements and, more importantly, makes the capability better.
A documented retainer structure: response times, escalation path, scope of advisory support, and coordination approach for external relationships. The relationship and context established before the incident — so the first call goes to someone who already knows the business.
When an incident starts, the right people know their roles and have practised them. The escalation path works because it has been tested. Legal and communications are already aligned on notification obligations. The playbook for the scenario matches the actual environment. The advisor on the first call already knows the business. The response is measured — not because the incident was easy, but because the preparation was real.