A cyber incident is a matter of 'when', not 'if'. Create a foundational plan to guide your team's response by answering three simple questions.
This context helps the AI create a more relevant plan.
It produces a first-draft incident response plan structured around the six recognised phases: preparation, identification, containment, eradication, recovery and lessons learned. You give it your sector, your rough size and your critical systems, and it writes actionable steps for each phase rather than generic advice.
The output is a Word document you can edit, circulate and put in front of a board. It is a starting point that takes minutes instead of the fortnight a blank page usually costs.
Put real names against the roles
A plan that says "the incident manager" is not a plan. Replace every role with a named person and a deputy, because deputies are frequently who you get at 11pm on a Friday.
Add your actual systems and suppliers
Generic plans fail at the specifics. Name the systems that would stop you trading, the suppliers who can access them, and the phone numbers you would need when email is unavailable.
Decide the authority questions now
Who can authorise taking a customer-facing system offline? Who approves unplanned spend? Who speaks to customers? These are the decisions that stall a real incident, and they are far cheaper to settle on a Tuesday afternoon.
Test it, because an untested plan is a document
Walk a scenario through it with the people named in it. The gap between a plan that reads well and a plan that works is only ever found by running it.
It cannot know your organisation. It does not know which supplier holds your payroll data, which system your revenue depends on, or that your finance director is on leave in August. It also cannot tell you whether the plan works, because only exercising it does that. Treat the output as a structure to fill in, not a finished document.
As a first draft, yes. It gives you a complete, correctly structured plan far faster than starting from a blank page, and a structured plan you actually finish beats a perfect one you never write. It is not sufficient on its own, because it cannot name your people, your systems or your suppliers, and those specifics are what make a plan usable under pressure.
Not by itself. Auditors and insurers increasingly ask whether response arrangements have been tested, not merely written. A plan plus evidence that you exercised it, with a timestamped record of the decisions taken, is a far stronger position than a document alone.
At least annually, and whenever something material changes: a new core system, a significant new supplier, a merger, or a real near-miss. The UK Cyber Governance Code of Practice, published by DSIT and the NCSC in April 2025, expects boards to ensure plans are tested at least annually.
No. The plan is generated and displayed in your browser and is never stored or transmitted to us. If you ask us to review it, only your email address, your organisation if you give one, and the name of the tool are sent.