Gamebooks: Enforce SOPs Across Every Tenant, Every Time

Reviewed by ContraForce Security Operations Team · Updated 2026-08-12

A ContraForce Gamebook is a versioned operating procedure that governs how a Security Delivery Agent investigates and responds. It defines required evidence, permitted tools, decision conditions, action authority, approval gates, escalation rules, and the record that must be preserved.

This page consolidates the former “Inside a Gamebook” article into the canonical product guide. A Gamebook is not source code generated from a prose document, and publishing a procedure does not make every incident safe to automate. Operators remain responsible for the policy, integrations, customer exceptions, approvals, and review cadence.

Why SOP documents drift

Traditional SOPs often live in documents, ticket templates, and operator knowledge. They can describe the intended process without enforcing it. Drift appears when analysts gather different evidence, skip steps under pressure, interpret authority differently, or record outcomes inconsistently.

A governed procedure addresses that gap by making the operational boundary explicit and testable. The goal is consistent execution with visible exceptions, not the removal of human accountability.

Anatomy of a Gamebook

From SOP to governed procedure

1. Select one incident class

Start with a frequent, well-understood class rather than converting every document at once. Identify the alert source, expected evidence, common benign explanations, confirmed-threat conditions, and current escalation path.

2. Define evidence before actions

List the observations required to support each outcome. Separate facts returned by connected tools from assumptions or model-generated summaries. If required evidence is unavailable, the Gamebook should stop or escalate rather than fill the gap.

3. Separate confidence from authority

An agent may reach a high-confidence verdict while still lacking permission to take a consequential action. Configure read, recommend, approve, and execute authority independently for each action and customer.

4. Encode exceptions without forking everything

Use a shared base procedure with explicit customer overrides for protected assets, notification requirements, contractual response authority, ticket routing, and escalation contacts. Keep each override attributable and reviewable.

5. Define the evidence record

Specify what the ticket and audit record must contain: procedure version, evidence sources, observations, verdict, actions attempted, approvals, failures, final disposition, and customer-facing summary.

6. Test in recommendation-only mode

Run known benign, confirmed-threat, ambiguous, exception, and integration-failure scenarios before permitting actions. Compare the proposed result with the approved procedure and have a qualified operator review discrepancies.

7. Expand authority deliberately

Move an action from recommendation to approval-gated or automatic execution only after the test evidence supports that change. Record who approved the change, the applicable tenants, and the rollback condition.

Example: phishing investigation boundary

A phishing Gamebook might require message headers, sender reputation, URL or attachment observations, recipient activity, identity signals, and mailbox state. It could permit evidence collection and ticket updates automatically while requiring approval for message purge, account disablement, or session revocation.

The exact evidence and action set depends on the connected products, delegated permissions, customer policy, and incident type. The procedure should state what happens when any required source is unavailable.

Versioning and change control

Each published Gamebook should have:

• A stable identifier and version
• An owner and approver
• A change summary and effective date
• Test fixtures and expected outcomes
• Applicable customers and overrides
• Rollback instructions
• A review trigger for integration, permission, threat, or contractual changes

Gamebooks, playbooks, and runbooks

A runbook documents a procedure for a human. A Microsoft Sentinel playbook executes a defined Logic Apps workflow. A Gamebook governs an agent that may adapt its investigation within explicit constraints. These artifacts can work together: policy establishes authority, a Gamebook governs decisions, and a playbook or integration can execute a specific operation.

See the full Gamebooks vs playbooks vs runbooks comparison, use the AI SOC RFP checklist to evaluate governance controls, and validate the Microsoft Defender XDR integration boundary before granting response authority.

Review checklist

• Can an operator identify the active procedure and version?
• Does every verdict require named evidence?
• Are action authority and investigation confidence separate?
• Do customer exceptions remain visible and attributable?
• Does missing evidence produce a safe stop?
• Are retries and integration failures visible?
• Are approvals tied to a person, action, and time?
• Can the final service record be reproduced from retained evidence?
• Has the failure path been tested as carefully as the happy path?

What are Gamebooks in ContraForce?

Gamebooks are ContraForce's SOP enforcement engine. They turn standard operating procedures into executable, governed workflows that Security Delivery Agents follow across every tenant.

How do Gamebooks standardize SOPs across Sentinel tenants?

Gamebooks define the exact investigation and response procedures for each incident type. When an incident occurs in any tenant, Security Delivery Agents execute the Gamebook workflow consistently.