ISO/IEC 27090 makes AI security its own threat layer alongside ISO/IEC 42001 and ISO 27001

After four years, ISO and IEC have finalised ISO/IEC 27090: guidance for securing AI systems against attacks such as prompt injection, data and model poisoning, information extraction and model theft. The standard does not replace ISO/IEC 27001 and 27002 but adds an AI-focused threat and control layer that you anchor in your existing information security management system.

The publication of ISO/IEC 27090 was reported in reporting on the AI security standard from ISO and IEC. Our reading: there is now an international document that approaches the security of AI systems systematically from their specific attack surfaces, alongside the existing classic cybersecurity approach.

What exactly does ISO/IEC 27090 regulate and what does it add to ISO 27001 and 27002?

ISO/IEC 27090 provides guidance for identifying and addressing AI-specific security threats, together with corresponding countermeasures. It is designed as a supplement to ISO/IEC 27001, the standard that, according to ISO, sets the requirements for establishing, implementing, maintaining and improving an information security management system, and to ISO/IEC 27002, which describes the general security controls.

In our assessment, the relationship is simple to summarise: ISO/IEC 27001 provides the governance foundation with risk ownership and continuous improvement, ISO/IEC 27002 provides the generic controls, and ISO/IEC 27090 adds a lens for AI security on top of that. In our assessment, ISO/IEC 27090 focuses specifically on security threats, whereas ISO/IEC 42001 and the NIST AI Risk Management Framework address broader AI-management or AI-risk questions. The official description of ISO/IEC 27001 by ISO makes that foundation concrete.

• ISO/IEC 27001: requirements for the management system, risk ownership and improvement.
• ISO/IEC 27002: general guidelines for information security controls.
• ISO/IEC 42001: a broader AI-management reference point, as described in our editorial comparison.
• NIST AI RMF 1.0: a broad AI-risk framework, as used in our editorial comparison.
• ISO/IEC 27090: AI-specific security threats and ways to detect and mitigate them.

Important: the publication of a standard does not certify a product and does not prove that an AI system is secure. And as long as a separate rule does not prescribe it, ISO/IEC 27090 is not a legal obligation.

Which AI-specific threats does the standard describe and why are generic controls not enough?

The core point is that AI systems have specific attack surfaces for which an ordinary firewall or access control does not suffice on its own. The European Union Agency for Cybersecurity ENISA names, in its opinion paper on the role of the agency in cybersecurity for AI, among others model poisoning, adversarial attacks, prompt injection, information extraction, model leakage, membership inference and model theft.

These threats call for specific language. Prompt injection — where hidden instructions in input or external content steer a model's behaviour — and data poisoning affect the working of the system itself, not only the infrastructure around it. ENISA states in its analysis of cybersecurity for AI that appropriate measures should address attempts to change the use, behaviour or performance of an AI system. In our analysis, that is precisely the gap an AI-specific security layer fills.

Our addition, as interpretation: anyone working exclusively with classic controls describes these threats too broadly to be able to test them. Treating external content as untrusted data is a practical starting point here — see our discussion of hidden instructions in external documents and retrieval.

What does the publication of ISO/IEC 27090 mean for board members, lawyers and CISOs?

Our analysis: because ISO/IEC 27090 explicitly names AI threats as a separate category, responsibility shifts from "we apply our cybersecurity to AI" to "we demonstrate that we control these specific threats"; we therefore advise that the CISO include a threat assessment per AI system in the risk register of the existing ISO/IEC 27001 system instead of placing AI under general IT. Because the standard is a supplement and not a replacement, there is a risk that teams run it as a standalone project without governance anchoring; we therefore advise that the board member appoint a risk owner for each production AI system at the next management review. Because the publication of a standard does not prove security or certification, the claim "we comply with ISO/IEC 27090" remains empty without evidence; we therefore advise that the lawyer stipulate in supplier contracts that tested measures and log evidence can be requested, not merely a reference to the standard. And because the standard is not a legal obligation unless another rule requires it, we advise that the compliance function distinguish which obligation genuinely follows from legislation and which from its own policy, so that commitments to regulators are accurate.

As a summary of that analysis, as our recommendations in steps:

1. Appoint a risk owner per production AI system within the ISO/IEC 27001 register.
2. Include the AI threat assessment in the regular management review.
3. Record testable measures and log evidence in contracts, not merely references to the standard.
4. Separate legal obligations from your own policy choices.

How do you build an AI system inventory with threat-to-control mapping?

Do not start with a model list alone, but with an inventory of the whole AI system. For each component, note which threats apply, who owns it and which measures you take preventively and detectively. Test those measures against the actual production configuration and revise the assessment after every change to the model, data, prompt, tool or infrastructure.

• Model versions and provenance, plus training, fine-tuning and retrieval data.
• Prompts and external content that enters the model.
• APIs, plug-ins and tools, with identities and permissions.
• Deployment infrastructure, logging and monitoring.
• Human approval and emergency-stop points.

Map concrete threats to each component — prompt injection, data or model poisoning, information extraction, model theft, privacy attacks and unauthorised tool actions — and retain evidence of the tests carried out. This approach aligns with broader AI security practice and threat management and with setting up AI governance with risk ownership. For incidents that arise when a model acts beyond its task boundaries, we advise a separate response plan alongside the cyber runbook and AI incident response.

Sources: The article draws on reporting about the completion of ISO/IEC 27090, on the official description of ISO/IEC 27001 by ISO and on the ENISA opinion paper on cybersecurity for AI.