Prepare for ISO/IEC 27090 by doing the groundwork that any AI security guidance will expect: list every AI system you run, map the threats that apply to each, put controls and tests in place, and keep dated evidence. Public frameworks from NIST, OWASP and MITRE give you a neutral starting point today.
What is ISO/IEC 27090, and what do we actually know?
ISO/IEC 27090 is the ISO and IEC work on guidance for addressing security threats and failures in artificial intelligence systems. We could not load the ISO catalogue page when writing this (it returned an access error), so we are not stating its publication status, scope wording or structure. Check the ISO catalogue entry yourself before you plan around dates.
This post is therefore not a summary of the standard and does not quote it. It is a general checklist for AI security threat work, built from public sources, that should leave you in a good position whatever the final text asks for.
Why start from public frameworks?
Three public documents cover most of the ground an engineering team needs.
- The NIST AI Risk Management Framework, released on 26 January 2023, organises AI risk work into four functions: Govern, Map, Measure and Manage. NIST also published a Generative AI Profile (NIST-AI-600-1) on 26 July 2024.
- The OWASP Top 10 for LLM Applications, 2025 version, lists ten risk categories, from prompt injection to unbounded consumption.
- MITRE ATLAS describes itself as a public knowledge base of adversary tactics, techniques and procedures targeting AI systems.
Together they cover governance, application risks and attacker behaviour. None of them is the ISO text, and none is a substitute for it.
What does a practical checklist look like?
1. Know what AI you run
You cannot secure what you have not listed. Record every model, hosted API, embedded assistant, agent and vector store, plus the data each one touches and who owns it. Include AI features inside third party tools your staff already use.
2. Assign ownership and a scope
NIST's Govern function is about accountability. Name an owner for each system and write down what is in scope for security review. A shared spreadsheet with an owner column beats a policy nobody reads.
3. Map threats per system
For each system, walk the OWASP LLM categories and ask which apply. A chatbot with no tools faces prompt injection and sensitive information disclosure. An agent with write access to tickets or code also faces excessive agency. A retrieval system adds vector and embedding weaknesses. Use ATLAS to check whether attacker techniques you had not considered fit your setup.
4. Cover the AI supply chain
OWASP lists supply chain and data and model poisoning as separate risks. Track where models, datasets, plugins and libraries come from, pin versions, and record what you pulled and when. This is the same discipline you already apply to software dependencies, extended to model artefacts.
5. Limit what the system can do
Give agents the narrowest permissions that work. Require human approval for actions that are hard to undo. Treat model output as untrusted input to the next system, which is the point of OWASP's improper output handling entry.
6. Test before and after release
Run adversarial tests against your own systems: injection attempts, attempts to extract system prompts or private data, and abuse that drives cost up. Repeat on every model, prompt or tool change, not once a year. NIST's Measure function is about exactly this kind of repeatable evaluation.
7. Monitor in production
Log prompts, tool calls and refusals in a way that respects privacy rules. Set alerts for odd spikes in usage, since unbounded consumption is both a security and a cost problem.
8. Plan for incidents
Write down what you do when a model leaks data or an agent takes a wrong action: who can switch it off, how you notify, how you review. Practise it once.
9. Keep dated evidence
Auditors and customers ask for proof, not intent. Keep inventories, test results, review notes and approvals with dates, in one place, ready to hand over.
What to do
- Build the AI inventory this week, with an owner per system.
- Pick one high risk system and map it against the OWASP LLM categories.
- Add an adversarial test run to your release process for that system.
- Turn on logging and alerts for tool calls and usage spikes.
- Store evidence from steps 1 to 4 with dates.
- Check the ISO catalogue for the current status of ISO/IEC 27090 and buy the text if your auditor needs it.
Where does Safeguard fit?
Safeguard's compliance suite includes ISO/IEC 27090 as a framework. It helps teams prepare and keep evidence ready, with continuous monitoring and automated tests. Autonomous remediation is off by default, and customers choose which categories, if any, run automatically. Using it does not make anyone compliant or certified, and ISO does not endorse it. Treat it as a way to organise the work above, not a replacement for the judgement of your own security team.
Quick check
Is this checklist the text of ISO/IEC 27090?
No. It is general preparation for AI security threat work, drawn from NIST, OWASP and MITRE material. It does not quote or reproduce the standard.
Where should a small team start?
With the inventory. A list of AI systems with an owner and the data each touches makes every later step possible.
Do I need the paid standard to begin?
Not to start the groundwork above. Buy the text when you need to align formally or an auditor asks for it.
Sources
- NIST AI Risk Management Framework, fetched 19 October 2026.
- OWASP Top 10 for LLM Applications, fetched 19 October 2026.
- MITRE ATLAS data repository, fetched 19 October 2026.
Last reviewed: 19 October 2026.
