ISO/IEC 27090:2026: AI security threats, governance and technical tests

Explore AI-specific attacks, trust boundaries and governance, then test one AI feature with the MicroApz checklist.

MicroApz Security · Updated 2 November 2026

An organisation enables an AI assistant inside a familiar business application. It can search internal files and draft answers. The launch feels like a software update—until a manager asks whether the assistant can retrieve documents the requesting employee should not see, or whether a malicious document can steer its response.

Those questions sit at the intersection of established security controls and AI-specific threats. ISO/IEC 27090:2026, published in October 2026, gives organisations guidance for understanding threats and compromises to AI systems and considering how to detect and mitigate them.

Open the phone-size infographic for larger text ↗

Illustrative review questions from MicroApz; this graphic is not a reproduction of the standard.

What does ISO/IEC 27090 cover?

ISO/IEC 27090:2026 addresses security threats and compromises to AI systems across their life cycle, their consequences, and approaches to detection and mitigation. It is relevant to organisations that develop or use AI and is not limited to generative AI. It complements conventional information-security controls and AI governance; it does not replace them.

This article is an independent practitioner’s synthesis of the published 2026 edition and practical MicroApz examples. It is not a substitute for the standard, a complete conformity assessment or a certification scheme. For the official scope and availability, see the ISO catalogue.

Five questions to take into a first review

1. Purpose and ownership: What feature is enabled, who approved the use, and what decisions can it influence?
2. Data: What can enter a prompt or be retrieved? Are existing access permissions preserved?
3. Actions: Can the feature send, modify or delete anything? Which actions require approval?
4. Testing: Can a user retrieve a restricted record, or can instructions in a document redirect the workflow? Test safely with synthetic data.
5. Operations: Who monitors unusual behaviour, handles incidents, and retests after a material model, supplier or connector change?

What the technical scope includes

The published edition combines three perspectives. Its first major area applies information security to AI: governance, zero trust, secure engineering, supply chains, threat modelling and red teaming. Its second examines compromises, their consequences and example detection and mitigation approaches. Its third looks at how safeguards interact and endure during operation. The informative annexes connect threats to assets and lifecycle stages, discuss conventional attacks against AI and explore federated learning. The examples below are selective implementation guidance, not a reproduction of the standard’s tables.

These examples are engineering interpretations, not ISO-prescribed controls. Threats vary by architecture; a hosted AI adopter may not control training pipelines or model weights. Assign supplier questions and retain product-specific answers for those boundaries. NIST’s adversarial machine-learning taxonomy provides detailed terminology and attack categories.

A technical architecture review: retrieval and agent actions

Map the requesting identity → retrieval service → document index → model → tool gateway → downstream application. Mark every trust boundary, service identity, data store and outbound network path. Then verify these invariants:

• Retrieval authorisation: enforce the requester’s permissions on the retrieved content, including cached chunks and citations. Test access revocation and stale indexes.
• Tool execution: the gateway validates identity, allowed action, resource and parameters; the downstream system performs its own authorisation. A model instruction is not an access-control boundary.
• Approval and replay: bind approval to the specific action and parameters; re-check authorisation when executing and prevent stale or replayed approvals.
• Output handling: treat generated text as untrusted when it becomes HTML, SQL, code or an API parameter. Use context-appropriate validation and encoding.
• Observability: correlate user request, retrieved document identifiers, model version, tool call, policy decision and outcome while minimising sensitive prompts in logs.

RAG and prompt instructions do not eliminate injection. Use layered controls, test their failure modes and prevent a successful instruction from acquiring permissions the user did not have. See OWASP’s prompt-injection guidance.

This is a MicroApz architectural example supported by OWASP and NIST’s definition; it is not a diagram reproduced from ISO/IEC 27090.

Run a repeatable negative test

1. Create two synthetic users: one can read document A; neither can access document B. Record the authorised scope and obtain permission for the test.
2. Put a harmless marker and a request to invoke a non-destructive test action in a synthetic document A. Index it through the normal ingestion path.
3. Ask both users the same legitimate question. Confirm that A is retrievable only by its authorised user. Capture retrieved identifiers, answers, proposed tool calls, authorisation and approval decisions.
4. Expected: A is returned only to its authorised user; B is not returned to either user; no unauthorised tool action occurs; a high-impact action cannot execute without the configured approval. Document any incorrect answer separately from actual privilege escalation.
5. Repeat after access revocation, cache refresh and a material model or connector change. Preserve test version, expected versus observed result, logs, owner and retest date.

