Why this standard matters now

Jabulani Chibaya 

HARARE – ISO/IEC 27090 gives businesses a common language for protecting AI systems from attack. Published in October 2026, the standard runs to 56 pages and covers the whole AI life cycle, from training data to model updates.

Why should a business owner care? Because AI breaks old security assumptions. A firewall cannot tell that someone has quietly corrupted your training data. Antivirus cannot notice a rival asking your model thousands of clever questions in order to copy it. These attacks look like normal use. That is what makes them hard to catch.

The standard names the threats: data poisoning, evasion, membership inference, model inversion, model theft, prompt injection and output injection. It maps each one to confidentiality, integrity and availability, so security teams can fold them into the risk registers they already keep.

One caveat matters. ISO/IEC 27090 is guidance, not a certifiable standard. No auditor will hand you a “27090 certificate”. Certification routes remain ISO/IEC 27001 for information security and ISO/IEC 42001 for AI management systems. Think of 27090 as the technical manual that makes those certificates mean something for AI.

Putting it to work in an ordinary business

You do not need a PhD to start. ISO’s own starting points are practical, and they translate into four moves.

1. Inventory every AI system you use or build. Include the ones vendors supply: the website chatbot, the fraud scoring inside your payments platform, the “smart” feature in your HR software. You cannot protect what you have not listed.
2. Trace where data and models come from. Who supplied the training data? Who can change it? What happens when the model retrains on data collected in operation? Nivedita Newar, Deputy CISO at UNSW, singles out an AI Bill of Materials, a record of where models and data originate, as a core control.
3. Pair security with your AI strategy. Give every use case on your roadmap a security tier. A chatbot answering opening hours is low risk. A model approving loans or flagging fraud is high risk. Fund protection to match, and ask one question at every strategy meeting: what is the worst thing an attacker could make this system do?
4. Audit the model, not just the server. A sound model audit asks:
   1. Can we show where the training data came from and who touched it?
   1. Who can query the model, how often, and would we notice probing?
   1. Did we try to break it ourselves, through red teaming, before an attacker did?
   1. What is logged, and who reads the logs?
   1. When did we last retrain, and was security reviewed again?

Roles matter too. Newar’s summary notes that providers secure the model and its life cycle, while deployers secure the integration, from data access to monitoring. If you buy AI, you still own half the risk.

Defences also interact. Rate limiting, input filtering and hidden confidence scores can degrade performance, so test them together.

Fitting it alongside the standards you already have

ISO/IEC 27090 is not a new silo. It plugs into the management systems mature organisations already run, and its introduction points readers back to ISO/IEC 27001 and 27002 as the foundation.

Start with the 27001 basics, add 42001-style governance, use 27090 as the threat library for your AI risk assessment, and run impact assessments on high-risk systems. Certify what is certifiable; use the rest as evidence.

The business value, and the metrics to watch

The value of 27090 is avoided loss and earned trust. A stolen model is stolen intellectual property. A poisoned model quietly makes bad decisions, such as approving the wrong loans or missing real fraud. A leaky model can expose customer data. Each of these ends in a regulator’s letter, a customer’s complaint or a boardroom question.

There is an upside too. Organisations that can show how their AI is secured clear vendor due diligence faster and answer auditors with evidence rather than reassurance. Measure what a board can act on. These six are suggestions to adapt, not requirements of the standard.

Why telcos carry more of this risk

A telco is a collection of other people’s technology. Radio, core network, billing, mobile money, cloud, customer service and fraud tools usually come from different vendors. Add thousands of retail agents and API partners, and the attack surface becomes a map nobody holds whole. Who sees the entire system? Often, nobody.

AI makes this harder. Each vendor ships its own models for network optimisation, fraud scoring or chatbots, each on its own update cycle. The telco deploys models it did not build, which is exactly where 27090’s focus on supply chains and provenance applies.

A short cascade: Econet Zimbabwe

None of this says Econet is negligent. It shows the shape of exposure any large, multi-vendor operator shares.

