What the AI section of a security questionnaire actually asks for

The AI section of your customer's security questionnaire looks like paperwork. It is really a backlog. Each question asks for something an engineer builds and a reviewer can open: a diagram of where the data goes, an eval suite with results, an injection test, an audit trail. A policy document answers none of these questions.

This piece goes through the questions one at a time. For each one we cover the artifact that answers it, who builds it, and what an honest "we don't have this yet" looks like.

Where the deal actually stalls

The G2 2026 Buyer Behavior Report surveyed more than 1,000 B2B software buyers and ran 50+ interviews. It names IT security review as the main source of delay after a vendor has been chosen: 39% of buyers, and 50% among enterprise buyers. Nearly half of buyers also saw a CFO cancel a purchase that had already been approved that year. One caveat from the source: G2 surveyed SaaS buyers, not buyers of custom development. A founder selling an AI feature into a bank or a clinic is selling SaaS, though, and that founder is who this piece is for.

We hear about the same shift from the field. The review no longer waits for the contract. It arrives right after the demo, as a separate track. The AI module inside it has grown: model provenance, data rights, prompt-injection defense, hallucination control, ISO/IEC 42001. Reviewers also spot autofill straight away. Answers carried over from last year's questionnaire that read "in progress" or "planned" are recognized for what they are.

A technical buyer goes one step further and asks for a sandbox so they can attack the system before signing. The categories they'll test are already written down. OWASP's Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling v1.0 (February 4, 2026) lists jailbreak resistance, prompt-injection defense, leakage control and hallucination rate under load.

Question by question

"Which models touch our data, and who can train on it?"

This is model provenance and data rights. The artifact is a data-path map: every hop a customer record takes, and which provider's terms apply at each hop. An engineer writes it, because only the person who wired the calls knows them all.

data-paths.yml

- path: support_ticket -> summarizer
  fields_sent: [ticket_body]          # no name, no email
  provider: <model provider>, region: <region>
  retention: <per provider terms, date read>
  training_on_customer_data: no (contract clause <ref>)
- path: support_ticket -> vector_index
  stored: embeddings only, our database, <region>

If the map can't be drawn, the product doesn't yet know its own data flow. In our view that's worth finding out before the customer's reviewer does.

"How do you control hallucinations?"

The artifact is an eval suite with results: a fixed set of cases, a pass criterion for each, and a dated run. The reviewer wants the numbers and the date of the last run, not a description of the method.

evals/run-<date>.txt

suite: answer_grounding      cases: <n>   pass: <n>   fail: <n>
suite: refuses_out_of_scope  cases: <n>   pass: <n>   fail: <n>
failures: evals/failures-<date>.jsonl   # each one triaged, none deleted

"How are you protected against prompt injection?"

The artifact is an injection test that runs on every release. It isn't a pentest from last spring. It's a set of hostile inputs that fails the build when the system obeys one of them.

tests/injection/
  doc_with_hidden_instruction    expect: instruction ignored, logged
  user_asks_for_system_prompt    expect: refused
  tool_call_to_unlisted_domain   expect: blocked before network
ci: runs on every merge to main; red = no release

This is also where the sandbox request lands. A team that already attacks its own system on every release can hand the buyer the same sandbox without dread.

"Can you show who did what, and when?"

The artifact is an audit trail: one append-only record per model action, written by the system and not reconstructed afterward.

{at, actor, tenant, model, input_ref, output_ref, tools_called, human_override}

You're done when a reviewer can name one event and you can pull its record in minutes.

"Are you ISO/IEC 42001 certified?"

ISO/IEC 42001 certifies a management system, not a model. Behind the certificate sit an inventory of AI systems, a risk register, testing records, a human-oversight procedure and supplier control. The certificate is still rare. BCG announced on January 27, 2026 that it was among the first 100 certified organizations in the world.

Much of what the standard asks for is the work from the sections above. The data-path map feeds the inventory and supplier control. The eval runs and injection tests are the testing records. The audit trail shows human oversight actually happening.

What an honest "no" looks like

We think the strongest answer to a question you can't fully meet is a scoped one. It names the artifact you have, the gap, and what closes it.

Q: ISO/IEC 42001 certification?
A: Not certified.
   Attached: AI system inventory, data-path map, eval run <date>,
   injection suite results <date>, audit-log sample.
   Not yet in place: formal risk register review cycle.

In our view, a plain gap with evidence next to it reads better than "planned" with nothing attached.

How we build for this (our view)

We don't treat these artifacts as compliance work bolted on at the end. In our view they're the same engineering that makes an AI product correct.

In RE Intelligence, our Dubai real-estate analytics product, the rule is "Postgres owns the truth, AI owns the story". Every number comes from a deterministic query, and the model only narrates what the data already shows. Forecasts are archived, graded against what actually happened, and the accuracy is shown to the user. That's an eval suite turned into a product feature.

In a clinic system we delivered under NDA, role access is enforced twice: once in application logic and again in row-level security in the database. That way a bug in one layer doesn't become a data leak. Patient contact details are scoped per appointment. The handover kit included a security-notes document, and later work added patient deletion compliant with PDPL, the UAE's data-protection law.

What would change our mind: finding that reviewers routinely accept a policy PDF with no artifacts attached. That isn't what we hear.

FAQ

Isn't the security questionnaire legal's job? Legal owns the contract and the data-processing terms. The AI module asks how the system behaves, and only the people who built the system can show that. This piece isn't legal or compliance advice. It's about the engineering the answers depend on.

We're a small team. Which artifact comes first? We'd start with the data-path map. Most other answers depend on it.

Can we reuse answers from last year's questionnaire? You can reuse the artifacts if they're current. Reviewers recognize carried-over "in progress" and "planned" answers. A dated eval run from last week beats a polished paragraph from last year.

Do we need ISO/IEC 42001 certification to close an enterprise deal? The certificate is rare. BCG called itself one of the first 100 certified organizations as recently as January 2026. What a reviewer can check today is whether the records the standard asks for exist. Hand those over and say plainly what's missing.

If the questionnaire has already arrived

For the same idea built into a product, see the RE Intelligence case at iloblique.com/re-intelligence: deterministic numbers, a model that narrates, and forecasts graded in public.

If a customer has just sent you the AI section and you're looking at an empty column, we'd like to hear about it.

Sources

• G2, 2026 Buyer Behavior Report (1,000+ B2B software buyers, 50+ interviews).
• OWASP, Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling v1.0, February 4, 2026.
• BCG, announcement of ISO/IEC 42001 certification, January 27, 2026.
• ISO/IEC 42001, AI management system standard.