Your Security Questionnaire Wasn't Built for AI

The Compliance-Industrial Complex

The last security questionnaire we received had 247 questions.

Question 83 asked about our clean desk policy. Question 84 asked whether we train AI on customer data. Both got equal weight. Both required the same checkbox.

This is insane.

One question determines whether your client's confidential merger documents might leak into a language model's weights and resurface in a competitor's query. The other determines whether someone might glimpse a sticky note.

The questionnaire treated them identically.

This isn't security. It's bureaucracy cosplaying as diligence. It's checkbox compliance that lets everyone feel protected while missing the risks that actually matter.

We've filled out dozens of these from law firms across the UK, Australia, and the US. The pattern is always the same: 200+ questions about policies, procedures, and certifications. Almost nothing about how data actually flows through AI systems.

They're asking whether we lock our doors while ignoring that the windows are open.

Why Questionnaires Fail

Security questionnaires were designed for a world of on-premise software and static data. They assume your vendor stores your data in a database, processes it with deterministic code, and deletes it when you ask.

AI vendors break most of these assumptions.

Your data doesn't stay in one place. When you send a document to an AI vendor, it might flow through multiple providers. The vendor calls OpenAI. OpenAI processes it on Azure infrastructure. Your "UK data" is now in a Microsoft data centre that might be anywhere. The questionnaire asks "where is data stored?" but the honest answer is "it depends on what you mean by stored."

Processing isn't deterministic. Traditional software runs the same code every time. AI systems are probabilistic. The model might be updated. The prompt might change. The output for identical inputs varies. Your questionnaire asks about "data processing procedures" but those procedures now involve probabilistic systems whose behaviour changes with every model update.

"Deletion" is philosophically complicated. If your data was used to fine-tune a model, is deleting the original file enough? The patterns from your data are now encoded in billions of parameters. You can't delete a memory from a brain. You can't fully delete training data from weights.

Traditional questionnaires don't even know how to ask these questions. They're checking whether you have a password policy while missing that the entire architecture is different.

The Five Questions That Actually Matter

We analysed every security questionnaire and verbal review we've received from law firms. Five firms, three countries, twelve themes emerged.

Five of those themes were the strongest predictors of whether a vendor was trustworthy. The rest added less signal than you would expect for the effort involved.

Here's what to actually ask, and why it matters.

1. Show Me the Badge

The question: "What security certifications do you hold? Can you share your audit reports?"

Why it matters:

Anyone can write a security policy. Anyone can claim they encrypt data. Certifications mean a third party actually tested the controls.

ISO 27001 means an auditor verified your information security management system. SOC 2 Type II means they tested your controls over time, not just on the day of the audit. IRAP (for Australian government work) means you've met the Australian Signals Directorate's requirements.

Without certifications, you're trusting the vendor's word. With certifications, you're trusting an auditor who has liability if they're wrong.

Red flags:

• "We're planning to certify", Planning is not doing
• "We follow ISO principles", Following principles is not being audited
• "We can't share our SOC 2 report", Real SOC 2 reports are designed to be shared under NDA

What good looks like:

• Current ISO 27001 certificate (check the date)
• SOC 2 Type II report available under NDA
• Willingness to discuss findings and remediation

Every firm asked this. It's table stakes.

2. Where Does It Sleep?

The question: "Where is our data stored and processed? Can you guarantee it stays in [our required region]?"

Why it matters:

Location determines law.

If your data is processed in the US, it's subject to US law, including potential government access under CLOUD Act. If you're handling UK government work, you probably need UK data residency. Australian firms working with government often need IRAP-certified, Australia-hosted infrastructure.

But here's what most questionnaires miss: storage and processing are different. A vendor might store your data in the UK but process it by calling an API that runs in the US. Your data "lives" in London but "visits" Virginia every time someone uses the system.

Red flags:

• "In the cloud", Which cloud? Where?
• "May transit through US", Your data is subject to US law
• "We use AWS", AWS has regions everywhere; which one?

What good looks like:

• Specific regions named: "EU (Frankfurt)" not just "Europe"
• Contractual commitment to data residency
• Clear statement on whether data leaves the region for processing

One firm told us: "ISO, SOC 2, data in Australia, those are the three ticks." They understood what mattered.

3. Who Else Is in the Room?

The question: "Which third-party AI providers do you use? What are their data handling policies?"

Why it matters:

This is the question most questionnaires completely miss.

When you send data to an AI vendor, you're probably not just sending it to that vendor. Most AI products are wrappers around foundation models: OpenAI, Anthropic, Google, Cohere. Your data flows through their infrastructure too.

So when you ask "do you train on my data?", the answer might be "we don't, but our AI provider might." When you ask "where is my data stored?", the answer depends on where OpenAI or Anthropic stores it.

Your vendor's security posture is only as strong as their weakest subprocessor.

Red flags:

• "We can't disclose our AI providers", Why not?
• No subprocessor list, They haven't thought about this
• Using consumer APIs, Consumer tiers often have worse data policies than enterprise

