For CISO · the method
How we solve it.Piece by piece, with provenance.
How one board page gets produced from per-function readings — and why you can defend every number on it.
Piece 1
The scorecard
Inputs
- Saved diagnostic runs, per function (self-assessed)
- An illustrative sample for any function without a run — always labeled as such
Mechanism
- Each control domain a function owns carries two readings: governance maturity (AISMM, 5 levels) and AI autonomy (AI-CMM, 4 levels, our authored ladder)
- Domain readings roll up per function; functions roll up to the portfolio: governance average, autonomy mix, and the share of domains where autonomy runs ahead
Outputs
- One board page: the gap percentage, maturity vs the McKinsey ’26 benchmark, the autonomy mix, and the top risks
Provenance: lib/maturity-portfolio.ts — every card carries its evidence state; mixed real/illustrative reads are labeled per cell.
3 deeper items · owner-gated · shown in a walkthrough
Piece 2
The gate
Inputs
- Per-category governance levels
- The autonomy level each workflow claims
Mechanism
- A table-driven floor: each autonomy rung requires named governance categories at minimum levels before the rung is allowed
- Any claim above the allowed rung is flagged — per function, per step, with the blocking category named
Outputs
- A gate verdict per function: which step runs ahead, and exactly which category blocks it
Provenance: lib/measure-model.ts (AUTONOMY_GATE) and lib/gate.ts — one rule, two granularities, changed together.
2 deeper items · owner-gated · shown in a walkthrough
Piece 3
The top three risks
Inputs
- Every domain row across all functions
Mechanism
- Domains where autonomy outruns governance are ranked by how far ahead they run
- Each surviving risk names its owning function and the first intervention that closes it
Outputs
- A top-risk list a CISO can read aloud in a board meeting without a backup slide
Provenance: Same portfolio module; ranking is deterministic — same inputs, same list.
2 deeper items · owner-gated · shown in a walkthrough
Piece 4
The stack & instruments
Inputs
- 15 published instruments in three lanes — 13 testers, 3 corpora, 5 controls — validated at every build
- Python 3 stdlib-only tooling — nothing to install to reproduce a claim
Mechanism
- The scorecard’s inputs are instrument-backed: the diagnostic question banks are build-validated against real control ids, and every case-study number traces to a fixed corpus a tester scored
- Lane integrity is machine-enforced: an instrument never grades its own lane, and nothing on this site says "tested" without a named instrument behind it
Outputs
- A named, reproducible instrument behind every tested claim you read here
Provenance: lib/tools-registry.ts, guarded by validate-tools in the prebuild chain; instrument detail renders in the /controls drill.
2 deeper items · owner-gated · shown in a walkthrough
The exhibits
The working surfaces behind the answer.
AI User Protection
Securing how your people use AI.
- Employees pull AI into existing work, often via tools no one bought. Shadow AI.
- Data leakage to third-party models.
- Oversharing across tenants.
- Copyrighted-content paste-ins.
- Prompt-history exposure.
The failure modes follow the user, not the model.
Closes mostly through · People
Domains · HRS · GRC · DSP · IAM · A&A
Regulated by · EU AI Act Art. 4 · India DPDP · GDPR
See the everyday risks →Owner · CISO · Data · HR-policy
AI App Protection
Securing what your org builds with AI.
- Org-built AI apps, copilots, agents, and fine-tuned models bring their own threat surface.
- Prompt injection.
- Jailbreaks.
- Training-data poisoning.
- Model theft.
- OSS supply-chain compromise.
The failure modes follow the system, not the user.
Closes mostly through · Technology
Domains · AIS · MDS · TVM · LOG · SEF · I&S
Regulated by · EU AI Act (high-risk) · Sector and product safety
See the AI security gates →Owner · CISO · App Sec · ML Platform
AI Customer Responsibility
Governing what your org procures and deploys.
- Your org is the deployer: the AI Customer in the CSA shared-responsibility model.
- Vendor copilots, embedded AI in tools you already pay for, third-party models behind APIs.
- Where the line falls between you and the provider is the question.
- The failure modes follow the contract, not the model: residency, training-data flowback, sub-processor opacity, model swaps.
Closes mostly through · Process
Domains · STA · A&A · GRC · DSP · CEK
Regulated by · Data residency (DPDP, GDPR) · EU AI Act provider duties
See where the line falls →Owner · CISO · GRC · Procurement
Canonical surfaces
The board scorecard →Placing a function on the AISMM scale (essay) →