How to Use Gemini to Draft a First-Pass Business Contingency Plan From Your IT Environment

The short answer: Most SMEs have working backups and no written Business Contingency Plan, and the gap only surfaces when a client, insurer or auditor asks for the document. Gemini can turn a plain description of your environment into a credible first draft — scope, RTO and RPO targets, a recovery sequence, roles and communications — in an afternoon rather than a quarter. What it cannot do is verify that any of those targets are achievable, and an untested plan is a document, not a capability.

A 90-person architecture practice in Singapore has backups that genuinely work. Veeam runs nightly against the on-premise file server and the project database, Microsoft 365 has a third-party backup, and the IT manager has restored individual files often enough to trust the process.

Then a government-linked client sends its updated vendor pack, and it contains a line that has not been there before: provide your business continuity plan, including recovery time objectives for systems holding client data. Tender response due in three weeks.

There is no document. There is a backup schedule, a monitoring dashboard, and a lot of knowledge in one person's head. The honest position — "our backups are solid and we have never lost anything" — is true and is not an answer to the question, because the question is about what happens in the four hours after the file server dies, and who decides what, and in what order things come back.

That is the gap this article is about: not backup capability, which the firm has, but the written, reviewable plan that demonstrates it. It is one of the most common documentation gaps in SME IT, and it is a good match for what an AI assistant is actually good at.

Why Most SMEs Have Backups but No Written BCP

Backups get built because something breaks. Plans get written because somebody asks. For most SMEs the second thing simply happens later than the first, usually years later, and usually because of an external trigger rather than an internal one.

The triggers are increasingly common. Enterprise and public-sector clients put continuity questions into vendor packs. Cyber-insurance applications ask for RTO and RPO figures and what testing you do. Certification schemes expect documented continuity arrangements. A parent company's group audit asks the subsidiary for its plan. None of these are satisfied by a screenshot of a healthy backup job.

The reason it stays undone is that a BCP is a genuinely hard blank page. It is not a technical document — it is an operational one, requiring decisions about which systems matter in what order, how long the business can tolerate being without each, who is authorised to declare an incident, and who tells clients. An IT manager asked to produce one from nothing will reasonably put it behind work that is actually broken, every time, until a deadline arrives.

What Gemini Can Actually Draft From an Environment Description

Gemini is available as a standalone assistant and integrated into Google Workspace, where it can draft directly inside Docs. Its handling of long inputs makes it practical to paste in a complete description of an environment — systems, dependencies, sites, headcount, what is cloud and what is on-premise — and work from that rather than from a generic template. Which features are available depends on your plan and edition, so check current documentation rather than assuming.

The honest framing is that this converts a blank page into a reviewable draft. It is the structure, the vocabulary and the completeness that you are getting: the sections an assessor expects, the questions you should have asked, the arrangement of what you already know. Every number in it is a proposal that you have to confirm or replace, and the plan only becomes real when someone tests it. A BCP written and never rehearsed is a document that will fail at the moment it is needed.

A structured outline — scope, RTO and RPO targets, recovery sequence, roles

The productive prompt is not "write us a BCP". It is a description of your environment plus a request for the plan's structure, with explicit placeholders wherever a decision is required from the business rather than from IT.

A workable structure: scope and what is deliberately out of it; the disruption scenarios covered — site loss, system failure, ransomware, key-supplier outage; a system inventory tiered by criticality; RTO and RPO per tier; the recovery sequence and its dependencies; roles, with named deputies; invocation criteria and who may declare; internal and client communications; and the test and review schedule.

Two of those deserve special attention, because they are where AI-drafted plans usually go wrong. RTO and RPO are business decisions, not IT preferences — how long the firm can operate without a system, and how much work it can afford to lose. Ask for them as explicit questions for the business to answer, and treat any number the model proposes as a prompt for that conversation.

Turning a list of systems into a prioritised recovery order

The genuinely useful second output is sequencing. Most SME system lists are alphabetical or historical; almost none are ordered by what has to come back first, and that ordering is the part a plan lives or dies on.

Describe the dependencies plainly — the project database needs the file server's shares, the quoting tool authenticates against on-premise directory services, the VPN has to be up before remote staff can do anything — and ask for a recovery sequence derived from them, with the dependency stated for each step. What comes back is usually 80% right and wrong in one instructive place, and that wrong place is typically a dependency the team had stopped noticing. Finding it is worth the exercise on its own.

A Practical Workflow — From "Here's What We Run" to a Reviewable First Draft

1. Write the environment description first, as a document. Systems, versions, where each runs, what backs it up, how often, where the backup lands, and who administers it. This has value whether or not you write a plan, and everything downstream depends on its accuracy.

2. Ask for the structure before any content. Get the section list, confirm it against what your client or insurer actually asked for, and adjust it before a single paragraph is drafted. Editing an outline is cheap; restructuring a finished draft is not.

3. Get the questions, not just the answers. Ask explicitly what the draft needs from the business that IT cannot decide — tolerable downtime per system, acceptable data loss, who can authorise an invocation. Take that list to a director. This conversation is the real work, and the draft exists to provoke it.

4. Draft section by section, with your own environment in each prompt. Generic continuity prose is worthless; a paragraph that names your file server, your backup tool and your actual dependency order is not. Keep the environment description in context throughout.

5. Read the recovery sequence as an engineer, not a reviewer. Walk it step by step against reality: is that server reachable if the domain controller is down, does the restore need a licence key nobody has, is the bandwidth there to pull that much data back in the stated window. Mark every step you are not sure about.

6. Set the RTO and RPO targets from evidence, then rehearse. Time an actual restore of a representative system and use that number, not an aspiration. Then run a tabletop with the people named in the plan, and record the date — being asked when you last tested is now a routine question.

