EU AI Act for the CISO
Less of this is yours than the org chart suggests, and the part that is yours is not covered by your ISMS. Article 15 names five attack classes that sit outside the classic confidentiality-integrity-availability frame, and Article 73 sets an incident clock that will not fit your existing runbook.
What lands on you, and what does not
Ownership boundaries are the most useful thing to settle early. Expert analysis: the Regulation names organisations, not job titles.
| Obligation | Yours? | Note |
|---|---|---|
| Art. 15 cybersecurity of the AI system | Yes: squarely | Accuracy and robustness sit with engineering; you own resilience against attack |
| Art. 12 logging capability | Shared | Engineering builds it; you specify what must be recorded and retained |
| Art. 19 / 26(6) six-month log retention | Yes | Usually a storage and access-control problem, not a policy one |
| Art. 73 serious incident reporting | Shared: you run it | Legal decides reportability; you preserve state and produce the facts |
| Art. 9 risk management | No | Risk to people, not to the organisation. Contribute, do not own |
| Art. 43 conformity assessment | No | Product and quality function |
| Art. 50 transparency | No | Product surface |
Where this usually goes next
Three situations account for most people reading this page. Each has a different answer.
A deal is blocked on an AI questionnaire
Legal will not sign until you can evidence how AI is governed. HumanAudit’s AI Trust Package is a fixed $3,500 over five business days: a public trust page, a pre-filled SIG Lite / CAIQ / SSPA Section K questionnaire bank, and your AI inventory and classification.
You need ISO/IEC 42001 documentation
23 clause-mapped AIMS documents with all 38 Annex A controls pre-populated, editable and yours to keep, from $199. Or score your gaps first: 18 questions, free, no signup to begin.
You are not sure what reaches you
Twenty minutes with the founder. No prep, no deck, straight to the person accountable for the work. If none of this applies to you, you get told that on the call.
This reference is published by HumanAudit Inc. Not a law firm, not an accredited certification body, not a registered auditor. We build documentation, your counsel interprets it, and an accredited body of your choosing certifies you. How this is funded →
Your ISMS does not cover the five named attacks
Article 15 requires technical solutions addressing AI-specific vulnerabilities, and it names five: data poisoning, model poisoning, model evasion, confidentiality attacks, and model flaws.
A mature ISO/IEC 27001 programme addresses roughly one of those, and only partially. Membership inference, model inversion, extraction attacks and adversarial examples are not in most control sets, do not appear in most vulnerability scanners, and are not what your pen-test vendor tests unless you ask.
Because they are named in the Regulation, they are the baseline threat model. An assessor comparing your security documentation against Article 15 will look for each of the five. “We hold ISO 27001” is not an answer to any of them. Where the ISMS stops →
The Article 73 clock breaks the standard runbook
Serious incidents must be reported within 15 days, 10 days where a death may have been caused, and 2 days for a widespread infringement or serious and irreversible disruption of critical infrastructure. Article 73(5) lets you file an incomplete initial report.
The conflict is Article 73(6): you must not alter the system in a way that may affect subsequent evaluation of the causes before informing authorities. Your runbook almost certainly says mitigate immediately.
Both are satisfiable, take out of service, preserve state and logs, notify, then remediate, but only if the runbook says so before the incident. And note the third limb of the Article 3(49) definition: an infringement of Union law protecting fundamental rights is a serious incident with no physical harm required. A discriminatory outcome may be reportable. Article 73 →
Your first 30 days
- Get the AI inventory, or start it. You cannot threat-model systems you cannot enumerate.
- Run the five named attacks against your top three AI systems. Even a desk exercise tells you whether anyone has thought about them.
- Establish who controls which logs for each AI system, provider side and deployer side, and whether six months is actually retained.
- Add an AI branch to the incident runbook covering the preserve-then-remediate sequence and the 2/10/15-day clocks.
- Map NIS2, DORA and Article 73 where they overlap. Different triggers, different deadlines, possibly different authorities.
Questions worth asking
- Which of our AI systems are high-risk, and who decided?
- What is our declared accuracy figure, and who is measuring it in production?
- Which party retains logs for each system, and for how long?
- Who signs a serious incident report at 4pm on a Friday?
Status labels on this page
Verified fact: Article references, dates and penalty tiers cited above, checked against the consolidated Regulation and the Commission's AI Act Service Desk.
Expert analysis: The ownership allocation, the failure modes, and the 30-day sequence — all our practice rather than the text.
Unsettled: Harmonised standards remain in development, and the Commission's Annex III guidelines are in draft. Both affect how these obligations will be evidenced.
Security evidence is management-system evidence
The artefacts Article 15 and Article 12 need, threat model, control set, log policy, incident procedure, are the same artefacts an ISO/IEC 42001 audit asks for. Build once.
Start with the inventory
Every role guide on this site converges on the same first step: a list of the AI systems, their intended purpose, their role and their tier.
Frequently asked
What does the EU AI Act require from security teams?
Principally Article 15, which requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities, with technical solutions addressing AI-specific vulnerabilities including data poisoning, model poisoning, model evasion, confidentiality attacks and model flaws. Security teams also typically own log retention under Articles 19 and 26(6) and operate the serious incident reporting process under Article 73.
Does ISO 27001 cover the EU AI Act cybersecurity requirement?
Partly. An information security management system provides the vulnerability management, secure development, access control and incident response machinery. It does not usually cover the AI-specific attack classes named in Article 15, such as data poisoning, model evasion and confidentiality attacks like membership inference and model inversion, which sit outside the classic confidentiality, integrity and availability frame.
How does Article 73 interact with NIS2 incident reporting?
They are separate obligations with different triggers, deadlines and potentially different authorities, and they can both apply to the same event. Draft Commission guidance has proposed a simplified approach for high-risk AI systems in sectors with existing equivalent reporting obligations, under which the Article 73 obligation would apply only to fundamental rights violations with other incidents reported under sector rules. That guidance is not settled; verify the current position.