What good looks like:

• Named providers: "We use Anthropic Claude via their enterprise API"
• Subprocessor list with data flow diagram
• Data Processing Agreements (DPAs) with each subprocessor
• Enterprise-tier agreements (not consumer APIs)

Most questionnaires ask about vendor security. Almost none ask about vendor-of-vendor security. This is the biggest blind spot in law firm AI procurement.

4. Are You Learning From Me?

The question: "Do you train AI models on our data? What happens to our data after processing?"

Why it matters:

This is where most people get confused, because "training" means two completely different things.

Model training is when you feed data into a neural network during the training phase. The data gets encoded into the model's weights and biases. Those weights are the model's "memory." If your confidential documents are used for training, patterns from those documents are now permanently embedded in the model. They could theoretically surface in another user's output.

This is the scenario everyone fears when they hear "AI training on your data."

Product improvement is when a vendor analyses usage patterns, error rates, or edge cases to improve their prompts, workflows, or software logic. No customer data gets embedded in neural network weights. No information leaks between users. It's normal software engineering.

The problem is that vendors often say "we may use data to improve our services" without clarifying which type they mean. This ambiguity lets them do the scary thing while sounding like they're doing the safe thing.

Red flags:

• "May use data to improve services", Which kind of improvement?
• Unclear retention policies, If they keep data, why?
• No written commitment, Verbal assurances aren't binding

What good looks like:

• Written commitment: "We do not use customer data to train AI models"
• Zero retention: data deleted immediately after processing
• Clear distinction between model training and product improvement
• DPA language that explicitly addresses AI training

80% of firms asked about this. The 20% who didn't were taking a risk they didn't understand.

5. What's the Plan When It Breaks?

The question: "If there's a data breach, what's your notification timeline? What's your incident response process?"

Why it matters:

Breaches happen. The question isn't whether your vendor will ever have a security incident. It's whether they'll tell you fast enough for you to protect your clients.

If a vendor discovers on Monday that your client's data was exposed, and they tell you on Friday, you've lost four days. Four days where your client's confidential information is in the wild. Four days where you could have been mitigating damage but weren't.

GDPR requires 72-hour notification. Many vendor contracts are vaguer: "as soon as reasonably practicable." That's not good enough.

Red flags:

• "As soon as possible", Too vague; what does "possible" mean?
• No documented process, They're making it up as they go
• "We've never had a breach", This suggests they haven't looked hard enough, or have a narrow definition of "breach"

What good looks like:

• Specific SLA: "24-72 hours from discovery"
• Documented incident response policy (ask to see it)
• Post-incident process: root cause analysis, remediation, communication

Only 60% of firms asked about incident response. Given that it's the highest-impact question when things go wrong, this is a gap.

The Scorecard

Use this to evaluate any AI vendor in five minutes:

5 passes: Proceed to deeper diligence.

3-4 passes: Investigate the gaps before proceeding.

0-2 passes: Walk away.

What This Doesn't Replace

Let's be clear about limits.

Five questions screen vendors. They don't replace:

• Penetration testing, Can someone actually break in?
• Architecture review, Is the system designed securely?
• Legal review, Do the contracts protect you?
• Ongoing monitoring, Is the vendor maintaining security over time?

Pass all five = worth talking to.

Pass all five ≠ unconditionally trustworthy.

This is a filter, not a certification.

We Pass Our Own Test

Transparency requires eating your own cooking.

We built this framework by going through the process ourselves. Every question we recommend, we can answer.

The Real Point

Security questionnaires have become a ritual. Vendors fill them out. Firms file them. Few people read all 247 answers carefully. The checkbox creates a feeling of diligence that may not match reality.

It doesn't.

What matters is whether you understand how your data flows, who touches it, and what happens when things go wrong. You can figure that out in five questions.

The rest is theatre.

Beyond Questions: The Architectural Answer

Better questions are a start. But they are still procedural. You ask, the vendor answers, you trust the answer.

The deeper problem is that questionnaires, however good, are probabilistic. They test what a vendor says, not what a vendor's system can do. A vendor can pass all five questions and still have an architecture that allows data exfiltration through a compromised plugin.

The real answer is architectural containment: systems designed so that certain violations are structurally impossible, not merely prohibited by policy. Where an AI agent's capabilities are bounded by architecture, not by promises. Where you do not need to ask "do you train on my data?" because the system provably cannot access training pipelines.

We are not there yet for most AI systems. The five questions remain the best practical filter today. But the direction of travel is clear: from procedural compliance, to substantive questions, to provable architecture.

Ask the five questions now. But choose vendors who are building towards architectures that make the questions unnecessary.

Data: August-December 2025. Methodology on request.

Related: Power Without Promiscuity: Why Contained AI Agents Beat Unbounded Ones

Related: When the Hands Run Wild: OpenClaw and the Case for Formal Capability Verification