Mapping OWASP LLM Top 10 Findings to SOC 2 and NIST AI RMF Controls

Your SOC 2 Type II renewal is six weeks out, and your auditor just added a line item you haven't seen before: "Describe the organization's process for assessing AI-specific risk in production systems." Your platform has a customer-facing chatbot and an internal copilot wired into your CRM. Nobody on your team has ever run a security assessment that speaks the language SOC 2 expects, because every AI security resource you've found talks about jailbreaks and prompt injection in isolation, with no path from "we tested for this" to "here's the control evidence."

This is the gap between AI security testing and AI security compliance, and it's where a lot of otherwise well-run companies get stuck. The OWASP LLM Top 10 (2025) tells you what to test. It doesn't tell you which SOC 2 Trust Service Criteria that testing satisfies, or which NIST AI RMF function it documents. That translation is what an auditor or an enterprise security questionnaire actually wants to see.

This guide builds that bridge directly: a category-by-category mapping from OWASP LLM Top 10 findings to SOC 2 criteria and NIST AI RMF functions, with the two highest-leverage categories, LLM02 (Sensitive Information Disclosure) and LLM06 (Excessive Agency), examined in detail because they intersect SOC 2's confidentiality and availability criteria most directly.

Why This Mapping Matters Right Now

SOC 2 was never written with large language models in mind. The Trust Service Criteria, security, availability, processing integrity, confidentiality, and privacy, are deliberately technology-agnostic. That flexibility is the problem. An auditor evaluating your AI-enabled product has to interpret how decades-old control language applies to a system that can be manipulated through natural language input rather than a traditional exploit chain.

Meanwhile, NIST AI RMF (NIST AI 100-1) has become the reference point regulators, auditors, and enterprise procurement teams reach for when they need a structured way to talk about AI risk. It doesn't replace SOC 2. It sits alongside it as a governance and risk-assessment layer, organized around four functions: Govern, Map, Measure, and Manage.

Put those two together and you get a workable answer to the question your auditor or your biggest customer's security team is actually asking: not "is your AI secure" in the abstract, but "show me how you tested it, what you found, and how that maps to the controls we already understand."

That's the deliverable this mapping produces.

The Core Mapping: OWASP LLM Top 10 to SOC 2 and NIST AI RMF

The table below covers all ten 2025 categories. Use it as a working reference when you're prepping audit evidence or responding to a vendor security questionnaire that asks about AI-specific risk.

A few things worth noting before you hand this to an auditor as-is. First, most rows touch two or three criteria, not one. AI risk doesn't sit neatly inside a single Trust Service Category, and an auditor will see through a mapping that pretends otherwise. Second, the NIST function columns lean heavily on Map and Measure because that's where most AI penetration testing evidence naturally lands. Govern and Manage require organizational artifacts (policies, escalation procedures, named owners) that a pentest report alone won't produce. You'll need both.

LLM02: Sensitive Information Disclosure, In Depth

LLM02 is the category most likely to show up by name in a customer security questionnaire, because it maps almost directly onto language procurement teams already use: "How do you prevent unauthorized disclosure of customer data?"

What it covers. An LLM that's been coaxed, through a crafted prompt, a poisoned retrieval document, or simple over-permissive context windowing, into revealing data it shouldn't: another tenant's records pulled from a shared RAG index, PII embedded in training or fine-tuning data, internal system details surfaced in a response meant for an external user.

Where it intersects SOC 2. This sits squarely in the Confidentiality category (C1.1, C1.2), which requires that information designated as confidential is protected against unauthorized disclosure. It also touches CC6.1 (logical access controls) and CC6.7, which governs how data is transmitted, moved, or disposed of. An LLM that leaks tenant B's data to tenant A during a chat session is a logical access control failure wearing a new mechanism. The auditor's question doesn't change. The attack surface does.

Where it intersects NIST AI RMF. This is primarily a Map and Measure problem. Map asks you to document what data the system can access and under what context, the exact inventory work most teams skip when they bolt an LLM onto an existing product. Measure is where adversarial testing comes in: you can't know whether your access boundaries hold until someone tries to break them on purpose.

Illustrative scenario. A SaaS company runs a support chatbot backed by a RAG pipeline pulling from a shared knowledge base that includes per-customer support tickets. During testing, a tester submits a support query phrased to ask the assistant to "summarize all open tickets mentioning [a specific keyword] across the account." Because the retrieval layer filters by keyword relevance rather than tenant ID, the model returns ticket excerpts from a different customer's account. No exploit code, no injected payload, just a retrieval boundary that was never scoped to enforce tenant isolation. This is illustrative only; the actual queries, payloads, and retrieval logic used in a real engagement are never published.

LLM06: Excessive Agency, In Depth

LLM06 matters more every quarter, because the trend across nearly every AI product roadmap is the same: give the model more tools, more autonomy, more reach into production systems. That trend is exactly what turns a contained chatbot into a system that can take irreversible action.

