OPERATE
Operations

Runbooks

Repeatable operator workflows for controlled execution and incident handling.

Runbooks are the operational contract that turns authorized work into bounded, repeatable execution paths.

1. Problem this page solves

Without runbooks, operations drift into ad hoc tool use and uneven evidence quality.

This page explains how runbooks constrain execution shape so governed operations stay repeatable and reviewable.

2. What you should understand after reading

After this page, you should understand:

  • what a runbook defines
  • how runbooks connect authorization to execution controls
  • how runbook steps relate to evidence and approvals
  • what this page leaves to deeper schema and command references

3. Mechanism-first runbook model

  1. Authorized work enters operations.
  2. A runbook is selected by objective and risk class.
  3. Scope and policy gates are declared per step.
  4. Execution runs in ordered, bounded steps.
  5. Evidence and receipt continuity are emitted.
  6. Escalation or closure follows policy outcomes.

Runbooks govern execution shape. They do not replace authorization policy or verification logic.

4. Core runbook components

Every runbook should define:

  • Metadata: runbook ID, version, classification, owner
  • Scope: allowed targets and exclusions
  • Steps: ordered actions with tool references and gate requirements
  • Evidence contract: expected artifacts and continuity expectations

Example shape

runbook:
  id: rb_external_recon_v2
  version: 2
  classification: reconnaissance

scope:
  targets:
    - "example.com"
    - "10.0.1.0/24"

steps:
  - id: step_dns_enum
    tool: dns-enumeration
    gates:
      - type: scope_check

  - id: step_vuln_scan
    tool: nuclei
    gates:
      - type: scope_check
      - type: approval

evidence:
  outputs:
    - dns_records
    - vulnerability_findings
  receipt_chain: true

5. Observed vs inferred

LayerWhat is observedWhat is inferred
Observeddeclared step order, gate requirements, scope constraints, emitted evidence contractnone beyond the declared runbook design
Inferredoperational quality and safety of outcomesdepends on execution discipline and enforcement fidelity

6. Trust assumptions

Runbook governance still depends on:

  • correctness of upstream authorization and scope inputs
  • runtime and tool integrity during execution
  • operator adherence to defined step and escalation behavior
  • exception-path controls when normal boundaries are bypassed

Runbook versioning improves traceability, but it does not prove execution quality on its own.

7. Next-page handoff

Next, read Decisions to see how operators decide scope, evidence sufficiency, and escalation while executing runbook-defined workflows.

Runbooks | WitnessOps