Business Continuity
Create a business continuity plan for "$ARGUMENTS" with critical business function identification, RPO/RTO targets, continuity strategies, disruption scenarios, and tabletop exercise planning.
Prerequisites
Read .metapowers/security/$ARGUMENTS/00-govern.md. If this file does not exist, tell the user:
Phase 0 (Govern) has not been completed for "$ARGUMENTS". Run a Govern skill first (e.g., /security:security-policy $ARGUMENTS), or use --skip-checks to bypass.
If --skip-checks is present in $ARGUMENTS, skip this check and log to .metapowers/security/$ARGUMENTS/skip-log.md.
Process
Read context files:
- Read
plugins/security/shared/incident-response-template.md for continuity workflow reference
- Read
.metapowers/security/$ARGUMENTS/00-govern.md for organizational context and risk appetite
Identify critical business functions and dependencies:
- List all business functions (revenue-generating, customer-facing, internal operations, compliance)
- Rank by business impact: what is the cost per hour of downtime for each function?
- Map technology dependencies for each function (applications, databases, third-party services, infrastructure)
- Identify single points of failure in dependency chains
- Map personnel dependencies (key person risk for critical functions)
Set RPO and RTO per function:
- RPO (Recovery Point Objective) — maximum acceptable data loss per function
- RTO (Recovery Time Objective) — maximum acceptable downtime per function
- Align with business SLAs and contractual obligations
- Consider regulatory requirements for availability (financial services, healthcare)
- Document cost implications of different RPO/RTO levels to support investment decisions
Define continuity strategies:
- Active-active — multiple live instances serving traffic simultaneously (lowest RTO, highest cost)
- Active-passive — standby environment ready to activate on failure (moderate RTO, moderate cost)
- Cold standby — infrastructure provisioned on demand during disaster (highest RTO, lowest cost)
- Manual workaround — business process can continue without technology for limited period
- Select strategy per function based on RPO/RTO requirements and budget constraints
- Document decision rationale for each function
Plan for disruption scenarios:
- Data center / cloud region failure — failover to secondary region, DNS-based routing, data replication lag impact
- Cloud provider outage — multi-cloud strategy assessment, portable workload design, manual fallback
- Ransomware — air-gapped backup restoration, clean environment rebuild, negotiation policy (pay/don't pay)
- Key person unavailable — cross-training, documentation, deputy assignments, knowledge base
- Extended power/network outage — remote work activation, communication alternatives, manual processes
- For each scenario: trigger conditions, response actions, communication plan, recovery steps
Define communication plan during disruption:
- Internal communication: who is notified, how, and at what cadence
- Customer communication: status page, email, social media, support channels
- Partner/vendor communication: SLA impact notifications, joint response coordination
- Regulatory communication: if disruption affects compliance obligations
Define roles and responsibilities:
- Business Continuity Manager: owns BCP activation and coordination
- Function owners: responsible for their function's continuity procedures
- IT/Engineering: responsible for technical failover and recovery
- Communications: responsible for stakeholder updates
- Define activation authority: who can declare a business continuity event
Plan tabletop exercises:
- Conduct at minimum annually, more frequently for critical functions
- Design realistic scenarios based on threat landscape and past incidents
- Involve all key roles: business, technology, communications, legal
- Document exercise findings: what worked, what failed, what was unclear
- Update BCP based on exercise findings
- Track improvement actions from exercises to completion
Write the artifact to .metapowers/security/$ARGUMENTS/05-recover.md with heading:
Business Continuity Plan
Include sections:
- Critical Functions — ranked list with dependencies and single points of failure
- RPO/RTO Targets — per function with cost justification
- Continuity Strategies — selected approach per function with rationale
- Disruption Scenarios — response plans per scenario type
- Communication Plan — stakeholder communication during disruption
- Roles and Responsibilities — BCP team structure and activation authority
- Tabletop Exercise Plan — schedule, scenarios, and improvement tracking
Output
The business continuity plan written to .metapowers/security/$ARGUMENTS/05-recover.md. Present a summary to the user highlighting:
- Critical business functions and their RPO/RTO targets
- Continuity strategy selected per function
- Key disruption scenarios planned for
- Tabletop exercise schedule and approach
1---2name: business-continuity3description: Create business continuity plan with RPO/RTO targets4---56# Business Continuity78Create a business continuity plan for "$ARGUMENTS" with critical business function identification, RPO/RTO targets, continuity strategies, disruption scenarios, and tabletop exercise planning.910## Prerequisites1112Read `.metapowers/security/$ARGUMENTS/00-govern.md`. If this file does not exist, tell the user:1314> Phase 0 (Govern) has not been completed for "$ARGUMENTS". Run a Govern skill first (e.g., `/security:security-policy $ARGUMENTS`), or use `--skip-checks` to bypass.1516If `--skip-checks` is present in $ARGUMENTS, skip this check and log to `.metapowers/security/$ARGUMENTS/skip-log.md`.1718## Process19201. **Read context files:**21 - Read `plugins/security/shared/incident-response-template.md` for continuity workflow reference22 - Read `.metapowers/security/$ARGUMENTS/00-govern.md` for organizational context and risk appetite23242. **Identify critical business functions and dependencies:**25 - List all business functions (revenue-generating, customer-facing, internal operations, compliance)26 - Rank by business impact: what is the cost per hour of downtime for each function?27 - Map technology dependencies for each function (applications, databases, third-party services, infrastructure)28 - Identify single points of failure in dependency chains29 - Map personnel dependencies (key person risk for critical functions)30313. **Set RPO and RTO per function:**32 - **RPO (Recovery Point Objective)** — maximum acceptable data loss per function33 - **RTO (Recovery Time Objective)** — maximum acceptable downtime per function34 - Align with business SLAs and contractual obligations35 - Consider regulatory requirements for availability (financial services, healthcare)36 - Document cost implications of different RPO/RTO levels to support investment decisions37384. **Define continuity strategies:**39 - **Active-active** — multiple live instances serving traffic simultaneously (lowest RTO, highest cost)40 - **Active-passive** — standby environment ready to activate on failure (moderate RTO, moderate cost)41 - **Cold standby** — infrastructure provisioned on demand during disaster (highest RTO, lowest cost)42 - **Manual workaround** — business process can continue without technology for limited period43 - Select strategy per function based on RPO/RTO requirements and budget constraints44 - Document decision rationale for each function45465. **Plan for disruption scenarios:**47 - **Data center / cloud region failure** — failover to secondary region, DNS-based routing, data replication lag impact48 - **Cloud provider outage** — multi-cloud strategy assessment, portable workload design, manual fallback49 - **Ransomware** — air-gapped backup restoration, clean environment rebuild, negotiation policy (pay/don't pay)50 - **Key person unavailable** — cross-training, documentation, deputy assignments, knowledge base51 - **Extended power/network outage** — remote work activation, communication alternatives, manual processes52 - For each scenario: trigger conditions, response actions, communication plan, recovery steps53546. **Define communication plan during disruption:**55 - Internal communication: who is notified, how, and at what cadence56 - Customer communication: status page, email, social media, support channels57 - Partner/vendor communication: SLA impact notifications, joint response coordination58 - Regulatory communication: if disruption affects compliance obligations59607. **Define roles and responsibilities:**61 - Business Continuity Manager: owns BCP activation and coordination62 - Function owners: responsible for their function's continuity procedures63 - IT/Engineering: responsible for technical failover and recovery64 - Communications: responsible for stakeholder updates65 - Define activation authority: who can declare a business continuity event66678. **Plan tabletop exercises:**68 - Conduct at minimum annually, more frequently for critical functions69 - Design realistic scenarios based on threat landscape and past incidents70 - Involve all key roles: business, technology, communications, legal71 - Document exercise findings: what worked, what failed, what was unclear72 - Update BCP based on exercise findings73 - Track improvement actions from exercises to completion74759. **Write the artifact** to `.metapowers/security/$ARGUMENTS/05-recover.md` with heading:7677 ## Business Continuity Plan7879 Include sections:80 - **Critical Functions** — ranked list with dependencies and single points of failure81 - **RPO/RTO Targets** — per function with cost justification82 - **Continuity Strategies** — selected approach per function with rationale83 - **Disruption Scenarios** — response plans per scenario type84 - **Communication Plan** — stakeholder communication during disruption85 - **Roles and Responsibilities** — BCP team structure and activation authority86 - **Tabletop Exercise Plan** — schedule, scenarios, and improvement tracking8788## Output8990The business continuity plan written to `.metapowers/security/$ARGUMENTS/05-recover.md`. Present a summary to the user highlighting:91- Critical business functions and their RPO/RTO targets92- Continuity strategy selected per function93- Key disruption scenarios planned for94- Tabletop exercise schedule and approach