Cybersecurity for AI Systems: EU AI Act, NIS2, CRA, and DORA

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.

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.

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 supply chain security for AI-specific dependencies.

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.

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.

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.

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.

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.

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.

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.

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.

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. may need to be repeated if the incident reveals that the system's compliance posture has been compromised.

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.

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.