What it covers. An LLM or agent granted more permission, autonomy, or tool access than its function requires, such that a manipulated or malfunctioning model can take consequential actions: sending real emails, modifying records, executing financial transactions, calling internal APIs without a human checkpoint.

Where it intersects SOC 2. This is the category with the clearest line to Availability (A1.1, A1.2), because an over-privileged agent that's tricked into deleting records, locking accounts, or triggering a resource-exhausting loop is an availability incident, not just a confidentiality one. It also lands on CC6.3, which governs how access is provisioned and modified, and CC6.1 broadly. An agent with standing write access to a database is, from a controls perspective, no different from an overprivileged service account. Auditors already know how to think about that. The framing just needs updating for agentic systems.

Where it intersects NIST AI RMF. This is a Govern and Manage problem more than a pure testing one. Govern is where you define the policy: which actions require human approval, which tools an agent can invoke without a checkpoint, who signs off on expanding an agent's permission scope. Manage is where you build the operational response: what happens when an agent takes an unintended action, how fast you can revoke its access, how the incident gets documented and escalated.

Illustrative scenario. An internal copilot has write access to a ticketing system so it can close resolved tickets automatically. A tester submits a request, framed as a routine support message, that includes embedded text instructing the agent to also reassign a batch of unrelated tickets to a different team and mark them resolved. The agent, lacking a permission boundary that distinguishes "close this ticket" from "take bulk action across the queue," complies. The fix isn't a smarter model. It's scoping the tool's API credentials so the action the agent attempted was never possible in the first place. This is illustrative only and does not reflect any specific client engagement or working payload.

Traditional Pentest vs. AI Penetration Testing for Compliance Evidence

A question we hear constantly from CTOs heading into a SOC 2 renewal: "We already ran a pentest this year, doesn't that cover it?" Usually, no. Here's the practical breakdown.

Most companies need both. A 2025-mapped AI penetration test doesn't replace your existing pentest program; it fills the part of the attack surface your existing program was never built to test. For a closer look at where standard pentests fall short specifically, see our breakdown of AI penetration testing versus traditional penetration testing.

Scoping AI Testing Around Your Audit Timeline

The right depth of AI penetration testing depends on how complex your AI footprint actually is, and that complexity also determines how much OWASP LLM Top 10 coverage you can realistically claim in front of an auditor. A single chatbot calling a third-party model API is a different risk surface than a multi-agent platform with RAG pipelines and write access to production systems, and your audit evidence should reflect that difference honestly rather than overstating coverage.

If you're heading into a SOC 2 Type II renewal with a hard date, work backward from it. A Professional-tier engagement on a RAG-backed product typically needs a few weeks for scoping, testing, and report delivery, plus time for remediation and a retest before the evidence is audit-ready. Starting that process the month of your audit field work rarely leaves room for a clean retest cycle. Starting it a full quarter out almost always does.

Turning Findings Into Audit-Ready Language

A penetration test report full of CVSS scores and technical findings isn't, by itself, something you hand to a SOC 2 auditor. The translation work is what makes findings usable as control evidence. A few patterns that work in practice:

Tie each finding to a specific criterion, not a category. "We identified a sensitive information disclosure risk" is a start. "We identified a logical access control gap (CC6.1) affecting cross-tenant data isolation in the RAG retrieval layer, since remediated and retested" is what an auditor can actually file.

Document the retest, not just the finding. SOC 2 Type II cares about controls operating effectively over a period of time, not a point-in-time snapshot. A penetration test that includes a documented remediation and a free retest gives you exactly that: before-state, fix, after-state confirmation.

Keep the NIST AI RMF language even though it's voluntary. NIST AI RMF isn't a certifiable framework and SOC 2 doesn't require it. But auditors and enterprise security teams increasingly use its vocabulary, Govern, Map, Measure, Manage, as a shared way to talk about AI risk maturity. Reports that speak that language move faster through review than reports that don't.

Keep a standing inventory of AI systems in scope. This is Map function work, and it's the single most common gap we see. If your auditor asks "what AI systems do you operate and what data can each one access," you want an existing document, not a scramble.

Get Audit-Ready Before Your Auditor Asks

If your SOC 2 renewal, customer security questionnaire, or vendor risk review has started asking questions about AI-specific risk that your current documentation can't answer, the fix isn't a generic AI policy. It's a penetration test that produces findings mapped to the criteria your auditor already evaluates, with NIST AI RMF language built in from the start.

Pentest Testing Corp's AI penetration testing service is built on the OWASP LLM Top 10 (2025) and structured so every finding lands directly on the SOC 2 and NIST AI RMF language your compliance program already uses. Engagements are fixed-price, manual-first, and come with a retest once fixes are in place.

Book a 15-minute scoping call and walk away knowing exactly what tier of AI penetration testing fits your audit timeline.