On 14 October 2026, ISO and IEC published ISO/IEC 27090:2026 – the first international standard dedicated to defending AI systems themselves against attack. For regulated enterprises in the EU, this changes the conversation about AI. Until now, a CISO assessing an AI-enabled GRC platform had to improvise their due diligence questions. Now there is a shared vocabulary of threats. Data poisoning, model compromise, indirect prompt injection and supply chain integrity are all mapped to the stages of the AI lifecycle.
At BCMLogic, we welcome this. Our customers are banks, insurers, investment firms and critical infrastructure operators. That is why we designed BCMLogic Next with audit in mind from day one. We assumed customers would scrutinise our AI the same way they scrutinise any other ICT service under DORA.
In this article, we show how the BCMLogic Next security architecture maps to the threat categories in ISO/IEC 27090. We also explain what this means for your due diligence.
What is ISO/IEC 27090?
The full title of the standard is ISO/IEC 27090:2026 “Cybersecurity – Artificial intelligence (AI) – Addressing security threats and compromises to AI systems”. It was published on 14 October 2026, after four years of work in ISO/IEC JTC 1/SC 27. This is the same committee that maintains ISO/IEC 27001 and 27002. Three things matter for practitioners:
- It is guidance, not a certifiable management system. There is no “ISO 27090 certificate”. The value of the standard is a structured catalogue of threats and controls that you can audit against.
- It protects the AI system, not organisational AI use in general. ISO/IEC 42001 tells you how to govern AI as an organisation. ISO/IEC 27090 tells you how to defend an AI system against an attacker. The two are complementary, and both assume a working ISMS (ISO/IEC 27001/27002).
- It covers the full AI lifecycle – design, data collection, training or grounding, deployment, operation and model updates. The standard explicitly notes that operational data can become future training data. In that case, poisoning risk extends far beyond the build phase.
ISO/IEC 27090 compared with ISO/IEC 27001 and ISO/IEC 42001
Why ISO/IEC 27090 matters right now
Early commentary on the standard makes a point we agree with: ISO/IEC 27090 is as much a due diligence tool as an engineering one. In Poland, one of the first to unpack it for compliance professionals was Dr Michał Nowakowski, in a Polish-language analysis on LinkedIn.
For EU financial entities, the timing is convenient. DORA has applied since January 2025. NIS2 is being enforced through national transposition laws across member states. The AI Act applies in stages. Following the Digital Omnibus amendments, obligations for high-risk AI systems will apply from 2 December 2027. ISO/IEC 27090 gives all three regimes a shared technical backbone for one question: “is your AI secure?”
The threat model: what attackers do with AI in a GRC platform
ISO/IEC 27090 organises AI-specific threats into categories that conventional cybersecurity does not fully cover. A GRC platform reads your BIA documents, vendor contracts and risk registers. In that context, the threats look like this:
- Data poisoning – manipulated inputs change what the AI “knows”. In GRC terms, a crafted vendor document or a tampered regulatory knowledge base can skew a DORA Article 28 assessment or a BIA report.
- Indirect prompt injection – instructions hidden in a processed document (a vendor PDF, an audit report) try to hijack the model’s behaviour. This is the most practical attack vector in any document-centric AI workflow.
- Model compromise and extraction – theft or manipulation of the model or its outputs. This includes inference attacks that try to reconstruct confidential training or context data.
- Cross-tenant leakage – the standard does not name it explicitly, but it is the GRC consequence of the threats above. One customer’s confidential continuity plans surface in an AI answer for another customer. For a SaaS platform serving competing banks, this is an existential risk.
- Supply chain threats – compromises upstream of the vendor: the foundation model, the embedding provider, parsing libraries, and the cloud services the AI runs on.
The key observation: these threats arise at specific lifecycle stages and must be mitigated there. You cannot patch a poisoned knowledge base at inference time.
How BCMLogic Next maps to ISO/IEC 27090
BCMLogic Next uses retrieval-augmented generation (RAG). The AI is grounded in two strictly separated context sources. Your own documents form the first one, isolated per customer. The second is a shared, versioned regulatory knowledge base (DORA, NIS2, ISO 22301, ISO 31000, EBA and ENISA guidelines). On top of that, the AI queries your structured GRC data live, with permission checks.
Grounding instead of training on customer data
We deliberately do not train or fine-tune models on customer data. This single architectural decision removes a whole class of threats that ISO/IEC 27090 spends much of its length on. We mean training data poisoning and model memorisation. There is no customer data in the model to poison or extract.
Where threats arise and where controls apply
We address the remaining attack surface layer by layer. The infographic shows the path of a single AI request in BCMLogic Next – from document to approved result.
Mapping ISO/IEC 27090 threats to BCMLogic Next controls
Contained, detectable, attributable
BCMLogic expert commentary: ISO/IEC 27090 forces an honest caveat on every vendor. No list of controls reduces AI risk to zero. What architecture can guarantee is that failures are contained (one tenant, one request) and detectable (citations, audit trail). They are also attributable, thanks to immutable logs. That is what the standard is really about – proportionate safeguards backed by evidence, not marketing claims of “secure AI”.
A secure AI lifecycle in practice
ISO/IEC 27090 covers the whole AI lifecycle, so controls on paper are not enough. They have to be operated every day. Four practices carry most of the weight in how we build and run BCMLogic Next:
- Design: threat modelling before features. Every new AI capability, such as a report generator or a vendor assessment assistant, goes through a security review. The review asks ISO/IEC 27090 questions up front: what context it sees, what tools it can call, and what happens with hostile input. Capabilities are limited to the minimum set of tools the task needs.
- Grounding, not training. The AI’s knowledge of DORA or EBA guidelines comes from a versioned corpus that we control, with a documented quarterly update cycle. When regulation changes, we update the corpus and the version is visible. It is the opposite of an opaque model update.
- Human in the loop by design. AI output in BCMLogic Next is a draft with citations, never an autonomous decision. A BIA report, a vendor risk score or a root cause analysis first goes to a named, accountable person. Only that person approves it into the system of record. This is an ISO/IEC 27090 mitigation, an AI Act expectation and simply good GRC.
- Monitoring and incident readiness. AI calls are logged with cost, latency and tenant attribution. Anomalous patterns are reviewed like any other security telemetry. An AI-related incident would go through the same process our platform helps customers run. That includes the evidence a regulator would ask for.
What this means for your due diligence
If you are a financial entity under DORA, AI-enabled vendors are ICT third-party service providers. ISO/IEC 27090 has just handed you a checklist for third-party risk assessment. These are the questions worth asking any AI-enabled GRC vendor, including us:
- Is customer data used to train or fine-tune models? If so, how are poisoning and memorisation mitigated?
- How is tenant isolation enforced specifically at the AI layer, and not only in the application database?
- Can the model be manipulated by the content of processed documents? What happens to an injected instruction?
- Can every AI-generated claim be traced to a source? Can every AI action be reconstructed from logs?
- Where does inference run, where does data rest, and can both move on-premise if a regulator requires it?
Supervised financial institutions have already started asking these questions in RFPs. They map almost one to one onto the ISO/IEC 27090 threat catalogue. A vendor who cannot answer them with architecture rather than adjectives has not done the work. The same questions apply outside financial services too. NIS2 requires essential and important entities to manage ICT supply chain risk.
FAQ
What is ISO/IEC 27090?
It is an international standard published on 14 October 2026. It provides guidance on understanding, detecting and mitigating security threats specific to AI systems across their lifecycle. These include data poisoning, model theft and extraction, and indirect prompt injection.
Can you get ISO/IEC 27090 certification?
No. ISO/IEC 27090 is guidance, not a set of management system requirements. It serves as a catalogue of threats and controls against which an AI system or its vendor can be assessed. The certifiable AI management system standard is ISO/IEC 42001.
What is the difference between ISO/IEC 27090 and ISO/IEC 42001?
ISO/IEC 42001 defines how an organisation should govern AI (governance, roles, impact assessment). ISO/IEC 27090 describes how to defend the AI system itself against attackers. The standards are complementary, and both assume an ISMS aligned with ISO/IEC 27001/27002.
Does ISO/IEC 27090 ensure compliance with DORA, NIS2 or the AI Act?
Not directly – following the guidance does not by itself meet legal obligations. However, the standard gives a shared technical language for assessing AI security. It helps with ICT third-party assessments (DORA Article 28), supply chain risk management under NIS2 and AI Act cybersecurity requirements.
Does BCMLogic Next train AI models on customer data?
No. BCMLogic Next does not train or fine-tune models on customer data. The AI uses retrieval-augmented generation. It is grounded in customer documents and a versioned regulatory knowledge base, and every answer includes source citations. Prompts and responses are not used for training.
Does the AI in BCMLogic Next make decisions on its own?
No. AI output is a draft with citations, approved by a named, accountable person. Every AI action is recorded in an immutable audit trail.
Summary
ISO/IEC 27090 does not make AI secure – it makes AI security auditable. That is exactly the shift regulated enterprises needed: from trusting vendor claims to verifying vendor architecture. BCMLogic Next was built for this kind of audit before the standard existed. Our customers’ regulators have never accepted “trust us” as a control.
Sources: ISO/IEC 27090:2026 – ISO catalogue; BSI press release on BS ISO/IEC 27090:2026; Dr M. Nowakowski, “ISO 27090 – standard cyberbezpieczeństwa dla AI”, LinkedIn (in Polish).
We will show you the audit trail, not a slide
Our team is happy to walk you through the AI security architecture of BCMLogic Next. We can do it against ISO/IEC 27090, DORA Article 28 or your own due diligence questionnaire. BCMLogic Solutions helps financial and technology companies manage operational risk, business continuity and regulatory compliance. We work in line with ISO 22301, ISO 27001, DORA and NIS2.
