Skip to content
AI Security Playbook

The advisor's playbook

Turns the playbook into a method: assess, explain, recommend.

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; record residual risk. For the recommendation set itself, work straight from the risk→prioritized-controls matrix (III.1), score gaps with AIVSS and stage them on the maturity ladder (IV.2), and walk the end-to-end method on the capstone (IV.6).

Explain (board spine)

Board risk statement (template)
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, months→hours, CSA advisory, frontier capability crossings - a tempo shift); 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).

Recommend (default ladder)

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 catalogues, not memory: ATLAS techniques (§29), the OWASP lists (§7), 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 (§30) 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 ISO/IEC 42001 Annex A so treatment is 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 (§28) 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 (§16), 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, §22), and residual-risk trend - not a wall of green checkmarks.