figma guide
Designing incident response runbooks and security playbooks UI in Figma: steps, roles, and handoff
Design incident response runbooks and security playbooks in Figma with step checklists, role assignments, break-glass links, audit hooks, and Dev Mode specs for enterprise Security admin.
- Published
- Updated
- Jul 18, 2026
- Read time
- 7 min
- Level
- Intermediate
Quick answer
Incident response runbooks give Security admins guided playbooks when something breaks—IdP outage, DLP false positive wave, suspected account takeover. Design a runbook library grouped by scenario (identity, network, data, integrations); step checklist with owner role, timer, and deep-link to the exact settings page; live incident mode that logs each step to the audit log; **break-glass shortcuts](/designing-break-glass-emergency-access-and-account-recovery-ui-in-figma/) only where policy allows; and post-incident review form tied to security posture gaps. Start from the Figma guides hub and pair with SSO, suspicious login alerts, DLP, and Dev Mode handoff.
Who this is for
- Product designers building Security admin runbook libraries, live incident consoles, and tabletop exercise flows.
- Design system teams aligning checklist rows with progress steppers, accordions, and badges.
- Engineers implementing runbook state machines, audit event emission, and integration with on-call paging.
Runbook library layout
| Zone | Content | Priority |
|---|---|---|
| Header | Search, filter by domain, “Start tabletop” | Always visible |
| Scenario cards | IdP outage, mass lockout, DLP spike, app compromise | Above fold |
| Recent incidents | Last 5 closed with duration and owner | Sidebar |
| Templates | Org-custom vs platform default runbooks | Tab |
RunbookLibrary
├── Header: Security runbooks · [ Search ] [ Filter: Identity ▾ ] [ Start tabletop ]
├── ScenarioGrid
│ ├── IdP / SSO certificate expired
│ ├── Mass member lockout (MFA / passkey)
│ ├── DLP false positive surge
│ ├── Suspected org-wide credential leak
│ └── Third-party app OAuth scope drift
└── RecentIncidents: INC-1042 closed · 47 min · jane@acme.comVerdict: organize by failure scenario, not by settings page name—admins think “SSO is down,” not “navigate to SSO settings.”
Runbook card anatomy
Each library card previews what happens when an admin starts the playbook:
| Field | Spec |
|---|---|
| Title | Plain language: “IdP certificate expired” |
| Severity default | P1 / P2 / P3 badge |
| Est. duration | 15–45 min typical |
| Roles required | Security Admin, optional Owner approval |
| Linked controls | SSO, break-glass, member comms |
| Last run | Tabletop or live date |
RunbookCard
├── IdP certificate expired · P1
├── ~30 min · Security Admin + Owner notify
├── Steps: 8 · Break-glass eligible: SSO bypass
├── Last tabletop: 2026-06-12 ✓
└── [ Start live incident ] [ Run tabletop ]Step checklist (live incident mode)
When an admin starts a runbook, switch to focused incident UI—hide unrelated nav:
| Step state | UI | Audit event |
|---|---|---|
| Pending | Empty checkbox, role badge | — |
| In progress | Highlight + timer | runbook.step.started |
| Blocked | Warning + “Needs break-glass” link | runbook.step.blocked |
| Done | Checkmark + completed by + timestamp | runbook.step.completed |
| Skipped | Strikethrough + required reason | runbook.step.skipped |
Example: IdP certificate expired runbook
IncidentConsole — INC-1043 · IdP certificate expired
├── Status: In progress · Started 09:14 · Owner notified ✓
├── Step 3/8 — Verify IdP metadata URL reachable
│ └── [ Mark complete ] [ Blocked — need help ] [ Open SSO settings ]
├── Step 4/8 — Enable break-glass SSO bypass (dual approval)
│ └── [ Start break-glass wizard ] ← deep-link
└── [ End incident ] [ Escalate to Owner ]Deep-link buttons must land on the exact toggle—same rule as posture gap cards.
Role assignments and escalation
| Role | Runbook permissions |
|---|---|
| Security Admin | Start live incident, complete most steps |
| Owner | Approve break-glass, end P1 incident, override skip |
| Team Admin | Member recovery steps only—not org policy |
| Auditor (read-only) | View closed incidents, export timeline |
Escalation path when step blocked > 10 min:
EscalationBanner
├── Step 4 blocked 12 min — SSO bypass needs Owner approval
├── Notified: owner@acme.com · Slack #security-oncall
└── [ Re-notify ] [ Assign backup approver ]Tie notification routing to notification preferences—P1 incidents bypass digest mode.
Break-glass and runbook integration
Not every step should offer break-glass—limit to pre-approved scenarios:
| Runbook | Break-glass step | Guardrails |
|---|---|---|
| IdP outage | SSO bypass | Dual approval, 1 hr scope |
| IP allowlist misconfig | Temporary rule edit | Audit + auto-revert timer |
| DLP mass block | Monitor mode toggle | Owner approval, 4 hr max |
| App compromise | Revoke app tokens | No break-glass—use app allowlist |
Copy on break-glass steps: “This step uses emergency access—session is logged and time-limited.”
Tabletop exercise mode
Dry-run without changing production settings:
| Mode | UI difference | Audit |
|---|---|---|
| Live incident | Real settings links active | Full incident timeline |
| Tabletop | Simulated outcomes, disabled destructive actions | runbook.tabletop.completed |
TabletopCompleteModal
├── Tabletop: IdP certificate expired — 22 min
├── All 8 steps walked through · 2 discussion notes added
├── Findings: "Backup approver unreachable" → create posture gap
└── [ Save to compliance evidence ] [ Schedule next quarter ]Link tabletop completion to compliance exports as optional SOC2 evidence.
Post-incident review
Closing an incident requires structured debrief—not just “End”:
| Field | Required |
|---|---|
| Root cause category | Config / IdP / User error / Attack |
| Duration | Auto-calculated |
| Controls that failed | Multi-select from posture domains |
| Follow-up tasks | Creates posture gap or ticket |
| Customer comms sent? | Yes / No / N/A |
PostIncidentReview
├── Root cause: IdP cert rotation missed
├── Create posture gap: "SSO cert expiry monitoring"
├── Follow-up owner: security-lead@acme.com · Due 7 days
└── [ Close incident ] [ Export timeline PDF ]Closed incidents appear in audit log as immutable timeline—filter incident.* events.
Comparison: runbook vs audit log vs posture dashboard
| Surface | Purpose | When admins use it |
|---|---|---|
| Runbooks | Guided response during active incident | IdP down, leak suspected |
| Audit log | Historical event stream | Forensics after close |
| Posture dashboard | Proactive gap list | Between incidents |
Cross-link all three from incident console header—teams confuse reactive vs proactive surfaces during stress.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Runbooks named after settings pages | Admins can’t find scenario | Scenario-first titles |
| No live vs tabletop distinction | Accidental prod changes | Mode toggle + banner |
| Steps without deep-links | Runbook abandoned mid-incident | Fix button per step |
| Break-glass on every step | Over-privileged response | Pre-approved matrix only |
| Skip without reason | Audit gaps | Required skip justification |
| No Owner notify on P1 | Leadership blind during outage | Auto-notify on start |
| Runbook duplicates suspicious login flow | Two paths for same problem | Link member vs org runbooks |
| Closed incident without debrief | Repeat failures | Required post-incident form |
| Tabletop not logged | SOC2 evidence gap | tabletop.completed audit row |
| Timer without timezone | Distributed team confusion | Show org timezone + UTC |
Recommended workflow
- Design runbook library with scenario cards grouped by identity, network, data, integrations.
- Build live incident console with step checklist, timers, and deep-link actions.
- Add tabletop mode with simulated outcomes and completion certificate.
- Wire break-glass steps to emergency access wizard with dual approval.
- Create escalation banner for blocked steps and Owner notification.
- Design post-incident review form that feeds posture gap creation.
- Annotate audit events and state transitions in Dev Mode.
FAQ
How is a runbook different from break-glass?
Runbooks are guided multi-step workflows; break-glass is one emergency capability (temporary elevated access). Runbooks may include a break-glass step—not replace it.
Should runbooks auto-start on alerts?
Optional in v2—v1 manual start avoids false-positive incident noise. Link from suspicious login alerts as suggested runbook, not auto-start.
Can Team Admins run org-wide runbooks?
No—org policy runbooks require Security Admin; member recovery runbooks are a separate, shorter library.
Tabletop frequency for SOC2?
Quarterly minimum for top 3 scenarios—surface “overdue tabletop” on posture dashboard.
Export incident timeline for auditors?
Yes—PDF with step timestamps, actors, break-glass usage, and debrief fields; include in compliance export bundle.
Next steps
- Design break-glass emergency access and account recovery UI in Figma — break-glass steps inside runbooks
- Design audit log and security activity UI in Figma — incident event timeline
- Design security posture dashboard and compliance checklist UI in Figma — post-incident gap creation
- Design suspicious login alerts and account recovery UI in Figma — member-level vs org runbooks
- Design SSO and enterprise login UI in Figma — top IdP outage runbook target
§ Keep reading