ISO/IEC 27090: AI security alongside ISO 27001

You must now demonstrate that your organisation controls AI-specific attack surfaces — prompt injection, data poisoning, model theft and similar threats — as distinct security risks within your existing information security management system, not as general IT problems.

The prompt is an analysis of 19 October 2026 of AI-specific security threats and their countermeasures, which argues that ISO/IEC 27090 provides systematic guidance for identifying and addressing security risks particular to AI systems. The standard supplements rather than replaces ISO/IEC 27001 and ISO/IEC 27002, anchoring AI security within your existing governance framework. In our assessment, this creates a practical obligation: you must now articulate which threats apply to each production AI system, who owns them, and what evidence you hold that your controls work against them.

What makes AI systems a distinct security problem?

AI systems have attack surfaces that conventional firewalls and access controls do not address. Prompt injection — where hidden instructions in user input or external content alter a model's behaviour — affects the system's functioning itself, not only the infrastructure around it. Data poisoning and model poisoning similarly change how the system works rather than merely compromising the data it touches. Model theft, membership inference attacks, and information extraction represent threats to the model's intellectual property and training data. These are not failures of your network perimeter; they are failures of the AI system's own boundaries.

The distinction matters for testing. If you describe prompt injection as "untrusted input" in your general security controls, you cannot easily verify whether your specific countermeasures actually work against it in your production configuration. Naming the threat explicitly — as ISO/IEC 27090 does — shifts responsibility from "we apply cybersecurity to AI" to "we demonstrate control of this specific threat."

Which threats must you assess for each AI system?

• Prompt injection — hidden instructions in user input or external content that alter model behaviour.
• Data poisoning — malicious modification of training or operational data to degrade system performance.
• Model poisoning — direct attacks on model weights or parameters to change outputs.
• Information extraction — techniques to recover training data or model internals from outputs.
• Model theft — unauthorised copying or reverse-engineering of the model itself.
• Privacy attacks — membership inference and similar techniques to determine whether specific data was in training.

What does your risk register now need to show?

ISO/IEC 27090 is not a legal obligation unless another regulation requires it. However, if your organisation has committed to the standard, or if you operate in a jurisdiction where AI security is becoming a regulatory expectation, you must be able to demonstrate control. This means:

1. Inventory each AI system's components — model, training data, operational data, prompts, retrieval sources, external tools — and note which threats apply to each.
2. Assign a risk owner per production AI system — not a general AI governance role, but accountability for each system's threat assessment and control evidence.
3. Document preventive and detective measures — what you do before an attack occurs, and what you monitor to detect it if prevention fails.
4. Test measures against your actual production configuration — not against a theoretical setup or a vendor's claims, but against what you actually run.
5. Retain evidence of testing — logs, test results, and dates, so that you can show regulators or auditors what you checked and when.
6. Revise the assessment after every material change — to the model, training data, prompts, retrieval sources, or infrastructure.

How should you structure this within your existing security programme?

Do not treat ISO/IEC 27090 as a standalone project. The standard is a supplement to ISO/IEC 27001, which means your CISO should add AI threat assessment to the risk register of your existing information security management system. At your next management review, the board member responsible for risk should appoint a named owner for each production AI system, just as you would for any other critical asset.

When you contract with suppliers or use third-party models, stipulate in your agreements that you can request evidence of tested measures and logs. A claim that "we comply with ISO/IEC 27090" is empty without evidence. Your legal function should distinguish between obligations that follow from regulation and those that follow from your own policy, so that commitments to regulators remain accurate.

What tooling can carry, and what cannot

Automated scanning can help you identify which components of an AI system are exposed to which threats. Logging and monitoring tools can record whether your detective controls are working. But no tool can decide whether a threat is material to your business, or whether the cost of a control is justified by the risk it reduces. That remains your professional judgement. The standard provides the language and structure for that decision; it does not make the decision for you.