If your organization is deploying AI in production, your current risk register is likely incomplete. AI introduces unique risks that don't fit traditional vulnerability categories. You need a structured way to catalog these risks before they become incidents.
This template provides a working document to inventory AI-related cybersecurity and privacy risks across three dimensions: risks from your AI systems, risks to your AI systems, and risks in how you use AI for defense. This aligns with the NIST Cybersecurity Framework for AI use cases.
Purpose of the Inventory
This template helps document and prioritize AI-specific risks that fall outside your current asset register or threat model. It's designed for teams managing:
- Machine learning models in production
- AI-powered security tools like SIEM analytics and threat detection
- Third-party AI services integrated into business processes
- Data pipelines feeding AI systems
Use this to identify gaps in your controls, discover new threat vectors, and communicate AI risks to stakeholders who might not understand why "we already have a vulnerability management program" isn't enough.
Prerequisites
Before you start:
- Asset inventory: Have a current list of systems, applications, and data stores. Without this, you can't identify what's AI-enabled.
- Data classification scheme: AI risks scale with data sensitivity. Know which datasets contain nonpublic information, training data, or model outputs.
- Existing risk register access: You're extending your risk management process to cover AI-specific exposures.
- Stakeholder input: Consult with application owners, data engineers, and security operations to understand where AI is actually deployed.
The Template
Copy this structure into a spreadsheet or risk management platform. Each row represents one AI-related risk.
Column A: Risk ID
Sequential identifier (AI-001, AI-002, etc.).
Column B: Risk Category
Select one:
- AI System Security: Risks to the confidentiality, integrity, or availability of your AI infrastructure.
- AI-Enabled Threat: Risks from adversaries using AI against you.
- AI in Defense: Risks from your use of AI in security operations.
Column C: Risk Description
One-sentence summary. Example: "Model training data leakage exposes customer transaction patterns."
Column D: Affected Asset
Name the specific AI system, model, or tool. Avoid generic entries like "all ML models."
Column E: Threat Vector
How this risk could materialize. Consider data poisoning, model extraction, adversarial inputs, deepfake phishing, automated vulnerability scanning, AI-generated social engineering, false positives, unexplainable detections, and bias in alert prioritization.
Column F: Data Dependency
List datasets this AI system consumes or produces. As AI spreads across business units, understanding data dependencies is crucial.
Column G: Explainability Gap
Rate as High, Medium, Low, or N/A. Can your team explain why the AI system made a specific decision? This matters when defending a decision to senior management or regulators.
Column H: Current Control
What you have in place today. If nothing, write "None." Don't list aspirational controls.
Column I: Control Gap
What's missing. Be specific: "No input validation on model API endpoints" is actionable.
Column J: Impact if Realized
Business impact in terms your organization already uses: revenue loss, regulatory penalty, operational downtime, reputational damage.
Column K: Likelihood
Use your existing risk scoring method (High/Medium/Low or numeric scale). Consider factors like internet-facing AI systems, public model architecture, and third-party AI services.
Column L: Owner
Name a person, not a department. Who is accountable for managing this risk?
Column M: Remediation Plan
Next action and target date. "Implement differential privacy guarantees on training dataset by Q2" is a plan.
Column N: Framework Mapping
Map to NIST CSF Core Functions (Identify, Protect, Detect, Respond, Recover) or relevant AI RMF categories.
Customizing the Template
Add industry-specific columns: For healthcare, add HIPAA considerations. For financial services, add model governance requirements. For critical infrastructure, add CIRCIA reporting triggers.
Adjust risk categories: Some organizations may want to separate "AI for privacy protection" as its own category.
Integrate with existing tools: Map these columns to your existing risk fields in a GRC platform.
Set review cadence: Review this inventory quarterly. New model deployments, algorithm updates, and third-party AI service changes all trigger inventory updates.
Scale the detail: For high-risk AI systems, complete every column. For low-risk experimental models, a lighter touch is acceptable.
Validation Steps
Cross-check with asset inventory: Every AI system in this inventory should appear in your broader asset register.
Test explainability ratings: For systems marked High explainability gap, ask the owner to walk through a recent decision.
Verify data dependencies: Pull a sample of the datasets listed in Column F. Confirm they're classified correctly and that access controls match the sensitivity level.
Map to incidents: When you have an AI-related security event, check whether that risk was in your inventory. If not, add it and review why you missed it.
Stakeholder review: Share the inventory with application owners and data engineers. They'll catch risks you missed and correct assumptions about AI systems in production.
This inventory won't prevent every AI-related incident, but it ensures you're not discovering critical exposures for the first time during a post-incident review. Start with the AI systems you know about, fill in what you can verify, and mark the rest for follow-up. An incomplete inventory you'll maintain beats a comprehensive one that's obsolete by next quarter.
