Workshop Resources · Plan
Build your plan
Four sessions to create a BC/DR draft. Click each chapter to open.
The plan generation is based on using the AI prompts, as building a plan is a complex task and solving the blank page problem is helpful.
If you want to attempt to write the plan yourself, the pages below outline the information that is important to collect and Step 3 contains a checklist of the sections necessary for the plan.
The intake worksheet in Step 0 will get you well on the way to developing a picture of the situation in your business. The prompts are also a good source of information.
The main things we are trying to learn are:
- What are the critical systems of our business, from the perspective of various stakeholders?
- What are the consequences of those systems having problems?
- Who is our incident response team? What roles and responsibilities do they have?
- How do we recover systems, documents, data?
- How and when do we test and train our readiness and improve our plan over time?
Get in touch with us if you need assistance.
0 Before you start · 10–15 min BC/DR Intake Worksheet
Basic information gathered up front. Answer what you can.
## 1. Company basics
- Company name:
- One-line description of what we do:
- Industry / sector:
- Total headcount:
- Engineering/technical headcount:
- Website URL:
## 2. What already exists
- Do we have an existing IR, on-call, or disaster recovery doc? Y / N — if yes, attach it.
- Do we have a status page or external incident comms channel? Y / N — where:
- Do we have an internal incident channel (Slack, Teams, etc.)? Y / N — name:
- Last time we had an incident that needed cross-team response:
## 3. Past incidents (1-2 lines each, no detail needed yet)
1. 1\.
2. 2\.
3. 3\.
## 4. Critical systems
List 3-6 systems or dependencies where an outage or breach would be severely impacting our business (a P1/P2):
1. 1\.
2. 2\.
3. 3\.
4. 4\.
5. 5\.
6. 6\.
## 5. Role coverage
Fill in a name next to each role. Write "no clear owner" if there isn't one.
| Role | Name |
|---|---|
| Incident Commander | |
| Public Information Officer | |
| Liaison Officer | |
| Safety Officer | |
| Operations Section Chief | |
| Planning Section Chief | |
| Logistics Section Chief | |
| Finance Section Chief | |
## 6. Stakeholder list (10-15 people)
This is a list of people who will receive a questionnaire about company readiness in the next part.
Aim for a mix of technical and business roles — CTO, CISO, engineering leads, product, ops, customer support lead, etc.
| Name | Role | Email/Slack |
|---|---|---|
| 1. | | |
| 2. | | |
| 3. | | |
| 4. | | |
| 5. | | |
| 6. | | |
| 7. | | |
| 8. | | |
| 9. | | |
| 10. | | |
| 11. | | |
| 12. | | |
| 13. | | |
| 14. | | |
| 15. | | |
## 7. Deadline
Date responses are due back to you: ____________
--- 1. Company basics
- Company name:
- One-line description of what we do:
- Industry / sector:
- Total headcount:
- Engineering/technical headcount:
- Website URL:
2. What already exists
- Do we have an existing IR, on-call, or disaster recovery doc? Y / N — if yes, attach it.
- Do we have a status page or external incident comms channel? Y / N — where:
- Do we have an internal incident channel (Slack, Teams, etc.)? Y / N — name:
- Last time we had an incident that needed cross-team response:
3. Past incidents (1-2 lines each, no detail needed yet)
- 1.
- 2.
- 3.
4. Critical systems
List 3-6 systems or dependencies where an outage or breach would be severely impacting our business (a P1/P2):
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
5. Role coverage
Fill in a name next to each role. Write “no clear owner” if there isn’t one.
| Role | Name |
|---|---|
| Incident Commander | |
| Public Information Officer | |
| Liaison Officer | |
| Safety Officer | |
| Operations Section Chief | |
| Planning Section Chief | |
| Logistics Section Chief | |
| Finance Section Chief |
6. Stakeholder list (10-15 people)
This is a list of people who will receive a questionnaire about company readiness in the next part.
Aim for a mix of technical and business roles — CTO, CISO, engineering leads, product, ops, customer support lead, etc.
| Name | Role | Email/Slack |
|---|---|---|
| 1. | ||
| 2. | ||
| 3. | ||
| 4. | ||
| 5. | ||
| 6. | ||
| 7. | ||
| 8. | ||
| 9. | ||
| 10. | ||
| 11. | ||
| 12. | ||
| 13. | ||
| 14. | ||
| 15. |
7. Deadline
Date responses are due back to you: ____________
1 Part 1 · 20–30 min Build your context
By the end of this part you'll have a business summary, your team mapped onto incident-response roles, your own P1–P4 severity scale, and a survey ready to send to 10–15 colleagues.
Copy the prompt below and paste it into your favourite AI tool, with the worksheet from the previous step attached. Also attach the incident severity matrix template.
You are helping me build an Incident Response (IR) plan starting point for my organization, based on the Albúinn Incident Response Foundations framework (structured roles, consistent language, blameless process, calibrated response).
**Do this in order. Don't skip steps. Confirm each step with me before moving to the next.**
### Step 1 — Collect my business context
If I did not provide the BC/DR Intake Worksheet or if it's incomplete, Ask me for, one at a time:
1. Company name and one-line description of what we do
2. Industry / sector
3. Headcount (total, and engineering/technical headcount if different)
4. Company website URL
5. Any existing IR, on-call, or disaster recovery docs I can paste or upload
6. Any past incidents worth knowing about (1-2 sentences each, no need for detail)
### Step 2 — Research and confirm
Using the website URL I gave you, pull together a 150-200 word business summary covering: what we do, who our customers are, what's technically critical to us (uptime, data, payments, etc.), and anything public-facing that suggests likely attack surface or failure points.
Show me the summary. Ask me to correct anything wrong before continuing.
### Step 3 — Map our team to IR roles
Using my headcount and the roles I describe, propose a lightweight mapping to these ICS-style roles: Incident Commander, Communications , Liaison (Clients, Governments, ...), and Section Chiefs (Operations, Planning, Logistics, Finance). Note that for small teams, one person may hold 2-3 roles. Flag any role we have no clear owner for.
### Step 4 — Build the P1-P4 severity scale for us
Draft a 4-level severity scale (P1 Critical through P4 Low) using our actual systems and customer impact, not generic examples. Base it on the business summary from Step 2. A generic "Incident-Severity-Matrix" may have been provided.
### Step 5 — Generate the Scenario Export Prompt
This is the main deliverable. Write me a **separate, standalone prompt** — ready to paste as-is into an email or Slack message — that I can send to 10-15 people at my company (CTO, CISO, engineering leads, product leads, ops, etc.) to run individually with their own AI tool.
That standalone prompt must open by having each recipient check their own AI first, before answering anything:
- If their AI has access to earlier conversations with them (memory, chat history, past sessions), have it search for anything relevant to incident response, outages, vendor issues, compliance, security, on-call, past incidents, or system architecture, and summarize what it found in plain language
- Have it flag which parts of a BC/DR plan it's least confident about for this business, based on what has or hasn't come up in their history
- Have it list every document it's seen from that person — uploaded files, pasted content, linked docs, spreadsheets — that would be useful for this BC/DR process, with a one-line reason for each
- If their AI has no memory or history access, have it say so plainly and move straight to the scenario questions below
Then the prompt must:
- Include the business summary from Step 2 so each recipient has context without me re-explaining
- Ask each person to name their **top 3-5 incident scenarios** they personally worry about, specific to their part of the business
- For each scenario, ask them to give: likelihood (low/med/high), impact if it happened, and who they think would need to be in the room
- Ask them to flag anything they think we have **no plan for today**
- Ask for output in a consistent short format (a table or numbered list) so 10-15 responses can be combined without cleanup — this includes the document list and history findings, not just the scenarios
- End with instructions telling the recipient to send their answers back to me by [DATE]
Give me that prompt in a clearly marked block so I can copy it out cleanly.
### Step 6 — Wait for me
Stop here. I'll come back once I've collected responses from my 10-15 people. **Incident Severity Matrix (P1–P4)**
*Reference guide for triaging incidents at a glance · Albúinn — Incident Response: Foundations*
| **PRIORITY** | **DEFINITION** | **EXAMPLES BY DOMAIN** |
| <br/><br/>**P1**<br/><br/>**CRITICAL** | <br/>*Business outage. All or most users affected. Immediate, all-hands response required.* | **Cybersecurity:  **Active ransomware encrypting production systems; confirmed data exfiltration in progress.<br/><br/>**InfoSec:  **Confirmed breach of a customer database with a public disclosure obligation.<br/><br/>**IT Operations:  **Total loss of the production environment; primary data center or region offline.<br/><br/>**DevOps:  **CI/CD pipeline compromised and shipping malicious code to prod.<br/><br/>**SaaS:  **Platform-wide outage; core service returning errors for all customers.<br/><br/>**Weather / Climate:  **Facility evacuated for hurricane or wildfire; power grid down with no failover. |
| <br/><br/>**P2**<br/><br/>**HIGH** | <br/>*Major impact. Multiple users or services degraded. Needs fast resolution, same-shift response.* | **Cybersecurity:  **Malware detected and contained on a subset of endpoints; unauthorized access.<br/><br/>**InfoSec:  **Phishing campaign compromises several employee accounts.<br/><br/>**IT Operations:  **Major service degradation affecting multiple regions or customer segments.<br/><br/>**DevOps:  **Bad deploy forces a partial rollback; alerting/monitoring goes dark (blind spot).<br/><br/>**SaaS:  **Key feature (billing, login, checkout) unavailable for a subset of customers.<br/><br/>**Weather / Climate:  **Storm knocks out one data center or office; flooding threatens on-prem hardware. |
| <br/><br/>**P3**<br/><br/>**MEDIUM** | <br/>*Limited impact. A workaround exists. Handled within normal SLA, no need to interrupt other work.* | **Cybersecurity:  **Isolated malware on a single non-critical endpoint; contained by existing controls.<br/><br/>**InfoSec:  **DLP tool flags a policy violation; no data loss confirmed.<br/><br/>**IT Operations:  **Non-critical service degraded; documented workaround available.<br/><br/>**DevOps:  **Deploy rolled back on failing tests before reaching customers; staging environment down.<br/><br/>**SaaS:  **Minor feature bug affecting a subset of users; workaround exists.<br/><br/>**Weather / Climate:  **Snow day — office closed, remote work continues without disruption. |
| <br/><br/>**P4**<br/><br/>**LOW** | <br/>*Minor issue. Cosmetic or single-user. Planned resolution, no urgency.* | **Cybersecurity:  **Reported phishing email confirmed benign; low-severity scan finding, patch scheduled.<br/><br/>**InfoSec:  **Documentation gap found during a routine access review.<br/><br/>**IT Operations:  **Cosmetic UI bug; a single non-critical alert misfiring.<br/><br/>**DevOps:  **Flaky test in the CI pipeline; noisy logging from a deprecated service.<br/><br/>**SaaS:  **Single-user account issue; upcoming planned maintenance window.<br/><br/>**Weather / Climate:  **Light rain delays an outdoor event; no operational impact. |
When in doubt, escalate a level — it's cheaper to stand a team down than to catch up from behind. **albuinn.com · hello@albuinn.com** You will then go through the following steps:
Step 1 – Company basics
Covered by your intake worksheet.
Step 2 – Business summary
The AI drafts a 150–200-word summary of what the business does, who its customers are, and what's technically critical — from your website. Your job is to correct it until it's true.
Step 3 – Map your people to IR roles
Map your people onto the ICS-style roles: Incident Commander, Public Information Officer, Liaison, and the four Section Chiefs. One person may hold 2–3 roles — and any role with no owner gets flagged, which is the point.
Step 4 – Your severity scale
Draft your own P1–P4 severity scale from your actual systems and customer impact, not generic examples. The severity matrix in Respond is the reference; this step localises it.
Step 5 – The scenario survey
The main deliverable of Part 1: a short standalone survey (the "Scenario Export Prompt") to send to the 10–15 colleagues on your worksheet list. Each names their top 3–5 incident scenarios — likelihood, impact, who should be in the room, and what has no plan today — in a format that merges cleanly.
If you would rather ask questions directly instead of sending a prompt, or you want to ask them in person, here are the critical questions:
– What are the 3-5 top incident scenarios you personally worry about, specific to your part of the business?
– For each scenario, what is the likelihood of it happening (low/medium/high), the impact of it happening, and who they think should be in the room to fix it?
– Which of these scenarios, should they happen, do we have no recovery plan for today?
Attach these questions to an email and include the deadline from the worksheet.
Step 6 – Wait
Stop here. Send the survey, set the deadline from your worksheet, and let the replies trickle in over the next few days.
2 Part 2 · 15 min, a few days later Merge the responses
Ten to fifteen replies are in. Go back to the same conversation as Part 1 — paste the responses in one after another, labelled by name and role. Don't start a new chat.
Here are the responses I collected from [X] people. Synthesize them into:
1. A single deduplicated list of incident scenarios, ranked by how often they came up and by combined likelihood/impact
2. A "parking lot" list of things multiple people flagged as having no current plan
3. A short gap summary: where did people disagree on severity or ownership, and where is that a problem worth resolving before it's real
4. A recommended next-3-scenarios to build tabletop exercises around, using the P1-P4 scale and role mapping from earlier in this conversation Synthesise one scenario list
Combine all the responses into one deduplicated, ranked list of incident scenarios, plus:
- a parking lot of "we have no plan for this" items
- where people disagreed on severity or ownership — and where that's a problem worth resolving before it's real
- the top 3 scenarios to run tabletop exercises on first
3 Part 3 · 15 min Draft the plan
Everything so far — the business summary, the severity scale, the role mapping, the scenario list — becomes a working first draft of your BC/DR plan. Eight sections.
Using everything from this conversation — the business summary, the P1-P4 scale, the role mapping, and the synthesized scenario list from Part 2 — draft a first-pass Business Continuity / Disaster Recovery (BC/DR) Plan for us. Keep it a working draft, not a finished policy document. Use these 8 sections:
1. **Assemble Plan** — one paragraph stating the plan's purpose and who owns keeping it current
2. **Identify Scope** — which systems, teams, and locations this plan covers, pulled from our critical systems list
3. **Appoint Emergency Contacts** — a contact table (name, role, primary channel, backup channel) built from our role mapping; flag any role still marked "no clear owner"
4. **Designate Disaster Recovery Team** — who leads recovery for each of our top-ranked scenarios from Part 2, using the ICS role mapping
5. **Assign Roles & Responsibilities** — for our top 3 ranked scenarios specifically, a short run-sheet: first call, first action, who's briefed and when
6. **Restore Technology Functionality** — for each critical system, what "restored" means (specific and measurable, not "back to normal") and roughly how it gets checked
7. **Data & Backups** — what we know about backup locations and recovery point/time objectives; flag anything we don't currently know as an open question rather than guessing
8. **Testing & Maintenance** — a proposed cadence for tabletop exercises and plan review, and who's responsible for scheduling them
Where you don't have enough information to fill a section accurately, don't invent it — write "Open question: [what's missing]" instead, and list all open questions again at the end as a single follow-up checklist for me to fill in with my team.
Format the whole thing as a document I can hand to my leadership team, not as a chat answer — headers, tables where useful, plain language over jargon. Draft the 8-section plan
The plan, section by section:
- purpose & owner
- scope — which systems, teams, locations
- emergency contacts
- the disaster-recovery team per top scenario
- a first-hour run-sheet for your top 3 scenarios
- a measurable "restored" definition per critical system
- backup locations & recovery objectives
- a test-and-review cadence
Read through the draft and correct anything necessary.
That's a working BC/DR draft. Save it somewhere your team can find it, put the review cadence on a calendar, and go to Respond next.