# Operate Through Compromise: tabletop pack

Draft facilitator template. No workshop has been conducted for this series. All scenario statements are illustrative, and all result fields remain empty. A tabletop can exercise decisions; it cannot establish Azure technical behavior.

The companion reader toolkit (`README.md` in this folder or the extracted ZIP) provides offline evidence mutations to use between injects. Keep its fictional results separate from observer records and separately approved Azure observations.

## Scope and preparation

Use a fictional non-production image-processing workload, a synthetic Blob canary, a healthy peer service and a separate trusted administration/evidence path. Adapt names without inserting real incident details into this repository. No Azure resources, role changes, network changes, credential tests or customer notifications are required.

Assign incident commander, application/service owner, network responder, identity responder, SOC/evidence custodian, communications owner, facilitator, scribe and independent observer. Roles may share people only if the decision conflicts are disclosed. A named alternate owns decisions when a responder is unavailable.

Before starting, agree an exercise ID, participants, allowed scenario scope, accessibility needs, timebox, stop word, handling of real incident interruptions, evidence retention and the acceptable degraded business function. Set numerical targets below with the organization; blank targets are not passes. An exercise may stop without executing all injects.

## Six inject cards

| ID / reveal condition | Illustrative information | Decision to elicit | Evidence or challenge |
|---|---|---|---|
| T1 / start | A workload alert names a process but not the principal actually used | Scope triage, separate confirmed/inferred/unknown facts, assign evidence owners | Ask for principal selection and one source-attributed reachable-consequence row |
| T2 / after initial scope | The identity is shared with a healthy service; a reviewed worker-local response exists | Record ACT/HOLD/ESCALATE, rejected alternatives, accepted impact and reassessment deadline | Name approver, gap owner and the observation that invalidates D1 |
| T3 / after action proposal | A harmless established session can still perform the unwanted canary operation | Distinguish residual access from later drift; create D2 rather than silently broaden D1 | Require separate fresh/existing-session evidence and independent recovery access |
| T4 / after verification proposal | A deployment job proposes pre-incident settings; service logs are missing; an evidence-export exception is requested | Distinguish proposed versus applied drift, coordinate automation owner and bound the exception | Require diff/change/outcome evidence separately, exception expiry and observation-gap escalation |
| T5 / after containment review | A critical business operation has degraded and an unsafe baseline is offered as rollback | Choose a minimum safe recovery path and explicit risk acceptance | Require customer impact, dependency order, negative control and recovery owner |
| T6 / recovery checkpoint | A DNS correction restores health, but an alternate service path remains untested | Decide release/hold, preserve unknowns, assign follow-ups | Require closure evidence, expiry, retest and service-owner acceptance |

Do not improvise a successful observation when participants request unavailable evidence. Say it is missing and record their response. Reveal cards in order unless the facilitator records a reason to branch. Preserve both the proposed decision and the later revision.

## Observer worksheet

| Inject | Reveal UTC | Decision UTC / no-decision reason | Decision owner | Evidence references / gaps | Confidence | Assumed service impact | Result / challenge |
|---|---|---|---|---|---|---|---|
| T1 | | | | | | | NOT_RUN |
| T2 | | | | | | | NOT_RUN |
| T3 | | | | | | | NOT_RUN |
| T4 | | | | | | | NOT_RUN |
| T5 | | | | | | | NOT_RUN |
| T6 | | | | | | | NOT_RUN |

## Objectives and measurement

| Measure | Define before exercise | Target / baseline | Actual / evidence |
|---|---|---|---|
| Decision latency | Decision UTC minus inject reveal UTC; paused intervals reported separately | | |
| Evidence completeness | Source-attributed required facts divided by predeclared required facts; list denominator and unknowns | | |
| Ownership completeness | Decisions with named accountable owners divided by decisions requiring owners | | |
| Availability impact | Scenario-estimated degradation vs agreed critical function; not a production outage measurement | | |
| Recovery discipline | Stages with required and prohibited checks divided by predeclared stages | | |
| Action follow-through | Due actions with attributable closure/retest evidence divided by actions due at review | | |

Do not omit failed or paused decisions to improve averages. Keep `NOT_RUN` separate from attempted-but-inconclusive observations. A prompt decision unsupported by evidence is not a better outcome than a justified escalation.

## Debrief and action register

Ask: Which fact changed the decision? Which unknown was tolerated and by whom? Could the proposed action have cut evidence or recovery access? Did the team distinguish documented timing from assumptions? Which “rollback” would have restored unsafe authority? What could the tabletop not prove?

| Finding / inject reference | Consequence | Corrective action | Owner / due date | Closure evidence / retest date | Status |
|---|---|---|---|---|---|
| | | | | | OPEN |

Close the exercise with an owner for every action, an agreed retest date and a statement of unexercised branches. Keep working records in a restricted location, redact shared teaching material and apply retention/deletion policy. Any later technical validation requires a separate approved isolated-lab plan with documented scope, recovery and cleanup; this pack does not authorize it.