Adversarial Security and Robustness Checklist

How to use this document

• What it is for. This is a base checklist to confirm, before a pilot, a production release or a relevant change, that an AI model or application was tested against manipulation and failure: prompt injection, jailbreaks, data leakage, agent abuse, poisoning, evasion, out-of-distribution inputs, service abuse and, for third-party models hosted internally, backdoors, tampered chat templates and embedded alignment or censorship. It does not replace a penetration test or a full red-team exercise, but it records what was tested, what was found and what was decided.
• Who should own it. Information security, together with the system owner and the technical team that builds or integrates the system. Enter the function in [RESPONSIBLE FUNCTION] and the person who signs off the result in [OWNER].
• Decisions to take first. Decide the testing depth for each risk level (aid C), who runs the tests (internal team, independent team or third party), which severity blocks deployment and who may accept residual risks.
• Fields to complete. Complete the identification details, mark each control as "Met," "Partial," "Not met" or "N/A," note the evidence and record each finding in Section 14. Use "Module selection" to keep the sections that match your profiles and the type of system.
• Country variants. This document has no country variants. Use "Related regulatory references" to see which cybersecurity, products-with-digital-elements or AI laws expect your organization to run adversarial testing or document robustness.
• Technical references. To design test cases, you can draw on public catalogs such as the OWASP Top 10 for LLM Applications (2025 edition), MITRE ATLAS and NIST AI 600-1.
• Approval and filing. The decision in Section 15 is signed by information security and the system owner; the [AI COMMITTEE] decides when the system is High risk and the decision is "Approve with conditions" or "Escalate." File the checklist with the model card and, for third-party models hosted internally, record the summary in their provenance sheet.

Module selection

Profile, level or system type	Sections to keep
All	1 to 4, 7, 9, 11, 12, 14 and 15
P2 Integrates models through APIs or RAG	Also 5 and 6; and 13.5 and 13.6 if it uses third-party models in Medium- or High-risk systems
P3 Hosts models, including open-weight models	Also 5, 6 and 13
P4 Trains or fine-tunes models	Also 10 and, if it fine-tunes a language model, 5, 6 and 13.7
P5 Uses agents that act in systems	Also 5, 6 and 8
Classic classification or scoring model	Also 10
Basic level	Rows with no level marker
Standard and Reinforced level	All rows, with rows marked [REINFORCED LEVEL] only at the Reinforced level

Delete the sections that do not apply to your organization.

Adversarial Security and Robustness Checklist

Field	Value
Organization	[LEGAL ENTITY NAME]
Responsible function	[RESPONSIBLE FUNCTION]
Verification owner	[OWNER]
AI system	[AI SYSTEM]
Model and application version	[COMPLETE]
Model vendor or developer	[VENDOR]
Deployment profiles of the system	[COMPLETE: P1 to P5]
Type of system	[COMPLETE: language model application, retrieval-augmented search over documents, agent with tools, classic classification or scoring model, vision or other]
Stage	[COMPLETE: before pilot, before production, relevant change or periodic review]
Risk level (per the "AI System Inventory")	[COMPLETE: Low, Medium or High]
Testing team	[COMPLETE: internal, independent or third party]
Testing dates	From [DATE] to [DATE]

1. Using the checklist

1.1 [ORGANIZATION NAME] applies this checklist to every Medium- or High-risk AI system, every AI application exposed to customers or the public, every agent that can take actions and every third-party model hosted on owned or rented infrastructure, before the pilot, before production and after relevant changes to the model, system instructions, data sources, connected tools, weights version or chat template.

1.2 Each control is marked as follows:

Result	Meaning
Met	The control exists and was tested, with evidence.
Partial	The control exists but does not cover all cases or was not fully tested.
Not met	The control does not exist or the test failed.
N/A	Does not apply to this type of system; the reason is stated.

1.3 Each "Partial" or "Not met" generates a finding in Section 14 with its severity. Finding severity is not a risk level: when the finding is recorded in the risk register of the "AI Risk Management Procedure," it is given the risk level shown in the last column.

Finding severity	Criterion	Risk level in the register
Critical	Allows confidential or personal data to be exposed, unauthorized actions to be taken, a hidden model behavior to be triggered, or unlawful or seriously harmful content to be generated in a reproducible way.	High (Unacceptable if it amounts to a prohibited practice)
High	Allows relevant controls to be bypassed or outputs to be significantly degraded with moderate effort.	High
Medium	Requires unlikely conditions or has a limited and reversible impact.	Medium
Low	Minor or good-practice weakness, with no demonstrated direct impact.	Low

2. Scope and threat model

ID	Control	Result	Evidence
2.1	The system is in the "AI System Inventory," with its system owner and technical lead identified.	[COMPLETE]	[COMPLETE]
2.2	The assets to protect are documented: data, system instructions, credentials, connected tools, the model itself and reputation.	[COMPLETE]	[COMPLETE]
2.3	Potential attackers and abusers are identified: external users, internal users, third-party content the system reads and vendors.	[COMPLETE]	[COMPLETE]
2.4	All entry points to the model are identified: user messages, documents, web pages, emails, tool responses and training data.	[COMPLETE]	[COMPLETE]
2.5	The consequences that would be unacceptable for this system are defined.	[COMPLETE]	[COMPLETE]