Prompt Injection Testing Templates
Six documentation templates that turn the Testing methodology and the reviewed test cases into a workflow for planning, executing, evidencing, reporting and retesting authorized LLM, RAG and AI agent assessments.
What this kit is and is not
- A practical documentation set for authorized prompt injection security testing. Not a compliance framework, certification scheme or benchmark.
- Teams adapt fields to their own architecture and policies. A template is not evidence, and filling in a form does not prove a control.
- Model narration is not authoritative evidence. Downstream evidence comes from application, provider or control records.
- Unobserved is not pass. Control not exercised is not pass for that control objective. Positive controls matter.
- Evidence and conclusions stay versioned and attributable.
How the pieces fit together
| Workflow order | Role in the workflow |
|---|---|
| 1. Plan | Plan fixes scope, authorization, versions and evidence sources. |
| 2. Case | Case defines oracle, positive control and evidence chain. |
| 3. Run | Run records each execution separately. |
| 4. Evidence | Evidence backs every chain state with an attributable source. |
| 5. Finding | Finding states what was demonstrated and what was not. |
| 6. Regression | Regression validates the fix and keeps history separate. |
All six templates
- Step 1 of 6Test Plan Template
Defines identity, authorization, threat model, instrumentation, case selection and closure for one authorized assessment.
Purpose: Fixes what is tested, under whose authority, against which versions and with which evidence before any stimulus is introduced.
When used: Before the first run, and again whenever scope, versions or authorization change.
Open template - Step 2 of 6Test Case Template
The blank, reusable version of the test case model used across the library, including evidence chain, positive control and all four outcomes.
Purpose: Turns a security question into a reviewable record with a decidable oracle before execution.
When used: When adapting a library case to a local system, or writing a new local case within an authorized assessment.
Open template - Step 3 of 6Run Record Template
One record per controlled run, with versions, run type, chain states, outcome and evidence references.
Purpose: Preserves each execution separately so results can be compared, reproduced and audited.
When used: During execution, completed immediately after every baseline, positive control, stimulus, variant or regression run.
Open template - Step 4 of 6Evidence Record Template
Captures one piece of evidence, its stage, status, authority, integrity and handling.
Purpose: Makes every claim in a run or finding traceable to an attributable source with known limits.
When used: Whenever evidence is captured during a run, and when reviewing a finding or retest.
Open template - Step 5 of 6Finding / Security Report Template
States exactly what was demonstrated, with observed and unobserved chain states, impact, cause and remediation.
Purpose: Communicates a security-relevant result so owners can decide, fix and retest without overclaiming or underclaiming.
When used: After runs show a control failure, a material evidence gap, or a risk the owner must decide on.
Open template - Step 6 of 6Regression Retest Record Template
Validates a fix with current evidence while keeping historical reconstruction status separate.
Purpose: Decides whether a finding can close, based on the control being exercised in the changed versions.
When used: After a fix, and after any regression trigger such as a model, prompt, policy, tool or catalogue change.
Open template