ISO 27090 explained for AI security teams

ISO/IEC 27090:2026 is an international standard providing guidance on security threats and compromises affecting artificial intelligence systems. Published on 14 October 2026, it addresses how organisations can understand, detect and mitigate those threats throughout the AI lifecycle. Its formal title is Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. ISO publication record

For a security team, the practical question is straightforward: what could an attacker change, steal or make an AI system do, and what would limit the resulting harm?

This guide explains the scope of the ISO 27090 standard, the main AI security threats, its relationship to ISO 27001 and ISO 42001, and a practical way to turn the guidance into security work that has owners, safeguards and evidence. The research behind it was checked on 18 October 2026.

What the ISO 27090 standard covers

ISO 27090 focuses on protecting AI systems. Its subject extends beyond generative AI, large language models and chatbots to AI systems more broadly. ISO explanation of ISO 27090

The published standard connects established information security practices with AI-specific threats. Its contents address governance, supply chain security, threat modelling and red teaming, followed by compromise types including poisoning, evasion, information exposure and prompt injection. It also considers how mitigations interact and remain effective over time. Published ISO/IEC 27090 sample

The scope includes organisations of any size that develop or use AI, including businesses, government bodies and nonprofits. Buying a third-party AI service therefore does not put an organisation outside the intended audience. IEC publication record

A useful starting point is a shared review involving security, engineering, data, procurement and the business owner. Each should be able to explain the part of the system they control and the decisions they depend on others to make.

Why AI systems need additional security analysis

An AI application connects several things that deserve separate scrutiny: software, data, model files or services, instructions, users and downstream actions.

Consider a document assistant connected to an internal knowledge base. A conventional review may examine authentication, encryption and software vulnerabilities. An AI security review should also ask what happens if a retrieved document tries to change the assistant’s instructions, whether users can retrieve material outside their permissions, and which actions generated output can trigger.

These questions become more consequential when an assistant can update records or call external tools. A wrong answer and an unauthorised action have different consequences and need different safeguards.

For your first review, map three questions:

• What can influence the system? Include training data, retrieved content, prompts, suppliers and model updates.
• What can leave the system? Include answers, logs, exports and model assets.
• What can the system change? Include files, tickets, accounts, transactions and other connected services.

This is a practical scoping method for the examples below, not a reproduction of the standard’s clauses.

AI security threats to understand

The following explanations use NIST’s adversarial machine learning terminology and OWASP’s guidance for LLM applications. The scenarios are illustrative. NIST adversarial machine learning taxonomy OWASP prompt injection guidance OWASP output handling guidance

Keep the distinctions clear during a risk assessment. A malicious document retrieved by a retrieval-augmented generation (RAG) application is not automatically training-data poisoning: retrieval does not, by itself, update model weights. It may instead expose the application to indirect prompt injection.

For LLM security, stronger prompts alone are an incomplete control strategy. OWASP recommends safeguards such as restricted privileges and approval for sensitive actions, while the NCSC emphasises managing prompt injection as a continuing risk through system design and operation. OWASP prompt injection guidance NCSC guidance on prompt injection risk

ISO 27090 vs ISO 27001 and ISO 42001

These standards support different parts of an organisation’s security and AI governance work.

The distinctions follow the publishers’ descriptions of ISO 27001, ISO 27002 and ISO 42001.

For a team already operating an ISMS, a practical approach is to extend existing records. Add relevant AI systems to the asset inventory, assess their attack paths, assign treatment owners and link supporting evidence. For background on organising that work, see the ISO 27001 implementation checklist.

A practical ISO 27090 implementation checklist

The steps below are an implementation approach built from the standard’s subject matter and public secure AI guidance. They are not an official ISO checklist or a statement of mandatory clauses.

1. Define the system and its owner

Choose an AI use case with a clear business purpose. Record the accountable owner, users, model provider, hosting arrangement and connected services.

Then draw the boundary of the review. Include the application and its dependencies, not just the model endpoint. A customer-facing assistant with tool access needs a different assessment from an internal text summariser with no permission to act.

Useful output: a system record that states its purpose, boundaries, dependencies, permitted actions and accountable owner.

2. Trace data and model provenance

Record where datasets and model artifacts come from, who can change them and which versions are deployed. Include fine-tuning inputs, retrieval collections, prompts and feedback channels relevant to the system.

NCSC development guidance recommends tracking AI assets and their provenance, protecting them and retaining information needed to recover trustworthy versions. NCSC secure AI development guidance

For a purchased model, ask the provider which responsibilities it handles and what information it makes available when models or services change.

Useful output: a versioned inventory with sources, access rules, change history and supplier responsibilities.

3. Threat model the actual workflow

Review the system from an attacker’s perspective. Identify entry points, sensitive assets, permissions and the consequences of a successful compromise. NCSC secure design guidance recommends threat modelling and attention to third-party components and least privilege. NCSC secure AI design guidance

Write concrete scenarios. “AI risk” is too broad to drive a useful action. “A document uploaded by an external party persuades the assistant to request a restricted evidence file” gives a team something specific to analyse.

Prioritise according to exposure and potential harm. Record who accepts any remaining risk and when that decision should be revisited.

