ai · security · skills

For Compliance · the method

How we solve it.Piece by piece, with provenance.

How one control spine answers many regimes — the crosswalk method, and where the genuine deltas come from.

← Back to the Compliance pagePublic view · method skeleton
One spineThe crosswalk & the rea…Who owns each controlTHE METHODThe comply-once coreINPUTS → MECHANISM → OUTPUTS · WITH PROVENANCE

Piece 1

One spine

Inputs

  • The CSA AICM: 18 domains, 247 control objectives, reconciled verbatim against the CSA source at every build

Mechanism

  • Every control question lives in exactly one domain (a MECE partition, machine-enforced); every regime is a lens onto that partition, never a second catalog

Outputs

  • One implementation surface — controls get built once, evidenced once

Provenance: lib/aicm-taxonomy.ts + the validate-mece build gate; CSA attribution preserved verbatim.

1 deeper item · owner-gated · shown in a walkthrough

Piece 2

The crosswalk & the real deltas

Inputs

  • 3 regimes mapped authoritatively (AI-native) and 3 inherited through the CCM bridge

Mechanism

  • Each regime maps to the spine with a gap profile: fully covered, partially covered, genuinely uncovered
  • Inherited (pre-AI) frameworks additionally carry an AI-delta: the AI-only controls they never reach — that delta is your genuinely new work

Outputs

  • Per-regime coverage plus a named delta list — what you already satisfy, what needs a mapping argument, what is new

Provenance: lib/standards-crosswalk.ts, generated from the CSA source files and guard-checked.

2 deeper items · owner-gated · shown in a walkthrough

Piece 3

Who owns each control

Inputs

  • The SSRM (Shared Security Responsibility Model) read of every objective

Mechanism

  • Each control resolves to provider-owned, shared, or deployer-owned — so audit effort lands only on what is actually yours to evidence

Outputs

  • An ownership split you can hand to an auditor next to the coverage read

Provenance: The SSRM ownership map, rendered at /library/ownership.

1 deeper item · 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

  • Control-lane instruments evidence objectives directly — the artifact an auditor sees names the instrument that produced it, so evidence reuse across regimes is mechanical, not argumentative
  • 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.

CSA Unified Framework ExplorerThe three CSA layers — AISMM, AICM, CCM — on the left connect to the external compliance regimes on the right, organised in two columns: NIST (the US audit reference) and ISO (the international equivalent).
AISMM
Maturity Governance · how mature is your implementation?
  • L1Initial· ad-hoc, undocumented
  • L2Repeatable· documented; inconsistent
  • L3Defined· standardised across function
  • L4Capable· measured against targets
  • L5Efficient· optimised, improvement loop
AICM
AI Security Extension · 247 controls · 197 inherit from CCM
  • L1Manual· all human; AI used only as advisor
  • L2Assisted· AI suggests; human executes
  • L3Augmented· AI executes; human approves
  • L4Autonomous· AI acts within sanctioned bounds
  • AI-CMM · our authored model · calibrated to SAE J3016
CCM
Foundational Cloud baseline · 207 controls · ISMS substrate
NIST AI RMF
AI Risk Management Framework
  • Functions:
  • GOVERN · MAP · MEASURE · MANAGE
US audit reference
NIST CSF 2.0
Cybersecurity Framework
  • Six functions:
  • GOVERN · IDENTIFY · PROTECT · DETECT · RESPOND · RECOVER
US audit reference
NIST SP 800-53 rev 5
Security & Privacy Control Catalog
  • 1,189 controls · 20 control families
  • FedRAMP foundation · federal baseline
US federal baseline
ISO/IEC 42001
AIMS · AI Management System
  • Clauses 4–10 · Annex A AI controls
EU AI Act
Regulatory · High-risk AI
  • Articles 9, 10, 15 obligations
ISO 27001 + 27017
ISMS + Cloud Security
  • HLS clauses 4–10 + cloud guidance
ISO 27018
Cloud PII protection
  • Public-cloud processor responsibilities
US · NIST primary
International · ISO
Direct CSA mappingMaturity overlayUS audit reference

Hover a layer to highlight its mappings. Click any node to walk its crosswalk. NIST is given visual primacy because US enterprises audit against NIST; the international ISO equivalents sit beside as parallel structure.

AISMM · how well it’s secured

3 domains· 12 categories· 5 maturity levels

AICM · what to secure

18 control domains· 247 control objectives

Foundational · AISMM

Foundational

4 categories
73 control objectives

The ground floor every function needs before AI specifics enter — governance, identity, monitoring.

01

Governance

30 controls

Who decides what, who is accountable, and how the rules are kept.

02

Organization Management

9 controls

How the organisation is structured and how change is controlled.

03

IAM

18 controls

Identity & Access Management — who can do what, with which credentials.

04

Security Monitoring

16 controls

Watching for trouble; logging what happened so it can be investigated.

Structural · AISMM

Structural

4 categories
111 control objectives

Controls on the AI stack itself — the model, the application around it, the data it learns from, the infrastructure it runs on.

01

Infrastructure Security and Resilience

38 controls

The compute and network the AI runs on, kept secure and able to recover.

02

Model Security

13 controls

Protecting the model itself — training, weights, behaviour, evaluation.

03

App Security

15 controls

Securing the application that surrounds the model.

04

Data Security

45 controls

Protecting the data the model learns from and works with.

Procedural · AISMM

Procedural

4 categories
45 control objectives

How the practice runs — assessing third parties, securing the supply chain, complying with privacy law, responding when something goes wrong.

01

Risk & Provider Assessment & Management

16 controls

Knowing the risk you carry from third parties and managing it.

02

AI Supported Development and Supply Chain Security

13 controls

Securing the build pipeline and the components it pulls in.

03

Privacy and Compliance

6 controls

Meeting the privacy obligations the law puts on the work.

04

Incident Response

10 controls

How the team detects, contains, and learns from incidents.

Not yet rolled up to an AISMM category

2 AI Controls Matrix (AICM) domains (18 controls) sit outside the current AI Security Maturity Model (AISMM) rubric. Not a gap to hide — a place the next rubric revision will land.

Canonical surfaces

The compliance hubChoosing the control spine (essay)