VIII.6VIII · Govern itgovern

The advisor's playbook

This is the consulting layer of the playbook: how to turn everything else into work a client will pay for - assess what they have, explain it to a board, recommend what to fix first, then stand up the program that keeps it fixed.

The engagement: scope, phase, deliver

Before the method comes the statement of work. Scope it wrong and you either underprice a program or overpromise on a two-week look. The three questions that set every SOW: how deep (a rapid diagnostic vs. a full ISO/IEC 42001 readiness), how many systems (a named tier-1 shortlist, not “all AI” - unbounded scope is the classic loss-maker), and what they can act on when you leave.

Engagement	Duration	Fee model	Sold as
Rapid AI risk diagnostic	2 - 4 weeks	Fixed fee	Top-system risk register + board slides
Governance readiness	6 - 12 weeks	Fixed fee, phased	ISO/IEC 42001 / NIST AI RMF gap + roadmap
Program build & run	3 - 6 months	Fixed + retainer	Standing governance function (Govern above)
AI red-team assessment	2 - 3 weeks	Fixed fee	Adaptive findings mapped to ATLAS (VI.4)

Phase the work so each stage has an exit a client can approve before funding the next: Discover (inventory + evidence gathering) → Assess (per-system risk + gap) → Recommend (prioritized, costed roadmap) → Govern/Run (program stand-up, optional retainer). Fixed fee per phase with a go/no-go gate beats an open-ended time-and-materials line.

Discover (turn “assess” into an activity)

You cannot assess a system you cannot see, and most clients hand you nothing - no inventory, no diagram, no list. Discovery is the operational bridge: gather evidence, interview the people who know, and build the inventory the assessment consumes. Budget one to two weeks for a first-pass inventory; treat full discovery as an ongoing program, not a one-time scan.

Stakeholder-interview map - who to interview and the one question that unlocks each:

Interview	The question that surfaces risk
CISO / security lead	Which AI systems are in scope, and what keeps you up at night?
Model / product owners	What can this system read, and what can it do unsupervised?
Data / privacy officer	What regulated data reaches a model, and under what basis?
Legal / procurement	Which vendor AI did we buy, and what did the contract commit us to?
Platform / SRE	What egress and tool-call telemetry already exists to mine?
Business unit leads	What AI are your teams actually using day to day? (surfaces shadow AI)

Building an inventory from zero - when the client has none, triangulate across channels; no single one is complete:

Network / CASB / proxy logs - traffic to public AI providers (OpenAI, Anthropic, dozens of model APIs) shows who is already sending data out, and from where.
Egress patterns - heavy POSTs to /generate-style endpoints, oversized payloads, new egress that was not there last month.
Service mesh / cloud - pod-to-pod traffic and namespaces quietly running model images (Hugging Face, TensorFlow); cloud-native governance surfaces managed model endpoints.
Human survey - the only channel that catches embedded SaaS AI features, spreadsheets wired to an API, and internal apps vibe-coded on Replit/Lovable running on personal accounts. Cross-reference the shadow-AI program (VII.3 · Detection, IR & forensics for AI).

Every discovered system becomes a row in the inventory / AIBOM (I.5 · The model artifact & its supply chain) - that register is what the assessment below scores.

Assess

Inventory every AI system (incl. vendor/SaaS) with model+provenance, data sources, tools, autonomy, who can be harmed. Classify by capability (advisory/assistive/agentic). Map the workflow to find where untrusted content enters and consequential actions exit. Threat-model (name ATLAS/OWASP). Gap-assess against NIST AI RMF / ISO 42001 + SAIF/CSA (Cloud Security Alliance); record residual risk. For the recommendation set itself, work straight from the risk→prioritized-controls matrix (II.5 · Guardrails - what holds, and how to prove it), score gaps with AIVSS and stage them on the maturity ladder (VIII.4 · ISO/IEC 42001, verification & maturity), and walk the end-to-end method on the capstone (One system, end to end).

Explain (board spine)

Risk: "Our support agent can read CRM data and send email - an injected web page or
  ticket could make it exfiltrate customer records (the lethal trifecta)."
Likelihood / impact: <H/M/L>   Exposure: <tier-1 systems affected>
Ask: fund spotlighting + outbound-action gating (III.1) this quarter; target residual <L>.
# one risk = one plain sentence, one number, one decision the board can act on

Four slides:

What changed - GTG-1002, the first reported AI-orchestrated espionage campaign (Anthropic, 13 Nov 2025): Claude Code ran an estimated 80-90% of the operation autonomously across ~30 targets, with humans stepping in at only a handful of decision points. Anthropic assessed Chinese state-sponsorship with high confidence, though that confidence was publicly debated. Plus the CSA SG (Cyber Security Agency of Singapore) advisory and frontier capability crossings. The signal for the board is tempo - operator effort measured in minutes, not months.
Our exposure - top systems by impact tier, each with its risk statement.
The gap - where timelines/controls lag attacker speed.
The ask - prioritized, costed moves with owners and dates, framework-mapped.

