CISO call program

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

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)

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)

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)

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)