The Chatbot Your Certificates Never Saw Coming

Imagine a security lead at a mid-sized company. Two years ago, her team earned ISO 27001. Then, this spring they added ISO 42001 to show they take AI governance seriously. Both certificates are framed in the lobby, and she has every reason to feel covered.

However, a colleague pastes a customer’s email into the company’s new AI assistant. There is a line of instructions buried in that email meant for the assistant, not for the colleague. The assistant obeys it.

When she goes back through her management system, she can’t find a broken control. Everything worked as written, but nobody had written a control for this.

That’s the gap ISO/IEC 27090 was going to fill. ISO released it this October as a standard on security threats to AI systems (1). It’s guidance rather than a set of requirements, so there’s no certificates to earn. What you get instead is a practical look at how AI systems get attacked, how to notice it happening, and how to respond at every stage of a system’s life (2).

Five ways AI gets attacked

ISO’s overview names more than five threats (2), yet the following five grabs the headlines.

Poisoning is the one that people find the most unsettling. Slip bad data into a model’s learning system, and it picks up bad habits. A joint study by Anthropic, the UK AI Security Institute and the Alan Turing Institute found that 250 poisoned documents could plant a backdoor in models ranging 600 million to 13 billion parameters (3). The backdoor was simple and low-stakes, so it doesn’t prove every model is that fragile. It does bury the assumption that an attacker needs to control a big slice of the data.

Extraction is quieter. Someone sends your model a steady stream of perfectly ordinary requests and slowly rebuilds a copy, without getting caught by access controls because the caller is allowed in. You have to watch how the model gets used (2). [OWASP now files under this under unbounded consumption (5).]

Evasion means crafting an input, a subtly doctored image for instance, that fools a finished model at run time. Membership inference asks something sneakier: was this particular person’s record in the training data? That one hurts the most when the data was personal. NIST’s attack taxonomy covers both, filing the second under privacy attacks (7).

Prompt injection is our security lead’s bad afternoon. OWASP still ranks it first among LLM risks (4), and it doesn’t care whether the instructions come straight from a user or hide in a web page, a document or an email the model happens to read.

The standard goes further, into model inversion, direct model poisoning and risky outputs (2).

Where it sits next to 27001 and 42001

Think of three standards asking three different questions.

ISO 27001 asks whether you run security as a disciplined system. The introduction to 27090 sends readers back to 27001 and 27002 for established practice, then adds detail on AI-specific threats and assets (2). It builds on that foundations without replacing it.

ISO 42001 asks whether the organizations manages AI responsibly, meaning its duties, risks and opportunities. ISO itself says security belongs in that picture but isn’t all of it (2).

27090 takes the narrower, more technical leftover: how would someone attack this system, and would we notice?

One practical reading can be feeding 27090’s threats into the risk assessments you already run for the the other two. The certificates remain your proof. This fills in what the paperwork took for granted.

A note on regulation

The EU’s timetable moved this summer. The Digital Omnibus on AI pushed high-risk obligations for Annex III systems from August 2026 to December 2027 (6). That’s a delay, not a pause, and security groundwork takes time anyway.

Where to start

ISO’s own suggestions are refreshingly plain (2). First, listing every AI system you build or buy, including the ones tucked inside vendor products. Second, tracing where data and models come from and how they change. Third, getting security, AI, data and procurement people into one room. Finally, looking for gaps in what you already do, and decide who would notice something odd and who would act.

One security lead did roughly that after her bad afternoon. The certificates stayed on the wall. What changed was a list of every model in use, a named owner for each, and a habit of asking what someone could feed it before anything launches.

That habit is most of what 27090 teaches.

Sources

[1] ISO, ISO/IEC 27090:2026 catalog page: https://www.iso.org/standard/27090

[2] ISO, “ISO/IEC 27090 explained”: https://www.iso.org/insights/ISO-27090-explained

[3] Anthropic, UK AI Security Institute and Alan Turing Institute, “A small number of samples can poison LLMs of any size”: https://www.anthropic.com/research/small-samples-poison

[4] OWASP, LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[5] OWASP, LLM10 Unbounded Consumption: https://genai.owasp.org/llmrisk/llm10-unbounded-consumption/

[6] Future of Privacy Forum, “The AI Act implementation timeline: what changes under the AI Omnibus?”: https://fpf.org/blog/the-ai-act-implementation-timeline-what-changes-under-the-ai-omnibus/

[7] NIST AI 100-2e2025: https://csrc.nist.gov/pubs/ai/100/2/e2025/final