NIST is writing the questionnaire. Read it before it arrives.
The control overlays NIST is developing for AI systems will become the shape of enterprise security due diligence, because they map onto controls large buyers already run. Their drafts are public, and the categories they use are the useful part now.
The security questionnaire for AI systems is currently improvised. Every large buyer has written its own, most of them by taking a cloud questionnaire and adding a section on models, and suppliers answer four incompatible versions of the same question every quarter. That is a transitional state and it is ending, because a common vocabulary is being written.
NIST is developing Control Overlays for Securing AI Systems, built on the SP 800-53 control catalogue that a great many organisations — particularly anyone selling into United States federal supply chains — already use as their control language. The project is explicitly organised around use cases rather than around technology: using a generative assistant, using and fine-tuning a predictive model, single-agent systems, multi-agent systems, and controls for those building AI rather than deploying it.
The claim: the categories are the forecast. Whatever the final wording, the question a buyer will ask in two years is which of those five situations you are in, and what controls you run for that one. An organisation that can answer today is ahead of a document that has not been published.
Why the use-case split matters more than the controls
Most internal AI security policy is written as one policy, and it fails in a predictable direction: it is simultaneously too heavy for an assistant that summarises meeting notes and too light for an agent with write access to a production system. Both are “AI”, both get the same control set, and the control set is a compromise that fits neither.
The overlay structure says something useful about that. These are different security problems with different threat models, and pretending otherwise is what produces policy nobody follows.
- Case 01 Using a generative assistant The exposure is what goes in and who sees what comes out. Data handling and access, mostly.
- Case 02 Using and fine-tuning a predictive model The exposure is the training data and the pipeline. Integrity and provenance, mostly.
- Case 03 A single agent The exposure is what the agent can do. Tool authority, identity, irreversibility.
- Case 04 Multiple agents All of the above, plus what one agent can cause another to do. Trust between components.
- Case 05 Building AI systems The exposure is the supply chain — weights, datasets, dependencies and what you pass downstream.
Reading down that list is a cheap exercise with an immediate return. Most organisations discover that their AI inventory contains systems in three or four of these categories, governed by one policy written for the first.
What to do with a draft standard
The instinct with an unfinished standard is to wait for it. That is usually right and it is wrong here, for a specific reason: the mapping work is the expensive part and it does not depend on the final text.
If your control environment is already expressed in SP 800-53 terms, or in ISO/IEC 27001 terms, the work is to say which existing controls apply to each of the five cases, where they do not reach, and what fills the gap. That analysis holds whatever the published overlay eventually says, because it is an analysis of your estate rather than of the document.
The third line is where nearly every mapping exercise finds its real gap. Classic security control catalogues have a great deal to say about access, configuration and monitoring, and very little about a component that decides for itself what to do next. The controls for that are not in the catalogue yet, which is precisely why the overlays are being written.
The relationship to everything else
This does not replace the AI Risk Management Framework, and the two do different jobs. The AI RMF is a governance structure — govern, map, measure, manage — that tells an organisation how to reason about AI risk in general. An overlay is a control specification for a particular kind of system, expressed in the language a security function already speaks. Frameworks are for deciding. Overlays are for evidencing.
For an organisation with EU exposure, neither substitutes for the AI Act’s own route to conformity, and the mapping between them is partial. What overlays are good for is the security questionnaire, the customer assurance conversation and the internal audit, which between them consume far more organisational time than the regulatory analysis does.
What this does not tell you
These documents are in progress. The drafts are drafts, the categories may move, and quoting an unpublished control as a requirement would be exactly the kind of overclaiming that makes assurance work untrustworthy. We do not certify anyone against them and nobody else can either, yet.
It is also not a claim that a control mapping makes a system secure. A mapping tells you which controls you have and which you do not. Whether the ones you have work is a question for testing, and an organisation with a complete map and no red teaming has documented an assumption rather than verified a property.
The person who should act is whoever owns the AI security policy. Split it into the five cases this quarter. The exercise takes a fortnight, it will find at least one agentic system governed as though it were a chat interface, and it is work you will have to do anyway — the only question is whether you do it now or under the deadline of a customer questionnaire you did not write.