An AI-Drafted BCP vs a Consultant-Written BCP vs No Written Plan at All

• An AI-drafted first pass. Removes the blank page, produces a complete and conventionally-structured document quickly, and — the underrated part — generates the list of questions the business has to answer. It cannot verify a single target, has no knowledge of your environment beyond what you paste, and will produce confident, plausible prose about a recovery that has never been attempted. Correct use: getting to a reviewable draft and a decision list fast, with every number treated as provisional.
• A consultant-written plan. Brings method, comparison against how other organisations in your sector handle the same risks, and an outside party's willingness to challenge optimistic assumptions. It costs real money and takes weeks, and the common failure is that it is delivered, filed and never rehearsed — the same fate as a bad plan, at a higher price. Correct use: regulated or contractually-demanding situations, and organisations complex enough that the sequencing genuinely needs expertise.
• No written plan. Not automatically negligent in a very small firm where one person can hold the whole recovery in their head and nobody is asking for a document. It stops being tenable the moment a client, insurer or auditor asks — or the moment that one person is on leave when the file server fails. Correct use: essentially none once anyone external is asking, and the ask is only getting more common.

Where a Draft Plan Is Dangerous If Untested

An RTO nobody has measured is a number, not a target. "Four hours" written into a plan and never tested is an assumption about restore throughput, licence availability, hardware on hand and the person who knows the process being reachable. Real restores routinely take several times the estimate the first time they are attempted, and the first attempt should not be during an incident.

A plan that names roles nobody has rehearsed will stall at the first decision. The step that fails is rarely technical. It is the moment when the plan says the incident lead declares an invocation and nobody is certain whether the situation qualifies, or whether they are allowed to authorise the spend. A tabletop surfaces this in an hour; an outage surfaces it expensively.

A confident document can make you less safe. This is the specific risk of a well-drafted plan built on untested assumptions: it converts an honest uncertainty into a stated commitment. Submitting a figure to an insurer or a client is a representation, and a plan is a poor place to be optimistic. Where a target is unverified, say so in the document and give the date you will test it.

Getting This Right — Infrastructure Detail in Prompts, Plan Testing, and When to Bring in IT

Be deliberate about how much of your environment you describe. A useful draft needs system roles, dependencies and rough scale. It does not need hostnames, IP addressing, public endpoints, admin account names or your backup vendor's portal details — a detailed description of your infrastructure and its recovery weak points is precisely the document an attacker would want. Describe functions rather than identifiers, and check your own policy on business-tier versus consumer-tier AI accounts before pasting anything.

Keep the plan short enough to be used under pressure. Continuity plans fail by length as often as by content. The part that matters during an incident is a few pages: invocation criteria, who does what, the recovery sequence, and the contact list. Everything else is annex. Ask for that split explicitly, because an assistant left to itself will produce a uniformly long document.

Bring IT in for the sequencing and the testing, which is where the plan is really made. Which system genuinely has to come back first, whether your RPO is achievable with the backup schedule you actually run, whether an immutable or offline copy exists for a ransomware scenario, and how long a full restore really takes are questions answered by testing, not by drafting. That is also where a plan stops being paper.

Working out where an assistant genuinely helps in a continuity process — and where its output must be tested before anyone relies on it — is AI+ Support work. The capability underneath the document, including BCP strategy and methodology around RTO and RPO, on-premise and inter-cloud backup, offsite media storage and periodic recovery drills, is cloud managed backup, run by the same IT support team that would be executing the plan. For the discipline of rehearsing rather than filing a plan, see our write-up on generating incident-response tabletop scenarios; for the same structured-runbook technique applied to a go-live, see drafting UAT scripts and cutover runbooks.

Frequently Asked Questions

Does a draft plan satisfy what an auditor or insurer actually asks for?

A well-structured document gets you past the first question and not the second. Assessors ask what your RTO is, where the number came from, when you last tested, and what the test found — and a plan with targets nobody has measured and no test record answers only the first of those. Treat the draft as the thing that makes the conversation possible, then do the measuring and the rehearsing, because that is what is actually being assessed.

How specific does our environment description need to be?

Specific about function and dependency, vague about identifiers. The draft needs to know that your project database depends on shares hosted by an on-premise file server, that remote staff reach it over VPN, and that the nightly backup lands on a NAS with a weekly offsite copy. It does not need hostnames, addresses or account names. That split gives you a draft grounded in your actual environment without writing down a map of it.

Does this replace an actual recovery drill?

No, and this is the single most important limit to hold onto. Drafting produces a plan; a drill produces evidence that the plan works and, almost always, a list of things that do not. The usual findings are mundane and decisive — a restore that takes far longer than assumed, a licence key nobody could find, a dependency nobody had documented. Plan first if it helps you organise the drill, but the drill is the part that makes the plan real.

How often should a BCP be updated?

On a schedule and on change, with the change trigger mattering more. An annual review plus a test is a common baseline and is what most assessors expect to see evidenced. But the changes that invalidate a plan are things like a system migration to cloud, a new office, a backup platform change, or the named incident lead leaving — any of which can make the document wrong within a week of the annual review. Tie plan updates to those events explicitly, rather than only to the calendar.

Can we use this to answer the continuity section of a client questionnaire directly?

Use it to prepare, not to answer on autopilot. Questionnaire responses are representations to a client, sometimes contractual, and an unverified figure pasted from a draft is a commitment you have not checked. The sound pattern is to build the plan, verify the targets by testing, and then answer from the verified document — which is also faster the second and third time a client asks, because the underlying work is already done.