Templates & checklists

Every skeleton the prose chapters tell you to copy lives here - the SOW block, the evidence request, the risk-register row, both report audiences, the findings table, the promptfoo CI gate, and the injection-to-exfil detection rule. Fill the slots and ship. The chapters teach these; this page is where you copy them from.

Collected here, taught in context

Every artifact below also appears in the chapter that teaches it - VIII.6 · The advisor’s playbook, VI.5 · Running the engagement, VII.3 · Detection, IR & forensics for AI, One system, end to end. Those chapters give you the reasoning; this page is the copy-paste surface when you already know what you need. If the two ever disagree, the chapter is authoritative.

Skeletons, not contracts

These are starting structures, not legal, contractual or professional advice, and not a quote. Anything you put in front of a client - scope, fees, risk language - needs your own review and your organization’s sign-off. See the full security, legal and privacy notice.

1 · Engagement SOW / scope block

Scope it wrong and you underprice a program or overpromise a two-week look. Set the three variables - how deep, how many systems, what they can act on when you leave (VIII.6 · The advisor’s playbook).

Engagement scope block - paste into the SOW

Engagement: <Rapid AI risk diagnostic | Governance readiness | Program build & run | AI red-team assessment>
Depth:      <rapid diagnostic ... full ISO/IEC 42001 readiness>
Systems in scope: <named tier-1 shortlist - NOT "all AI"; unbounded scope is the loss-maker>
Out of scope:     <systems / environments / data explicitly excluded>
Phases (fixed fee per phase, go/no-go gate between each):
  Discover -> Assess -> Recommend -> Govern/Run (optional retainer)
Deliverables: AI inventory/AIBOM (II.12); risk register; gap report vs NIST AI RMF / ISO 42001;
  prioritized costed roadmap (P0/P1/P2); board deck; red-team artifacts + CI gate (if in scope)
Stated risk appetite: <the line findings are measured against - pin this down FIRST>
Authorization: <authorized model/versions, endpoints, time box>   # II.20 - authorized targets only

2 · Evidence-request checklist

Send before kickoff. Discovery is the operational bridge - you cannot assess a system you cannot see (VIII.6 · The advisor’s playbook).

Evidence request - send before kickoff

[ ] AI policy / acceptable-use (or written confirmation none exists)
[ ] System list & architecture - existing inventory, diagrams, data-flow maps
[ ] Model provenance - model cards, registry entries, hub/vendor sources, fine-tuning data
[ ] Access & identity - who/what calls each system, tool permissions, service accounts, agent scopes (III.2)
[ ] Vendor/SaaS AI - contracts, DPAs, vendor safety/security frameworks, embedded-AI feature list
[ ] Data - classification per system, retention, PII/regulated exposure
[ ] Logs & telemetry - network/proxy/CASB, tool-call logs, prior incidents
[ ] Prior work - past risk/pen-test/audit reports, stated risk appetite (or its absence)

3 · Risk-register row schema

One row per risk, the whole method visible. Map each control to a named ISO/IEC 42001 Annex A clause so treatment is auditable (VIII.6 · The advisor’s playbook); score severity with AIVSS (VIII.4 · ISO/IEC 42001, verification & maturity).

Risk-register row - one per risk

Fields: id | risk statement | likelihood | impact | AIVSS | treatment | control clause | residual | owner | review date

Risk-statement pattern: "System X uses [model/provenance] with [autonomy] over [data/tools]; an attacker
  via [entry] could achieve [impact] mapped to [ATLAS/OWASP]; current controls reduce but don't eliminate
  this; residual risk is [H/M/L]."   # if you can't fill every slot, the assessment is incomplete

Example: RAG assistant leaks customer PII via prompt injection | L: High | I: High | AIVSS 8.1 |
  treatment: input mediation + egress controls + DLP on retrieval (III.1), human approval on export |
  clause A.6.2.6 | residual: Medium (accepted by <owner>) | <owner> | reviewed quarterly

4 · Two-audience report skeleton

Write it twice. The technical write-up proves the finding; the board section drives the decision (VI.5 · Running the engagement, VIII.6 · The advisor’s playbook).

Two-audience report skeleton

TECHNICAL  (developer / assurance team)
  1. Scope, RoE, model + version, dates
  2. Methodology: harness, arms, probe families, N trials, baseline
  3. Findings per barrier: barrier | technique | turns | behavior | score | SME severity | ATLAS id
  4. ASR per technique family; enumerated close calls
  5. Reproducibility: harness config, seeds, transcript references
  6. Recommendations: refusal training, output filtering, monitoring, gating

BOARD  (executive / regulator) - the four-slide spine
  1. What changed   2. Our exposure (top systems, each with its risk statement)
  3. The gap (where controls lag attacker speed)   4. The ask (prioritized, costed, framework-mapped)
  Close: verdict vs threshold - residual risk + societal-resilience framing - the single highest-leverage
         control - assurance statement (independent, reproducible, standard-aligned)

5 · Findings-table schema

The table a practitioner screenshots at the end of the engagement. Verify ATLAS ids against atlas.mitre.org at write-up time - the technique set is versioned (One system, end to end).

Finding	ATLAS / OWASP ASI	AIVSS	Control	Status
Indirect injection via poisoned KB doc → customer-record exfil	AML.T0051.001 → AML.T0057 / ASI01	8.1	Approval gate on outbound send + role-aware retrieval (II.5)	Open · P0
Multi-turn jailbreak bypasses the output filter	AML.T0054.001 / ASI01	7.2	Refusal training + output filtering (II.5)	Open · P1

6 · promptfoo redteam CI gate

The P1 launch-gate artifact: fail the build when residual attack-success-rate exceeds the appetite the board funded. Run it against the agent’s own authorized endpoint (VIII.6 · The advisor’s playbook).

promptfooconfig.yaml - fail CI when residual ASR exceeds appetite

# 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.

CI step (GitHub Actions) - non-zero exit blocks the release

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) -> 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 (IV.1)

7 · Detection stub - prompt-injection to exfil

The Sigma-style rule for the injection-to-egress chain, mapped to ATLAS. Run it over the agent’s OTel GenAI action ledger (VII.3 · Detection, IR & forensics for AI).

Detection rule - injection -> outbound tool call (ATLAS-mapped, Sigma-style)

title: Indirect prompt injection followed by egress
logsource: { product: ai_agent, service: action_ledger }
detection:
  sel_inject: tool_result.content|contains: ["ignore previous", "system:", "<!--"]
  sel_egress: next_action.type: "outbound_http"
  condition: sel_inject and sel_egress within 2 steps
tags: [atlas.AML.T0051.001, atlas.AML.T0057]   # LLM prompt injection (indirect) -> LLM data leakage / exfiltration

Take it further

Look up any term in the glossary; trace any claim to its source in the reference library.