RAG Security Checklist
Retrieval-augmented generation pipelines have four attack surfaces that STRIDE-style threat modelling typically misses: the ingestion pipeline, the vector store, the retriever, and the prompt assembly layer. This checklist covers all four with lifecycle gates and evidence requirements. 24 rows, ready to paste into your AI Committee review.
Free spreadsheet
Excel · .xlsx · 2 sheets
Download free
Enter your work email. Includes a how-to guide tab and working columns for status, owner, and gap tracking. Opens in Excel, Google Sheets, or any spreadsheet tool. You'll also receive new blog posts when they publish.
Who it's for
Security architects, AppSec leads, and AI governance teams preparing a RAG application for pilot or production review.
Use it per system — one copy per RAG pipeline under review. It is especially useful before pilot, when indirect injection controls and retrieval trust boundaries need to be locked in architecturally.
How to use it
- 1Identify the RAG pipeline: ingestion sources, vector store, retriever, generation model.
- 2Filter by Lifecycle Gate — Before pilot controls must be in place before any user access.
- 3Mark each row: Covered / Partial / Missing / Not applicable / Unknown.
- 4Pay particular attention to the Prompt assembly rows — indirect injection controls are the most commonly missed.
- 5Assign an owner and add an evidence link where evidence exists.
- 6Treat Missing rows at the relevant gate as review blockers.
- 7Use the completed checklist as input to a security review or AI Committee submission.
What's in the file
Five fixed columns plus eight working columns (status, owner, evidence link, gap, priority, target date, notes). Each row is a specific RAG-layer control.
| Column | Contents |
|---|---|
| Attack surface | Ingestion / Vector store / Retriever / Prompt assembly / Output |
| Required control | Specific, actionable — not a category |
| Lifecycle gate | Before pilot / Before production / Ongoing |
| Evidence required | What you show an auditor to prove the control is working |
| Framework tags | OWASP LLM, NIST AI RMF, ISO 42001 clause, EU AI Act article |
Sample row — Prompt assembly
Attack surface
Prompt assembly
Required control
Retrieved content treated as data, not as instruction (indirect injection mitigation)
Lifecycle gate
Before pilot
Evidence required
Prompt template review + adversarial test with poisoned document
Framework tags
OWASP LLM, NIST AI RMF
From checklist to review pack
Spreadsheets are the starting point.
This checklist helps identify which RAG security controls are in place and which are missing. Drel turns that gap analysis into a guided AI security review — mapping controls to findings, generating a risk disposition, and producing a review-ready dossier your AI Committee can actually approve or reject.
Frequently asked
Frequently asked questions
- Why a RAG-specific checklist instead of just OWASP LLM Top 10?
- The OWASP LLM Top 10 covers LLM application risks generally. RAG systems have an additional content layer — the knowledge base — that introduces trust boundaries STRIDE-style threat modelling typically doesn't represent. This checklist drills into the four RAG-specific attack surfaces and the indirect injection vector that they enable.
- What is indirect prompt injection?
- Indirect prompt injection happens when content reaches the LLM through a retrieval step (or tool response) that embeds instructions the LLM treats as authoritative. A malicious document in a RAG knowledge base can inject instructions into the agent's context. Mitigation is architectural: treat retrieved content as data, not instruction, and validate it before assembly into the prompt.
- Does this assume a specific RAG architecture?
- No. The five attack surfaces (ingestion, vector store, retriever, prompt assembly, output) appear in essentially every RAG pipeline regardless of the specific vector database, embedding model, or generation model. Where a control doesn't apply to a given architecture, mark it as N/A with a one-line rationale.
- What lifecycle gate applies to indirect injection controls?
- Controls that limit indirect injection — such as prompt design treating retrieved content as data — should be in place before pilot, not before production. They are difficult to retrofit because they require architectural choices in prompt assembly and trust boundary design.
- How does this map to ISO 42001?
- Each row carries a framework tag column linking to relevant ISO 42001 clauses (mostly 8.4 for operational controls, 9.1 for monitoring). Use the tags to demonstrate clause coverage in a single artefact alongside your control plan.
- Does this replace a security review?
- No. The checklist is an input to a security review, not the review itself. The review combines the checklist with system-specific threat modelling, residual risk acceptance, and a clearance decision.