ISO/IEC 27090: bringing AI security risks into your ISMS

Your team connects an AI assistant to internal documents. Procurement knows the supplier, IT operates the integration, and the business team wants to save time. Who checks whether manipulated documents could cause unwanted actions? Who decides which information the assistant may access?

These questions need a shared risk assessment. A new standard cannot answer them for your particular application.

What is ISO/IEC 27090?

ISO/IEC 27090 provides guidance on threats to AI systems, including poisoned training data and model theft. It complements established information security practices.

As of 12 October 2026: The official ISO page lists stage 60.00, “Under publication”. Publication is not yet marked complete. Check the final edition before applying it.

How does it relate to ISO 27001 and ISO 42001?

ISO 27001 sets ISMS requirements. ISO 42001 addresses AI management. ISO 27090 focuses on AI system security and offers guidance rather than AI management system requirements. ISO explains this distinction.

A practical example: an internal knowledge assistant

This is our own fictional example, not a requirement from the standard. A knowledge assistant reads a shared folder and can create tasks. Someone adds a manipulated document. The assistant treats its contents as instructions rather than material to evaluate.

A useful risk description is: “A manipulated source document causes the assistant to copy confidential information into a task visible to other teams.” This identifies the trigger, unwanted behaviour and potential impact.

Our recommendation: record existing access restrictions, assess the specific scenario, and agree additional measures. Options might include narrower access, human confirmation before write actions, and tests using manipulated documents. Suitable measures depend on your system; a generic checklist cannot replace that assessment.

Turn a finding into a verifiable task

An entry stating “AI might be insecure” gives the team little direction. A concrete assignment is more useful:

• Task: Restrict the assistant’s write actions.
• Owner: The operations team together with the business team.
• Evidence: A documented test showing that a manipulated source document cannot trigger an unconfirmed action.
• Next review: After changes to permissions, integrations or the model.

Reassess residual risk after implementation and verification. A planned measure has not reduced the actual risk yet.

Bring the supplier into the same assessment

For an external AI service, include relevant questions in your vendor assessment. What data reaches the supplier? What contractual and technical restrictions apply to its use? How will you learn about changes, and what evidence can you examine?

Connect the answers to the specific risk and outstanding tasks. That keeps unanswered questions visible across procurement, IT and the business team.

An ISMS platform and a shared risk register can bring this work together. The useful outcome is a traceable connection between the application, risk, responsible person and verified measure – rather than another document named after a standard.