Purpose of the Template
Your organization's current Cybersecurity Framework likely doesn't address AI-specific risks. This template offers a structured addendum that integrates AI considerations into your existing framework controls without requiring a complete overhaul.
The template focuses on three risk categories identified by NIST: securing AI systems and data, defending against AI-enabled attacks, and using AI to enhance defensive capabilities. Integrate this addendum into your existing framework documentation, whether you're using NIST CSF, ISO 27001, or a custom control set.
Prerequisites
Before customizing this template, gather:
- Current cybersecurity framework documentation (asset inventory, risk register, control mappings)
- List of AI systems deployed or planned, including vendor solutions and internal models
- Data flow diagrams showing training data origins and model output destinations
- Current security awareness training materials
- Roles and responsibilities matrix for your security team
You'll also need stakeholder access. AI risk spans multiple functions, so input from data science teams, application owners using AI features, and privacy officers is essential.
The Template
AI RISK ADDENDUM TO [FRAMEWORK NAME]
Version 1.0 | Effective Date: [DATE]
SECTION 1: AI SYSTEM INVENTORY SUPPLEMENT
For each AI system identified, document:
System ID: [Unique identifier]
System Name: [Commercial name or internal designation]
Deployment Status: [Production | Pilot | Development | Planned]
Business Owner: [Department/individual]
Technical Owner: [Team/individual]
AI Type: [Generative | Predictive | Classification | Other]
Data Sources: [List datasets used for training/fine-tuning]
Data Sensitivity Classification: [Per existing data classification policy]
External Dependencies: [Third-party APIs, foundation models, cloud services]
User Base: [Internal only | Customer-facing | Partner-facing]
SECTION 2: AI-SPECIFIC CONTROL EXTENSIONS
Map to existing framework functions. For NIST CSF users, append to each function:
IDENTIFY (ID)
ID.AM-AI: Maintain inventory of AI systems, including model provenance and training data lineage
ID.RA-AI: Assess re-identification risk for datasets used in model training
ID.RA-AI-2: Evaluate data leakage potential from model outputs and embeddings
ID.GV-AI: Define governance for AI system procurement, development, and deployment
PROTECT (PR)
PR.AC-AI: Implement access controls for model weights, training data, and inference APIs
PR.DS-AI: Apply differential privacy techniques where re-identification risk exceeds [threshold per risk appetite]
PR.PT-AI: Secure machine learning infrastructure (training environments, model registries, deployment pipelines)
PR.AT-AI: Update security awareness training to address AI-enabled social engineering attacks
DETECT (DE)
DE.CM-AI: Monitor for anomalous model behavior indicating adversarial inputs or data poisoning
DE.CM-AI-2: Track model [performance](/glossary/performance) degradation that may signal security compromise
DE.DP-AI: Establish baseline false positive rates for AI-enhanced detection tools
RESPOND (RS)
RS.AN-AI: Include model forensics capability in incident response procedures
RS.MI-AI: Define rollback procedures for compromised AI systems
RECOVER (RC)
RC.RP-AI: Document model retraining requirements following security incidents
RC.IM-AI: Capture lessons learned specific to AI system compromises
SECTION 3: AI-ENABLED THREAT SCENARIOS
Update threat model and annual training to include:
Deepfake voice phishing: Adversary uses AI voice generation to impersonate executives or trusted contacts
Control response: [Map to existing anti-phishing controls + new verification procedures]
Adversarial inputs: Attacker crafts inputs designed to cause misclassification or data extraction
Control response: [Input validation, rate limiting, model monitoring]
Data poisoning: Attacker manipulates training data to compromise model integrity
Control response: [Training data validation, provenance tracking, model versioning]
Model theft: Adversary extracts model weights or training data through API queries
Control response: [API rate limiting, output filtering, query logging]
SECTION 4: AI-ENHANCED DEFENSIVE CAPABILITIES
Document where AI improves existing security functions:
Capability: [e.g., "Threat hunting in SIEM"]
AI Enhancement: [e.g., "ML-based anomaly detection for lateral movement"]
Explainability Requirement: [How analysts validate AI-flagged incidents]
False Positive Management: [Acceptable rate, feedback mechanism, human review threshold]
Skill Requirements: [New competencies needed per NICE Framework Security of AI competency area]
SECTION 5: DATA ASSET RE-EVALUATION
For each data asset used in AI systems:
Asset ID: [From existing asset inventory]
New AI Usage: [Training data | Inference input | Output destination]
Risk Classification Change: [If AI usage elevates sensitivity]
Dependency Mapping: [Which AI systems depend on this asset]
Backup/Recovery Priority: [Adjust based on AI system criticality]
SECTION 6: THIRD-PARTY AI RISK
For vendor-provided AI systems or foundation models:
Vendor Name: [Organization]
AI Service/Product: [Specific offering]
Data Sharing Scope: [What data leaves your environment]
Model Transparency: [Black box | Limited documentation | Full transparency]
Security Attestations: [SOC 2, ISO certifications, AI-specific audits]
Contractual Controls: [Data usage restrictions, model update notification, incident response SLAs]
Exit Strategy: [How you migrate off this AI system if needed]
Customization Instructions
Begin with Section 1. Document known systems now and establish a quarterly review to capture new deployments. Many organizations discover shadow AI by directly asking business units.
In Section 2, map controls to your framework. If using ISO 27001, cross-reference to Annex A controls instead of NIST CSF functions. Extend existing controls rather than creating parallel requirements.
For Section 3, prioritize threat scenarios based on your attack surface. Customer-facing AI systems need deepfake and adversarial input scenarios. Internal AI tools may face greater data poisoning risk if training data comes from user-submitted content.
Section 4 requires an honest assessment of your team's capabilities. The NICE Framework now includes Security of AI as a competency area. If deploying ML-based detection tools, identify which analysts need training in interpreting model outputs and recognizing algorithmic bias.
In Section 5, challenge existing data classifications. A dataset marked "internal use" may need reclassification if it trains a model generating customer-facing outputs. Data leakage from model training creates re-identification risks not previously considered.
Section 6 applies to every SaaS product with an "AI-powered" feature. Your vendor risk assessment template needs questions about model training data sources, whether your data trains shared models, and how the vendor secures model weights.
Validation Steps
Before finalizing this addendum:
Cross-reference with privacy documentation. Your privacy officer should review Section 5 data asset changes and Section 2 re-identification risk assessments. AI creates privacy risks that traditional cybersecurity controls don't fully address.
Test with a real incident scenario. Walk through your incident response plan using an AI-specific scenario from Section 3. You'll likely find gaps in forensic capabilities and escalation procedures.
Validate AI inventory completeness. Survey application owners directly. Ask: "Do any of your systems use machine learning, natural language processing, or predictive analytics?" Don't rely on the term "AI" alone.
Review with your audit function. If subject to SOC 2 or ISO 27001 audits, confirm that your AI control extensions map to auditable criteria. Auditors increasingly ask about AI governance, and "we're working on it" won't satisfy compliance requirements.
Assess skill gaps. Compare Section 4 requirements against your team's current competencies. If using AI for threat detection but no one can explain how the model reaches its conclusions, you've identified a critical gap.
This addendum isn't static. NIST's AI cybersecurity program will release updated guidance as the threat landscape evolves. Schedule a quarterly review to incorporate new AI deployments, emerging attack techniques, and framework updates. Your existing change management process should trigger addendum updates whenever a business unit procures or develops an AI system.
