Summary
- ISO/IEC 27090:2026 addresses AI-specific threats such as prompt injection and data poisoning.
- The standard was published internationally on 14 October; BSI's UK announcement came on 27 October.
- BSI's survey separates all respondents reporting an AI failure from the smaller group reporting a security breach.
The British Standards Institution has highlighted new international guidance on security threats affecting artificial intelligence, alongside survey results suggesting that organisations are deploying AI faster than their governance procedures are maturing.
ISO/IEC 27090:2026 was published internationally on 14 October. BSI’s UK announcement on 27 October provides the current news development and includes research involving 1,287 business leaders from multiple countries.
The standard describes ways to identify and mitigate risks affecting models, datasets and AI applications. It does not establish a new standalone certification that proves a product is secure, and its guidance should be distinguished from legally binding regulatory requirements.
How AI changes established security assumptions
Traditional cybersecurity controls address vulnerabilities in software, infrastructure and human processes. AI systems add attack surfaces involving training information, model inputs, generated outputs and integrations that allow software to act on external services.
Data poisoning involves manipulating information used to train or update a model. A compromised source might change predictions without introducing an obvious defect in the application code, which makes the provenance and validation of training datasets significant.
Prompt injection occurs when an attacker embeds instructions in material an AI application is supposed to read, such as documents or web pages. If the model treats this lower-trust content as instructions, it may disclose information or change the behaviour of a connected workflow.
Model extraction and theft involve attempts to reproduce or obtain access to proprietary systems, while other attacks aim to recover sensitive information from training material or prompts. Different threats require different testing and monitoring rather than a single generic AI security checklist.
An enterprise assistant may use secure authentication while still misinterpreting a malicious document fetched under a legitimate user’s authority. Controls must therefore cover not only user access but also the trust assigned to external information.
Guidance alongside other standards
ISO/IEC 27090 complements existing information security management frameworks and AI management guidance. ISO/IEC 27001 covers information security management systems, while ISO/IEC 42001 addresses governance across an organisation’s AI activities.
The new guidance helps teams examine AI-specific vulnerabilities through that broader management context. Adopting it does not automatically demonstrate that security controls operate effectively or that an application has passed independent adversarial testing.
Controls may include documented sources for training data, limits on model and tool access, testing for malicious prompts, incident response procedures and monitoring of changes that affect model behaviour. Implementations will vary with the functions and permissions of each AI system.
An internal forecasting model operating on approved numerical data has a different risk profile from a public chatbot connected to account records. Testing needs to reflect the actual workflow, not simply the brand or type of foundation model being used.
Survey findings require their denominators
BSI says 75% of its 1,287 respondents reported an AI failure in their organisation during the previous year. Of those reporting an AI failure, 30% said the incident led to a security breach. The second figure refers to that subset, not all respondents.
Separately, only 38% of respondents said their organisations had established an AI governance programme, while 78% expected to increase AI investment. Those are reported survey findings, not an independently verified census of business technology practices.
Survey design, respondent selection and definitions can influence results. In particular, the category of AI failure can cover different kinds of incidents, and respondents’ assessments may vary according to their role and access to internal information.
The reported gap between investment plans and formal governance suggests a reason to examine procurement procedures. Teams may introduce tools through existing software providers or department-led experiments before security teams have evaluated data access and operational permissions.
Agents and consequential actions
Agentic AI introduces questions about how software may call business services and perform tasks without repeated manual instructions. If the system can update supplier details or send confidential information, malicious input may have effects beyond a misleading answer.
Permission design, approval workflows, auditability and rollback capability become important. A compromised prompt or inaccurate model output should not automatically gain the privileges of the employee or system that originally initiated an otherwise legitimate task.
The BSI release and international standards framework provide useful references for identifying AI-specific threats. Effective assurance still depends on documented implementation, independent testing and a demonstrated capacity to respond when systems fail.
A standard can help different teams use consistent terminology, but implementation often spans procurement, risk, engineering, legal and security staff. Without clear ownership, an assessment may identify a vulnerability while leaving no one responsible for correcting it.
Supplier questionnaires should distinguish between the foundation model, the application that wraps it and the business systems it can access. Each layer may have a different operator, update process and contractual arrangement, creating gaps if responsibility is assumed rather than assigned.
Organisations should also retest systems after model upgrades or changes in data connections. Security behaviour demonstrated with one release cannot automatically be assumed to persist when instructions, tools and underlying model behaviour change.
