ISO/IEC 27090:2026 — A New International Standard for AI System Cybersecurity

1. What is ISO/IEC 27090?

ISO/IEC 27090:2026 is an international guidance standard for protecting artificial intelligence (AI) systems. First edition; published 14 October 2026; committee ISO/IEC JTC 1/SC 27. Its official title is Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. It addresses organizations of any size that develop or use AI, including public bodies and commercial users of external models.

AI security concerns the confidentiality, integrity and availability of the AI system and its dependencies. It differs from using AI to detect cyberattacks. A model can remain available yet produce attacker-influenced decisions: operational success is not evidence of trustworthy behavior. ISO’s published overview emphasizes threats to data and models, their consequences, detection and mitigation across the life cycle, complementing established cybersecurity practice.

Editorial scope: this article uses official public information, not a licensed clause-by-clause review. ISO’s explanatory guide still describes the final draft; its topic list is identified as draft-based below. The detailed controls, fictional scenarios and roadmap are independent engineering recommendations, not quoted ISO requirements. The standard is not a mandatory Georgian regulation, a standalone certifiable management system, or a guarantee of security.

• ISO — published standard
• IEC — edition and release date

2. Why conventional controls need AI-specific extensions

Firewalls, patching and identity management remain essential. Their usual coverage does not establish that training datasets are trustworthy, model weights are unaltered, or inference requests cannot manipulate decisions. Fine-tuning and updates change behavior; external providers can change components outside your release schedule. Prompts, retrieved context and agent tools connect low-trust content to privileged operations.

For example, a support assistant may retrieve a maliciously edited knowledge article and treat its instructions as authority to expose account information. No server intrusion is necessary. Retrieval-Augmented Generation (RAG) supplies documents to a model at inference time; it does not turn those documents into trusted instructions. Security design must trace how information becomes an action, not just how traffic reaches an endpoint.

• OWASP — prompt injection

3. What needs protection?

An asset inventory should connect information, components and owners to business consequences. A model file is not the whole system. The examples below are implementation choices: select and test them against the actual architecture rather than treating the table as an ISO-prescribed control catalogue.

4. AI-specific threats: mechanism, detection and response

Source distinction: ISO’s published overview explicitly mentions data poisoning and model theft. Its draft-based explanatory guide additionally names direct model poisoning, evasion, membership inference, model inversion, prompt injection and sensitive output, and discusses supply-chain security. That is not verification of final clause wording. The following defensive scenarios are our own examples. Agent/tool abuse extends the discussion using OWASP; none is an asserted ISO checklist.

• ISO guide — final-draft basis
• NIST — adversarial ML terminology
• OWASP — application risks

4.1. Data poisoning

An attacker alters training examples or labels so learning produces harmful behavior. Intake feeds and retraining feedback are typical entry points. A fictional fraud model learns to accept suspicious transfers after corrupted feedback labels them legitimate. Compare source contributions and label distributions; investigate targeted performance shifts, not only overall accuracy. Quarantine new data, require provenance and approval, and preserve clean evaluation sets. Statistical checks can miss subtle, targeted poisoning.

4.2. Model poisoning

Malicious changes to weights, adapters or training processes can implant targeted behavior while ordinary evaluations still pass. A substituted fine-tuning adapter might distort one customer category’s recommendations. Verify artifact signatures against trusted provenance, inspect registry changes and test sensitive scenarios against a known baseline. Separate training, registry administration and deployment approval. A valid hash proves correspondence to an artifact, not that its producer or behavior is trustworthy.

4.3. Prompt injection

Untrusted text attempts to redirect model behavior across an instruction boundary. A retrieved invoice could ask an assistant to disclose other customers’ balances. Inspect tool proposals and unexpected destinations, linking them to retrieved sources; keyword filtering alone is unreliable. Treat retrieved material as data, constrain available actions and enforce authorization outside the model. RAG and fine-tuning do not, by themselves, eliminate injection. A blocked suspicious response should still prompt investigation of the source.

4.4. Adversarial examples and evasion

Carefully manipulated inference inputs can move a model toward an incorrect classification without changing its weights. A document classifier might misroute an altered application. Compare robustness across realistic input variations and monitor disagreements with independent checks. Use bounded preprocessing, adversarial evaluation and escalation for uncertain high-impact decisions. Normal data drift can resemble attack effects, so investigate context before attributing intent. Robustness on one test set does not establish resistance to every future manipulation.

4.5. Model extraction and theft

Artifact theft copies stored model files; query-based extraction tries to approximate valuable functionality through observed responses. Repeated systematic requests to a pricing model might enable a substitute service. Monitor query diversity, abnormal volume and artifact downloads; combine identity, cost and egress signals. Restrict registry access and endpoint quotas, and expose only necessary response detail. Rate limits reduce opportunity but may not identify distributed extraction, while excessive restrictions can impair legitimate users.