Useful output: a short risk register linking attack scenarios to assets, consequences, safeguards and owners.

4. Put safeguards at the relevant boundaries

Select controls for the scenario you are addressing. For model assets, this may involve protected storage, access restrictions and integrity checks. For deployed services, consider authentication, separation between environments and controls that reduce unauthorised access or exfiltration. These are themes in NCSC deployment guidance. NCSC secure AI deployment guidance

For generated output, validate and encode content for its destination before another system acts on it. OWASP’s output handling guidance explains why model output should not acquire authority merely because it came from the model. OWASP output handling guidance

Useful output: a control record naming the boundary it protects, its owner and the evidence used to check it.

5. Test the complete application

Design tests around the consequences identified in your threat model. For a RAG assistant, use adversarial documents and users with different permissions. For an agent, test what happens when retrieved content asks it to exceed its permitted actions.

Define the expected result before running the test. An example: the application must deny a restricted file request even if the model attempts to make that request.

Record the application configuration, model version, test inputs, result and any remediation. Choose test data that does not unnecessarily expose real confidential information.

Useful output: repeatable security tests tied to specific risks and release decisions.

6. Monitor changes and prepare a response

Review the effect of model, data and prompt updates. Monitor relevant inputs and outputs while protecting sensitive information in logs. NCSC operational guidance highlights behavioural monitoring and the security implications of changes throughout operation. NCSC secure AI operation guidance

Decide in advance who can disable a tool, revoke a credential, isolate an integration or revert a release. Set review triggers such as a new provider, expanded permissions, a material model update or a security incident.

Useful output: monitoring responsibilities, change review criteria, an incident response procedure and a tested recovery route.

Turning AI security risks into evidence

The table below is a suggested working template. Its evidence examples are practical recommendations, not a list of documents mandated by ISO 27090.

For example, imagine a security team using an assistant to summarise customer evidence. A supplier document includes instructions to upload the evidence to an external address.

The team’s test should follow the attempted action through the application. Does the assistant have a tool that can upload files? Does that tool enforce the user’s permissions? Are destinations restricted? Is a responsible person required to approve the transfer?

A useful review record would identify the scenario, the boundary that prevents the transfer, the test result and the person who approved the remaining risk. If the system changes, that record tells the next reviewer what needs to be checked again.

This approach gives an assessment more substance than a claim that the system uses “responsible AI”. It connects the security decision to something another person can inspect. For more on organising supporting material, see how to structure audit readiness.

ISO 27090 certification and requirements

ISO 27090 provides security guidance rather than management system certification requirements. ISO’s explanation distinguishes its purpose from the AIMS requirements in ISO 42001. ISO explanation of ISO 27090

First define the assurance you need: a security review, a customer assurance response, an internal gap assessment or certification against an applicable management system standard.

Ask anyone offering an assessment to state its scope, criteria and assurance scheme. That makes the result easier to interpret and avoids confusing a review of AI security practices with certification of a management system.

For an implementation project, obtain the published standard, review the guidance against your own systems and record why particular safeguards are appropriate. The examples in this article provide a starting structure for that work.

ISO 27090 and the EU AI Act

Applying an international standard does not automatically establish compliance with the EU AI Act. Article 40 links a presumption of conformity to harmonised standards whose references have been published in the EU Official Journal, and only to the extent that they cover the relevant requirements or obligations. EU AI Act Article 40

Use an ISO 27090 security review as one input to a separately scoped compliance assessment. Keep a record of the legal obligation being evaluated, the evidence supporting it and any remaining gap.

Frequently asked questions about ISO 27090

What is the ISO 27090 release date?

The first edition, ISO/IEC 27090:2026, was published on 14 October 2026. Check the current publisher record when older material refers to a draft or an earlier year. IEC publication record

Does ISO 27090 cover generative AI and LLM security?

Its published contents include prompt injection and sensitive model outputs, making it relevant to generative AI security. Its scope also includes other AI systems. Published ISO/IEC 27090 sample ISO explanation of ISO 27090

Can a company using third-party AI apply the standard?

Yes. The stated audience includes organisations that use AI, as well as organisations that develop it. Start with the risks and responsibilities within your control, and identify what you need to understand about your suppliers. IEC publication record

Does ISO 27001 certification mean an AI system is secure?

A management system certification is not a guarantee that an individual application will resist every attack. Use the management system to organise risk decisions, and assess the AI system’s actual design, configuration and behaviour. ISO 27090 can help inform that security work.

Where can I get the ISO 27090 PDF?

Use the official ISO catalogue or IEC Webstore for the published standard and licensing options. Check that the designation is ISO/IEC 27090:2026. An article or preview provides only part of the material.

Make AI security work reviewable

Start with one consequential AI use case. Identify how it could be compromised, choose safeguards for the relevant boundaries and define the evidence that will demonstrate those safeguards are working. Give each action an owner and a review trigger.

Secani connects requirements, risks, controls, evidence, owners and review decisions in a shared security and compliance workspace. Talk to Secani about organising your AI security work so teams can see what has been assessed, what needs attention and who is responsible.