The P1 launch gate is where a consultant hands over a copy-paste artifact - the actual CI config that fails the build when residual attack-success-rate exceeds the appetite the board funded. Run it against the agent’s own authorized endpoint:

# Gates the build on residual attack-success-rate, the number the board funded.
providers:
  - id: https
    config:
      url: https://<staging-agent>/v1/chat
      headers: { Authorization: 'Bearer ${AGENT_TOKEN}' }
      body: { messages: [{ role: user, content: '{{prompt}}' }] }
redteam:
  purpose: 'Enterprise support agent with email-send + CRM read tools'
  plugins:
    - harmful:privacy          # PII exfiltration
    - pii:direct
    - rbac                     # tool-permission bypass
    - id: indirect-prompt-injection
      config: { indirectInjectionVar: retrieved_kb_chunk }
  strategies: [jailbreak, crescendo, prompt-injection]
# promptfoo has no inline PII assert type; the redteam plugins above attach their own
# graders, and `redteam run` (below) exits non-zero on graded failures - that is the gate.

npx promptfoo@latest redteam run -c promptfooconfig.yaml \
  --output results.json --no-progress-bar
# `redteam run` exits non-zero when a graded redteam attack succeeds (a leak/injection lands) -> that blocks the release.
# `npx promptfoo@latest redteam report` (no file arg) opens the interactive report UI when you want to review.
# findings then map to ATLAS in the write-up ([VIII.1 · Frameworks & standards](/govern/frameworks/))

Running an AI risk assessment

The gap-assessment above tells a client where they fall short of a framework; a risk assessment tells them which of their own AI systems could hurt them and what to fix first. The method of record is ISO/IEC 23894 (the AI application of ISO 31000) run as the risk process inside an ISO/IEC 42001 management system, with NIST AI RMF’s Map → Measure → Manage as the operating cadence. Run it per system, repeatably:

Scope & context. One AI system - its purpose, data, autonomy, and who can be harmed - plus the organization’s stated risk appetite (without it, “evaluate” has no yardstick).
Identify. Enumerate AI-specific risks from the catalogs, not memory: ATLAS techniques (VIII.1 · Frameworks & standards), the OWASP lists (II.2 · Prompt injection & the LLM attack surface), a harm taxonomy, and NIST AI 600-1’s GenAI risks. Cover adversarial and design-level risks - a model can fail without an attacker.
Analyze. Score likelihood × impact with the AI-specific factors classic scoring misses: autonomy (can it act unsupervised), blast radius (what its tools and data reach), data sensitivity, reversibility, and human oversight. Use AIVSS (VIII.4 · ISO/IEC 42001, verification & maturity) for per-finding severity.
Evaluate. Compare each scored risk against the appetite - above the line needs treatment, below it is consciously accepted.
Treat. Per risk, choose avoid (don’t deploy / narrow scope), reduce (the controls throughout this playbook), transfer (insurance, contractual), or accept (with sign-off). Map each control back to a named ISO/IEC 42001 Annex A clause so treatment is auditable - e.g. an egress-control treatment maps to A.6.2.6 (AI system operation and monitoring), a data-provenance control to A.7 (data for AI systems), and a third-party model policy to A.10 (third parties and customers). Naming the clause, not just the standard, is what makes the register auditable.
Record & monitor. A risk-register row per risk (description, score, owner, treatment, residual risk, review date); residual risk is signed off by the accountable owner, and the register is reviewed on a cadence, not once.

Standing up an AI governance program

Assessment tells a client where they are; a governance program keeps them there. This is the NIST AI RMF Govern function and the ISO/IEC 42001 management system made concrete - the partner-level deliverable, because “we can run AI governance,” not just test it, is what a board buys. The pieces:

Accountability. A named owner for AI risk (a person, not “the AI team”), a governance committee spanning security, legal, data, and the business, and a RACI so model owners know they own their models.
Policy. Acceptable-use, data-classification, model-lifecycle, and third-party AI policies - the rules the maturity assessment and the shadow-AI program (VII.3 · Detection, IR & forensics for AI) enforce.
Lifecycle gates. Go/no-go checkpoints from design to decommissioning (a risk assessment before launch, signed residual risk, monitoring in place) - ISO/IEC 42001’s Plan-Do-Check-Act, not a one-time review.
Operating artifacts. The evidence an auditor and a board actually want: an AI inventory / AIBOM (I.5 · The model artifact & its supply chain), a risk register (above), model cards, and decision/approval logs. Governance that isn’t written down didn’t happen.
Board reporting. A small set of indicators leadership can act on - coverage (% of AI systems inventoried and assessed), control effectiveness (residual ASR under adaptive red-teaming, VI.4 · AI red-team playbook), and residual-risk trend - not a wall of green checkmarks.