Key takeaways
- Data poisoning is listed as LLM04 ("Data and Model Poisoning") in the OWASP Top 10 for LLM Applications 2025 and is one of the nine threats ISO/IEC 27090:2026 describes in clause 6. The standard lists direct model poisoning as a separate threat.
- Companies that train no models of their own are exposed too: a retrieval-augmented generation (RAG) chatbot that answers from a wiki, shared drives, or tickets treats every manipulated page as knowledge. In the PoisonedRAG experiments (USENIX Security 2025), five crafted texts per target question in a database of millions of texts were enough for a 90 percent attack success rate.
- A large volume of data does not dilute the poison. In an October 2025 study by Anthropic, the UK AI Security Institute, and the Alan Turing Institute, 250 crafted documents were enough to plant a simple backdoor in models ranging from 600 million to 13 billion parameters.
- In the ISO 27001 risk process, data poisoning belongs in the risk assessment under clause 6.1.2. It is treated mainly through A.5.9 (inventory), A.5.19 to A.5.21 (suppliers and the ICT supply chain), A.8.25 (secure development), and A.8.16 (monitoring).
- Under Article 15(5) of the EU AI Act, providers of high-risk AI systems must, where appropriate, include measures against data poisoning and model poisoning. These obligations apply from December 2, 2027, for Annex III systems and from August 2, 2028, for Annex I systems.
Data poisoning sounds like a problem for companies that train their own AI models. Most companies with an ISO 27001 ISMS do not: they call a language model through an API, connect it to their wiki, and let it answer questions from customers or employees. That is exactly where the risk sits. Whoever can change the data an AI system learns from or reads can change its answers.
This article is for the person responsible for the ISMS who now has to work out where data poisoning reaches their own company, how the risk gets into the risk register, and which measures actually hold up.
What is data poisoning?
Data poisoning is an attack in which someone manipulates the data used to train, fine-tune, or feed an AI model in order to change how it behaves. The model then learns or reads something false and repeats it with the same confidence as everything else. The OWASP list explicitly covers pre-training data, fine-tuning data, and the embeddings a RAG system works with.
In our overview of the AI security standard ISO 27090, data poisoning is one of nine threats. This article covers that one threat, from the point of view of a company that relies on third-party models.
Data poisoning, model poisoning, and backdoors
The three terms are often used interchangeably, but they describe different things. In data poisoning, the attacker targets the data. In model poisoning, which ISO 27090 calls direct model poisoning, the attacker manipulates the model itself: its parameters or a pre-trained component you build on. A backdoor is not a third route but a possible result of either attack. The model behaves normally until a specific trigger appears in the text.
Three examples show the range:
- Corrupted training data: A filter for incoming messages is regularly retrained on user feedback that marks a message as "not spam." Over several weeks, an attacker uses a handful of accounts to mark their own phishing emails as legitimate. The model learns to let exactly that kind of message through.
- A backdoor in a public model: A team downloads a freely available model from a public repository and fine-tunes it. The model contains a backdoor that skips safety checks when it sees a rare string of characters. No standard test finds it, because no test case contains that string.
- A poisoned knowledge base: Someone edits the page in an internal wiki that lists the bank details for refunds. From the next indexing run onward, the customer chatbot that answers from that wiki gives out the wrong IBAN.
A common misconception: data poisoning requires access to your infrastructure. In the first two examples, the attacker needs no access to your systems at all; they mark messages from an ordinary user account or publish a model your team downloads. According to the study by Anthropic, the UK AISI, and the Alan Turing Institute, the amount of poison needed does not depend on the size of the model: a small, fixed number of documents was enough. The study only tested a harmless backdoor that produces gibberish, though, and the authors leave open whether the result holds for larger models and more harmful goals.
Where data poisoning hits companies that only use AI
Companies that train no models meet poisoned data in three places: in the knowledge base of a RAG system, in their own fine-tuning data, and in models or datasets from suppliers. In all three cases, treating the risk is the job of your ISMS, not of the foundation model provider.
The mistake many teams make: "We don't train models, so poisoning isn't our problem." The provider of the base model looks after its own training data. It knows nothing about your Confluence, your ticket history, or the datasets your team downloads from the internet.
A RAG knowledge base built from wikis, drives, and tickets
For every question, a RAG system retrieves matching passages from a knowledge base and hands them to the language model as the basis for its answer. That knowledge base is usually filled automatically: from a Confluence space, a SharePoint site, a shared drive, or the ticket history. Anyone who can write there also writes into the chatbot's knowledge. In many companies, that means every employee, external guest accounts, and, for tickets, the customers themselves.
For companies that only use AI, RAG poisoning is usually the most obvious entry point. The researchers behind PoisonedRAG reached a 90 percent success rate with five crafted texts per target question, even though the database held millions of texts. The reason: a text tailored to one question is preferentially retrieved for that question.
Fine-tuning on your own data
If you adapt a model to your own examples, such as resolved support cases or past proposals, those examples become training data. If some or all of them come from outside, an attacker can shape them. Unlike RAG, the damage is then stored in the model itself. Correcting the source does not repair the model; you have to retrain on cleaned data.
Models and datasets from suppliers
The third place is the supply chain. You use a foundation model through an API, an embedding model for search, a freely available model, or a dataset from a public repository. You cannot inspect the training data of these components. If one of them was poisoned, you inherit the problem with the download. For your ISMS, this is a supplier risk like any other and belongs in the assessment under A.5.19 to A.5.21.
Data poisoning in the ISO 27001 risk process
Data poisoning belongs in the risk assessment under ISO 27001 clause 6.1.2 like any other threat: with the affected asset, likelihood, impact, and risk owner. Three questions drive the assessment. Who can change the data the system learns from or reads? Can you show where the model and the data come from? And how would you notice that its behavior has changed?
That gives you a rule of thumb. A system that answers from a space with five named editors, and whose output a person reviews, carries a low risk. A system that draws on openly editable sources, talks directly to customers, and runs on models of unknown origin carries a high one.
Both assessments depend on a complete inventory under A.5.9. It covers not just the AI systems themselves but also the data sources that feed them and the models they are built on, each with its origin and owner. A dataset that is not recorded as an asset has no owner to decide who may write to it. How this inventory fits into the certification process is covered in our guide to ISO 27001 certification.
Which Annex A controls apply
Annex A of ISO 27001:2022 does not name this attack. Existing controls cover the critical points once you extend their scope to AI systems and their data. The table below maps typical scenarios; it is a working interpretation, not part of the standard.
| Scenario | Risk | Control (ISO 27001:2022, Annex A) | Measure |
|---|---|---|---|
| RAG chatbot answers from the company wiki | A manipulated page gives customers false information, such as wrong bank details | A.5.9 Inventory of information and other associated assets; A.5.15 Access control | Define the indexed sources; restrict write access to those spaces; review changes before each indexing run |
| Ticket history feeds the knowledge base or fine-tuning | Outsiders shape the data the system learns from or reads | A.8.25 Secure development life cycle; A.8.29 Security testing in development and acceptance | Do not ingest external content unchecked; validate the dataset before every training run |
| Fine-tuning a model on your own data | A backdoor or systematic bias in the adapted model | Clause 6.1.2 Risk assessment; A.8.25 Secure development life cycle | Version the dataset; review samples; evaluate the model against a fixed test set before release |
| Foundation model from a third-party API | Unknown origin of the training data; model changes without notice | A.5.19 to A.5.21 Supplier relationships and ICT supply chain; A.5.23 Cloud services | Ask the provider about data provenance and poisoning safeguards; require notice of model changes in the contract |
| Freely available model or dataset from a public repository | Manipulated weights or data (direct model poisoning) | A.5.21 ICT supply chain; A.8.25 Secure development life cycle | Source only from approved repositories; verify checksums; record the origin in an ML bill of materials |
| Every AI system in production | The poisoning goes unnoticed | A.8.15 Logging; A.8.16 Monitoring activities | Compare answers to fixed reference questions regularly; report deviations to incident management |
Our ISO 27090 overview places both forms of poisoning under clause 6.1.2, A.5.21, and A.8.25; the table adds inventory, access control, and monitoring. Because clause 6.1.3 makes clear that Annex A is not exhaustive, you can cite ISO 27090 in your Statement of Applicability as the source of additional AI controls. How all 93 controls are structured, and what evidence an auditor expects for each, is covered in our overview of the ISO 27001 Annex A controls.
Data poisoning safeguards that actually work
The most effective safeguards against data poisoning start at the data source, not at the model. Detecting poisoning after the fact is hard: a model with a backdoor answers every normal test question correctly, and a manipulated wiki page looks like any other. If you only start looking at the outputs, you are searching for a trigger you do not know.
Five measures have proven themselves:
- Data provenance and write access: Define which sources an AI system may read, and restrict write access to exactly those spaces. Log every change, so that in an incident you know which version was indexed when.
- Supplier and model assessment: Ask model providers where their training data comes from, how they protect it against manipulation, and how they announce model changes. Source freely available models only from approved repositories and verify their checksums.
- Validation before fine-tuning: Version every training dataset, review samples and outliers, and compare the new model with the old one against a fixed test set before release.
- Output monitoring: Ask the system the same reference questions on a schedule and compare the answers. If an answer changes for no known reason, treat it as an incident, not as noise.
- Red teaming: Test the system deliberately by loading crafted documents into the knowledge base in a test environment. ISO 27090 recommends red teaming in clause 5.7; a classic penetration test only checks the infrastructure.
The OWASP project maintains an up-to-date collection of attack patterns and countermeasures in its description of LLM04. It also recommends tracking where data comes from and how it is transformed, for example with an ML bill of materials (ML-BOM).
Example: a support chatbot that answers from Confluence
A fictional SaaS company with 120 employees, certified to ISO 27001, runs a support chatbot on a hosted language model. The chatbot answers from the Confluence wiki, which is fully reindexed every night. The numbers in this example are for illustration: the wiki holds about 2,400 pages, 85 employees have edit rights, and 12 external freelancers have guest accounts.
In the risk assessment, the ISMS team rates the likelihood as medium, because a single compromised account out of 97 is enough. The impact is high: if the chatbot gives a customer the wrong bank details, the result is direct financial loss, and a data protection problem soon follows.
The treatment changes existing controls rather than inventing new ones. The chatbot now reads only the "Help Center" space, which has six named editors (A.5.9, A.5.15). A second person approves changes in that space before they are indexed (A.8.25). After every indexing run, the chatbot answers 40 reference questions, and the answers are automatically compared with the previous week (A.8.16). The contract with the model provider requires advance notice of model changes (A.5.20). The residual risk drops from high to medium and is accepted by management. It does not reach zero, because one of the six editors could be compromised too.
What regulations and standards say about data poisoning
Three frameworks address data poisoning explicitly, with different degrees of obligation: ISO 27090 as guidance, the EU AI Act as law for high-risk AI, and the 2027 SOC 2 draft as a future audit benchmark.
ISO/IEC 27090. Published on October 14, 2026, the standard lists data poisoning and direct model poisoning as separate threats in clause 6. Clause 5.5 covers supply chain management and clause 7 the countermeasures. ISO 27090 is guidance; there is no certification against it. Its recommendations reach an ISO 27001 ISMS or an AI management system under ISO 42001 through your risk treatment.
EU AI Act. Article 15(5) requires high-risk AI systems to be resilient against attempts by unauthorized third parties to alter their use, outputs, or performance. The technical solutions include, where appropriate, measures against attacks on the training dataset (data poisoning) and on pre-trained components (model poisoning). The obligation falls on the provider; if you only deploy such a system, you check it as part of your supplier assessment. Which systems count as high-risk is explained in our article on high-risk AI under the EU AI Act.
SOC 2. The AICPA's draft of the 2027 Trust Services Criteria names data poisoning among its new AI points of focus. Comments are open until January 15, 2027; if the draft is approved, it applies to engagements that begin on or after December 31, 2027. The outcome is still a SOC 2 report. What else the draft changes is covered in our article on the SOC 2 Trust Services Criteria 2027.
As a technical reference for test cases, the NIST AI 100-2 E2025 taxonomy from March 2025 is also useful; it describes poisoning attacks as a distinct class of attack.
How Kertos covers AI risks in your ISMS
With Kertos, data poisoning sits in the same risk register as your other information security risks, not in a separate spreadsheet for AI. You inventory your AI systems once, assess the related risks, and link their treatment to Annex A controls, policies, and evidence. Your Statement of Applicability then shows which measures apply to which AI risk.
Kertos covers ISO 27001 and ISO 42001 on one platform. For the AI management system, there are pre-mapped ISO 42001 controls and an AI risk library aligned with the EU AI Act and ISO/IEC 23894. Kertos's certified experts help you decide which of your AI systems carry a relevant poisoning risk and how to document the treatment so it holds up in the audit.
Want to see how your own RAG chatbot or fine-tuning pipeline looks in the ISMS? Book a demo and bring your example.
Frequently asked questions
What is data poisoning?
Data poisoning is an attack in which someone manipulates the data used to train, fine-tune, or feed an AI model through a knowledge base, in order to change how it behaves. The OWASP Top 10 for LLM Applications 2025 lists the risk as LLM04 "Data and Model Poisoning." ISO/IEC 27090:2026 describes data poisoning in clause 6 as one of nine threats to AI systems.
What is the difference between data poisoning and prompt injection?
Data poisoning manipulates the data a model learns from or draws its knowledge from, so it affects every later answer. Prompt injection smuggles instructions into a single input or a document the model is processing, and hijacks that one task. In a RAG knowledge base the two overlap: a crafted page with false facts is data poisoning, while a page with hidden instructions is indirect prompt injection.
How do you detect data poisoning?
After the fact, only with difficulty, because a poisoned model answers normal test questions correctly until an unknown trigger appears. Warning signs include answers to fixed reference questions that change for no reason, unusual edits in indexed sources, and outliers in training datasets. Controlling the provenance of data and who can write to it, and logging every version, is more effective than hunting for the poison.
Does data poisoning also affect companies that only use AI?
Yes. Any company that connects a language model to a knowledge base built from a wiki, drives, or tickets, fine-tunes on its own data, or uses models and datasets from third parties can take on poisoned data. The foundation model provider only protects its own training data. For every other data source, treating the risk is the job of your own ISMS.
Which ISO 27001 controls help against data poisoning?
Annex A of ISO 27001:2022 does not name data poisoning, but several existing controls apply. The most important are A.5.9 for the inventory of data sources and models, A.5.15 for write access, A.5.19 to A.5.21 for suppliers and the ICT supply chain, A.8.25 for the secure development life cycle, and A.8.16 for monitoring. The risk itself is assessed under clause 6.1.2.
