Eighteen Questions
An enterprise customer sent an AI security questionnaire a few weeks ago. It didn’t arrive as an email attachment. It came through their vendor risk platform as a structured assessment, which tells you something before you read a single question: this is part of a program, someone owns it, and it will be back.
The title was about AI-accelerated attacks. It named a specific frontier model in the first question. Eighteen questions total, organized into sections on exploitation timelines, incident response, software development, code scanning, third-party risk, and contracts.
Four of the eighteen were actually about AI.
I’ve written before that AI isn’t a new category of risk, it’s a new vector for existing ones. I believed that when I wrote it. This questionnaire is the first time I’ve seen a large enterprise reach the same conclusion and build their vendor assessment around it.
What It Actually Asked
Strip the section headers off and read the questions cold. What is your mean time to patch a critical vulnerability under active exploitation. Can you handle more than one security incident at the same time. Do you maintain a software bill of materials and keep it current. Does your code scanning cover every language you write in, including infrastructure as code. Have you integrated static analysis and dependency scanning into your build pipeline. How often do you scan. Do you push SBOM requirements down to your own vendors. Do you continuously monitor your suppliers. Have you looked at your cyber insurance lately.
Every one of those could have been asked in 2019. None of them require the word “AI” to make sense.
The four genuinely AI-specific questions asked whether I had a plan for frontier models compressing the window between vulnerability disclosure and working exploit, whether I use AI-powered security tooling, whether my incident response plan had been updated for AI-orchestrated intrusions, and whether I planned to put AI into the vulnerability triage workflow.
So the questionnaire is really making one argument. AI hasn’t changed what a secure vendor looks like. It’s changed how fast that vendor has to be, and how much of its answer needs to be automated rather than manual.
That’s a much more useful claim than most of what’s being written about AI risk right now, and it came from a customer’s procurement process rather than from anyone selling AI governance.
The Threat Model Runs the Other Way
Here’s the part worth sitting with.
Nearly everything written about AI governance assumes the risk is your AI. Your models, your prompts, your training data, your employees pasting customer records into a chatbot. That’s a real risk and I’ve done that work.
This questionnaire assumed the risk is the attacker’s AI, pointed at you.
The concern behind every question was that adversary tooling is getting faster, so the gap between a vulnerability becoming public and someone exploiting it in your environment is collapsing from months to hours. Under that model, my internal AI usage barely matters. What matters is whether I can find, triage, and fix things at machine speed, and whether I can see far enough into my supply chain to know when someone else’s problem becomes mine.
A company that built a careful AI governance program on the standard advice would have failed this questionnaire outright. Beautiful acceptable use policy, model inventory, approved tools list, nothing to say about patch velocity.
What It Never Asked
It never asked for a model inventory. Or an AI acceptable use policy. Or training data provenance, or an approved model list, or anything about prompt injection, or how employees use AI tools day to day.
I have an AI coding agent policy. It’s a real document, written before this questionnaire arrived, and it governs how AI-generated code enters our codebase. Nobody asked to see it. I referenced it once, in an answer about future tooling decisions, and only because it happened to be the standard I’d evaluate against.
That’s most of the artifacts the AI governance market currently sells, and this customer wanted none of them.
I’m not going to over-read one questionnaire. Those artifacts do get asked for, and if you’re building AI into your product rather than using it internally, you’ll need them.
But in the US there’s no general mandate behind them. What exists is narrow and tied to specific uses, mostly automated decisions in employment, lending, housing, and healthcare. Colorado passed the most comprehensive state AI law in the country in 2024, and then repealed and replaced it in May of this year with a much narrower transparency law that doesn’t take effect until 2027. If you’re a B2B SaaS company that isn’t making consequential decisions about consumers, most of that patchwork doesn’t reach you.
What reaches you is your sector regulator, your customer’s contract, and questionnaires like this one. Which is another reason to attach AI governance to the security program you already run instead of standing up a separate one next to it.
Half Policy, Half Architecture
I answered roughly half the questions straight out of existing policies and procedures. Third-party management, incident response, vulnerability management, insurance. The language was already written and reviewed. I edited it to fit the question and moved on.
The other half I answered by describing the platform. What’s deployed, what it detects, how the pieces connect.
The first question is a good example. It asked about frontier AI compressing exploit timelines. My answer walked through continuous vulnerability assessment across the cloud environment, attack path analysis rather than isolated findings, runtime threat detection on servers, app services, databases and storage, threat intelligence updating continuously, and a SIEM correlating all of it with automated response playbooks. Then two sentences at the end saying I don’t maintain controls specific to any single named AI system, because the combination above is designed to stay effective as adversary tooling changes.
That’s the whole answer to the AI question. Everything above it existed before anyone wrote the question, and none of it was built with AI in mind.
Which is the point. You don’t answer a question about AI-accelerated attacks with an AI control. You answer it with the architecture and the program you already run, and then explain why naming a specific model doesn’t change either one.
I Didn’t Use the SOC 2 Report
Worth being precise about this, because it’s where a lot of companies get the sequencing wrong.
I answered eighteen questions without opening the audit report.
The report attests that a program exists and operated effectively over a period. It doesn’t contain my expedited remediation tier, or my scan coverage by language, or who can authorize an emergency change, or how my vendor reviews run. Those live in the policies and procedures underneath the report.
A questionnaire like this one reaches straight past the attestation and into that layer. If the program is thin and the report is the only real artifact, that shows up fast, because you end up writing new answers under deadline for questions the program should already have answered.
The report gets you through the first filter. The program answers the actual questions.
Three Gaps
I don’t want to make this sound cleaner than it was. Three questions I couldn’t answer as-is.
Patch timing. I had no defined expedited tier for critical vulnerabilities under confirmed active exploitation. Standard severity-based SLAs, nothing that distinguished “critical” from “critical and being exploited right now.”
The capability was there. We would have moved on something like that immediately. What was missing was the number and the authority written down.
So I updated the vulnerability management procedure. Twenty-four hours to remediate or mitigate from confirmed exposure, compensating controls in the same window when no vendor patch exists, and a documented emergency change procedure letting the security manager act outside standard change windows with notification and retrospective review.
No purchase, no headcount, no new tooling. The gap was documentation, not capability. That’s the most common shape a questionnaire gap takes, and it’s why I tell founders to inventory what they already do before they conclude they have a security problem.
Continuous vendor monitoring. They asked whether I continuously monitor my suppliers using something like a security ratings service. I wasn’t.
I implemented one at the minimum scope that satisfies the requirement, and I stopped there deliberately. We don’t have many vendors, and the ones we have are large providers with published assurance programs and their own audit reports. Continuous scoring on that population tells me almost nothing I don’t already get from their attestations. Building it out further would produce a dashboard nobody acts on.
That’s a judgment call, and I’d defend it. Right-sizing means implementing the control at a weight that matches the actual risk, not skipping it and not gold-plating it. The failure mode I see most often in small companies isn’t missing controls. It’s controls implemented at enterprise weight by a team of nine.
AI in the development pipeline. They asked about integrating AI into the SDLC to identify, triage, and remediate vulnerabilities. I’m not doing it, and I said so.
The constraint here is technical. The tooling we use for static analysis, dependency scanning, and cloud posture management doesn’t currently do what they’re describing. This isn’t a budget decision or a deprioritization. The capability doesn’t exist in our stack yet, and bolting on a separate tool outside the pipeline to satisfy a questionnaire item would create more surface area than value.
So the answer led with what does exist, named the specific tooling, and explained how findings get triaged today. Then it said we evaluate AI-assisted capabilities as the market matures, against effectiveness, integration with our existing stack, alignment with our AI coding agent policy, and operational fit. The platform forced a timeline selection and I picked the longest bucket available.
I’ve argued before that a gap plus a credible date keeps a deal moving where a flat no stalls it. That still holds. But don’t invent a date to fill the box. If the constraint is real, name it, show what you do instead, and say what would change your mind. A reviewer can work with that. What they can’t work with is a quarter you picked because the form wanted one.
What This Changes
If you sell to enterprise and you’re waiting for the AI questions to arrive, they’re already here, and they probably don’t look the way you expected. Mine came dressed as a vulnerability management review.
The preparation that pays off isn’t an AI policy binder. It’s knowing your patch numbers, knowing your scan coverage, being able to describe your detection architecture without a meeting first, and having your vendor program written down. Same fundamentals as five years ago.
AI didn’t add new questions to the list. It shortened the time you have to answer the old ones well.