Framework · Security of AI systems
ISO 27090 describes how attackers can compromise AI systems and how you detect and contain such attacks. Sightadel helps you assess these threats for each AI system and manage the controls where your evidence for ISO 27001, ISO 42001 and the EU AI Act already lives.
What it is about
The first edition of ISO 27090 was published in October 2026. The standard deals with security threats that specifically affect AI systems. It describes the consequences an attack can have across the life cycle of a system and how such attacks can be detected and mitigated. It is intended for organisations of every type and size that develop or use AI systems.
It covers attacks that do not exist in this form for conventional software. ISO gives poisoned training data and theft of a model through seemingly harmless queries as examples. Expert articles on the standard list further types, such as crafted inputs that deceive a model, prompt injection or inferences about the training data. The standard also helps to clarify what needs protecting in the first place, from the training data to the finished model.
ISO 27090 is guidance. It contains no requirements against which a body certifies, and no management system of its own. ISO positions it as a complement to ISO 27001 and ISO 27002: if you run an ISMS, you add the AI-specific threats to your risk assessment and select suitable controls. So far the standard is only available in English.
Customers and procurement ask how you protect models and training data against manipulation. The standard gives you a shared language for these answers and a list of attacks you should have checked.
Even if you only use a language model through a provider, you are affected, for example when text from emails or documents makes the system take the wrong action. Here the focus is on choosing the provider, configuration and monitoring.
If you run ISO 27001 or ISO 42001, you do not need a new process. The threats from ISO 27090 go into your existing risk assessment, the controls into your existing treatment plan.
Requirements
Summarised in our own words. The original text in its current version is always authoritative.
You know which AI systems you develop or use and which parts of them need protecting: training data, models, inputs and outputs.
In SightadelYou record AI systems and their components as assets with an owner. An AI inventory from ISO 42001 can be reused.
The types of attack that are conceivable for your systems are known, for example data poisoning or model theft, as is the damage a successful attack would cause.
In SightadelYou record threats per AI system in the risk register, assessed and linked to the assets affected.
Attacks are assigned to the phases in which they take effect: development, operation and updating of the model.
In SightadelOpen items from every phase become action plans with an owner and a due date.
The consequences of an attack are estimated, especially where AI is involved in safety-critical applications or important decisions.
In SightadelThe assessment sits with the risk, the rationale in the comment. The activity log shows who decided what and when.
For the relevant threats, controls are selected that detect attacks or limit their effect.
In SightadelEvery control with status, owner and evidence. The same control can also cover a requirement from ISO 27001 or ISO 42001.
Training data, pre-trained models and AI services from third parties are treated as a possible point of entry. You know where they come from and who can change them.
In SightadelYou assess suppliers of data, models and AI services in the Vendors module, with questionnaire and evidence.
In operation you watch for signs of attacks, such as unusual query patterns. Incidents affecting AI systems go through the usual incident process.
In SightadelFindings from incidents become actions with a deadline, and the history stays visible in the activity log.
The AI-specific threats are part of the ISMS risk assessment, the controls part of the treatment plan.
In SightadelYou link evidence once and use it for ISO 27001, ISO 42001 and the EU AI Act.
Process
Two to four months to a threat analysis and control plan for the most important AI systems if an ISMS is already running. Implementing technical controls can take longer.
List all AI systems, including purchased services. For each system, note which data, models and interfaces belong to it.
Go through the standard to see which types of attack are relevant to which system and in which phase they take effect.
Estimate consequences and likelihood, critical systems first. The results go into the existing risk register.
Select countermeasures, name owners, back up implementation with evidence. Plan technical controls together with development and operations.
Watch operations, reassess after model changes and when new types of attack become known, and feed the results into the management review.
Ready to start
Clarify these questions early and you save weeks later on. In Sightadel they are set up as your first tasks.
Division of work
If software filled everything in, the standard would not serve its purpose – and the auditor would notice. That is why it is clearly defined what stays with you.
From practice
From many years of consulting and certification practice: these are the points that cost the most time or lead to nonconformities in the audit.
Firewalls and access control do not help against poisoned training data or crafted inputs. Check the attacks that target the model itself separately.
Language models in standard software and cloud services count too. This is exactly where attacks through inputs work, even if you do not train a model of your own.
There is none for ISO 27090. Plan the evidence through the ISO 27001 or ISO 42001 audit or through an external review.
Implementing it helps with Art. 15 of the EU AI Act but does not prove compliance. Check legal obligations separately.
Without development and data owners, the threat analysis stays theoretical. Whoever builds or runs the model belongs at the table.
New models, data and types of attack change the situation all the time. Define triggers for reassessment and review critical systems regularly.
One piece of evidence, several frameworks
We deliberately do not give a percentage – it depends on your scope. Where requirements overlap, one piece of evidence is attached to all of them.
ISO describes ISO 27090 as a complement to ISO 27001 and 27002. The risk assessment, treatment plan, incident process and internal audit of the ISMS also carry the controls for AI systems.
ISO 42001The AI management system requires a risk assessment for AI systems. ISO 27090 provides the part on targeted attacks, and the AI inventory serves both.
EU AI ActArt. 15 requires robustness and cybersecurity for high-risk AI systems, explicitly also against data poisoning, model evasion and confidentiality attacks. ISO 27090 helps with implementation but is not a harmonised standard.
GDPRAttacks that allow inferences about training data can expose personal data. For privacy in AI, ISO is working on the sister standard ISO 27091, which has not yet been published.
Audit and evidence
You cannot be certified against ISO 27090. The standard is guidance and contains no auditable requirements. It becomes visible through the management systems you build it into: in an ISO 27001 or ISO 42001 audit, you show how you have assessed and treated threats to AI systems.
If you want an independent view, have the threat analysis and controls reviewed externally. Sightadel does not review. You choose a reviewer from our independent partner network or one of your choice, and no commission is paid for reviews, neither to us nor to the partners. The reviewer gets separate access in Sightadel to answers, rationales and evidence and cannot delete anything.
To the independent auditor networkISO 27090 concentrates on threats that only or mainly affect AI systems. It maps them to the life cycle, describes possible consequences and shows ways to detect and mitigate attacks. ISO's description of the standard explicitly mentions poisoning of training data and theft of a model through queries that look like normal use. It also stresses the consequences in safety-critical applications.
The standard does not redefine general information security. Access control, encryption, logging, vulnerability management and contingency planning remain the domain of ISO 27001 and 27002. ISO 27090 starts where these controls are not enough for AI, for example when an attacker changes the behaviour of a model through data or inputs without taking over a server.
Fairness, transparency or the impact on affected people are not its subject either. For those there is ISO 42001 with risk assessment and impact assessment for AI, and the EU AI Act. For privacy in AI, ISO is developing the sister standard ISO 27091. Anyone introducing the standard should know this boundary so that responsibilities are not assigned twice or not at all.
You buy the standard itself from ISO or a national standards body. You do not need a certification body, because there is no certificate. The Sightadel licence for ISO 27090: Price on request. If you already run ISO 27001 or ISO 42001 in Sightadel, you keep using the risk register, controls and evidence.
The biggest item is the time of specialists. A threat analysis for AI systems cannot be done by the information security team alone. You need people who know the models, data and interfaces: development, data owners, operations and, for purchased services, procurement. Expect several working sessions per critical AI system.
Implementing technical controls can be expensive, for example additional checks on training data, limits on queries or tests with deliberately crafted inputs. It pays to proceed by criticality and start with the systems where an attack would do the most damage. Where experience is lacking, you can add consulting as a package in the app.
In Art. 15, the EU AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity throughout their life cycle. The attacks named include data poisoning, model poisoning, crafted inputs for model evasion, confidentiality attacks and model flaws. This largely matches the topics of ISO 27090.
Even so, the standard is not proof of conformity. It is not a harmonised standard referenced in the Official Journal of the EU and therefore does not create a presumption that Art. 15 is met. CEN-CENELEC is drafting a separate European standard on the cybersecurity of AI systems under the regulation, which so far exists as a draft. Following the 2026 postponement, the obligations for high-risk systems apply from December 2027 for stand-alone systems and from August 2028 for AI in regulated products.
Whether your system counts as a high-risk system and which obligations follow from that is something you check separately, ideally with your legal advisers. Sightadel does not provide legal advice on this. For the legal obligations, Sightadel has a separate framework for the EU AI Act, which you manage with the same evidence.
The least effort arises when you use ISO 27090 as a source of knowledge for existing processes. In the risk assessment under ISO 27001, you add the threats from the standard for each AI system. The selected controls go into the treatment plan and, where they go beyond Annex A, into the Statement of Applicability as additional controls.
If you run ISO 42001, the AI inventory already gives you the list of systems, their purposes and owners. The AI risk assessment there asks about risks to the organisation and to affected people. ISO 27090 helps you fill the part on targeted attacks properly, rather than ticking it off with general statements on IT security.
In Sightadel, threats, controls and evidence are attached to the AI system concerned. You link the same control, for example a check on the origin of training data, to ISO 27001, ISO 42001 and the EU AI Act. That way you maintain it once and see in every framework where it counts. In the internal audit you then check whether the controls for AI systems work as planned.
In data poisoning, an attacker smuggles manipulated data into training so that the model later reacts wrongly or as the attacker wants. This matters above all if you train or fine-tune models yourself, for example with data from the internet, from customers or from service providers. Protection comes from known sources, checks before training and clear rights over who may change data.
In model theft, an attacker sends many queries and uses the answers to build a model that behaves similarly. This mainly affects providers whose model can be reached through an interface. Unusual query patterns and limits per user are obvious starting points here. If you only buy in AI, this attack usually concerns you less.
Systems with language models add prompt injection: instructions hidden in inputs, emails or documents make the system bypass rules or disclose data. This also affects companies that only use AI through a provider. Which of these attacks the standard describes in detail can be found in the text of the standard. Sightadel does not contain the wording.
As there is no certificate, nobody prescribes a particular set of documentation. Useful, and helpful in ISO 27001 or ISO 42001 audits, are a list of AI systems with the parts that need protecting, the threat analysis per system, the selected controls with rationale, and evidence that they are implemented and effective. Record who carried out which assessment and when.
AI systems change faster than many other systems. A new model at the provider, a new data set or a new interface can change the assessment. Define which changes trigger a new analysis and make the check a fixed step in procurement and release. After an incident or when a new attack becomes known, review the systems concerned outside the regular cycle.
In Sightadel, reassessments, vendor reviews, internal audit and management review run as recurring cycles with dates. In the Trust Center you show customers how you secure AI systems without putting together new documents for every request.
What it costs
You only pay for the frameworks you actually need. The editions differ in capacity and response time, not in subject-matter scope. If you run several frameworks, you save permanently. All prices, discounts and a calculator are on the pricing page.
The certification or audit body invoices its fees directly to you. If needed, you can add consulting as a package in the app.
Working materials
Checklists and templates for other frameworks are available under Resources.
Practical aids, not legal advice.
Terms
No. The standard is guidance without auditable requirements. In an ISO 27001 or ISO 42001 audit, however, you can show how you have assessed and treated threats to AI systems.
Yes. The first edition was published in October 2026, so far only in English.
Not automatically. In content, the standard fits the cybersecurity obligations for high-risk AI systems well, but it is not a harmonised standard. Whether and which obligations apply to you is something you check separately. Sightadel does not provide legal advice on this.
Often yes, on a smaller scale. Attacks through inputs such as prompt injection also affect services you use. The focus is then on choosing the provider, configuration, the system's permissions and monitoring.
ISO describes ISO 27090 as a complement to ISO 27001 and 27002. You build the AI-specific threats into the risk assessment of your ISMS and manage the controls in the same treatment plan.
ISO 42001 is the management system for AI with inventory, risk assessment and impact assessment. ISO 27090 provides expertise on targeted attacks that feeds into this risk assessment. A certificate exists only for ISO 42001.
The Sightadel licence: Price on request, with all details on the pricing page. On top come the copy of the standard and your internal effort. There are no costs for a certification body.
No. ISO standards are protected by copyright. Sightadel contains structure, guiding questions, templates and its own explanations, not the wording. You need a copy of the standard in-house.
Besides information security, the people who develop or run models, the data owners and, for purchased services, procurement. Without them the analysis stays superficial.
14 days, full access, no payment details. Everything you set up carries over into the paid plan.