4.6. Model inversion

Inversion seeks information about training-associated features or records from model access. It should not be confused with guaranteed recovery of exact training examples. A health-related model might reveal sensitive population characteristics through informative outputs. Assess privacy under realistic attacker access and inspect excessive confidence or detail exposure. Minimize sensitive training data, restrict outputs and evaluate privacy-preserving training where appropriate. Detection is difficult because a small number of ordinary-looking queries may be informative.

4.7. Membership inference

The attacker asks whether a particular record participated in training, rather than reconstructing its contents. Revealing that a person appeared in a specialist clinical dataset can itself harm privacy. Evaluate differences between model behavior on training and held-out records, using authorized privacy tests. Reduce overfitting and unnecessary output detail; consider differential privacy with explicit utility and privacy-budget analysis. A test result is probabilistic evidence, not proof of membership or a universal privacy guarantee.

4.8. Sensitive information disclosure

Confidential information may escape through responses, context, logs or integrations without any training-data attack. A cross-tenant retrieval mistake could include another client’s contract in an answer. Test access boundaries with synthetic records and monitor unusual retrievals and outbound destinations. Apply per-document authorization before retrieval, redact unnecessary data and protect logs. Output filters add a layer but cannot repair overly broad source access. Avoid storing production secrets inside prompts.

4.9. AI supply-chain compromise

External datasets, model packages, dependencies, plugins and providers can introduce malicious behavior. A trusted-looking model update could include unsafe loading code or unexpected network access. Review provenance, dependency changes and runtime connections; test updates in isolation before promotion. Pin approved versions, verify artifacts and document supplier responsibilities and notification obligations. Publisher reputation or a vulnerability scan alone is insufficient. Maintain a tested fallback when a provider changes or withdraws a critical component.

4.10. Agent and tool abuse — additional engineering scenario

An agent can turn manipulated reasoning into an authorized API call with an unauthorized business purpose. A billing assistant with unrestricted write access might change a refund destination. Log proposed and executed tool arguments and compare them with the approved task. Use narrowly scoped functions, downstream policy checks and human authorization of consequential actions. Monitor unusual operation sequences, not just individual requests. Removing unused tools reduces the actions an attacker can induce.

5. Security throughout the AI life cycle

Treat release approval as one checkpoint, not the end of assessment. Keep a traceable relationship between data versions, model artifacts, evaluation results and the configuration actually deployed. These six stages organize engineering work; they are not claimed to reproduce the standard’s section structure.

• Planning: define permitted decisions, misuse cases, owners and unacceptable business outcomes.
• Data acquisition: verify provenance and usage rights, quarantine changes and separate training from evaluation.
• Development: isolate experiments, protect credentials and reproduce approved builds and model versions.
• Testing: evaluate adversarial behavior, privacy and recovery against explicit acceptance thresholds.
• Deployment: restrict endpoints and tools, approve the release and confirm monitoring before enabling access.
• Operation through retirement: review feedback, retrain under change control, rehearse incidents and revoke tools, keys and retained data when decommissioning.

6. Technical and organizational safeguards

Governance: assign an accountable service owner and maintain an AI inventory, acceptable-use policy and documented threat model. Procurement should establish provider change notifications, data retention terms and incident cooperation before integration.

Data and models: control intake and registry writes, validate dataset quality and retain version lineage. Signed artifacts and protected storage help establish integrity; neither substitutes for behavioral tests of an approved model.

Applications: authenticate API callers, enforce resource authorization, isolate secrets and validate generated output before it reaches another interpreter. Retrieve only authorized documents. Restrict tool functions and destinations rather than asking the model to enforce permissions.

Monitoring: correlate model versions, retrieval identifiers, tool calls and downstream outcomes. Alert on abnormal query patterns, unexpected exports and behavior changes. Define incident escalation and minimize logged personal data; telemetry must not become a second uncontrolled dataset.

Testing: combine AI red teaming, adversarial inputs, prompt-injection and leakage tests, robustness measurements and update regression tests. Report observed success rates, test coverage, false positives and residual uncertainty. No single safeguard eliminates all threats; controls can conflict, so measure their combined behavior and legitimate-user impact.

7. Generative AI and connected agents

A large language model (LLM) predicts or generates content; its text is not an authorization decision. RAG adds data access, while agents add tool execution and repeated planning. An application that only drafts answers has different exposure from one that queries customer databases, updates billing or triggers external workflows.

For financial or operational decisions, separate recommendation from execution. Require strong authentication and human approval tied to exact action parameters, with segregation of duties where appropriate. Enforce transaction limits, scoped credentials and emergency disablement in deterministic services. Keep approval outside untrusted prompts and maintain auditable links between the requesting user and each action. These are practical engineering recommendations, not asserted ISO/IEC 27090 clauses.

• OWASP — excessive agency

8. Organizations and professionals

