Held to the weakest of People, Process, Technology (L1, tier 4 not yet evidenced). Autonomy is ahead of governance — the gate flags it below. A self-assessment, never a measured or certified result.
The maturity radar
Self-assessed
Maturity · governance (AISMM · L1–L5) · this function
How well-governed Security Operations is across the 12 AISMM categories, L1 hub to L5 rim. Measures 5 of 12; dashed spokes are outside scope, not zeros.
Autonomy · AI adoption (AI-CMM · L1–L4) · the org portfolio
How far AI adoption has advanced in each of the 8 security functions, Manual → Autonomous — the wider frame Security Operations sits in. our model · calibrated to SAE J3016.
AI adoption (AI-CMM)
Levels1 Manual2 Assisted3 Augmented4 Autonomous
1 Identity Security
2 Network & Infrastructure Security
3 Endpoint & Workload Security
4 Application & DevSecAIOps Security
5 Data Security
6 Cloud & Container Security
7 Security Operations
8 Security Governance, Risk & Assurance
Two axes: governance maturity (AISMM, 5 levels) vs AI autonomy (AI-CMM, 4 levels, our authored ladder). Set targets below to see the dashed overlay. The autonomy lens is the org portfolio, self-assessed where a run exists, illustrative otherwise.
Govern · AISMM
L2.8
Defined · avg of 5 categories
Adopt · AI-CMM
L2.2
Assisted · our model · calibrated to SAE J3016, not a Cloud Security Alliance (CSA) standard
The gate
Autonomy ahead of governance
Coverage governs autonomy up to L2. Some steps run above that, close the govern gap or pull autonomy back.
Govern reads the AI Security Maturity Model (AISMM); Adopt reads the AI Cyber Maturity Model (AI-CMM).
FoundationInformation security: Not yet profiledCloud: Not yet profiledPrivacy: Not yet profiled
Capability · People · Process · Technology
The same control answers, read on the three dimensions a program is actually managed by (our lens over Cloud Security Alliance (CSA) control text). Capability is bounded by the weakest dimension, tooling alone can’t carry it.
PeopleAdministrative · evidence by document L1 Initial1 asked · capped: tier 4 not yet evidenced
ProcessAdministrative · evidence by document L3 Defined5 asked · capped: tier 4 not yet evidenced
TechnologyTechnical · evidence by instrument → L3 Defined6 asked · capped: tier 4 not yet evidenced
Capability, bounded by PeopleL1 Initial · tier 4 not yet evidenced
The lever names itself: weak People is fixed by training and champions; weak Process by runbooks and review cadences; weak Technology by vendor features, automation or fitted skills. The PPT grouping is our authored interpretation of the CSA control objectives.
What L3 looks like for Security Monitoring · the next rung
Where you are (L3 Defined): Prompt/response logging implemented for key AI applications (with appropriate data handling/masking). Agent action logging captures tool calls and resource access. Initial AI-specific alerting (e.g., guardrail violations, information disclosure). Logs aggregated into central SIEM. MCP and tool invocations logged.
The next rung (L4 Capable): Comprehensive AI telemetry across applications, including prompts, responses, agent actions, delegation chains, and data access. AI-specific threat detection in place (prompt injection, jailbreak attempts, anomalous patterns). Delegation chain auditability for multi-agent workflows. Alerts integrated with SOC workflows. Sensitive data detection in key AI inputs/outputs.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
What L3 looks like for Incident Response · the next rung
Where you are (L3 Defined): Initial AI-specific playbooks (prompt injection, data exfiltration, model abuse, unauthorized usage, compromised agent credentials, tool misuse). IR team trained on AI-specific threats and response procedures. Input/output monitoring in place for high-risk AI deployments. Responders have read access to AI deployment configurations, logs, and telemetry. AI incidents categorized and tracked separately from general application incidents.
The next rung (L4 Capable): Threat intelligence for AI systems integrated into program. Input/output security telemetry tools (guardrails, prompt injection detection) deployed for production AI systems. AI security alerts integrated with SIEM for correlation and tracking. Agentic threat detection (tool abuse, prompt injection, anomalous delegation) via log analysis. Response automation available for common AI incidents via SOAR integration. Responders can escalate to administrative access for AI system containment.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Model Security L3 Defined
2 implemented · 0 partial · 0 absent
What L3 looks like for Model Security · the next rung
Where you are (L3 Defined): Standardized security and safety (bias/harm/hallucination) requirements for models based on deployment type and risk classification. Self-hosted models require integrity verification and secure file formats. PaaS/API model configurations hardened per documented standards. Formal risk assessment process for third-party and open models. Model versioning and rollback capability established. Initial monitoring for model behavior and performance in production.
The next rung (L4 Capable): Model signing and provenance verification enforced for self-hosted models. Automated configuration validation for PaaS/API deployments. Adversarial robustness testing standard for production use cases. Continuous monitoring for model drift, degradation, safety, and anomalous behavior across deployment types. Model risk metrics tracked and reported through governance processes.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
AI Supported Development and Supply Chain Security L3 Defined
1 implemented · 0 partial · 0 absent
What L3 looks like for AI Supported Development and Supply Chain Security · the next rung
Where you are (L3 Defined): Enterprise-managed AI coding assistant deployed (e.g., GitHub Copilot Business/Enterprise) configured to prevent code exposure to model training. AI coding tool usage tracked via enterprise licensing and administration. AI components included in existing SAST/SCA scanning processes. AI providers and major AI components documented in supply chain inventory. Open models require integrity verification (checksums, safe file formats) before use.
The next rung (L4 Capable): SAST/SCA tools include AI-specific assessment capabilities (insecure AI-generated code patterns, AI library vulnerabilities). Security testing consistently integrated into pipelines for AI-generated and AI-assisted code. AI security agents integrated into CI/CD for automated code review. AI supply chain inventory includes models, versions, MCPs, and dependencies (initial AI-BOM). Model provenance verification for self-hosted models. Automated scanning blocks known-vulnerable AI libraries and unsafe model formats.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Data Security L2 Repeatable
1 implemented · 0 partial · 0 absent
What L2 looks like for Data Security · the next rung
Where you are (L2 Repeatable): AI-specific data risks identified (poisoning, RAG leakage). Training and fine-tuning data sources documented for critical models. Basic access controls on vector databases. Basic validation (source approval, format checks) for external sources used in RAG. Sensitive data handling requirements documented for AI contexts but inconsistently applied.
The next rung (L3 Defined): AI data security requirements documented by data type (training, fine-tuning, RAG, embeddings). Data ingestion restricted to approved, documented sources with format validation before use. Vector databases use tenant or application isolation to prevent cross-context access. Sensitive data filtering applied to training and grounding sources (e.g. PII scanning). Initial data versioning for critical AI systems.
Verbatim from CSA AISMM v3.7; your level stays a provisional self-assessment.
Peer benchmark
Not enough peer data yet for Security Operations — need at least 5 other orgs’ runs, currently 0. No comparison is shown below that floor; this is a real count, not a placeholder.
Autonomy by workflow step (AI-CMM)
Alert triage L3 Augmented
Enrichment L3 Augmented
Investigation L2 Assisted
Response L2 Assisted
Documentation L1 Manual
Plays. Can this function run them at its current autonomy?
Each play names the controls it requires before running at an autonomy level, and the key performance indicator (KPI) it moves. Judged here at your current adopt level (L2) from this run’s answers, a control the diagnostic didn’t ask about reads not yet assessed, never assumed. Browse the full catalog →
Alert triage & enrichmentAI-secure the enterpriseKPI: Time per alert ↓1/3 controls evidenced2 not yet assessed✓ no gaps found
Phishing-report handlingAI-secure the enterpriseKPI: Time per reported email ↓0/3 controls evidenced3 not yet assessed✓ no gaps found
Incident summarization & commsAI-secure the enterpriseKPI: Time per incident report ↓2/3 controls evidenced1 not yet assessed✓ no gaps found
Detection-rule engineeringAI-secure the enterpriseKPI: Time to new detection ↓2/3 controls evidenced1 not yet assessed✓ no gaps found
Threat-intel digestionAI-secure the enterpriseKPI: Time to actionable intel ↓0/3 controls evidenced3 not yet assessed✓ no gaps found
Vulnerability triage & prioritizationAI-secure the enterpriseKPI: Critical-vuln backlog age ↓0/3 controls evidenced3 not yet assessed✓ no gaps found
Use cases: each play plotted on the grid
Use cases are the third placeable unit, alongside functions on /board and AI Controls Matrix (AICM) domains on the per-run card. v1 seeds one canonical use case per play in this function; your own concrete instances replace these as the measurement layer ships. Ungoverned dots (⚠) signal the gate caught autonomy ahead of maturity.
Autonomy × Maturity — each play in this function plotted as a use case
Maturity (AISMM) →
Mature autonomyUngoverned ⚠Over-controlledNot started
Alert triage & enrichmentAI-secure the enterpriseM3 · A2
Phishing-report handlingAI-secure the enterpriseM3 · A2
Incident summarization & commsAI-secure the enterpriseM3 · A2
Detection-rule engineeringAI-secure the enterpriseM3 · A2
Threat-intel digestionAI-secure the enterpriseM3 · A2
Vulnerability triage & prioritizationAI-secure the enterpriseM3 · A2
Maturity from this run’s governance reading; autonomy capped at min(your function’s autonomy, the play’s catalog ceiling). All use cases are within the gate at the current reading. Real per-use-case grading arrives with the measurement layer.
Gaps register
The hard gaps to close, consolidated: every cell where autonomy outran the control’s maturity, the workflow steps running ahead of the gate, and the controls you marked absent. This is the diagnosis the action plan below is fitted to, not a coverage scoreboard.
cellLOG-01Is there a documented logging & monitoring policy covering your AI systems and the data they touch?autonomy L3 · governed to L2
cellLOG-05Are monitoring alerts triaged and responded to with tracked metrics (e.g. MTTR)?autonomy L3 · governed to L1
cellSEF-01Is there a documented incident-response policy that covers AI-specific incidents?autonomy L3 · governed to L2
cellSEF-04Are those plans tested — tabletop or live — against AI incident scenarios?autonomy L3 · governed to L1
cellSEF-05Do you track incident-response metrics for AI incidents?autonomy L3 · governed to L1
cellMDS-02Are model artifacts scanned for integrity and tampering before deployment?autonomy L3 · governed to L2
stepAlert triageruns at L3 · governed only to L2
stepEnrichmentruns at L3 · governed only to L2
AI analysis
Security Operations runs at a mid-level maturity (2.8) with strong process and technology foundations (both L3) but a critical people gap at L1 that caps all capability at L1. Most categories reached L3, though Data Security lags at L2. The autonomy gate blocks further AI adoption because the team deployed AI tools faster than maturity supports, creating risk in monitoring, incident response, and supply chain workflows where unverified AI outputs could bypass human judgment.
Strengths
Process and technology both at L3 show solid investment in runbooks, tooling, and automation frameworks
Four of five categories at L3 demonstrate breadth: monitoring coverage, incident procedures, model security, and AI-supported dev workflows all operationalized
Incident Response and Security Monitoring both reached L3 despite coverage limits, indicating foundational detection and triage capabilities
Gaps, by priority
People dimension at L1 is the binding constraint: no evidence of trained personnel able to supervise or validate AI-drafted outputs in IR or detection workflows
Autonomy at 2.2 exceeds the gate-allowed 2.0, meaning AI tools operate with insufficient human oversight given current maturity
Data Security at L2 lags other categories, signaling weaker controls around data inventory, classification, or access governance in AI contexts
Recommended next step
Train incident-response leads to review and validate AI-drafted summaries and triage recommendations before sign-off, then document that verify-before-act step in the IR runbook. This single move lifts people capability, unblocks the autonomy gate, and reduces the highest operational risk without requiring new tools.
AI-assisted reading of your self-reported answers — not certified.
Generated Jul 5, 2026
Ranked action plan: the fitted few
Targeted at your weakest capability dimensions. Each gets interventions of its own kind: weak People means training, never another tool; weak Process means runbooks and policies; weak Technology draws from vendor features, automation, and the curated core skill set, never the full library. Candidates from the play catalog; fit happens per ecosystem.
People · L1 → L2
Capped: tier 4 not yet evidenced.
PeopleIR leads trained to review AI drafts for accuracy before sign-off · Incident summarization & comms
Process · L3 → L4
Capped: tier 4 not yet evidenced.
ProcessTriage runbook rewritten with explicit AI hand-off and escalation points · Alert triage & enrichment
ProcessPost-incident review cadence with the draft-then-verify hand-off written down · Incident summarization & comms
ProcessDetection-as-code review gate: every AI-drafted rule tested against replayed logs · Detection-rule engineering
Each AISMM category for Security Operations is sequenced by its current level. Weakest categories land in Start now; the rest follow as Next and Later. Targets are capped at L5. This phasing is derived; re-assess to see it shift.
L1
L2
L3
L4
L5
Data Security
Move from L2 → L4.
AI Supported Development and Supply Chain Security
Move from L3 → L5.
Incident Response
Plan for L3 → L5 once Phase 1 controls land.
Model Security
Plan for L3 → L5 once Phase 1 controls land.
Security Monitoring
Consolidate at L5 after the earlier phases.
Start now
Next
Later
Current
Target
Set your own targets
Pick where each category should land. The roadmap below sequences the gaps Foundational first, then Structural, then Procedural — CSA’s own domain ordering, not an invented dependency graph — and by gap size within a domain.
Security Monitoring
L3 nowL3
Incident Response
L3 nowL3
Model Security
L3 nowL3
AI Supported Development and Supply Chain Security
L3 nowL3
Data Security
L2 nowL2
Independent assessment
A second, independent read of the same run — an auditor or a peer team answering the same controls. Saved separately; it never overwrites the self-reported track above.
Implement
Tick the prescribed skills as you fit and operate them. Re-assess to see the categories move.
Implemented 4/4
Progress
Versus the previous run (May 20, 2026)
Security MonitoringL3 → L3 ·
Incident ResponseL2 → L3 ↑ +1
Model SecurityL2 → L3 ↑ +1
AI Supported Development and Supply Chain SecurityL1 → L3 ↑ +2
Data SecurityL2 → L2 ·
Governance average L2.0 → L2.8. Gate: within → ungoverned.
TrendL2.0May 20, 2026→L2.8Jun 8, 2026
Roll-up to the board
This function owns these AICM domains on the board. Each board number is this reading’s evidence, nothing modelled — re-assess any function and its row moves. This is the second altitude: see the portfolio →
LOG L3 Defined
SEF L3 Defined
TVM L3 Defined
Light read now, deeper read next
What you have here is the light, self-assessed read: fast, honest, and enough to see where autonomy has outrun governance. The deeper read is what turns it into proof.
This read (light)
Self-assessed against real control objectives
A headline posture and the gate verdict
The gaps register and the fitted few to close them
The next read (deep)
Each control verified against evidence, not self-report
Task-level before/after measured on the few skills adopted
The same motion run across functions to stand up the practice
Only the deep read earns the word measured; everything on this page is self-assessed until then.
Self-assessed and indicative, governance from AICM control coverage (AISMM), autonomy from the AI-CMM ladder (our model · calibrated to SAE J3016). Skill-to-objective fit is illustrative at this stage. Framework pins: CSA AICM v1.0.3, AI-CMM v1 (our construct), CSA AISMM, CSA AI-CAIQ v1.0.2.