The European Central Bank (ECB) has reached out to CEOs of Europe's leading banks, requesting their AI-related cybersecurity strategies. This isn't just a survey; it's a clear signal that supervisory expectations are evolving. Regulators now want proof that AI is being managed as a cyber threat vector.
If you're waiting for detailed regulatory guidance before building an AI cyber risk program, you're already behind. Here's how to construct one that meets emerging supervisory expectations.
The Problem: AI Creates Attack Surface, Not Just Efficiency
Your organization likely uses AI for fraud detection, customer service automation, or credit decisioning. Each implementation introduces new cyber risks: adversarial attacks on models, data poisoning, prompt injection vulnerabilities, and supply chain risks from third-party AI services.
The ECB's inquiry matters because it sets a precedent. When a central bank demands CEO-level accountability on a risk category, other regulators tend to follow. You need a program that addresses AI-specific cyber threats within your existing risk management framework, not a separate AI governance initiative in a different department.
What You Need Before Starting
Inventory of AI systems in production and development
You can't manage risks in systems you don't know exist. Your inventory must include:
- Model type and purpose
- Data sources and sensitivity classification
- Third-party components or APIs
- User access patterns
- Integration points with critical systems
Defined risk appetite for AI-related cyber incidents
Your board should articulate acceptable risk levels for AI system compromise. This isn't theoretical. If an attacker manipulates your fraud detection model to approve fraudulent transactions, what's your tolerance for false negatives before you shut down the system?
Assigned ownership
AI cyber risk sits at the intersection of information security, model risk management, and third-party risk. Designate a single owner, typically your CISO or Chief Risk Officer, with clear authority to enforce controls across these domains.
Baseline security controls
Your existing controls from ISO/IEC 27001, NIST Cybersecurity Framework 2.0, or similar frameworks provide the foundation. Don't build from scratch.
Step-by-Step Implementation
Map AI-specific threats to your existing control framework
Start with NIST Cybersecurity Framework 2.0 or ISO/IEC 27002 controls you already maintain. Extend them to cover AI-specific scenarios:
Access control (ISO/IEC 27002 Control 5.15): Apply the Principle of Least Privilege to model training data, inference APIs, and model weights. Implement Just-in-Time Access for data scientists accessing production model environments.
Secure development (ISO/IEC 27002 Control 8.25): Extend your secure SDLC to include model development. Require code review for training scripts, versioning for datasets, and validation of model outputs before production deployment.
Vendor management (ISO/IEC 27002 Control 5.19): For third-party AI services (cloud-hosted models, pre-trained APIs), document data flows, contractual liability for model failures, and incident notification requirements.
Implement model-specific monitoring
Your SIEM likely won't catch adversarial attacks or model drift. Add monitoring for:
- Unusual inference patterns (volume spikes, out-of-distribution queries)
- Model performance degradation that could indicate data poisoning
- Access to model artifacts (weights, training data, hyperparameters)
- API abuse patterns in externally-facing AI services
Configure alerts when model accuracy drops below defined thresholds or when query patterns deviate from baseline behavior. This requires collaboration between your security operations team and data science team.
Establish AI incident response procedures
Extend your Computer Security Incident Response Team playbook to include AI-specific scenarios:
Model compromise: If an attacker gains access to model weights or training data, your response must include model retraining, validation of outputs since compromise, and notification to affected parties if decisions were made on manipulated predictions.
Adversarial attack detection: Define thresholds for rolling back to a previous model version versus taking the system offline entirely during investigation.
Data poisoning: Document procedures for identifying corrupted training data, revalidating historical model versions, and assessing impact on past decisions.
Include escalation paths to legal and compliance teams. If your AI system processes personal data under the General Data Protection Regulation, model compromise may trigger the 72-Hour Notification Requirement.
Document your program for supervisory review
The ECB's request to CEOs indicates regulators want board-level accountability. Prepare documentation that demonstrates:
- How AI cyber risks are identified and assessed
- Control mapping to recognized frameworks (ISO/IEC 27001, NIST AI Risk Management Framework)
- Metrics showing control effectiveness
- Incident response testing results specific to AI scenarios
Your documentation should show AI cyber risk management as integrated into enterprise risk management, not as a standalone initiative.
Validation: How to Verify It Works
Test adversarial scenarios in non-production environments
Work with your red team or external penetration testers to attempt:
- Model inversion attacks to extract training data
- Adversarial examples designed to cause misclassification
- Prompt injection attacks on language models
- API abuse to exfiltrate model behavior
Document detection time, response effectiveness, and gaps in monitoring coverage.
Conduct tabletop exercises
Run scenario-based exercises with your incident response team, data science team, and legal counsel. Scenarios should include model compromise, data poisoning detected post-deployment, and third-party AI service outages affecting critical business processes.
Review access logs
Verify that access to model artifacts follows the Principle of Least Privilege. Check for dormant accounts with model training permissions, overly broad API keys, or shared credentials in model deployment pipelines.
Measure control coverage
Calculate the percentage of AI systems covered by each control category (access management, monitoring, incident response procedures). Gaps indicate where to focus remediation efforts.
Maintenance and Ongoing Tasks
Quarterly AI system inventory updates
New AI implementations appear faster than traditional IT systems. Require project teams to register AI systems in your configuration management database before production deployment.
Monthly monitoring rule validation
Review detection rules for model-specific threats. As your AI systems evolve, baseline behaviors change. Recalibrate thresholds to reduce false positives while maintaining detection sensitivity.
Annual control testing
Include AI-specific controls in your internal audit program. Test effectiveness of access controls on training data, validation of model output monitoring, and incident response procedure adequacy.
Regulatory tracking
Monitor developments in the EU AI Act, NIST AI Risk Management Framework updates, and guidance from your primary regulators. When the ECB formalizes supervisory expectations beyond CEO letters, you'll need to demonstrate program maturity, not scramble to build one.
The ECB's inquiry to bank CEOs signals that AI cyber risk management is transitioning from emerging concern to supervisory expectation. Build your program now using existing control frameworks as scaffolding. When regulators formalize requirements, you'll have evidence of a functioning program, not just policy documents.