Banking and FinTech should examine payment advice, fraud decisions and customer-data boundaries. Healthcare should assess sensitive records and clinical decision support. Energy and critical infrastructure should keep AI recommendations separated from unsafe operational commands. Telecommunications should review network automation and subscriber-data access.

Government should consider citizen-data confidentiality and the consequences of automated decisions. Technology and SaaS providers should test tenant isolation and model dependencies. Developers of proprietary AI control training and artifacts; purchasers of third-party AI still own integration, access and business-use risks. These are risk scenarios, not new sectoral legal obligations.

CISOs and security teams coordinate protection; AI/ML engineers validate model behavior; developers and IT architects enforce application boundaries. Data governance teams manage provenance and permitted use. Risk managers evaluate residual exposure, internal auditors test evidence, and procurement teams examine provider dependencies. Executive owners decide whether the remaining risk is acceptable for the intended business activity.

9. How the frameworks fit together

Use management systems to establish ownership, policies, review and improvement; use technical threat guidance to challenge the system design. ISO/IEC 27090 complements ISO/IEC 27001 and ISO/IEC 42001 rather than replacing either. It does not establish a new independent certification scheme. Certification of a management system is not proof that a particular AI application resists every attack.

• ISO/IEC 27001
• ISO/IEC 27002
• ISO/IEC 42001
• ISO/IEC 23894
• NIST AI RMF

10. A practical ten-step adoption roadmap

This proposed sequence translates risk thinking into accountable work. It is inspired by the standard’s purpose, not a mandatory ISO procedure. Scale evidence to the system’s consequences: a public summarizer and an agent that changes financial records should not share identical approval thresholds.

11. Audit and assessment considerations

Assess design and operating effectiveness separately. A policy may promise restricted tools while a service account still has broad database access. Sample actual releases and trace a risk through architecture, configuration, test evidence and incident handling. Agree the criteria and time period; these questions are not a mandatory ISO certification checklist.

Expected evidence includes the AI register, risk assessment, threat model, architecture, provenance records, access configurations, security test reports, monitoring records, incident procedures and supplier assurance. Validate currency and scope rather than accepting a certificate or screenshot alone. Record exceptions, owners, deadlines and the basis for residual-risk acceptance.

• Is the AI inventory complete, and are cybersecurity risks documented?
• Are dataset and model sources verified and artifacts protected from unauthorized changes?
• Are application permissions restricted and injection and leakage scenarios assessed?
• Is security testing performed, and are incidents monitored and escalated?
• Are third-party dependencies assessed and significant model changes reviewed?

12. Fictional case: a utility billing assistant

A fictional utility deploys an assistant to explain invoices and prepare correction requests. It reads an authenticated customer’s bill and approved tariff documents. Customer messages, uploaded invoices and retrieved documents remain untrusted; the model provider is another data-processing boundary. The assistant must not inherit unrestricted database or payment access.

A malicious attachment could request an export of other customers’ balances or a refund to a different account. Separate read-only retrieval from correction proposals. The backend binds every lookup to the authenticated customer and requires an authorized employee to approve the exact amount, account and reason before execution. A changed proposal invalidates approval; repeated requests cannot replay the same transaction.

Before release, test cross-customer access, malicious retrieved text, unexpected tool parameters, duplicate operations and approval bypass using synthetic accounts. Record blocked actions and residual failures. In operation, correlate approvals with ledger changes, limit transaction exposure, alert on unusual exports and provide an emergency tool shutoff. Retain essential evidence without recording unnecessary customer data. This reduces exposure without claiming that the agent has become immune to manipulation.

13. Common implementation mistakes

An application-only review misses corrupted training data, compromised artifacts and retraining feedback. Treating retrieved documents as instructions or granting agents broad write permissions converts content manipulation into operational harm. Ignoring behavior monitoring leaves targeted failures invisible even when availability dashboards remain green.

Cloud providers do not manage every customer integration risk. Unassessed third-party models, missing update review and confidence in one successful test leave assurance outdated. Confusing AI governance certification with technical protection hides remaining weaknesses. Define which controls belong to the provider, the application team and the business owner, then verify that the handoffs actually work.

14. Conclusions

ISO/IEC 27090 offers a focused starting point for AI cybersecurity discussions. Effective protection connects data, models, integrations and operations to business consequences. Traditional cybersecurity remains the foundation; AI-specific assessment adds questions about learned behavior, untrusted context and delegated actions. Keep evidence current, test significant changes and monitor residual risk. Security is a continuing engineering and management responsibility, not a property acquired once by adopting a standard.

How Can IO Consulting Support Your Organization?

Secure AI adoption requires systematic assessment of technology risks, information security controls and third-party dependencies. IO Consulting helps organizations assess cybersecurity risks, improve IT governance and security controls, and apply relevant international standards.

• IT audit and governance
• Information security management