ai · security · skills
Why ReskillReskillAI MaturityHermes AgentLibrarySign in

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.

← Back to the CISO pagePublic view · method skeleton

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 · Human Resources · Governance, Risk and Compliance · Data Security and Privacy Lifecycle Management · Identity & Access Management · Audit & Assurance

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 · Application & Interface Security · Model Security · Threat & Vulnerability Management · Logging and Monitoring · Security Incident Management, E-Discovery, & Cloud Forensics · Infrastructure Security

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 · Supply Chain Management, Transparency, and Accountability · Audit & Assurance · Governance, Risk and Compliance · Data Security and Privacy Lifecycle Management · Cryptography, Encryption & Key Management

Regulated by · Data residency (DPDP, GDPR) · EU AI Act provider duties

See where the line falls →

Owner · CISO · GRC · Procurement

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.

The deeper layer — named here, shown in a walkthrough

  • The roll-up arithmetic: how per-domain pairs compose into function averages and the portfolio gap percentage
  • How self-assessed runs overlay the illustrative baseline without contaminating provenance labels
  • The benchmark mapping: which AISMM read compares against which published benchmark tier

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.

The deeper layer — named here, shown in a walkthrough

  • The full floor table: which categories, at which levels, gate rungs 3 and 4 — and the rationale for each floor
  • The verdict-copy rules that keep a gate reading from overclaiming beyond self-assessed evidence

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.

The deeper layer — named here, shown in a walkthrough

  • The ranking function and its tie-breakers
  • How interventions are matched to a risk (play catalog → required controls)

Piece 4

The reskilling list

Inputs

  • The Track 2 reskilling master list: 247 AICM controls, each attributed to one persona owner with a skill verb and a capability prompt
  • Your saved diagnostic answers, where a run exists: the same answers Track 1 scored

Mechanism

  • Controls that govern the program, set the appetite and the gates, own oversight and the ethics of use, and build the AI-ready workforce resolve to the CISO as primary
  • Track 2 is the diagnostic inverted: a control absent or breached in a function’s answers is re-read as the named skill this role acquires. No second scorer, no second instrument

Outputs

  • 11 controls resolving to this role across 4 skill groups — a named skill list: direction and next rung, never a complete how-to

Provenance: tools/reskill-persona-map.json → lib/reskill-master.ts (owner sample-review approved 2026-07-17); gaps join in lib/reskill-deltas.ts.

The deeper layer — named here, shown in a walkthrough

  • The per-control attribution table for this role and the judgment notes on boundary controls

Piece 5

The stack & instruments

Inputs

  • 16 published instruments in three lanes — 14 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.

The deeper layer — named here, shown in a walkthrough

  • The per-instrument wiring: which tool validates which skill, and which tool grades which instrument
  • Acceptance thresholds per tester lane

Canonical surfaces

The board scorecard →Placing a function on the AISMM scale (essay) →