The CISO's EU AI Act Compliance Guide
CISOs and EU AI Act: AI inventory, Article 15 cybersecurity, Article 73 incident reporting, NIS2 overlap, board reporting. High-risk deadline: Dec 2027.
Your security program already owns risk registers, incident response procedures, and audit logs. The EU AI Act — Regulation (EU) 2024/1689 — extends that same discipline into the AI systems your organisation builds or operates. For a CISO, this is not a legal novelty; it is a new asset class with familiar controls. The question is which obligations land on your desk, which you share with the DPO and legal, and where you need to build something new.
Build the AI Inventory First
Every compliance programme starts with knowing what you have. Under the EU AI Act that means an AI inventory: a structured register of every AI system your organisation develops (as a provider under Article 16) or deploys on behalf of others in a professional context (as a deployer under Article 26). Most large organisations are deployers of third-party tools — HR screening software, fraud-scoring services, customer-triage models — rather than providers building systems from scratch. A minority are both.
Shadow AI is the inventory problem that keeps CISOs up at night. Employees adopting SaaS tools with embedded AI features, development teams integrating third-party model APIs, business units procuring tools outside the IT procurement process — each of these can create an undisclosed high-risk system inside your organisation's operational perimeter. Discovery requires active scanning: reviewing software procurement records, querying IT asset management, auditing API keys in version-control repositories, and interviewing business owners.
Build the register before you classify. Without it, every subsequent step is guesswork.
Classify Against Article 5, Article 6, and Annex III
Once you have an inventory, the Act's classification logic is binary at each step.
Article 5 — prohibited systems. If a system falls here, it must be removed regardless of how it was acquired or how useful it has been. The prohibitions have applied since 2 February 2025. The categories relevant to most organisations: real-time remote biometric identification in publicly accessible spaces (Article 5(1)(h), narrow law-enforcement exceptions only); emotion recognition in the workplace or education settings (Article 5(1)(f)); AI-based social-scoring systems (Article 5(1)(c)); subliminal manipulation (Article 5(1)(a)). If you find a tool doing any of these, stop it. Escalate to legal. Document the removal.
Article 6 + Annex III — high-risk systems. Article 6(2) creates a presumption: any system in one of Annex III's eight categories is high-risk. Those categories include biometric identification and categorisation (Annex III, point 1), critical infrastructure safety components (point 2), employment and worker management tools — recruitment screening, task allocation, performance and termination monitoring (point 4), access to essential services including creditworthiness scoring and health/life-insurance risk pricing (point 5), and others. Review each inventoried system against all eight points.
The Article 6(3) filter. A system that falls into an Annex III category is not automatically high-risk if it poses no significant risk of harm to health, safety, or fundamental rights. One condition suffices: narrow procedural task, improvement of a previously completed human activity, no replacement of human assessment, or preparatory work without direct effect on individuals. Any system that profiles natural persons remains high-risk regardless. Providers claiming the filter must document the assessment and register the finding (Article 49 — registration in the EU database established under Article 71).
Article 50 — limited-risk transparency. Chatbots, synthetic-content generators, emotion-recognition tools outside the Article 5 prohibition, and AI-generated content must meet disclosure duties. These apply from 2 August 2026.
The Security-Relevant Obligations
For a CISO, the high-risk stack is not an abstract compliance checklist. Several requirements map directly to security controls you already own or should own.
Article 15 — Accuracy, Robustness, and Cybersecurity
Article 15 is the obligation with the most direct security content. High-risk AI systems must be resilient against errors, faults, and adversarial attacks. The Act names three attack vectors the CISO owns: data poisoning (corruption of training sets — requires provenance tracking, data-quality audits, and integrity verification); model poisoning (corruption of trained weights — requires access controls over model artefacts and version signing); and adversarial inputs (crafted inference-time manipulation — requires input validation and anomaly detection on inference requests).
Article 15 also covers availability. A high-risk system used in healthcare triage, emergency dispatch, or infrastructure management must fail safely, with fallback procedures that preserve human oversight when the AI is degraded or unavailable.
Article 12 — Logging and Record-Keeping
Article 12 requires high-risk AI systems to automatically log events during operation, to the extent the provider has control over such logging. Providers must design logging in from the start: what the system ingested, what output it produced, which version of the model was active, and when. Logs must be sufficient to enable post-hoc monitoring, incident investigation, and audit by competent authorities.
Deployers have a parallel obligation under Article 26: retain logs of operation for at least six months. If you are operating a third-party high-risk AI system, your SIEM or log-management infrastructure needs to capture and retain those outputs for the statutory minimum.
Technical documentation covering logging architecture belongs in the Article 11 / Annex IV technical documentation package.
Article 72 — Post-Market Monitoring
Article 72 places a continuous monitoring obligation on providers: collect and analyse operational data to detect unexpected risks or performance degradation not found during pre-market risk assessment (Article 9). The monitoring plan — defining metrics, review frequency, and remediation thresholds — is part of the Article 11 technical documentation and feeds back into the risk management file when new risks emerge.
Article 73 — Serious-Incident Reporting
When a high-risk AI system causes — or contributes to — a serious incident, providers must report to the national market-surveillance authority where the incident occurred. The statutory timelines are tight:
- 15 days from becoming aware of a serious incident (Article 73(2)).
- 2 days for widespread infringement or serious and irreversible disruption of critical infrastructure (Article 73(3)).
- 10 days where a person has died (Article 73(4)).
The Act permits an incomplete initial report where full information is not yet available, with the completed report to follow (Article 73(5)). A "serious incident" is defined in Article 3(49).
This maps directly onto your existing incident-response process. The CISO function typically owns incident detection, classification, and notification; Article 73 adds a regulatory-notification branch alongside data-breach notification under GDPR Article 33 and cyber-incident notification under NIS2. These timelines run concurrently — the same event can trigger all three. Build a unified notification workflow before an incident forces you to improvise one.
Overlap with NIS2, ISO/IEC 27001, and ISO/IEC 42001
The EU AI Act layers on top of NIS2 (Directive (EU) 2022/2555), which mandates cybersecurity risk management and incident reporting for essential and important entities. AI systems embedded in critical infrastructure sit at the intersection of both regimes.
NIS2's Article 21 security measures — access control, incident handling, supply-chain security, cryptography — are substantially aligned with what Article 15 requires for AI system cybersecurity. Map existing ISO/IEC 27001 controls (A.5.23, A.8.8, A.8.25) against Article 15 before building anything new; the overlap is significant.
ISO/IEC 42001, the 2023 AI management system standard, is the closest structural parallel to the Act's governance architecture. Article 9 (risk management), Article 17 (quality management system), and Article 72 (post-market monitoring) map to ISO/IEC 42001 clauses 6, 8, and 9 respectively. If your organisation is already on the ISO/IEC 42001 path, use that scope statement and risk register as the foundation for AI Act documentation — they share the same skeleton.
CISO Owns vs. Shares
Not every EU AI Act obligation is a security function. The CISO clearly owns: AI inventory and shadow-AI discovery; Article 15 cybersecurity and robustness controls; Article 12 logging architecture and retention; Article 72 post-market monitoring infrastructure; and Article 73 incident notification. Article 9 risk management is co-owned with product — the CISO owns the technical risk section, legal owns the governance wrapper. Article 6 classification is legal-led but requires the CISO's technical read on what each system actually does.
The DPO owns the fundamental-rights dimension — GDPR intersection and Article 27 FRIA for qualifying deployers. Legal validates interpretation. The CISO's zone is the technical and operational layer: what the systems do, what they log, how they fail, and who gets notified when something goes wrong.
Deadlines, Penalties, and Board Reporting
Revised timeline. Under the Digital Omnibus (political agreement reached between Parliament and Council in May 2026), high-risk Annex III stand-alone systems must comply by 2 December 2027; high-risk AI embedded in Annex I products by 2 August 2028. The original 2 August 2026 date now applies only to general provisions and Article 50 limited-risk transparency. Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025.
Penalty exposure. Article 99(4) sets the ceiling for most high-risk obligation breaches at €15,000,000 or 3% of total worldwide annual turnover — whichever is higher. Article 5 prohibition breaches reach €35,000,000 or 7% (Article 99(3)). Supplying incorrect information to authorities: €7,500,000 or 1% (Article 99(5)). For SMEs and start-ups, Article 99(6) caps fines at the lower of the two figures.
Board reporting. CISOs already present cyber risk to boards. The minimum AI Act board view covers: inventory status; high-risk system count by Annex III category; gaps in Article 9 documentation and Article 43 conformity-assessment readiness; incident posture; and the Article 99(4) penalty ceiling. A Compliance Health Score — the proportion of inventoried systems with complete documentation — gives directors a trend-line rather than a snapshot.
How Confir Helps
Confir is EU AI Act compliance software, built for teams that cannot afford a six-month consultancy engagement. The classification and scoping logic is deterministic and rule-based — same intake produces the same finding, every time, with the rule that fired visible in plain language.
For a CISO-led compliance programme, Confir addresses three pressure points:
Inventory and classification. Register each AI system, answer plain-English intake questions about intended use and Annex III fit, and the engine derives the risk tier (Unacceptable / High / Limited / Minimal) and your role (Provider / Deployer / Importer / Distributor) from Article 5, Article 6, and Annex III logic. Shadow-AI entries discovered through discovery exercises can be logged immediately.
Audit log. Every classification decision, assessment step, and document change is recorded in an immutable audit log. When the competent authority asks for evidence of your Article 9 process or your Article 6(3) self-assessment, the log is the answer.
Health score for board reporting. Confir surfaces an organisation-wide Compliance Health Score — the proportion of registered systems with complete, current documentation across the four compliance areas (AIRC, AITR, AITO, AIGM). Present it at board level; it translates the Article 99 risk into a single indicator without requiring directors to read the Regulation.
Pricing starts at €600 per year. Self-serve, EU-hosted, no consultants required.
Frequently Asked Questions
What does the EU AI Act actually require a CISO to do?
The CISO's core obligations are technical: build and maintain the AI inventory, run or commission the Article 9 risk management system for high-risk systems you provide, design logging under Article 12, ensure Article 15 cybersecurity and robustness controls (including data-poisoning and adversarial-input defences), operate the Article 72 post-market monitoring programme, and own the Article 73 incident-reporting process. Classification (Article 6) is a shared function with legal; fundamental-rights assessment (Article 27 FRIA) is DPO-led. The board reporting and risk register are yours.
How does Article 73 incident reporting fit into an existing security-incident process?
Article 73 runs alongside, not instead of, GDPR Article 33 breach notification and NIS2 incident reporting. All three timelines can be triggered by the same event — for example, a data poisoning attack that causes a high-risk AI system to produce harmful outputs. The Article 73 timeline for providers is 15 days from awareness (or 2 days for critical-infrastructure disruption, 10 days where a person has died). Build a triage step into your existing IR playbook: does this incident involve a high-risk AI system? If yes, route to the Article 73 notification branch in parallel with GDPR and NIS2 tracks.
What is the difference between the Article 9 risk management system and a standard IT risk assessment?
Article 9's risk management system is lifecycle-scoped and continuous — not a point-in-time audit. It requires identification and analysis of foreseeable risks from intended use and reasonably foreseeable misuse, estimation of severity and probability, mitigation with documented residual-risk evaluation, and ongoing monitoring for new risks throughout the system's operational life. The output is a live risk management file that must be updated as the system evolves. Your existing ISO/IEC 27001 risk-assessment methodology is structurally compatible but typically scoped to information assets; Article 9 extends that scope to model behaviour, output harms, and affected individuals.
What counts as a "serious incident" for Article 73 reporting purposes?
"Serious incident" is defined in Article 3(49) of the Regulation. In short: an incident that directly or indirectly causes (or is reasonably suspected to have caused) death or serious harm to health, a serious and irreversible disruption to critical infrastructure, infringement of obligations under EU law protecting fundamental rights, or serious property damage. Minor performance degradation or a contained model error does not cross the threshold. The judgment call is whether the harm reached the statutory severity — document your reasoning either way.
Does the EU AI Act change how CISOs handle third-party AI tools (deployer role)?
Yes. As a deployer under Article 26, you must use the system according to the provider's instructions, implement the human-oversight measures defined in the provider's technical documentation, monitor performance in operation, retain logs for at least six months (Article 26), and report serious incidents or risks you discover to the provider (and the competent authority where required). Due diligence on procurement changes: before deploying a third-party AI system that could be high-risk, verify that the provider has completed conformity assessment (Article 43) and can supply the Article 11 technical documentation. If the provider cannot, you inherit a compliance risk you did not build.
Related guides
- Article 5 biometric restrictions
- high-risk system classification framework
- 2026 compliance obligations checklist
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →