Agentic AI Risk Register Template
One risk register per agentic system, pre-populated with the OWASP Agentic Top 10 plus system-specific risk slots. Each row carries an attack path (not just a description), the inherent risk before controls, the controls applied, residual risk after controls, and a named acceptor for any accepted residual risk.
Get the spreadsheet
Enter your email to download
Excel format (.xlsx). Two sheets: how-to guide and the working risk register. 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, AI governance leads, and AppSec teams preparing an agentic AI system for pilot or production review.
Use it per system — one register per agentic deployment under review. The pre-populated OWASP Agentic rows are a starting point; add system-specific risks as needed.
How to use it
- 1Identify the agentic system: orchestrator, tools, memory, identity model.
- 2For each pre-populated OWASP Agentic row, mark Applicable? and assess Likelihood / Severity for your system.
- 3Add system-specific risks beyond the OWASP Agentic Top 10.
- 4Document the Attack Path — how a threat actor would realise this risk in your system.
- 5Document Residual Risk after controls and name the acceptor.
- 6Treat any High inherent risk without a Covered control as a review blocker.
What's in the file
Each pre-populated row covers one OWASP Agentic threat, with example controls and risk ratings ready to adapt to your system. Two system-specific rows show how to add risks beyond the Top 10 (vendor model change, regulatory exposure).
| Column group | Contents |
|---|---|
| Risk ID + Category | Maps to OWASP Agentic Top 10 or system-specific category |
| Attack Surface | Orchestrator / Memory / Tool surface / Identity / Output / Supply chain |
| Risk Description + Attack Path | What could go wrong AND how a threat actor would realise it |
| Likelihood + Severity + Inherent Risk | Pre-control risk rating |
| Controls Applied | References to your control plan IDs |
| Residual Risk + Acceptance | Post-control risk, acceptance status, named acceptor |
From risk register to review pack
Spreadsheets are the starting point
This register helps document agentic AI risks and the controls that address them. Drel turns that analysis into a guided AI security review — mapping risks to findings, generating a risk disposition, and producing a review-ready dossier your AI Committee can actually approve or reject.
Frequently asked questions
- What makes this different from a generic risk register?
- Three things: pre-populated OWASP Agentic Top 10 rows so you don't start from a blank page; an Attack Path column that forces you to describe how a threat actor would realise the risk (not just the category name); and a named Acceptor column for any residual risk, so accountability is explicit.
- Should I treat the pre-populated risks as definitive for my system?
- No. They are starting points. Mark Applicable? for each row, adjust likelihood and severity based on your specific system, and add system-specific risks beyond the Top 10 (supply chain specifics, regulatory exposure, business-context risks). Don't delete rows you decide are not applicable — mark them N/A with a one-line rationale.
- How does this relate to the OWASP Agentic Top 10 Control Map?
- The risk register names the risks; the control map names the controls. Use them together: for each risk in your register, identify which controls from the control map address it. The Controls Applied column references your control plan IDs.
- Who should be the Acceptor for residual risk?
- Someone with authority to accept consequences. For most accepted residual risks, this is the AI Committee or its delegate (CISO, AI Governance Officer). For risks that affect product strategy, it may be a product or business owner. The point is that an accepted risk has a named owner — not 'the team'.
- Does this map to ISO 42001 or EU AI Act?
- The register supports ISO 42001 clause 6.1.2 (risk identification) and 6.1.3 (risk evaluation and treatment), and supports Article 9 risk record evidence for high-risk AI under the EU AI Act.
- How often should this be re-reviewed?
- On a regular cadence (quarterly is common) and on any re-assessment trigger fired by changes to the system: new tool, new data source, new model, scope expansion, vendor change. The register is a live artefact, not a one-time deliverable.