1. Many hands on the network. Ericsson has been a supplier for more than two decades, and Econet’s own announcement says its 2025 agreement extends lifecycle management of Ericsson network functions. ZTE also supported the 2022 5G launch.
2. APIs open new doors. The same agreement adds a platform that lets businesses and developers reach core network capabilities through APIs. Every API needs rate limits, logging and abnormal-use detection, the exact mitigations 27090 discusses.
3. AI sits on top of the data. Wherever Econet or its vendors apply AI to subscriber and transaction data, poisoning, probing and model extraction become relevant. I have not verified which AI systems Econet runs; the question belongs on the audit list.
4. Identity is the soft spot. Police say a suspect allegedly used social engineering to obtain replacement SIMs and empty mobile wallets and bank accounts. A 2024 trial heard how an agent spotted an ID photo that did not match. Econet issued a security alert on 23 September 2026 as WhatsApp takeovers rose.
5. The weak link cascades. A compromised agent or partner interface leads to a hijacked SIM, then a drained wallet and bank account, then lost trust. Add AI-based ID checks, and attackers will try to fool those models with forged documents. That is evasion, a named 27090 threat.

The lesson for telcos: write AI security into vendor contracts. Ask for model provenance, notice of retraining, access logs and the right to test.

Banks: pairing 27090 with Santander’s open-source governance tools

A bank can use 27090 as the threat map and Santander’s open-source tooling as part of the test and enforcement kit. In June 2026, Santander published 11 AI projects on GitHub under the Apache 2.0 licence, built without real customer data.

The centrepiece is mech-gov-framework: governance regimes (R1 to R3), hard gates and metrics that let rules and thresholds, not blind trust, decide when an LLM’s output may be used.

The mapping is mine, not Santander’s or ISO’s. Three cautions apply.

1. These are tools, not a compliance certificate. 27090 has no certification, and neither does this code.
2. Open source is also a supply chain. Vet the code, pin versions and record it in your AI Bill of Materials. Note that sota-stressed-datasets carries its own data licences.
3. Supervisors still expect your own evidence. Run your own tests on your own models.

A practical start: pick one high-risk use case, such as credit decisioning or fraud scoring. Threat-model it against the 27090 list, wrap it in hard gates, stress test and red-team it, and take the logged metrics to your model risk committee.

Key takeaways for CISOs and CTOs

• Use 27090 as a threat library. Map each named threat to your systems in the risk register you already keep.
• Own the inventory. If you cannot list your AI, including vendor-supplied AI, nothing else holds.
• Demand provenance. Build an AI Bill of Materials for your own models and require one from vendors.
• Design security in. Build it from development through operation, apply zero trust, and log everything that matters.
• Watch for legitimate-looking abuse. Model extraction can arrive as ordinary queries, so monitor patterns, not just access.
• Test defences together. Layered controls can interact and cost accuracy; measure both.
• Write down who owns what. Provider and deployer duties should be explicit in contracts.
• Report to the board. Take the six metrics above to every quarterly risk review.

Putting it all together

AI security is a management problem before it is a technical one. Hayek taught that knowledge is dispersed; so is risk. No single vendor, team or tool sees the whole system, which is why a shared standard matters.

ISO/IEC 27090 gives you a common vocabulary for what can go wrong and how to catch it. Paired with 27001, 42001 and your AI strategy, it turns “we use AI” into “we know what our AI can be made to do, and we would notice.”

A realistic first 90 days:

1. Days 1 to 30: inventory every AI system and its data sources, including vendors’.
2. Days 31 to 60: map 27090 threats to your highest-risk systems, and send vendors the provenance, retraining and logging questions.
3. Days 61 to 90: red-team one critical model, set up the six metrics, and report to the board.

The attackers are already studying your models. The only question is whether you studied them first.

Sources

• ISO/IEC 27090:2026, ISO
• ISO/IEC 27090 explained, ISO
• Nivedita Newar, Deputy CISO at UNSW, LinkedIn post on the publication of ISO/IEC 27090, October 2026
• Santander publishes AI projects under an Open Source licence, Santander
• Econet Wireless Zimbabwe partners with Ericsson to advance 5G network infrastructure, Econet
• Zimbabwe: Econet Wireless contracts Ericsson to modernize its network infrastructure, Ecofin Agency, March 2023
• Press statement, 21 October 2025, Zimbabwe Republic Police
• Econet agent nails trio accused in US$190 000 cyber fraud, The Herald

WhatsApp account takeovers surge in Zimbabwe, Zambian Observer, citing The Herald

Jabulani Simplisio Chibaya is a Data and AI Consultant specializing in data science, artificial intelligence, blockchain, and cryptocurrency innovation. A seasoned conference speaker, he also writes on the intersection of technology, regulation, and economic development. Contact: Cell: +263 778 921 881 | Email: simplisiochibaya22@gmail.com | LinkedIn: https://www.linkedin.com/in/jabulani-simplisio-chibaya