figma guide
Designing business continuity and disaster recovery planning UI in Figma: RTO/RPO, runbooks, and failover drills
Design business continuity and disaster recovery planning UI in Figma with RTO/RPO targets, dependency maps, failover runbooks, and drill tracking for enterprise resilience.
- Published
- Updated
- Jul 27, 2026
- Read time
- 9 min
- Level
- Intermediate
Quick answer
Business continuity and disaster recovery (BCP/DR) UI turns abstract resilience goals into actionable plans—RTO/RPO per service, dependency maps, failover runbooks, and drill evidence auditors can trust. Design a service catalog with recovery targets; a dependency map showing upstream/downstream blast radius; failover runbooks linked to incident playbooks; and a drill calendar with pass/fail criteria and remediation actions. Start from the Figma guides hub and pair with post-incident review, war room, security posture dashboard, compliance exports, and Dev Mode handoff.
Who this is for
- Product designers building resilience modules inside enterprise GRC, ITSM, or cloud operations platforms.
- Design system teams aligning service tier badges, dependency graph nodes, and drill status chips with badges, tables, and progress steppers.
- Engineering and SRE teams implementing service metadata sync, runbook versioning, and drill evidence export for SOC 2 and ISO 22301 audits.
BCP/DR hub (program overview)
BCPHub — Org: Acme Cloud · Plan version 2026.2 · Last drill: 2026-06-14
├── Header: Services 47 · Critical tier 12 · Drills due 3 · Open gaps 8
├── Actions: [ Add service ] [ Schedule drill ] [ Export plan PDF ] [ Compare to last PIR ]
├── Tabs: Service catalog · Dependencies · Runbooks · Drills · Gaps & actions
├── Health: RTO met 89% · RPO met 94% · Runbooks current 41/47
└── Link: Post-incident actions (4 open) · Posture dashboard| Section | Purpose |
|---|---|
| Service catalog | Every recoverable unit with tier, RTO/RPO, owner |
| Dependencies | Visual blast radius and failover order |
| Runbooks | Failover, failback, and communication steps |
| Drills | Scheduled tests with evidence and scores |
| Gaps & actions | Remediation from drills and PIR |
Verdict: BCP hub is always-on planning—not the live war room. Link “Activate DR runbook” from hub only when incident declared.
Service catalog with RTO/RPO
ServiceCatalog
├── Filters: Tier (Critical/High/Medium/Low) · Region · Owner team · Drill overdue
├── Row: payments-api · Tier Critical · RTO 15m · RPO 5m · Owner Platform · Last drill Pass (2026-05)
├── Row: analytics-batch · Tier Medium · RTO 24h · RPO 4h · Owner Data · Drill overdue
├── Row: auth-service · Tier Critical · RTO 5m · RPO 0 · Multi-region ✓ · Runbook v4.1
└── [ Bulk import from CMDB ] [ Export tier report ]| Field | Handoff detail |
|---|---|
| Service name | Matches CMDB or service mesh ID |
| Tier | Critical / High / Medium / Low with color badge |
| RTO | Max acceptable downtime; tooltip shows definition |
| RPO | Max acceptable data loss window |
| Recovery strategy | Active-active, warm standby, cold backup, manual |
| Owner | Team + DRI; links team roles |
| Runbook version | Stale warning if drill failed or PIR flagged gap |
| Regulatory tag | PCI, HIPAA, etc.—feeds compliance export |
Critical tier services require annual drill minimum—surface overdue count on hub header.
Dependency map and blast radius
DependencyMap — Focus: payments-api
├── Upstream: identity-provider (Critical) · config-service (High) · secrets-vault (Critical)
├── Downstream: checkout-ui (Critical) · billing-webhooks (High) · fraud-scoring (Medium)
├── External: Stripe API · AWS us-east-1 · Cloudflare DNS
├── Blast radius estimate: 3 Critical · 5 High · ~40k users/hr if down 1h
└── Failover order suggestion: 1 vault · 2 identity · 3 payments-api · 4 checkout-ui| Element | UI detail |
|---|---|
| Node | Service with tier badge; click opens catalog row |
| Edge | Sync/async; required vs optional dependency |
| External node | Vendor boundary—link vendor risk |
| Region pin | Multi-AZ vs single-region warning |
| Blast radius panel | Estimated customer/revenue impact—non-binding, editable assumptions |
| Failover order | Drag to reorder; export as runbook preamble |
Use zoom/pan canvas or simplified list view for mobile admin. Avoid hairball graphs—collapse non-critical branches by default.
Pair with SIEM connectors when dependency health feeds from monitoring.
Failover and failback runbooks
DRRunbook — payments-api failover v4.1
├── Preconditions: Incident declared Sev 1 · War room active · Comms lead notified
├── Steps:
│ 1. Verify secondary region health (automated check)
│ 2. Pause write traffic — link [automation workflow](/designing-security-automation-and-response-workflows-ui-in-figma/)
│ 3. Promote read replica · Owner: Platform on-call
│ 4. Update DNS / traffic switch · Owner: SRE
│ 5. Validate synthetic transactions · Owner: QA delegate
│ 6. Notify status page — link customer comms module
├── Failback section: Separate numbered list with rollback gates
├── RTO checkpoint: Step 5 must complete within 12m (target 15m)
└── Attachments: Architecture diagram · Contact tree · [API keys rotation](/designing-secrets-rotation-and-credential-vault-ui-in-figma/) note| Pattern | Why |
|---|---|
| Dual runbooks | Failover and failback are separate flows—do not merge |
| RTO checkpoints | Time budget per phase; war room shows countdown |
| Owner per step | Same pattern as incident runbooks |
| Automated vs manual | Icon on each step for tooling integration |
| Version diff | Show changes since last drill failure |
| PIR link | ”Created from ACT-441” when action spawned runbook update |
Runbook stale if service tier changes without review—show blocking banner on hub.
Drill scheduling and execution
DrillCalendar — Q3 2026
├── Scheduled: payments-api failover · 2026-08-12 · Type: Tabletop + partial failover
├── In progress: auth-service RPO validation · Facilitator: Morgan · Observers: 4
├── Completed: analytics-batch restore · Score 72% · 3 gaps opened
└── [ Schedule drill ] [ Clone last drill ] [ Import scenario from PIR ]DrillExecution — payments-api · Live
├── Scenario: Primary region unavailable · Inject at T+0
├── Checklist: 12 steps · 8 complete · RTO clock 9m / 15m target
├── Evidence: Screenshot upload · Log snippet · Timestamped notes
├── Gap found: DNS TTL exceeded budget — [ Create action ] [ Link to RCA ]
└── Outcome: Pass with gaps / Fail / Cancelled| Drill type | UI treatment |
|---|---|
| Tabletop | Discussion steps; no live traffic |
| Partial failover | Subset of runbook; sandbox region |
| Full failover | Production DR; requires approval gate |
| Restore test | RPO validation from backup |
| Vendor dependency | Third-party participation flag |
Pass/fail requires facilitator sign-off and at least one evidence attachment for Critical tier.
Failed drills auto-create actions in tracker—same schema as PIR corrective actions.
Gap tracker and remediation
GapTracker — Open from drills & audits
├── GAP-88 · DNS TTL too high for RTO · Source: Drill 2026-06-14 · Owner: SRE · Due 2026-07-30
├── GAP-91 · Runbook missing failback gate · Source: PIR INC-0891 · Owner: Platform · Overdue
├── GAP-94 · No multi-region for analytics-batch · Source: Catalog review · Priority P2
└── [ Link to posture metric ] [ Export for audit ]| Field | Handoff |
|---|---|
| Gap ID | Immutable |
| Source | Drill, PIR, audit, catalog review |
| Control mapping | ISO 22301 / SOC 2 CC refs optional |
| Remediation | Action owner, due date, verification |
| Re-test | Schedule follow-up drill from gap row |
Surface open Critical-tier gaps on security posture dashboard as resilience debt.
Integration with incident response
| Source | BCP/DR usage |
|---|---|
| War room | ”Launch DR runbook” when availability incident |
| Post-incident review | Import actions that update runbooks or RTO targets |
| Breach notification | Availability vs data breach—different comms templates |
| Forensic evidence | Drill logs archived when regulatory scope |
| Compliance export | Annual BCP PDF bundle for auditors |
When real incident invokes DR runbook, execution log feeds PIR timeline automatically—do not make teams re-enter steps.
BCP templates by organization size
| Template | Emphasis | Pairs with |
|---|---|---|
| Startup (<50 services) | Spreadsheet-style catalog, tabletop-only drills | Runbooks |
| Mid-market | Tiering, quarterly Critical drills | Posture dashboard |
| Enterprise multi-region | Dependency map, full failover approval | War room, automation |
| Regulated (finance/health) | Control mapping, evidence retention | Compliance exports |
| SaaS with status page | Customer comms hooks on runbook steps | Customer status page UI (companion guide) |
Template picker sets default RTO/RPO suggestions by tier—not hard limits.
Handoff checklist (Dev Mode)
- Service schema — tier enum, RTO/RPO units, CMDB ID, owner team.
- Dependency graph — node/edge types, collapse rules, export format.
- Runbook versioning — semver, diff view, stale detection rules.
- Drill lifecycle — scheduled → in progress → pass/fail/cancelled.
- Evidence upload — file types, max size, retention class.
- Gap/action sync — link to PIR ACT- IDs and Jira fields.
- Permissions — who schedules full failover vs tabletop.
- Export bundle — PDF structure for auditor handoff.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| RTO/RPO with no owner | Plans rot | Required DRI per service |
| Dependency map unreadable | Teams ignore it | Tier collapse, focus mode |
| Runbook never drilled | False confidence | Overdue drill badges on Critical |
| Failover without failback | Extended wrong-region ops | Separate failback runbook |
| Drills without evidence | Audit failure | Required attachments for Critical |
| BCP separate from live IR | Duplicate work during incident | Launch runbook from war room |
| Generic “restore from backup” steps | Untestable | Specific systems, owners, checkpoints |
| Ignoring vendor dependencies | External single points of failure | External nodes + vendor risk link |
| Closing gaps without re-test | Same failure repeats | Schedule verification drill |
| No link to PIR actions | Lessons lost | Import ACT items into gap tracker |
Recommended workflow
- Design BCP hub with catalog, dependency map, runbooks, drills, and gaps tabs.
- Build service catalog with tier badges, RTO/RPO, and stale runbook warnings.
- Create dependency map with blast radius panel and failover order export.
- Author failover/failback runbook templates linked to war room activation.
- Add drill calendar and execution UI with evidence, scoring, and gap creation.
- Wire posture dashboard and PIR imports in Dev Mode.
FAQ
BCP vs DR vs incident runbook?
BCP is the program (catalog, targets, drills). DR runbooks are planned failover/failback procedures. Incident runbooks handle active security/ops events—DR runbooks may attach when availability is impacted.
RTO vs RPO in UI copy?
RTO = how long service can be down. RPO = how much data loss is acceptable. Always show definitions in tooltips—auditors and new hires confuse them.
How often to drill Critical services?
UI default: quarterly partial or tabletop, annual full failover where feasible—configurable per org policy.
Real incident vs drill?
Drill mode banners prevent accidental customer comms; live mode invoked from war room writes to PIR timeline. Never reuse drill status page drafts in production.
Export for auditors?
Generate PDF with catalog snapshot, drill results, open gaps, and runbook version history—via compliance export workflow.
Next steps
- Design post-incident review and root cause analysis UI in Figma — import remediation actions into gap tracker
- Design security operations shift handover and war room UI in Figma — activate DR runbooks during live incidents
- Design incident response runbooks and security playbooks UI in Figma — shared step/owner patterns
- Design security posture dashboard and compliance checklist UI in Figma — resilience debt and drill overdue metrics
- Design customer incident status page and communication UI in Figma — notify users during DR events
§ Keep reading