Inside a Gamebook: How SOPs Become Code

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

Every MSSP has a phishing response SOP. Every MSSP has a credential-harvest runbook. Every MSSP has a procedure for an executive impossible-travel alert. The problem isn’t that the SOPs don’t exist, it’s that they live in human form. They’re documentation that someone wrote two years ago, that has drifted as the team changed, and that no two analysts actually execute the same way.

What a Gamebook is

A Gamebook is an SOP rendered as an executable, governed workflow. It defines the steps the Security Delivery Agents will take. It defines the gates where a human analyst has to approve before a high-risk action is executed. It defines what evidence gets captured and what fields populate the customer ticket.

The point isn’t to write code. The point is to make the SOP the system of record. When the SOP changes, because the threat changed, the customer’s policy changed, or the team learned something new, the Gamebook is the artifact you update. Every workspace running that Gamebook gets the new behavior the next time the trigger fires.

What versioning gives you

Where it gets interesting

The most valuable Gamebooks are usually the ones nobody wrote down. They’re the institutional knowledge in your senior analysts’ heads, how to triage a specific kind of business email compromise pattern, what to check before isolating a domain controller, when to wake the customer up. Capturing that knowledge as a Gamebook is how an MSSP keeps its institutional advantage when the people who built it move on.