Controls · spine & crosswalk
One control spine.Assess once. Close with evidence.
For auditors and compliance leads: the AI Controls Matrix (AICM) is the MECE partition — 18 domains, 247 control objectives. NIST, ISO, and AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) reads are lenses on that one assess, not a second quiz. Jump a block below when you already know which part you need.
GRC · Governance
Governance, Risk and Compliance
Who owns AI risk, who decides, and how policy becomes operating practice.
Foundational: Ground floor every function needs before AI-specific controls land.
Situation · what this is for
A usable control reference, not a catalogue dump.
You already answer to more than one regime. This page names the spine this research site runs on, how external standards map onto it, and what produces evidence — skills, tools, and ownership — without listing every control inline.
Step 1
Name the spine
AI Controls Matrix (AICM) is the MECE partition - one assess covers the control surface.
Step 2
Read the lens they asked for
NIST, ISO, AI-CAIQ and peers are lenses on that assess, not a second quiz.
Step 3
Close with evidence
Skills, tools, and ownership tell you what produces the artifact the auditor can file.
Maturity pressure-tests roll up through 12 AI Security Maturity Model (AISMM) categories onto this same AICM surface. 16 published instruments and 8 mapped regimes sit on that spine.
Lenses · assess once
When they ask for NIST or ISO, point here.
Compatible-standard reports are lenses on AI Controls Matrix (AICM) answers from the function diagnostic — the AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) is the attestation view of that spine, shown as a sample. Not certification.
A navigation map, not a conformance attestation: assess once on the AI Controls Matrix and read every standard as a lens on that one run. Privacy regimes arrive from skill tags in the panel below.
AI Security Maturity Model: The maturity read. The lit standards cover the same governance ground.
Spine · Foundational · Structural · Procedural
Three AISMM domains. One AICM spine.
Cycle the bands: each AI Security Maturity Model (AISMM) domain discloses its categories and the AI Controls Matrix (AICM) domains that roll up to them.
AI Security Maturity Model · Foundational
73 control objectives
One AI Controls Matrix (AICM) partition · 18 domains · 247 objectives. AISMM is the maturity lens, not a second catalog.
Foundational: The ground floor every function needs before AI specifics enter: governance, identity, monitoring.
Foundational inheritance · the CCM bridge
Dock the baseline you already run.See what each regime still cannot reach.
The AI Controls Matrix (AICM) extends the Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM). For shared control ids, CSA’s own CCM crosswalk reaches the foundational standards below — including AICPA Trust Services Criteria 2017 (SOC 2) and Payment Card Industry Data Security Standard (PCI DSS). Reach varies by regime (cells marked “No Mapping” do not count). The remainder of 247 objectives is outside that dock — for NIST CSF v2.0, that delta is 63.
Two CSA-authoritative hops: AICM→CCM by shared control id (the documented design of AICM), CCM→standard by CSA’s published CCM v4.0.13 mapping. Gap levels are not re-labelled across the bridge. HIPAA, GDPR, and India DPDP are not CCM columns — leverage the skill-mediated panel. NIST SSDF is not mapped in any source here and is omitted, not inferred.
Skills · regime leverage
Regimes the skill catalog already reaches.
Privacy & payments · leveraged from skills
Regimes the CSA sheets omit: joined through the skill catalog.
Modeled, from the skill catalog, not a Cloud Security Alliance sheet: published skills already tagged to a privacy or payments law, read against the control domain they touch.
Four ways in · one answer
Demand, obligation, instrument, ownership.
Mutually exclusive entry points onto the same domain detail. Open one. Leave with a takeaway — expand the catalog only when you already know what you are hunting.
Ownership: SSRM evidence
Shared Security Responsibility Model (SSRM): owned, shared, or inherited. Auditors care who produces the artifact - not only that a control exists.
Use the ownership lens for the AI-Customer chair read, then pressure-test the function that owns the gap.
Open ownership lens→Browse the ownership catalog (power users)
The same 69 core skills, read along the shared-responsibility line — given how you consume AI, which controls are yours to own? Each skill is tagged by the posture it answers to (Operated · Procured) and, when it is shared or inherited, the provider on the other side.
This is where the Bought posture from the home lands: who owns which control across the line between you and your provider. Operated is what your org built and runs; Procured is what it bought in.
Our authored read of the Shared Security Responsibility Model (SSRM), scoped to the core set — a navigation affordance, not a measured claim.
Where next
Leave with a next move.
Pressure-test a function
Run the org maturity read on the same AICM spine — gate held between autonomy and control.
Open maturity→Build defender skills
Track 2: personal mastery on the same controls, seat by seat — gaps and path, nothing saved.
Open skills→Board and sample lenses
See every finished sample — board, function, mastery, and standards lenses — in one Reports index.
Open reports→