Your AI Risk Register Is a Vendor List
A note on the Mythos breach, the asset-class problem ISO 27001 has always solved, and why most AI risk registers are governing the wrong unit of analysis.
The breach that wasn't supposed to happen
When the Mythos compromise surfaced last month, the most striking detail wasn't the technical sophistication of the attack. It was the target list. Five enterprises — among the most security-mature organizations operating today, with mature third-party risk programs, named vendor governance, ISO 27001 certifications, SOC 2 reports on file, and CISO-led supplier review cadences. None of them were soft targets.
They were breached through a third-party vendor environment running an AI model that none of their risk registers named.
The vendor was named. The model was not. The model was where the risk lived.
This is the gap that's about to swallow a lot of AI risk programs in the next twelve months — and it's not a sophisticated gap. It's a unit-of-analysis problem that ISO 27001 has had a clean answer to for two decades. The answer simply hasn't been applied to AI yet.
What a risk register is supposed to do
An information security risk assessment exists to do three things: enumerate the assets in scope, identify the threats and vulnerabilities those assets are exposed to, and assign treatment decisions that name a control owner and a review cadence. The register is not the work. The register is the artifact that proves the work has happened — and that the organization can repeat it when something changes.
The whole structure depends on getting the asset right. Every clause that touches supplier governance — A.5.19 (supplier relationships), A.5.20 (addressing security in supplier agreements), A.5.21 (ICT supply chain), A.5.22 (monitoring, review, and change management of supplier services), A.8.8 (technical vulnerabilities), A.6.7 (remote working) — operates at the asset level. The threat model isn't "OpenAI." The threat model is "GPT-5.4 deployed in our customer-support workflow processing PII, owned by Operations, last reviewed when we onboarded the vendor in Q3."
When the asset is the vendor, the register can't answer the questions those clauses require it to answer.
The vendor-level register is the wrong unit of analysis
Walk through a typical AI risk register I see in an ISO 27001 readiness assessment right now and the pattern is consistent:
Row 47 — OpenAI. Risk: data leakage. Control: DPA executed, SOC 2 on file. Owner: Security.
Row 48 — Anthropic. Risk: data leakage. Control: DPA executed, SOC 2 on file. Owner: Security.
Row 49 — "GenAI tools — misc." Risk: various. Control: acceptable use policy. Owner: IT.
Three rows. Two named vendors and a catch-all. Most organizations don't have row 49 yet — they have a slide deck somewhere that says "we use AI responsibly" and a Vanta tile that aggregates evidence for the two named vendors.
Now consider what those three rows are actually governing:
OpenAI shipped at least fourteen distinct production models in the last twelve months, each with different context windows, different system-prompt behaviors, different fine-tuning options, and meaningfully different output distributions. Three of them have been deployed inside the organization. Two of those three are in customer-facing workflows. One is being used by a single engineering team in a way nobody outside the team can name.
Anthropic is the same story with different model names.
"GenAI tools — misc" is somewhere between sixteen and forty individual model instances embedded in SaaS products the organization already pays for — every CRM module with "AI summarization," every meeting transcription tool, every analytics platform that quietly added an LLM feature in the last two release cycles.
A register that has three rows for that landscape is not governing AI risk. It's recording that AI exists.
What the asset actually is
The asset is the model in the deployment. Not the vendor. Not the category. The specific model version, in the specific process, owned by a specific person, used to do a specific thing on specific data.
That sounds like a heavy formulation. It isn't. It's the same discipline software asset management has used since the mid-2000s — and it's the discipline release-tracked change control has used in ISO 9001 environments for longer than that. A version is an asset state. When the version changes, the asset state changes, and the controls protecting it have to be re-validated against the new state. Nobody finds this controversial when the asset is a piece of software. They find it controversial when the asset is an AI model because the model feels like a feature of the vendor relationship rather than a distinct asset in its own right.
It isn't a feature. The vendor relationship is the contract. The model is the asset. Confusing those two is the unit-of-analysis error that turned the Mythos targets' registers into compliance theater.
What model-level inventory actually looks like
The fields aren't exotic. They're the same fields ISO 27001 Annex A.8.1 (inventory of assets) has always required, applied to the right asset class:
Model identifier — vendor, family, specific version (not "GPT" but "GPT-5.4-Cyber-2026-04-12").
Deployment surface — where it runs. Hosted endpoint, on-prem, embedded inside another product, agent framework.
Process owner — the business process it serves and the named owner of that process. Not "IT."
Data classification — what flows in, what flows out, classified at the same level the rest of the register classifies data.
Threat model delta — what changed about the threat model when this asset was introduced. If the answer is "we copy-pasted the vendor's threat model," the register is not doing its job.
Control mapping — which controls are protecting this asset specifically, separate from the controls protecting the vendor relationship in general.
Last review — when was the model version, the deployment, and the controls last reviewed together. A.5.22 requires this. Most organizations review the vendor annually and the model not at all.
That's seven fields. None of them are exotic. All of them are required by clauses the organization is already audited against.
The hard part isn't the schema. The hard part is that almost nobody has done the inventory work yet, and the inventory work is uncomfortable — because it surfaces how many models are running in how many processes that the security function didn't know about.
Why Vanta and Drata don't fix this
Every time I bring this up in an ISO 27001 implementation, the first response is "Vanta already covers our AI tools." It doesn't. It can't. GRC platforms aggregate evidence against a defined catalog — they monitor whether a control exists and whether evidence falls out of normal operation. They are not designed to surface model-level deployment inventory inside business processes, because that inventory doesn't exist as a queryable source of truth anywhere in the organization for them to monitor against. AI risk management tools sit in the same posture: they operationalize governance that has to be designed somewhere else first.
The Vanta-versus-Drata distinction at the AI layer is exactly the distinction we've been making at the broader management-system layer for two years: tools aggregate evidence; they don't design controls. The control design — what the asset is, what the threat model is, who owns it, what the review cadence is — has to come from inside the organization, and it has to come from the management system that's already responsible for asset inventory and supplier governance.
If your management system can't tell you which models are deployed in which processes, the gap isn't tooling. The gap is the system itself.
Where ISO 42001 fits
The structural answer to AI governance at the management-system layer is ISO 42001, the AI Management System standard. ISO 42001 doesn't replace ISO 27001 — it sits alongside it and gives the AI asset class its own governance architecture: AI system impact assessments, lifecycle controls, accountability structures, and explicit requirements for transparency and oversight. For organizations already operating an ISMS, ISO 42001 implementation is mostly a question of extending existing infrastructure rather than building parallel structure.
But 42001 isn't a prerequisite for fixing this problem inside 27001. The clauses in 27001 that govern supplier risk and asset inventory can carry this work today. 42001 makes the AI-specific governance discipline auditable in its own right; 27001 already requires the asset class to be governed correctly. Both are true at the same time.
What the Mythos targets had
The post-incident reporting on Mythos isn't fully public yet, and parts of it may never be. But the public reporting is clear on one structural detail: the affected organizations had vendor-level controls and effectively zero model-level inventory. They knew which AI vendors were in their stack. They didn't know which models were running where, in which deployments, against which data.
That's not a sophisticated failure. That's a definitional failure. The organizations were measuring the wrong asset class. The vendor relationship was governed; the model deployment wasn't.
Every CISO reading this is now mentally running the same exercise on their own register. Most of them are reaching the same conclusion. The honest answer in almost every mid-market environment I've assessed in the last six months is: we have a vendor list with risk fields on it. We don't have an AI risk register.
What changes between now and your next surveillance audit
The clauses haven't changed. A.5.19 through A.5.22, A.8.8, and A.6.7 read the same way they did before any of this. What's changing is the auditor lens. Mythos has moved AI supplier governance from "interesting future topic" to "active audit finding category" inside roughly the time it took the press release to circulate. The next surveillance cycle will not be the cycle where this is theoretical.
The treatment plan from here is not complicated. It's three steps in the order they need to happen:
Inventory the assets. Find every model in every deployment. Use the seven fields above as the schema. Expect to find more than you think you have. This is uncomfortable; do it anyway.
Re-baseline the threat model. For each asset, document what the introduction of that model changed about the threat model, separate from the vendor relationship. Where the answer is "we don't know," that's the finding the register is supposed to surface.
Re-cadence the review. A.5.22 requires monitoring and review of supplier services and changes to them. Models change faster than vendors. The cadence has to match the asset velocity, not the contract renewal cycle.
None of these steps require a new tool. They require deciding that the asset class is the model, not the vendor, and re-doing the work the register was supposed to do in the first place. A disciplined internal audit program is where most organizations will catch the gap before the certification body does — assuming the audit is actually scoped to test the asset class, not just confirm the vendor list.
The compliance-shaped version of this
There's a version of the next twelve months where every mid-market organization in scope for ISO 27001 reads the Mythos coverage, adds a row to the register that says "AI models — generic" with a vague control like "monitor vendor communications," and considers the question handled. That version will produce surveillance findings. It will produce findings because the register won't survive an auditor question about A.8.1, A.5.21, or A.6.7 once the auditor knows to ask it, and the auditors are learning to ask it now.
The honest version of the next twelve months is harder. It involves opening up the asset inventory, finding the gap, and treating the gap as the system finding it is — not as a documentation task to defer until something forces it.
If your register names the vendor and not the model, you don't have an AI risk register. You have an AI vendor list waiting to be audited.
The audit is coming. The list won't hold.
Wintersmith Advisory designs management systems that hold up under scrutiny — including the ones that need to govern model-level AI deployment under ISO 27001 and ISO 42001. If your supplier governance is doing vendor-level work where the risk lives at the model level, start with a 30-minute diagnostic — no deck, no pitch, just an honest read of what your register actually governs.
