---
sensitivity: internal
schema_version: 1
last_updated: 2026-05-03
status: outline
---

# CISO call program 02–04

> Sequel to CISO call 01 (the original "94% chose safe enablement" reference
> conversation that anchors the website's [SafeEnablement section](../../../packages/website/src/components/SafeEnablement.astro)).
> Calls 02–04 stress-test specific claims, gather objections, and validate
> deferred-feature priorities (see `future-work.md`).

## Cohort targets (q2 resolution)

Call 01 vertical was unspecified. Sprint 31 decision: target three
**different regulated verticals** across calls 02-04, with at least one
EU-based to validate EU AI Act framing.

| Call | Target vertical (preferred) | Why |
|---|---|---|
| 02 | EU-based **fintech** or **regulated healthtech** | EU pulls in EU AI Act conversation (validates q4 framework choice); fintech surfaces procurement-side rigor (validates q3 budget gating). |
| 03 | US **federal civilian** or **defense contractor** | Pressure-tests the air-gapped + signed-evidence story; FedRAMP authorization conversation. |
| 04 | **Regulated retail** or **regulated payments** (PCI-DSS-heavy) | Validates the cross-cutting "we don't fight your existing infosec posture" claim; SOC 2 + PCI overlap. |

**Hard rule:** never run two calls with the same vertical. Diversity is
the goal; depth comes from call 05+.

## Standing block — Block 4 procurement reality (q3 resolution)

Block 4 was **not covered** in call 01. Going forward it is a **standing
block** — every call (02, 03, 04, 05+) closes with these three questions:

1. *What was the last enterprise-tier security tool budget you signed
   for? Order of magnitude in dollars per year.*
2. *Who was on the buying committee? Specifically: did Legal, Finance,
   Procurement, IT, or AppSec block or accelerate it?*
3. *What closed it? An executive mandate, a peer reference, a
   regulatory deadline, an audit finding, a champion in your team?*

The goal is to triangulate the actual enterprise procurement loop so
Tier 1 SSO/SCIM (F1.14) productization priority + the OSS → Team →
Business → Enterprise pricing tier gating decisions are calibrated to
real budget patterns, not assumptions.

This document is the agenda + question bank + open-question register for
the next three CISO conversations. Treat it as a working file — append
notes after each call; the format is intentionally pre-populated so we
can do A/B comparisons across calls.

---

## Call 02 — "Does the audit chain hold up to a real auditor?"

### Goal
Verify that fastpace's audit chain produces evidence a SOC 2 / ISO 27001
auditor would actually accept. This is the single biggest unknown after
shipping F0.2 + F2.4 + F2.12.

### Pre-call homework

Send the CISO 24h before the call:

1. A real `fastpace audit verify` JSON output from a fastpace-installed repo
   (5–10k entries minimum so the chain has signal).
2. The `assets/docs/audit-schema.md` (F2.12) so they can hand it to their
   audit firm.
3. A signed AI-BOM (F2.4) showing which models, agents, and prompts shipped
   in a tagged release.
4. The `assets/docs/framework-mapping.md` so they can see the SOC 2 / ISO
   27001 / NIST AI RMF / ISO 42001 / EU AI Act mapping in one place.

### Agenda (45 min)

| Time | Topic |
| ---- | ----- |
| 0:00 | Recap: what changed between call 01 and now (Tier 0 + Tier 1 + 11/12 Tier 2 done) |
| 0:05 | Walk through one signed audit entry — show prev_hash, entry_hash, signature |
| 0:15 | The auditor question: "what would your audit firm need to accept this as evidence?" |
| 0:25 | The pre-merge audit gate (F2.9) — does this fit your CI? |
| 0:35 | Unknowns for them: what's missing from the audit chain to satisfy SOC 2 CC8.1? |
| 0:40 | Roadmap input: F2.5 control monitoring, F2.11 policy bundle — relevance? |
| 0:45 | Wrap |

### Question bank

Open-ended (use first):
- "Walk me through the last time your audit firm asked for evidence on a
  control. What artifacts did they want, and what format?"
- "If I gave you `fastpace audit verify` JSON for your most-AI-heavy repo,
  what would you do with it? Would you forward it as-is, or would you need
  to massage it into a different shape?"
- "Where does Drata / Vanta fit in your stack today? Are they the source of
  truth for control state, or is something else?"

Sharpening (use after the open-ended ones loosen things up):
- "Our hash chain links every entry to its predecessor with prev_hash; do you
  consider that sufficient for tamper-evidence, or would you want a separate
  immutable store?"
- "We sign every entry with the install's Ed25519 private key. Is the key
  rotation policy (currently: manual) acceptable, or do you need automated?"
- "Do you have a minimum age requirement for AI-BOMs in compliance evidence?
  We default to 30 days but the audit gate is configurable."

Skeptical (don't lead with these but probe if they sound interested):
- "Auditors love checkboxes. Where is the checkbox version of all this? Is
  the framework-mapping doc sufficient, or do they want it in their tool?"
- "What does the CFO say about another tool in the stack? What budget line
  would this come out of?"

### Listening for

- Any mention of evidence formats we don't currently emit (specifically: do
  they want CSV exports? PDF reports? CycloneDX-AI? OpenSSF SBOM Generator?)
- Any audit firm or framework we haven't mapped against (FedRAMP, HIPAA,
  PCI-DSS).