A pass demonstrates only the tested cases and configuration. Model behaviour can vary; include variations and regression testing rather than relying on one prompt.

Governance and supplier handoffs

Maintain a system inventory with business owner, technical owner, model and dataset versions, intended use, access boundaries, supplier dependencies and prohibited uses. Before release, agree test criteria, residual-risk acceptance, incident escalation, rollback and data-retention responsibilities. Require suppliers to identify what they control, what customers must configure, how changes are communicated and what evidence can be independently checked.

Post-quantum cryptography: AI services also rely on ordinary cryptographic infrastructure, so include their certificates, signing and key-establishment dependencies in your wider post-quantum inventory. The supplied published edition discusses cryptographic protections and provenance, but a search of its extractable text found no mention of “quantum” or “post-quantum”. This is a related infrastructure action, not a claim that the standard specifies a PQC transition.

Protect the whole lifecycle, not just the model API

Clause 5 addresses governance, zero trust, secure engineering, supply chain, threat modelling and red teaming; the informative annexes extend the view to assets and conventional attacks. The practical question is whether the safeguards remain effective as the system changes hands.

Mitigations can conflict: test the portfolio

The standard discusses interactions among safeguards and the possibility that model performance or mitigation effectiveness deteriorates. An adversarially trained classifier may improve against the perturbations used in training while remaining weak against a different attack. A detector can flag unfamiliar but legitimate input, and an attacker can craft malicious input that looks familiar. Measure ordinary accuracy, false alarms and attack outcomes together; record the test conditions. An out-of-distribution alert is a signal for review, not proof of attack.

Per-user throttling can slow repeated probing without proving that extraction or inversion is impossible. Model-size optimisation and privacy-preserving methods can also affect utility, performance and attack exposure; evaluate the actual model and threat assumptions rather than treating any technique as a universal fix.

Illustrative release decision: a team evaluates a new classifier against a fixed benign test set and two authorised perturbation families. It records error rates for each, compares them with approved thresholds, and holds deployment when a mitigation improves one case but exceeds the acceptable false-rejection rate. The business owner decides whether to restrict use or accept residual risk after remediation. Thresholds are organisation-specific.

Privacy, oversight and provenance are engineering choices

• Limit data exposure: define what data is necessary, who can access it and how long inputs, outputs and training artefacts are retained. Evaluate encryption and other privacy techniques against performance and operational constraints.
• Make oversight actionable: give reviewers the proposed action, target, supporting context and authority to reject or halt it. A routine confirmation click can become ineffective if the reviewer lacks context or time.
• Trace changes: connect source and transformation history to dataset, model, prompt or configuration version, deployment and test result. Protect provenance records from unauthorised change.
• Monitor and retest: correlate relevant identities, timestamps, model version, policy decisions and outcomes. Determine which inputs or outputs are necessary for investigation, and protect and retain them proportionately.

Federated learning changes the boundary

In federated learning, participating clients train locally and share updates for aggregation. Keeping raw data local can reduce central collection, but it does not automatically eliminate privacy leakage or poisoning. A malicious participant can influence updates; model transfers, the aggregator and heterogeneous devices add attack surfaces. Authenticate participants, protect transfers, assess update integrity and evaluate privacy and utility together. Apply these controls to the actual architecture; do not promise that federated learning by itself makes sensitive data impossible to infer.

Worked example: the document-search assistant

These are illustrative MicroApz review practices, not clause-by-clause requirements of ISO/IEC 27090. A failed test or missing evidence needs an owner and a decision; do not treat a vendor’s general security statement as proof of your tenant configuration.

Download the 20-check AI adoption checklist

Use the same MicroApz checklist shared on LinkedIn to review one AI-enabled feature across approval, data protection, permissions, testing and operation. Record the evidence, gaps and an owner for each answer.

Download the AI adoption security checklist (PDF)

The checklist is an independent practical aid informed by ISO’s public material and other guidance. It is not the ISO standard, a full-standard conformity assessment or a certification scheme.

Bring a decision to leadership

Summarise the use case, business benefit, material gaps, potential impact, evidence and proposed action on one page. Ask the accountable decision-maker whether to proceed with documented residual risk, restrict the feature while gaps are addressed, or hold it pending critical evidence. Set an owner and a review date.