There are two OWASP documents on LLM security and they get confused constantly. One is the OWASP Top 10 for LLM Applications, the list of ten technical risks, from prompt injection to unbounded consumption. The other is the LLM Applications Cybersecurity and Governance Checklist, now at version 1.1, which says nothing about specific attacks and everything about what an organisation needs in place before and during LLM adoption.
The second one is the one almost nobody has read. Part of the blame is the name: it circulates as the LLM AI Security & Governance Checklist, as the LLM AI Cybersecurity & Governance Checklist and now as the LLM Applications Cybersecurity and Governance Checklist. Three labels for the same PDF, which makes even finding it harder than it should be.
Two documents, two readers
You read the Top 10 if you build or audit the system. You read the checklist if you have to decide whether your company adopts LLMs and then answer for that decision: leadership, security, legal, compliance. It is written to accompany an adoption strategy, not to be run as a penetration test.
That changes the kind of question being asked. The Top 10 asks whether an attacker can poison your corpus. The checklist asks whether you know which models are deployed across your organisation, who approved them and what happens the day one of them fails. They sit at different levels and neither replaces the other.
The thirteen areas
The document is organised into thirteen blocks numbered 1 to 13. On paper they look like a flat list, but they fall into four groups depending on the work they take and on who does it.
Understand the exposure, areas 1 and 2
Adversarial risk looks outward: what competitors are doing with AI, what attackers are doing and what your own deployment exposes. It includes one check almost nobody runs, which is reviewing your current vendors in case they have added AI features to a product you already had under contract. That tends to surface more new attack surface than your own projects do.
Threat modelling looks inward, and it is the usual exercise translated to a system that reads text and acts on it. Who can reach the model, what they can inject into its context, which tools it can invoke and with whose credentials. If you already run a threat modelling process, this extends it rather than replacing it.
Know what you have, areas 3 and 4
The AI asset inventory is the most uncomfortable area and the one that goes stale fastest. Which models, which integrations, what data goes in and out, who owns each piece. The first version always comes out incomplete, because there are deployments nobody registered and AI features inside SaaS tools that switched themselves on in an update.
AI security and privacy training is the other half. It is not a generic awareness course: it is making sure the people who use and operate these systems know what they must not paste into a prompt and what it means for an output to be plausible but false. In Europe there is an obligation behind it too, Article 4 of the AI Act, which has applied since February 2025 and does not wait for any of the delays.
Decide and answer for it, areas 5 to 8
Business cases ask why you are adopting it, what you expect from it and what you are measuring it against. It sounds like consultancy filler and it is what prevents the deployment nobody can justify six months later, when the licence comes up for renewal.
Governance sets out who decides, who approves and who answers, with acceptable use policies, assigned roles and a route for escalating incidents. The legal area covers contracts, intellectual property, liability for model output, vendor warranties and what happens to the data you send to a third-party API. And the regulatory area is knowing which rules reach you and from when, which in Europe means Regulation (EU) 2024/1689, the GDPR and, depending on the sector, NIS2.
These four look the most like committee work, and they are also the ones that leave a documentary trail. That material gets reused in any compliance project later on.
Build and verify, areas 9 to 13
Using or implementing LLM solutions orders the controls according to how you consume the model, because calling a public API is not the same as fine-tuning your own or hosting it on your infrastructure. Each option moves the risk somewhere else rather than removing it.
TEVV (testing, evaluation, verification and validation) insists that checking is a continuous process, not a snapshot taken at launch. Metrics, thresholds and somebody who revisits them when the model changes underneath, which with a managed provider happens without notice.
Model cards and risk cards document what the model does, what it was trained on, where it fails and which known risks it carries, in a format somebody outside the team can read. The RAG area treats retrieval as the usual way to improve answers without retraining, with its own implications for the corpus and for retrieval permissions.
AI red teaming closes the list: attacking the system on purpose and in a structured way. The document warns that it does not replace the other controls, and it is right. A red team run against an organisation that does not know which models it has only produces a list of surprises.
Where it falls short
It is a good starting point and it has one underlying problem: almost everything is a question, not a threshold. "Maintain an AI asset inventory" does not say when an inventory is good enough. That works to open the conversation in a committee and not to close it.
The other gap is that the technical areas and the governance areas sit at the same level, so a team can tick twelve process boxes and never have tested whether its agent executes instructions that arrive inside a document. That is why it is worth reading alongside the Top 10 for LLM applications, which is where the concrete failures live with their proof of concept.
What it gives you for the AI Act
A good part of what the checklist asks for is, under a different name, material that Regulation (EU) 2024/1689 will require of a high-risk system. It is not an equivalence, but the overlap is enough that the work does not go to waste.
What appears nowhere is the formal side: conformity assessment, the EU declaration, CE marking, registration in the EU database and post-market monitoring. Working through the checklist does not make you compliant with the Regulation. What it does is let the compliance project start with real material instead of a blank page.
On timing: the Digital Omnibus delay moved the bulk of the high-risk regime to December 2027 and August 2028, and the exact dates are in the application timeline. That buys room to do the work calmly, not to skip it.
Where to start
If you have to pick a single area, pick 3. The AI asset inventory is the one that unblocks the others and the one most people discover they do not have. As soon as you build it, the deployments nobody approved show up, which is exactly the information you need before deciding anything.
Then the technical side. We keep an operational version of the Top 10 with binary checks and regulatory mapping in the OWASP LLM checklist: the same one we apply on audits, so you can run it yourself.
Source: OWASP Gen AI Security Project, LLM Applications Cybersecurity and Governance Checklist v1.1, available at genai.owasp.org.