Article 15 requires high-risk AI systems to be resilient against unauthorised exploitation of vulnerabilities. This section covers traditional cybersecurity foundations, AI-specific threats including the OWASP LLM Top 10, cross-regulatory mapping for NIS2, CRA, and DORA, and supply chain security.
Cybersecurity for high-risk AI systems under the EU AI Act extends traditional security requirements to address thirteen AI-specific threat categories including prompt injection, training data poisoning, model extraction, and adversarial evasion. Article 15 requires resilience against unauthorised exploitation, documented in AISDP Module 9. The cybersecurity obligation intersects with NIS2 for essential entities, the Cyber Resilience Act for software products (with a deemed compliance pathway under Article 15(5)), and DORA for financial sector organisations. Multi-regime incidents can trigger simultaneous reporting obligations with timelines ranging from 4 hours (DORA) to 15 days (AI Act). A zero trust architecture provides the foundation, with microsegmentation, identity-based access, and continuous verification. DevSecOps embeds security into the CI/CD pipeline through static analysis, dependency scanning, container scanning, and dynamic testing. AI-specific incident response requires model state preservation and multi-regime reporting coordination. Supply chain security extends to model components, training data sources, and third-party AI services.
Article 15(4) and (5) require high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, results, or performance by exploiting system vulnerabilities.
Article 15(4) and (5) require high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, results, or performance by exploiting system vulnerabilities. This encompasses protection against adversarial attacks, data poisoning, model extraction, and other AI-specific threats, in addition to traditional cybersecurity requirements applying to any software system.
AISDP Module 9 must document the cybersecurity measures in place. A competent authority or notified body reviewing Module 9 expects a threat model specific to the AI system, evidence of security testing including penetration tests and adversarial testing, a description of the security architecture, an incident response plan, and evidence of ongoing security monitoring.
NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across energy, transport, health, digital infrastructure, and other sectors.
NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across energy, transport, health, digital infrastructure, and other sectors. NIS2 focuses on network and information system security broadly; Article 15 focuses on AI system resilience specifically, including AI-specific threats that NIS2 does not address. The AI system's controls should be built on top of the NIS2 framework, adding AI-specific threat modelling and testing as extensions. NIS2 supply chain controls are typically satisfied by the AI-specific controls because model provenance verification and sentinel testing are stricter than NIS2 requires.
The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to AI systems delivered as software products. Article 15(5) of the AI Act provides a deemed compliance mechanism: systems meeting CRA essential requirements for cybersecurity are deemed to comply with the AI Act's Article 15 requirements where those requirements overlap. This creates a practical efficiency but requires careful scope mapping to identify which requirements overlap and which remain CRA-only or AI Act-only. The CRA requires Software Bills of Materials (SBOMs) documenting all software components, an obligation that aligns with for AI-specific dependencies.
Before addressing AI-specific threats, the system must satisfy foundational cybersecurity requirements.
Before addressing AI-specific threats, the system must satisfy foundational cybersecurity requirements. Network security requires deploying within a dedicated Virtual Private Cloud with segmentation isolating the AI system, restricted traffic flows, web application firewalls, and DDoS protection. Authentication and access control requires multi-factor authentication for all operator and administrative access, role-based access control enforcing least privilege, mutual TLS for service-to-service authentication, and auditable access to model artefacts and training data.
Encryption requires AES-256 or equivalent at rest and TLS 1.3 in transit, with dedicated key management including rotation and separation of duties. Vulnerability management requires continuous scanning with documented remediation timelines: typically 72 hours for critical and 30 days for high-severity findings. Patch management follows a documented schedule with emergency processes for zero-day vulnerabilities.
AI systems face thirteen threat categories beyond traditional cybersecurity, including the OWASP LLM Top 10.
AI systems face thirteen threat categories beyond traditional cybersecurity, including the OWASP LLM Top 10. Each threat requires specific controls documented in Module 9.
Prompt injection (OWASP LLM01) manipulates LLM behaviour through crafted inputs. Controls include input sanitisation, prompt/data separation, and output monitoring for compliance violations. Insecure output handling (LLM02) occurs when model outputs are trusted without validation. Controls include output filtering, content classification, and format enforcement. Training data poisoning (LLM03) introduces malicious data during training. Controls include data provenance verification, anomaly detection on training data, and holdout validation.
DevSecOps embeds security into the CI/CD pipeline rather than treating it as a separate review stage.
DevSecOps embeds security into the CI/CD pipeline rather than treating it as a separate review stage. Static Application Security Testing runs on every code commit, identifying vulnerabilities in application code. Software Composition Analysis scans dependencies for known vulnerabilities, producing alerts for critical findings. Container image scanning checks base images and installed packages against vulnerability databases.
AI-specific incidents require response procedures that extend beyond traditional cybersecurity incident response.
AI-specific incidents require response procedures that extend beyond traditional cybersecurity incident response. A model compromise, whether through data poisoning, adversarial manipulation, or unauthorised model replacement, demands immediate evidence preservation of the model state, inference logs, and data pipeline state before any remediation action.
The incident response plan must address classification of whether the incident is operational, affecting infrastructure, or model-related, affecting AI behaviour, or both, because the response path and regulatory implications differ. For model-related incidents, the response must determine whether the model's outputs during the compromise period were affected, how many individuals were impacted, and whether the incident constitutes a serious incident under Article 73.
The AI supply chain extends beyond traditional software dependencies to include model components, training data sources, and third-party AI services.
The AI supply chain extends beyond traditional software dependencies to include model components, training data sources, and third-party AI services. Each layer introduces risks that the organisation must assess, monitor, and mitigate.
Software dependency management requires generating and maintaining a Software Bill of Materials listing every component with its version, licence, and known vulnerabilities. Dependency scanning runs continuously, with alerts for critical findings. For AI-specific dependencies, this extends to ML framework versions, CUDA libraries, and specialised numerical computing libraries where vulnerabilities can affect model behaviour.
Partially. Article 15(5) provides deemed compliance for overlapping requirements, but the AI Act includes AI-specific threats (adversarial attacks, data poisoning, model extraction) that the CRA does not address. Careful scope mapping is needed to identify which requirements overlap and which remain regime-specific.
Know your dependencies through a software, model, and data inventory. Use open-source scanning tools (Trivy, Semgrep) for automated vulnerability detection. Implement basic zero trust principles. Document a threat model and incident response plan. Test annually.
Prompt injection manipulates LLM behaviour through crafted inputs that override the system prompt, causing the model to ignore instructions, reveal confidential information, or produce harmful outputs. Controls include input sanitisation, prompt/data separation, and output monitoring.
High-risk AI systems must be resilient against adversarial attacks, data poisoning, model extraction, and other AI-specific threats. Module 9 documents threat model, security testing evidence, architecture, incident response plan, and ongoing monitoring.
NIS2 covers network security broadly; AI Act adds AI-specific threats. CRA provides deemed compliance for overlapping requirements via Article 15(5). DORA adds financial sector obligations. Multi-regime incidents trigger simultaneous reporting with different timelines.
Thirteen categories including the OWASP LLM Top 10: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, model extraction, and adversarial evasion.
An AI system incident can trigger AI Act (2-15 days), NIS2 (24h early warning, 72h notification), DORA (4h initial), and GDPR (72h) reporting simultaneously. Article 73(9) simplifies where equivalent sector-specific reporting exists.
Every service component authenticates independently, identity-based access replaces network trust, microsegmentation prevents lateral movement, and continuous verification re-evaluates access based on context and anomaly detection.
The cybersecurity obligation does not exist in isolation. It intersects with the NIS2 Directive for operators of essential and important entities, the Cyber Resilience Act for products with digital elements, and DORA for financial sector entities. Organisations subject to multiple cybersecurity regimes must map the overlapping requirements and ensure Module 9 addresses the AI Act's specific expectations without duplicating effort.
DORA (Regulation (EU) 2022/2554) creates additional obligations for financial sector organisations, including ICT risk management, incident reporting with a 4-hour initial notification, resilience testing, and third-party risk management for model providers. A cybersecurity incident affecting a high-risk AI system can trigger reporting obligations under multiple regimes simultaneously. Article 73(9) of the AI Act provides simplification: where an equivalent reporting obligation exists under sector-specific legislation, AI Act reporting is limited to fundamental rights infringements.
A zero trust architecture assumes no implicit trust based on network location. Every service component authenticates and authorises independently. Identity-based access using SPIFFE/SPIRE or cloud-native workload identity replaces network-based trust. Microsegmentation restricts lateral movement at the workload level: even if an attacker compromises the feature engineering service, they should not reach the model artefact store or training data. Continuous verification re-evaluates access decisions based on context including security posture, resource sensitivity, and request pattern anomaly scores.
API security for model inference endpoints requires authentication on every request, per-consumer rate limiting calibrated against model extraction and denial-of-service thresholds, strict input validation against schemas, output filtering for confidence thresholds and PII redaction, API versioning preventing consumers from unknowingly receiving outputs from different model versions, and comprehensive request-response logging for forensic analysis.
Model denial of service (LLM04) exploits inference resource consumption. Controls include request rate limiting, input size constraints, and inference timeout enforcement. Supply chain vulnerabilities (LLM05) arise from compromised dependencies, including model components and data sources. Controls include SBOM generation, dependency scanning, and model provenance verification. Sensitive information disclosure (LLM06) occurs when the model reveals training data or confidential information. Controls include output filtering, membership inference testing, and data extraction testing.
Additional threats include model extraction where attackers reconstruct the model through systematic querying, adversarial evasion where crafted inputs cause misclassification, data exfiltration through the inference API, and privilege escalation through agentic AI tool access. For each threat, the Technical SME documents the threat description, the likelihood and impact assessment, the controls in place, the residual risk, and the monitoring approach.
The cybersecurity testing programme should include penetration testing of the infrastructure and application, adversarial testing of the model against known attack vectors, data poisoning detection on training pipelines, model extraction resistance testing, and prompt injection testing for LLM systems. Testing results are retained as Module 9 evidence.
Dynamic Application Security Testing runs against the deployed application in the staging environment, testing for runtime vulnerabilities that static analysis cannot detect. Secret scanning prevents credentials from entering the code repository. Infrastructure-as-code security scanning validates Terraform, Kubernetes manifests, and cloud configurations against security benchmarks.
Security monitoring integrates with the organisation's SIEM platform. AI system security events including authentication failures, rate limit breaches, anomalous inference patterns, and model access attempts feed into the centralised security monitoring infrastructure. Correlation rules detect patterns that individual events do not reveal: a burst of inference requests from a single consumer followed by a new consumer submitting similar requests may indicate a model extraction campaign.
Cloud Security Posture Management continuously assesses the cloud infrastructure against security benchmarks, detecting misconfigurations such as publicly accessible storage buckets, overly permissive IAM policies, and unencrypted data stores. For AI systems, CSPM should additionally monitor model artefact storage access patterns, training data storage configurations, and inference endpoint exposure.
Multi-regime incident reporting may be triggered simultaneously. An incident affecting a high-risk AI system in a NIS2-regulated sector triggers AI Act reporting to the market surveillance authority, NIS2 reporting to the national CSIRT with 24-hour early warning, and potentially GDPR breach notification within 72 hours. DORA adds a 4-hour initial notification for financial sector entities. The incident response plan must map each incident type to the applicable reporting obligations and ensure the response team can meet all deadlines.
Evidence preservation during an AI incident requires capturing the current model version and configuration, inference logs for the incident period, data pipeline state, monitoring metrics, and system configuration. Article 73(6) prohibits altering the system before informing authorities. Conformity assessment may need to be repeated if the incident reveals that the system's compliance posture has been compromised.
Model supply chain security covers pre-trained models, fine-tuned models, and model components sourced from third parties. Organisations should verify model provenance, assess the provider's security practices, and implement sentinel testing to detect unauthorised changes. For GPAI models accessed through APIs, the organisation cannot control the model's security but can monitor for behavioural changes and contractually require the provider to notify of security incidents.
Data supply chain security covers training data from external sources. Organisations should verify data provenance, assess data quality and integrity, and monitor for poisoning indicators. Contractual controls should require data providers to notify of security incidents affecting the data supply.
For organisations at earlier maturity levels, supply chain security can begin with a dependency inventory spreadsheet listing all software, model, and data dependencies with their sources and update mechanisms. Vulnerability scanning using open-source tools such as Trivy and Semgrep provides automated detection at zero licence cost. The minimum viable approach is knowing what dependencies exist and monitoring them for known vulnerabilities; the advanced approach adds continuous monitoring, automated patching, and contractual security requirements for all suppliers.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Technical Documentation Contents
Record-Keeping
Risk Management System