- Any specific Drata / Vanta / Secureframe API behavior we'd need to handle
  in the F2.5 control monitor live mode.
- Whether `fastpace gate check` running in CI would conflict with their
  existing pre-merge approvals or branch protection rules.

### Post-call

After the call, append findings under `## Call 02 findings` below. Open new
items in `future-work.md` if anything crystallises into roadmap work.

---

## Call 03 — "How do you talk to your developers about this?"

### Goal
Test the developer experience claims. F1.9 coach agent says fastpace points
the developer at the next action when something blocks; we need to know
whether real developers actually use that path, or quietly disable hooks.

### Pre-call homework
- A short video recording of a deliberate violation: agent tries to read
  outside its scope, scope-guard blocks, coach agent emits the
  `fastpace exception request` next step, developer files exception.
- The org-default Tier-1 install with all hooks enabled.
- A list of every fastpace hook the org has ever disabled (ask them to
  bring this from their fastpace.config.yaml history).

### Agenda (30 min)

| Time | Topic |
| ---- | ----- |
| 0:00 | Show the violation flow video (don't narrate, watch their face) |
| 0:05 | "What was your developer's first reaction to this? Be honest." |
| 0:10 | Walk their disabled-hooks list with them — why each, and what was the trigger |
| 0:18 | Coach agent UI integration — does the one-click exception button help? |
| 0:25 | Trade-offs: does adding more friction reduce mistakes, or just push them around? |
| 0:30 | Wrap |

### Question bank
- "Tell me about a fastpace hook you tried to enable but had to disable.
  What broke?"
- "If your developer hits the same scope-guard block 5 times in a session,
  what's the right behaviour? Auto-grant? Auto-block? Page someone?"
- "How do you measure 'fastpace is working' versus 'developers are working
  around fastpace'? What's the leading indicator?"

### Listening for
- Hook configurations that are too coarse to be usable
- Cases where a one-time exception became permanent because the workflow
  was painful
- Friction-vs-value points where the team is pulling in different directions

---

## Call 04 — "What's the org-scale story?"

### Goal
Pressure-test F1.13 (org dashboard) + F1.14 (RBAC/SCIM/SAML) + F2.11
(org-wide policy bundle). These are the three features that move fastpace
from "trust harness for one repo" to "trust harness for an org's fleet".
We need to know if the org-scale story holds up at 100+ repos.

### Pre-call homework
- A demo org dashboard with 30+ ingested summaries (synthetic is fine).
- A signed policy bundle with realistic policies (runtimes, MCP scope,
  redaction patterns, blast-radius defaults).
- The `fastpace control reconcile` output for a Drata snapshot reconciled
  against fastpace ground truth.

### Agenda (45 min)

| Time | Topic |
| ---- | ----- |
| 0:00 | Walk through the dashboard at 30+ repos — what jumps out? |
| 0:10 | Policy bundle: the org-admin pattern. Who in your org would publish? |
| 0:20 | F2.5 control monitoring: drift between Drata and ground truth — useful or noise? |
| 0:30 | F2.11 expiry / rotation — how often should bundles refresh? |
| 0:35 | Audit gate at fleet scale — does it scale to 1000+ PRs/day? |
| 0:40 | Concerns + asks |
| 0:45 | Wrap |

### Question bank
- "Who in your org has the authority to publish a policy that affects every
  repo? Is that the same person who has the SAML private key?"
- "If a policy bundle expires and no replacement is pushed, what's the right
  failure mode — deny everything, fall back to local config, or alert?"
- "Your fastpace install signs every audit entry with its own Ed25519 key.
  Do you want a single org key everyone shares, or per-install keys? What's
  your actual rotation cadence?"
- "Drift between Drata and fastpace: is the answer 'fix the push' or
  'deprecate Drata for AI-related controls'?"

### Listening for
- Specific scaling pain points (1000+ repos, multi-region, regulated industry)
- Ask shapes: "what would it take to make this our system of record for AI
  governance?" — those are buying signals
- Push-back on the policy-bundle revoke story (today: re-pull a new bundle
  with the prior policies removed; harder: revoke a published bundle)

---

## Open-ended questions worth asking on every call

These are evergreen, regardless of which call we're on:

1. "If I told you fastpace shipped feature X tomorrow, what would you stop
   doing?" — finds the displacement story.
2. "What does your Q3 (or current quarter) AI governance roadmap look like?
   Where does fastpace fit?"
3. "Who's your biggest internal critic of fastpace, and what's their
   strongest objection?"
4. "In one year, what does fastpace's footprint in your org look like, and
   what changed to get there?"

---

## Anti-patterns to avoid

- Don't lead with the demo. Lead with their problem.
- Don't ship-talk features they don't ask about. Notes on F2.x deferred work
  are below; only surface them if the call goes that direction.
- Don't argue with their auditor's preferences. Even if it's "wrong" in our
  view, that's the constraint they live under.
- Don't promise dates on roadmap items in `future-work.md`. Concretely: F2.x
  deferred items, anything in Tier 3, marketing-surface work.

---

## Open question register

Append findings as bullet points after each call. Items that crystallise
into roadmap commitments move into `future-work.md` (not here).

### Call 02 findings
- _(to be filled after call)_

### Call 03 findings
- _(to be filled after call)_

### Call 04 findings
- _(to be filled after call)_