NIST already publishes a CSF 2.0 map to the OWASP LLM Top 10. It is in a spreadsheet.

If you are trying to govern an AI system and you already run NIST CSF 2.0, there is an obvious question: which parts of the framework actually apply to a large language model?

There's already an answer. NIST publishes 169 mappings from CSF 2.0 Subcategories to the OWASP Top 10 for LLM Applications, posted in April through its Online Informative References program and shipped in the same download as the framework itself. I'd never seen anyone cite them, so I went and got them.

They are in a spreadsheet.

The download

The Cybersecurity and Privacy Reference Tool serves the CSF 2.0 Core with its Informative References attached. The endpoint is:

https://csrc.nist.gov/extensions/nudp/services/json/csf/download?olirids=all

Note the /json/ in that path. It returns an XLSX workbook. I probed four plausible variants looking for the documented CPRT JSON schema, which does exist as a published schema file, and couldn't find an endpoint that serves CSF 2.0 through it. So the machine-readable format of the framework is a ZIP full of XML that you parse yourself.

That is a mild annoyance. The next part is not.

The count is off, and on purpose

CSF 2.0 has 6 Functions, 22 Categories, and 106 Subcategories. Parse the worksheet and you get 12, 34, and 185.

The extra elements are withdrawn CSF 1.1 entries, shipped inline in the same sheet, marked like this:

Business Environment (ID.BE): [Withdrawn: Incorporated into GV.OC]

There are 91 of them, 12 Categories and 79 Subcategories, plus six trailing rows that carry a bare Function label and nothing else. Filter those and you land exactly on 6 / 22 / 106.

This is a reasonable thing for NIST to do. Keeping the withdrawn entries visible tells a CSF 1.1 reader where their old control went. But it means any tool that parses the sheet naively is silently working with 79 extra Subcategories, every one of them defunct.

Three things that will break your parser

I hit all three. Each produces valid-looking output rather than an error, which is the worst failure mode.

Identifiers live inside the text. There is no ID column. A Subcategory cell reads GV.OC-01: The organizational mission is understood and informs cybersecurity risk management. Functions and Categories use a different shape again: Organizational Context (GV.OC): The circumstances.... You need two different splits depending on which column you are in.

Reference lines contain up to three colons. This one cost me a whole framework. The Informative References column is newline-separated lines like CIS Controls v8.1: 14.1. Split on the first colon and you are fine. Then you hit:

ISO/IEC 27001:2022: Mandatory Clause: 6.1

222 distinct reference lines carry more than one colon. First-colon splitting renames the source to "ISO/IEC 27001" and hands you an empty value. I dropped every ISO 27001 mapping, all 488 of them, from my own first tally this way, and didn't notice until a second pass counted 23 reference sources where I'd recorded 22.

The shared-strings table is rich text. XLSX stores strings once in sharedStrings.xml. NIST bolds each identifier, which splits a single logical string across separate runs. The obvious regex, <si><t>(.*?)</t></si>, matches 11 of 486 entries. A correct parser concatenates every <t> inside each <si> with no per-fragment trimming, because the styling boundary lands mid-sentence and trimming fuses words together inside text you are promising to reproduce verbatim.

What the mappings actually say

Now the useful part. With the data out, here's coverage by source framework, counting distinct CSF Subcategories rather than raw mapping lines. The distinction matters, because a source can map heavily onto a handful of Subcategories: CIS Controls v8.1 contributes 62 mapping lines but touches only 48 Subcategories. Raw line counts say very little about coverage. These are the sources most people will know; the tool lists them all.

Two things jump out.

If you run SP 800-53 or ISO 27001, every Subcategory has somewhere to land. Those frameworks touch all 106. Getting from them to CSF is mostly a translation exercise, not a hunt for missing areas. A mapping only says a control is related to a Subcategory, not that it fully satisfies it, but you won't find a Subcategory with nothing behind it.

If you run CIS Controls v8.1, 58 Subcategories have no mapping at all. That is the majority of the framework. CIS is a technical controls catalog and CSF 2.0 spends its first Function entirely on governance, so this is not a defect in CIS. But if CIS is your only reference point, more than half of CSF is invisible to you, and GOVERN takes the biggest share: 19 of its 31 Subcategories have no CIS mapping.

The OWASP mapping needs inverting

This is where I got my own framing wrong, and it's worth showing.

My first instinct was to ask: which CSF Subcategories govern LLM risk? Answer: 77 of 106. That is 73% of the framework. As a filter it is useless. "Most of CSF applies to your AI system" is true, unhelpful, and something you could have guessed.

Turn it around and it becomes a real tool. Ask instead which Subcategories govern a specific risk:

Ten buckets, each small enough to read in one sitting, each listing the Subcategories in NIST's own wording. That's something you can actually work from, and it's the same 169 mappings, just keyed the other way.

One caveat before you lean on them. NIST checks that submitted mappings follow its format, not that they're correct, and it says plainly that listing a mapping it didn't write is not an endorsement. Treat these as a well-sourced starting point, not a ruling.

The shape of that table is itself informative. Data and Model Poisoning pulls 31 Subcategories because poisoning touches supply chain, data governance, integrity monitoring, and incident response all at once. System Prompt Leakage pulls 5, because it is a narrow, mostly technical concern. The number is a rough proxy for how much of your governance program a given AI risk actually implicates.

Why this was buried

I don't think anyone decided to hide this. The data is published, it is free, it sits on NIST's own site, and the endpoint is a public URL. But it is delivered as a spreadsheet, keyed in the less useful direction, mixed with withdrawn elements, and gated behind three parsing traps that each fail silently.

The effort between "NIST published it" and "a defender can use it" is small, but it is not zero, and I couldn't find anyone who had closed it.

So I did. The crosswalk is in the lab: browse the OWASP risks and expand each into the CSF Subcategories that govern it, or pick a framework you already run and see its blind spots. Static data, generated once, no runtime API calls.

The part worth keeping

The lesson generalizes past this one dataset. Standards bodies increasingly ship machine-readable artifacts alongside their PDFs, and those artifacts are where the genuinely useful cross-references live. They are also where nobody looks, because the PDF is what gets read and the spreadsheet is what gets downloaded once and forgotten.

If you want to find something in compliance work that nobody else is citing, the download link is a better place to look than the document.