What is ISO/IEC 27090:2026?
ISO/IEC 27090:2026 is an international standard from ISO and IEC. Its first edition was published on 14 October 2026; it is a published standard, rather than a draft. The official entry describes guidance on AI-specific security threats throughout the life cycle, including protection of training data and models.
It can help organisations developing AI and those using it. It provides guidance and should not be presented as a standalone certification. This article uses public official information, without reproducing the full standard or claiming access to unverified clauses. The controls and examples below are practical suggestions from Céntrika, rather than a reproduction of the standard.
Why AI needs specific cybersecurity measures
An application can run on protected servers and still produce manipulated results. A security review needs to consider what the model learns, what it receives during use and what actions it can perform. Established protections remain essential: identity management, access control, backups and vulnerability management still matter.
Separate the assets in the system: training data, model weights and configuration, inference processes, inputs, outputs and integrations. Updates and suppliers matter too. A read-only document assistant has a different exposure from one allowed to send emails or modify records. Actual purpose and permissions determine which safeguards make sense. An assessment should therefore describe the deployed workflow, not just the model name or the supplier's marketing description.
Main cybersecurity threats to AI
ISO’s public description outlines AI-specific threats. Its explanatory guide, based on the final draft, also names membership inference, model inversion and direct model poisoning, alongside threats involving inputs and outputs. NIST AI 100-2 E2025 provides further context on adversarial machine learning attacks and mitigations.
This table is Céntrika’s explanatory synthesis, not a verbatim reproduction or an official ISO/IEC 27090 classification. The suggested safeguards are practical Céntrika recommendations to be adapted and tested for each system, rather than mandatory controls attributed to the standard.
| Threat | What could happen | Consequence | Possible safeguard |
|---|---|---|---|
| Data poisoning | Manipulated records enter training | Degraded or directed behaviour | Check provenance, integrity and samples |
| Model theft or extraction | A model is obtained through direct access, or queries are used to try to reconstruct its behaviour | Loss of intellectual property | Restrict access and detect anomalous queries |
| Evasion attacks or adversarial inputs | Crafted inputs change predictions during use | Incorrect decisions | Relevant attack testing and contextual validation |
| Prompt injection | Untrusted content tries to direct an assistant | Unauthorised responses or actions | Separate data from instructions and restrict tools |
| Sensitive information exposure | Outputs reveal restricted content | Harm to people or business | User-level permissions and output checks |
| Membership inference | An attacker tries to determine whether a person’s data or a particular record was used in training | Disclosure of a record’s membership in the training dataset | Limit observable information, assess model exposure and test privacy risks |
| Model inversion | An attacker tries to reconstruct information from model responses or characteristics | Possible disclosure of sensitive information | Assess outputs, limit unnecessary information and apply data protection measures |
| Direct model poisoning | Parameters, weights or other model components are altered directly | Unauthorised changes to model behaviour | Control access, verify integrity and maintain version traceability |
| Malicious model outputs (outputs containing injection attacks) | Generated output contains malicious instructions or content that other components process | Unintended actions or compromise of connected systems | Treat outputs as untrusted content, validate their use and restrict integration permissions |
Other exposure points: retraining and suppliers
Compromised retraining. Data collected during operation can introduce threats when reused to train new versions. This can allow a compromise to persist beyond the original release. Validate datasets and approve new versions before use.
Supplier compromise. External components, models and services can also provide routes for compromise. Review their provenance, changes and supplier terms. Retraining and suppliers are exposure points where attacks such as those above can occur, rather than separate attack categories.
Controls need testing: a prompt filter alone does not guarantee security. Distinguishing malicious attacks from data quality problems and legitimate changes also helps teams investigate without jumping to conclusions. The same unusual output may have several possible causes.
Security throughout the AI life cycle
The following sequence proposes review points, rather than reproducing official stages from the standard. At each transition, the organisation should be able to identify what changed, who authorised it and which checks were completed.
- Design: define purpose, permissions, threats and potential consequences.
- Data collection: check origin, conditions of use and integrity.
- Training: control access to data, code, parameters and artefacts.
- Validation: test relevant attacks and record limitations.
- Deployment: separate environments, manage secrets and minimise privileges.
- Operation: observe access, queries and unusual actions.
- Monitoring: connect alerts with risks and owners.
- Updates or retraining: validate new data, compare versions and plan rollback.
- Retirement: revoke access, close integrations and manage retention and deletion.
AI system monitoring turns these checks into continuing oversight. A model or supplier change can invalidate security assumptions even when the user interface looks identical. Review should therefore follow meaningful technical and organisational changes, not only visible product redesigns.
ISO/IEC 27090 and ISO/IEC 27001
ISO/IEC 27001:2022 sets requirements for an information security management system. ISO/IEC 27090 provides AI threat guidance and complements established practices, including ISO/IEC 27001 and ISO/IEC 27002.
| Aspect | ISO/IEC 27001 | ISO/IEC 27090 |
|---|---|---|
| Purpose | Manage information security | Address AI-specific threats |
| Scope | Information and processes within the ISMS | AI systems throughout their life cycle |
| Approach | Management system requirements | Specialist guidance |
| Application to AI | Covers AI assets within the defined scope | Focuses on their particular exposure |
| Controls | Risk-based selection and treatment | Support for understanding threats and protection |
| Organisational role | Management and improvement framework | Complement to security analysis |
A practical integration does not require two disconnected approval processes. An organisation can extend its risk register and change management process with AI scenarios, linking owners and evidence. The aim is to make existing security decisions more informed, while retaining a clear account of the system and its exposure.
ISO/IEC 27090 and ISO/IEC 42001
ISO/IEC 42001 establishes an AI management system. It helps organise policies, responsibilities, risks and improvement. AI-specific cybersecurity can fit within that framework according to its scope and the organisation's exposure. This is a proposed integration, not an additional requirement attributed to either standard.
For example, a sales team requests a document assistant. The business owner defines its purpose; security reviews threats and access; engineers test restrictions; and the accountable owner decides whether the remaining risk is acceptable. Implementing ISO/IEC 42001 can connect those decisions without treating every department as an independent process.
In an AI management system audit, evidence that established processes actually operate matters. A dated test, its result and a decision about identified limitations are more informative than a presentation describing planned controls. Clear ownership also helps ensure that unresolved findings remain visible after the project team moves on.
ISO/IEC 27090 and AI risk management
ISO/IEC 23894:2023 provides guidance on AI risk management. Connecting security with business decisions means describing concrete scenarios: which asset could be affected, through which route and with what consequences. Naming a threat is not enough to prioritise investment.
A practical Céntrika sequence for AI risk management is Identification → Risk → Control → Owner → Evidence → Monitoring. Likelihood and impact should reflect context, affected people and external dependencies. Teams should also state important assumptions, such as whether an assistant can access restricted files or invoke external tools.
| Asset | Threat | Potential impact | Control | Evidence |
|---|---|---|---|---|
| Internal documents | Indirect prompt injection | Unauthorised access or disclosure | Document and user-level authorisation | Permission test and result |
| Training data | Manipulation | Altered predictions | Provenance and dataset validation | Version and approved review |
| Model | Extraction | Loss of proprietary knowledge | Restricted access and alerts | Reviewed access logs |
| Connected tools | Induced action | Records changed without authority | Human approval and action limits | Authorisation record |
This table is illustrative. Each row also needs an owner, review date and decision about residual risk. Installing a control without checking its operation leaves the assessment incomplete. Where evidence is unavailable, the gap should remain explicit rather than being treated as proof that the risk has been resolved.
How ISO/IEC 27090 relates to the AI Act
Article 15 of Regulation (EU) 2024/1689 addresses accuracy, robustness and cybersecurity for high-risk AI systems. Security testing may help establish evidence, but voluntary guidance and legal duties serve different purposes. Identify the organisation's role, the system's classification and the applicable timetable first.
Article 15(5), available through the Commission's official portal, addresses safeguards appropriate to circumstances and risks, including manipulation of data, pretrained components and inputs, confidentiality attacks and model flaws. Regulation (EU) 2026/1744 amended Article 113: Chapter III Sections 1–3, except Article 6(5), apply from 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems. Relevant exclusions and transitional provisions must also be checked.
Applying ISO/IEC 27090 does not guarantee AI Act compliance or automatically create a presumption of conformity. The latter requires checking applicable legal conditions, including relevant Official Journal references. It also does not replace conformity assessment. Our ISO 42001 versus AI Act guide explains the distinction between voluntary management and legal compliance.
What businesses should do
A proportionate approach starts with specific systems and decisions that the organisation can maintain. Different organisations need different levels of testing and documentation; the process should reflect exposure rather than the size of a checklist.
- Inventory: record purpose, use, supplier and owner in the AI inventory.
- Identify assets: map data, models, integrations, credentials and permitted actions.
- Analyse threats: examine entry points and possible attacker capabilities.
- Assess risk: consider likelihood, impact and actual exposure.
- Treat: select feasible safeguards and decide on residual risk.
- Assign ownership: identify who approves, implements, monitors and responds.
- Document: link decisions to controls and tests.
- Review: establish monitoring and reassessment triggers.
AI vendor management should clarify what the organisation can verify and what depends on the supplier. Specific evidence about permissions, versions and change notifications is more useful than a generic assurance that a product is secure. Where a third party controls testing or logging, contractual arrangements and escalation routes need particular attention.
What evidence should be retained?
Useful records may include inventories, risk assessments, threat registers, treatment decisions, security tests and approvals. Version histories, changes, incidents, corrective actions, supplier reviews and monitoring results can also matter. This is practical advice, not a universally mandatory ISO/IEC 27090 document list.
AI evidence should make a decision traceable: what was tested, which version was used, what happened and who accepted the limitations. Logs and traceability help, but access and retention need limits. Protect personal data and avoid storing unnecessary secrets. Collecting records without a defined purpose or review does not demonstrate effective control. Evidence should be accessible to authorised reviewers while remaining protected against unauthorised alteration.
Business example: protecting an AI assistant
A company connects an assistant to internal documents. An external file contains instructions intended to induce disclosure of confidential information. This is an illustrative indirect prompt injection scenario, not an official example from the standard. Exposure depends on user permissions, retrieved content and available tools.
The team detects an unexpected response and preserves the query, relevant document, version and necessary logs under restricted access. Security and the system owner assess exposure; the data owner identifies affected information. Legal, privacy staff and the supplier contribute where appropriate. AI incident management coordinates investigation, response and relevant communications.
Possible treatment includes reviewing authorisation during document retrieval, separating external content from instructions and restricting tools. Sensitive actions require approval. Before restoring functions, repeat the original test and add variants, legitimate queries and users with different permissions. Preserve results and limitations: fixing one demonstration does not prove that every attack has been eliminated. The business owner should understand what remains uncertain before accepting the updated service.
Bringing cybersecurity into AI governance
Protection becomes easier to maintain when policies, inventory, owners, risks, suppliers, incidents and audits share references. A system should be identifiable in the inventory and connected to its controls, changes and decisions. Business and security teams can then discuss the same exposure without relying on scattered documents or informal recollection.
AI governance connects these elements with continual improvement. Céntrika's approach translates management needs into verifiable controls and useful evidence. The AI Act for business guide provides wider regulatory context. A practical starting point is a single important system: establish its exposure and decision process, then extend the method as the organisation learns.
Conclusion
Protecting AI involves data, models and behaviour as well as infrastructure. ISO/IEC 27090 can complement existing security and governance approaches. The practical step is to identify a specific exposure, choose proportionate measures and verify that they work, with an accountable owner and evidence of follow-up.
References and editorial scope
Sources checked on 16 October 2026: ISO/IEC 27090:2026, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 42001:2023, ISO/IEC 23894:2023, NIST AI 100-2 E2025, Article 15 on the Commission portal, Regulation (EU) 2026/1744 and Regulation (EU) 2024/1689. Examples and safeguards are Céntrika recommendations, without claims about unverified clauses.
Do you know the security risks of your organisation’s AI systems?
Identifying AI systems, assessing their risks and defining controls is the first step towards safer, responsible governance.