Runbook Testing Sequence & Sign-Off Order¶
Last Updated: 2026-06-17 Status: 13 of 84 assets signed off — D1 ✅, R1 ✅, C4 ✅, D3 ✅, V2 ✅, V3 ✅, D5 ✅, K1 ✅, D4 ✅, I1 ✅, I2 ✅, X1 ✅, X2 ✅ · S1 🟨 (offline only)
Overview¶
This document defines the canonical order for executing all SnowOps runbooks — test sign-off runbooks (Part 1) and operational playbooks (Part 2). The test sequence respects dependency flows: offline-first, sandbox setup before cloud tests, foundational modules before consumers.
Each test runbook takes ~5–45 min to complete. Total time to full sign-off: ~30–40 hours over multiple sessions.
Part 1: Manual Test Runbook Sequence¶
84 tracked assets · 84 runbook files · all assets have runbook files
Phase 0: Pre-Flight Setup ⭐ START HERE (one-time, ~30 min)¶
Complete once before any other runbook.
| Runbook | Description |
|---|---|
| client-onboarding/01-azure-cloud-setup.md | Configure Azure credentials, install Terratest harness, validate sandbox access |
Checklist:
- [ ] Azure subscription ID & tenant ID obtained
- [ ] Auth configured (Service Principal or az login)
- [ ] Go 1.22+, Terraform 1.6+, Azure CLI 2.50+, kubectl, helm installed locally
- [ ] go test -v -timeout 5m ./... passes (schema-only tests)
- [ ] SNOWOPS_SANDBOX_SUBSCRIPTION_ID and SNOWOPS_SANDBOX_TENANT_ID exported
All phases below require Phase 0 to be complete.
Phase 1: Offline Quality Gates (~67 min)¶
Fully offline — no cloud credentials required. Complete these first.
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 1 | D1 | Pre-Commit Quality Gates | test/D1.md | None | 15m | ✅ 2026-05-26 |
| 2 | R1 | PR Template Enforcement | test/R1.md | None | 10m | ✅ 2026-05-26 |
| 3 | C4 | GitOps Branching Standard + Repo Template | test/C4.md | None | 10m | ✅ 2026-05-26 |
| 4 | D3 | OPA / Conftest Policy Bundle | test/D3.md | None | 10m | ✅ 2026-06-14 |
| 5 | D5 | Policy Waiver Engine | test/D5.md | D3 (bundle loaded) | 10m | ✅ 2026-06-14 |
| 6 | D2 | PR-Blocking Quality Gates | test/D2.md | D1 (hooks installed) | 10m | ⬜ |
| 7 | K1 | IR Runbook Library | test/K1.md | None (offline doc) | 2m | ✅ 2026-06-14 |
Rationale: All offline — no Azure credentials needed. D1/R1/C4 are the local dev contract; D3/D5 extend it to OPA policies; D2 extends it to the GitHub PR gate. K1 validates the five IR playbooks are structurally complete — fast enough (~2 min) to run here alongside the other doc-quality checks.
Phase 2: Kyverno Policy Bundle (~20 min, offline)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 7 | D4 | Kyverno Policy Bundle (D4 + X4) | test/D4.md | None (offline) | 20m | ✅ 2026-06-16 |
Rationale: Offline — requires only a local kind cluster for Part C. Tests the SnowOps
Kyverno bundle and the X4 kyverno-install chart (both covered by this single runbook).
Phase 3: Security Scanning (~20 min, offline/CI)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 8 | I1 | Container Image Scanning | test/I1.md | None | 5m | ✅ 2026-06-16 |
| 9 | I2 | Dependency Scanning | test/I2.md | None | 5m | ✅ 2026-06-16 |
| 10 | I3 | CodeQL SAST | test/I3.md | None | 10m | ⬜ |
Rationale: Offline YAML-lint parts require only Python. Parts B/C require GitHub Actions (no Azure credentials). Validate the security-scanning pipeline early — it gates every future PR.
Phase 4: Visualization & Evidence (~35 min, offline)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 11 | V2 | Architecture Diagrams Generator | test/V2.md | None (offline) | 10m | ✅ 2026-06-03 |
| 12 | V3 | Runbook Generator | test/V3.md | None (offline) | 5m | ✅ 2026-06-03 |
| 13 | E0 | Lightweight Compliance Snapshot | test/E0.md | V2, V3 outputs | 10m | ⬜ |
| 13a | E4 | Resource Graph Query Library | test/E4.md | E0 (query substrate) | 10m | ⬜ |
Rationale: V2 and V3 are 100% offline golden-file tests. E0 snapshots compliance evidence from TF outputs; offline Part A/B can run here, live Part C runs after Phase 5. E4 extends E0's query substrate with the full Azure Resource Graph library — offline-capable and tested alongside E0 before any cloud work starts.
Phase 5: Sandbox Subscription Setup (~40 min)¶
Stand up the sandbox and validate the Terratest harness before any cloud tests.
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 14 | X1 | SnowOps Sandbox Subscription | test/X1.md | Phase 0 (Azure creds) | 20m | ✅ 2026-06-16 |
| 15 | X2 | Terratest Harness | test/X2.md | X1 (sandbox live) | 15m | ✅ 2026-06-16 |
| 16 | B6 | Client Self-Service Bootstrap | test/B6.md | None (read-only) | 5m | ⬜ |
Rationale: X1 provisions the sandbox subscription (budget alerts, tag policy, Defender, Activity Log). X2 proves the Go Terratest harness can reach the sandbox. B6 validates the client-facing prerequisite checker offline.
Phase 6: Reliability & DR Modules (~25 min offline + optional cloud)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 17 | L1 | Azure Backup Policy Module | test/L1.md | X1 (sandbox for Part C) | 8m | ⬜ |
| 18 | L2 | Cross-Region Replication Module | test/L2.md | L1 (backup foundation) | 8m | ⬜ |
| 19 | L4 | Automated Restore Drill | test/L4.md | L1, L2 (backups in place) | 10m | ⬜ |
Rationale: L1 defines the backup baseline; L2 adds geo-redundancy; L4 validates the full restore chain end-to-end. Parts A/B of each are offline.
Phase 7: Bootstrap & State Modules (~65 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 20 | F1 | Baseline Module | test/F1.md | X1, X2 (sandbox) | 20m | ⬜ |
| 21 | F6 | State-Backend Module | test/F6.md | X1, X2 (sandbox) | 20m | ⬜ |
| 22 | B3 | Subscription Baseline (F1 + Group RBAC + MCSB) | test/B3.md | F1 (baseline module) | 15m | ⬜ |
| 23 | B4 | Client State Backend (F6 + Blob RBAC) | test/B4.md | F6 (state-backend module) | 15m | ⬜ |
| 24 | B2 | Client-Bootstrap (AAD App Reg + Federated OIDC) | test/B2.md | F1, F6 (baseline + state) | 25m | ⬜ |
| 25a | F11 | Module Versioning + Private Registry | test/F11.md | None (git + metadata only) | 6m | ⬜ |
| 25 | F7 | Terragrunt Live-Infra Reference | test/F7.md | F1, F6 (modules in place) | 20m | ⬜ |
Rationale: F1 and F6 are the baseline and state foundation for all subsequent modules. B3/B4 validate end-to-end provisioning using those modules. B2 bootstraps client OIDC. F7 validates the terragrunt live/ directory structure.
Phase 8: Azure Policy Suite (~85 min)¶
Subscription-scoped Azure Policy modules — all follow offline-validate → sandbox-apply pattern.
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 26 | U1 | Subscription Budget + Alerts | test/U1.md | X1 (sandbox sub) | 10m | ⬜ |
| 27 | U2 | Require Mandatory Tags (Azure Policy) | test/U2.md | X1 (sandbox sub) | 10m | ⬜ |
| 28 | M1 | Deny Unencrypted Resources (Azure Policy) | test/M1.md | X1 (sandbox sub) | 10m | ⬜ |
| 29 | M2 | Customer-Managed Keys (HSM-backed, auto-rotation) | test/M2.md | X1, F5 (KV for Part D) | 15m | ⬜ |
| 30 | M3 | Enforce TLS 1.2+ / HTTPS-only (Azure Policy) | test/M3.md | X1 (sandbox sub) | 10m | ⬜ |
| 31 | M6 | Data Residency — Allowed Regions Only (Azure Policy) | test/M6.md | X1 (sandbox sub) | 10m | ⬜ |
| 32 | N5 | Deny Public Network Access on PaaS (Azure Policy) | test/N5.md | X1 (sandbox sub) | 10m | ⬜ |
Rationale: Foundational guardrails applied at subscription scope. U1/U2 cover cost and tagging hygiene. M1/M3/M6 cover encryption, TLS, and data-residency policies. N5 enforces private networking. These are prerequisites for all subsequent module deployments to be compliant.
Phase 9: Monitoring, Logging & On-Call (~60 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 33 | J1 | Log Analytics Workspace | test/J1.md | X1, F1 (sandbox + baseline) | 15m | ⬜ |
| 34 | J2 | Enforce Diagnostic Settings (Azure Policy) | test/J2.md | J1 (LAW for DINE) | 15m | ⬜ |
| 35 | J4 | Detection Alert Rule Pack | test/J4.md | J1 (LAW ARM ID) | 15m | ⬜ |
| 36 | X8 | Synthetic Monitoring | test/X8.md | J1 (LAW for alerts) | 15m | ⬜ |
| 36a | K2 | On-Call Integration | test/K2.md | J1 (LAW), J4 (Sentinel alerts) | 10m | ⬜ |
Rationale: J1 is the log-collection backbone; everything else in this phase feeds into it. J2 automatically wires new resources to J1 via DINE policy. J4 adds curated Defender alerts. X8 adds Application Insights web tests. K2 connects Sentinel/Defender to the paging system (PagerDuty/Opsgenie/Slack) and must come after J4 so the alert rules it consumes are live.
Phase 10: Identity & Azure AD (~90 min, requires tenant sandbox)¶
Note: This phase requires a separate Azure AD tenant sandbox (snowops-sandbox-tenant-01),
distinct from the subscription sandbox used in previous phases.
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 37 | H1 | Azure AD Tenant Baseline | test/H1.md | Tenant sandbox access | 25m | ⬜ |
| 38 | H2 | Conditional Access Bundle | test/H2.md | H1 (AAD baseline) | 30m | ⬜ |
| 39 | H3 | PIM Eligible Role Templates | test/H3.md | H1 (AAD baseline) | 30m | ⬜ |
| 40 | H7 | Break-Glass Accounts + Sign-In Alert | test/H7.md | H1 (AAD baseline) | 30m | ⬜ |
| 41 | H5 | Service Principal Inventory + Rotation | test/H5.md | H1 (tenant read access) | 20m | ⬜ |
| 42 | B5 | PIM for Azure Resources | test/B5.md | H3 (PIM templates) | 25m | ⬜ |
Rationale: H1 establishes the AAD tenant baseline (auth policies, security defaults). H2 adds Conditional Access. H3 defines PIM role eligibility templates. H7 creates emergency break-glass accounts. H5 inventories and rotates service principal credentials. B5 activates PIM eligibility for Azure resource roles.
Phase 11: Core Network & Compute Modules (~130 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 43 | F2 | Network Hub | test/F2.md | X1, F1, F6 (sandbox + state) | 45m | ⬜ |
| 44 | N6 | NSG Baseline + Flow Logs | test/N6.md | F2 (hub network) | 15m | ⬜ |
| 44a | N3 | WAF Policy Module | test/N3.md | F2 (hub network) | 5m | ⬜ |
| 44b | N4 | DDoS Network Protection | test/N4.md | F2 (hub network) | 5m | ⬜ |
| 45 | F3 | AKS Secure | test/F3.md | F2, N6 (hub + NSG) | 30m | ⬜ |
| 46 | F4 | Azure Container Registry | test/F4.md | F2 (hub network) | 30m | ⬜ |
| 47 | F5 | Azure Key Vault | test/F5.md | F2 (hub network) | 30m | ⬜ |
| 48 | J6 | WORM Audit-Log Archive | test/J6.md | J1 (LAW), F5 (KV) | 15m | ⬜ |
| 49a | F8 | K8s Reference Manifests Bundle (ArgoCD app-of-apps) | test/F8.md | F3 (AKS), F5 (KV), D4 (Kyverno) | 40m | ⬜ |
| 49 | X7 | Sandbox Cleanup Workflow | test/X7.md | X1 (sandbox live) | 10m | ⬜ |
Rationale: F2 is the hub network — all other network-connected modules depend on it. N6 adds NSG baseline and flow logs. N3 (WAF Policy) and N4 (DDoS Protection) attach network security controls at the hub level; N4 Part C carries a cost warning (~$2,944/mo) — destroy immediately after. F3 deploys the AKS private cluster. F4 (ACR) and F5 (KV) attach via private endpoints. J6 adds WORM audit log archiving. F8 installs the ArgoCD app-of-apps GitOps bundle onto the AKS cluster. X7 runs nightly to clean up sandbox resource groups.
Phase 12: Drift, Compliance & Evidence Adapters (~55 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 50 | S1 | Scheduled Terraform Drift Detection | test/S1.md | X1, F1, F6 (state backend) | 10m | 🟨 offline only (2026-06-03) |
| 51a | S2 | Azure Policy Compliance Dashboard | test/S2.md | E0 (snapshots), L4 (optional DR panel) | 6m | ⬜ |
| 51 | E2 | Vanta Adapter | test/E2.md | E0 (evidence snapshots) | 10m | ⬜ |
| 51b | E3 | Drata Adapter Stub | test/E3.md | E0 (evidence snapshots) | 10m | ⬜ |
| 51c | E5 | Evidence Sync | test/E5.md | E0, E2, E3 (adapters ready) | 10m | ⬜ |
| 51d | E6 | Access Review Automation | test/E6.md | H1, H3 (AAD/PIM identity) | 10m | ⬜ |
Rationale: S1 detects drift via scheduled terraform plan (Part C needs live state backend). S2 aggregates E0 snapshot history into a compliance dashboard (fully offline). E2 and E3 are parallel GRC-platform adapters (Vanta and Drata respectively) — both consume E0 snapshots. E5 syncs evidence across all configured adapters; run after E2/E3 are validated. E6 automates PIM/AAD access reviews and requires the identity foundation from Phase 10 (H1/H3).
Phase 13: Ticketing & Reporting (~30 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 52 | E7 | TicketPlatform Adapters | test/E7.md | None (offline Parts A/B) | 10m | ⬜ |
| 53 | R2 | Production Change Log | test/R2.md | E7 (ticket adapter) | 10m | ⬜ |
| 54 | I5 | Defender → Ticket (via E7) | test/I5.md | E7 (ticket adapter) | 10m | ⬜ |
Rationale: E7 is the ticket-platform CLI abstraction; R2 and I5 both depend on it. E7 Parts A/B are offline (unit tests + dry-run). Parts A/B of R2 and I5 are also offline, making this phase largely offline-first.
Phase 14: CI/CD Pipelines (~110 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 55 | C1 | terraform-plan-apply Reusable Workflow | test/C1.md | X1, F1, F6 (sandbox + state) | 30m | ⬜ |
| 56 | C2 | container-build-sign Reusable Workflow | test/C2.md | F4 (ACR), F5 (KV) | 40m | ⬜ |
| 57 | C3 | aks-deploy Reusable Workflow | test/C3.md | F3 (AKS), F8 (ArgoCD) | 75m | ⬜ |
| 58 | X5 | Pipeline Integration Tests | test/X5.md | C1, C2, C3 (all pipelines) | 20m | ⬜ |
| 59 | B1 | snowops-onboarder GitHub App | test/B1.md | B2 (App Reg), C4 (template) | 60m | ⬜ |
Rationale: C1 (terraform CI) needs a live state backend. C2 (container build + sign) needs ACR (F4) and Key Vault (F5). C3 (AKS deploy) needs a running AKS cluster (F3) and ArgoCD (F8). X5 exercises the integration contracts between all three. B1 (the onboarder) consumes B2 and C4 to provision client repos.
Phase 15: Module Contracts & Brownfield (~35 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 60 | F0 | Cloud-Agnostic Module Contracts | test/F0.md | All F-modules (offline validation) | 15m | ⬜ |
| 61 | F12 | Brownfield Import Library | import/F12.md | X1, X2 (sandbox for Part C) | 20m | ⬜ |
Rationale: F0 validates the cloud-agnostic output contracts across all F-modules; it only needs the module definitions (offline). Run it after all F-modules are implemented. F12 tests the import-block library for adopting pre-existing Azure resources.
Phase 16: Discovery & CRM Pipeline (~90 min)¶
| # | Asset | Name | Link | Dependencies | Time | Status |
|---|---|---|---|---|---|---|
| 62 | G0 | Discovery Auditor — Reader SP Bootstrap | test/G0.md | X1 (sandbox, Owner via PIM) | 20m | ⬜ |
| 63 | G2 | Discovery — YAML Rule Pack + Engine | test/G2.md | None (offline) | 10m | ⬜ |
| 64 | G3 | Discovery — Report Renderer | test/G3.md | None (offline + Pandoc) | 10m | ⬜ |
| 65 | G1 | Discovery — Collectors | test/G1.md | G0 (Reader SP), X1 (sandbox) | 20m | ⬜ |
| 66 | G4 | Discovery Run Workflow | test/G4.md | G0, G1, G2, G3 | 20m | ⬜ |
| 67 | G5 | HubSpot Deal Attachment | test/G5.md | G4 (discovery report URL) | 10m | ⬜ |
| 68 | G6 | Immutable Run Audit Log | test/G6.md | G0, G4 (run complete) | 20m | ⬜ |
| 69 | A1 | HubSpot Lead Enrichment | test/A1.md | HubSpot sandbox, Clearbit token | 10m | ⬜ |
| 70 | A5 | HubSpot Discovery Trigger | test/A5.md | G4 (workflow), A1 (HubSpot) | 10m | ⬜ |
Rationale: G0 creates the read-only discovery service principal; all collectors (G1) depend on it. G2 and G3 are offline and can be done in parallel with G0/G1. G4 is the end-to-end workflow that ties together all G-components. G5 and G6 depend on G4 completing successfully. A1 and A5 are the CRM integration layer; A5 dispatches the G4 workflow from HubSpot.
Quick Reference: Sign-Off Status¶
✅ SIGNED OFF (13): D1 (2026-05-26), R1 (2026-05-26), C4 (2026-05-26),
D3 (2026-06-14), V2 (2026-06-03), V3 (2026-06-03),
D5 (2026-06-14), K1 (2026-06-14), D4 (2026-06-16),
I1 (2026-06-16), I2 (2026-06-16), X1 (2026-06-16), X2 (2026-06-16)
🟨 PARTIAL (1): S1 — offline parts only (2026-06-03); live Part C pending
⬜ PENDING (70): All other assets in phases above
Total tracked assets: 84 (all with runbook files)
Execution Tips¶
Before You Start¶
🚨 STOP: Complete Phase 0 first! → client-onboarding/01-azure-cloud-setup.md
During Execution¶
- Work offline-first — Phases 1–4 need no cloud credentials. Complete them in any session.
- Respect phase order — Phases 5+ have real dependency flows; don't skip ahead.
- Fill sign-off blocks — every runbook has a "Sign-off" section with tester/date/result.
- Keep a log — use the sample log below; copy it to your local notes.
- Link bugs — if a test fails, create an issue and reference it in the runbook's notes.
- Tenant vs. subscription sandbox — Phase 10 needs a tenant sandbox (
snowops-sandbox-tenant-01); all other cloud phases use the subscription sandbox (snowops-sandbox-01).
Sample Execution Log¶
## Execution Log — [Date]
| Phase | Asset | Tester | Date | Result | Notes |
|-------|-------|--------|------------|--------|--------------------------------------------|
| 1 | D1 | Sagar | 2026-05-26 | PASS | All hooks fire; gitleaks blocked correctly |
| 1 | R1 | Sagar | 2026-05-26 | PASS | PR template check passes |
| 4 | V2 | Sagar | 2026-06-03 | PASS | Golden-file matches; d2 render skipped |
| 12 | S1 | Sagar | 2026-06-03 | PASS* | Offline only; live Part C pending |
Dependencies Map¶
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 0: PRE-FLIGHT (one-time) │
│ Azure creds + Terratest harness + schema validation │
│ 👉 client-onboarding/01-azure-cloud-setup.md │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASES 1–4: OFFLINE (no cloud) │
│ P1: D1 → R1 → C4 → D3 → D5 → D2 (quality gates) │
│ P2: D4 (Kyverno, offline) │
│ P3: I1, I2, I3 (security scanning) │
│ P4: V2 → V3 → E0 (visualization + evidence) │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 5: SANDBOX SETUP │
│ X1 (subscription) → X2 (Terratest harness) │
│ B6 (bootstrap checker, offline) │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASES 6–9: SUBSCRIPTION-SCOPED MODULES │
│ P6: L1 → L2 → L4 (reliability / DR) │
│ P7: F1 → F6 → B3, B4, B2 → F7 (bootstrap + state) │
│ P8: U1, U2, M1, M2, M3, M6, N5 (policy suite, parallel) │
│ P9: J1 → J2, J4, X8 (monitoring + logging) │
└─────────────────┬─────────────────────┬───────────────────────┘
↓ ↓
┌─────────────────────────┐ ┌──────────────────────────────────┐
│ PHASE 10: TENANT IDENTITY│ │ PHASE 11: NETWORK + COMPUTE │
│ H1 → H2, H3, H7 │ │ F2 (hub) → N6 → F3 (AKS) │
│ H3 → B5 │ │ F2 → F4 (ACR), F5 (KV) │
│ H5 (SP rotation) │ │ J1 + F5 → J6 (WORM archive) │
└──────────────────────────┘ │ F3+F5+D4 → F8 (ArgoCD bundle) │
│ X7 (sandbox cleanup) │
└──────────────┬───────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASES 12–13: COMPLIANCE & TICKETING │
│ P12: S1, S2[TBD], E0 → E2 (Vanta) │
│ P13: E7 → R2, I5 (ticketing + Defender) │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 14: CI/CD PIPELINES │
│ F1+F6 → C1 (terraform plan-apply) │
│ F4+F5 → C2 (container build + sign) │
│ F3+F8 → C3 (AKS deploy) │
│ C1+C2+C3 → X5 (pipeline integration tests) │
│ B2+C4 → B1 (GitHub onboarder) │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 15: CONTRACTS + BROWNFIELD │
│ (all F-modules) → F0 (cloud-agnostic contracts) │
│ X1+X2 → F12 (brownfield import) │
└────────────────────────┬────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 16: DISCOVERY + CRM │
│ X1 → G0 → G1 │
│ G0+G1+G2+G3 → G4 → G5, G6 │
│ G4 → A5; HubSpot → A1 → A5 │
└─────────────────────────────────────────────────────────────────┘
FAQs¶
Q: Can I skip a runbook? A: No. Every asset must have its sign-off block filled. If N/A, mark result as "N/A" with a note.
Q: What if a runbook fails? A: Create a bug issue, link it in the runbook notes, move to the next asset. Return after the fix.
Q: Can I run runbooks in parallel? A: Within a phase, assets with no inter-dependencies can run in parallel. For example, in Phase 8 all seven policy modules are independent of each other. In Phase 16, G2 and G3 can be done concurrently with G0.
Q: The Phase 10 "tenant sandbox" — is that different from the subscription sandbox?
A: Yes. Phase 10 modules (H-series, B5) modify the Azure AD tenant (Conditional Access, PIM,
AAD baseline). Use a dedicated sandbox tenant (snowops-sandbox-tenant-01). The subscription
sandbox (snowops-sandbox-01) is used by all other phases.
Q: Who approves sign-offs? A: For now, Sagar. Community contributors may propose sign-offs once open; Sagar reviews.
Q: How often do I re-run a signed-off runbook? A: Only when the asset's code changes. The sign-off is a watermark for "works in sandbox as of this date."
Q: What does the suffix "a" mean on order numbers like 25a, 49a, 51a? A: These assets were added after the initial numbering pass. The "a" suffix slots them between their neighbours without renumbering everything. They are full runbooks, not optional extras.
Next Steps¶
- FIRST: Complete Phase 0 →
client-onboarding/01-azure-cloud-setup.md - Start Phase 1 (D1 is offline, ~15 min). Phases 1–4 need no cloud at all.
- After Phase 5 (X1 + X2 sandbox live), all cloud phases unlock.
- Update sign-off as you go — fill the sign-off block in each runbook file.
- After each session, update
docs/context/06-project-state.md. - When all 73 assets are complete, update
CLAUDE.md§ Machine State and commit.
Part 2: Operational Runbooks¶
These are live-operation playbooks — used during real incidents, DR events, change windows, client offboarding, privacy requests, and team exercises. They are not test/sign-off runbooks.
Incident Response¶
Index: incident/README.md
Five incident classes, each following Identification → Containment → Eradication → Recovery → Post-Incident (PICERL).
| Runbook | Trigger |
|---|---|
| incident/compromise.md | Suspicious login, PIM alert, MFA fatigue, credential compromise |
| incident/data-leak.md | DLP alert, abnormal egress, exposed SAS URL, GitHub secret scan hit |
| incident/ddos.md | Volumetric (L3/4) or application-layer (L7) DDoS against Azure Front Door / WAF |
| incident/ransomware.md | Defender alert for malware, encrypted VM/share, lateral spread |
| incident/vendor-breach.md | Third-party vendor breach disclosure affecting SnowOps OIDC / API keys |
Tabletop simulations for each of the five classes are in Part 2 § Tabletop Exercises.
Disaster Recovery¶
Index: dr/README.md
DR estate: L1 (Azure Backup), L2 (Cross-Region Replication), L4 (Restore Drill), L3 (templates). RTO/RPO targets by environment are defined in the DR README.
| Runbook | When to use |
|---|---|
| dr/dr-plan-template.md | Master DR plan template — fill in for each client / workload |
| dr/scenario-region-failover.md | Planned or forced failover to secondary region (SQL failover group + blob + edge routing) |
| dr/scenario-full-region-loss.md | Worst-case: entire primary region unavailable; rebuild from IaC in secondary |
| dr/scenario-sql-failover.md | SQL-specific failover group promotion (planned zero-loss or forced with data-loss path) |
| dr/scenario-data-restore.md | Point-in-time data restore from L1 vaults (VM, Azure Files, AKS, blob) |
Change Management¶
Index: change/README.md
Two approval paths: normal CAB pre-approval and emergency break-glass with retrospective review.
| Runbook | When to use |
|---|---|
| change/emergency-change.md | Expedited change (R3) bypassing CAB when delay would cause unacceptable harm; retrospective required within 5 business days |
Client Offboarding¶
Index: offboarding/README.md
Eight-phase playbook for winding down a SnowOps engagement: evidence freeze, knowledge transfer, identity teardown, repo hand-back, state/secrets transfer, cost/monitoring reassignment, optional decommission, and final attestation.
| Runbook | When to use |
|---|---|
| offboarding/client-offboarding.md | Full W4 offboarding playbook — start here when an engagement ends |
Privacy & DSAR¶
Index: privacy/README.md
GDPR (30-day) and CCPA (45-day) data-subject request workflows.
| Runbook | When to use |
|---|---|
| privacy/dsar-workflow.md | Data-subject access, deletion, or portability request — intake to response |
| privacy/dsar-record.template.md | Blank DSAR record template to fill in per request |
Tabletop Exercises¶
Index: tabletop/README.md
Discussion-based rehearsals, 1:1 with the five K1 incident classes. Run quarterly for prod, twice-yearly for staging. Each session follows the facilitation guide.
| Runbook | Maps to |
|---|---|
| tabletop/facilitation-guide.md | How to facilitate: prep, ground rules, timeboxing, inject-reveal, rubric scoring |
| tabletop/scenario-account-compromise.md | incident/compromise.md |
| tabletop/scenario-data-exfiltration.md | incident/data-leak.md |
| tabletop/scenario-ddos.md | incident/ddos.md |
| tabletop/scenario-ransomware.md | incident/ransomware.md |
| tabletop/scenario-vendor-breach.md | incident/vendor-breach.md |
| tabletop/after-action-template.md | After-action report template (fill in after each exercise) |
| tabletop/tabletop-template.md | Blank scenario template for creating new tabletop exercises |
Document version: 2.0
Sync with: CLAUDE.md (§ 0. Session Handoff), docs/context/06-project-state.md, docs/context/09-testing-dod.md