Sample case

Approval-gated containment review

This is a named published explanatory sample case showing how WitnessOps would review a containment path that requires recorded approval before execution. It is a stable explanatory route, not a live customer artifact and not a claim of completed verification for your environment.

Artifact class: Explanatory sample case
Class: Workflow type
Status: Not live
Request Proof RunCompare with sample reportBrowse all named sample cases
Case name

Approval-gated containment review

Decision class

Containment action requiring recorded approval before execution

Primary question

Did the containment action occur only after real authority was recorded, and does the evidence path survive outside the response system?

Publication status

Published named sample case for product explanation. Not a live customer artifact and not a claim of completed verification for your environment.

Artifact manifest

Artifact class
Published explanatory sample case
Receipt status
No live customer receipt published on this page
Publication status
Public named sample case with stable route
Replay scope
Narrative review path and named evidence expectations only
Trust-dependent gaps
Pre-execution gate enforcement proof, target-state confirmation, and portable replay outside response tooling

Review boundary

  • Containment request and stated incident rationale
  • Approver identity, standing, and approval event
  • Execution path for the containment action
  • Target-side evidence that the action actually took effect
  • Exportable artifacts used to replay the judgment outside the operator environment

Authority map

Incident operator
Requests the containment action for one bounded target based on incident context.
Containment approver
Approves, rejects, or delays the action under incident authority and policy constraints.
Execution surface
Runs the actual containment command or workflow after the gate condition is met.
Target system
Reflects the blocked account, isolated host, revoked token, or other containment result.
Evidence export path
Carries approval, execution, and target-state evidence out for later inspection.

Execution path observed

  1. Operator opens a containment request for one named target and one defined action.
  2. Approver reviews urgency, scope, and blast radius, then records a decision.
  3. Execution surface checks the recorded approval state before running the action.
  4. Containment action is applied to the target system or identity surface.
  5. System emits execution events and target-side state evidence.
  6. Artifacts are exported for later replay outside the source environment.

Evidence inspected

  • Containment request record with target, action, and incident rationale
  • Approval event showing approver identity, time, and decision state
  • Execution record from the workflow runner or command surface
  • Target-side confirmation that the containment state actually changed
  • Exported artifacts used to replay the judgment outside the source system

Replayability judgment

  • Potentially replayable: request record, approval event, execution event, and target-state evidence when they share stable identifiers.
  • Still trust-dependent: proof that approval was technically enforced as a no-bypass gate unless the execution artifact explicitly binds the gate result.
  • Blocking gap: lack of one exportable artifact that binds approval, gate enforcement, action execution, and resulting target state.

Integrity risks

Approval may exist without hard pre-execution enforcement proof

  • Observed condition: The approval event is recorded, but the execution record does not always prove that the runner enforced approval as a hard gate before the action fired.
  • Why it matters: A reviewer may see both approval and execution while still lacking proof that execution was impossible before approval.
  • Stronger evidence to close: Emit one signed artifact binding approval state, gate evaluation, execution start time, and target action ID.

Target-side effect evidence can be weaker than command evidence

  • Observed condition: The workflow shows that a containment command ran, but target-side proof of the blocked or isolated state may be incomplete or delayed.
  • Why it matters: Reviewers can prove that the command was attempted without proving at the same fidelity that the target actually entered the intended containment state.
  • Stronger evidence to close: Capture target-state confirmation alongside the execution record with stable identifiers and timestamps.

Replay path may depend on incident tooling access

  • Observed condition: Judgment often relies on internal consoles, SIEM views, or response tooling that outside reviewers cannot access.
  • Why it matters: Third parties may need screenshots or operator narration instead of a portable replay path.
  • Stronger evidence to close: Publish a bounded artifact set with request, approval, execution, target-state evidence, and replay instructions that work outside the original tooling.

Operator recommendation

Publish one bounded artifact set for the containment path: request, approver standing, gate result, execution event, target-state confirmation, and a replayable receipt that binds them together outside the source systems.

Boundary note

This sample case is limited to the containment path described on this page. It does not claim broader incident-response assurance, SOC maturity, or environment-wide verification.