Skip to main content

The Demo Went Well. Then Procurement Sent the Security Questionnaire.

• By Yuriy Mykhalchuk • 9 min read
Featured image for The Demo Went Well. Then Procurement Sent the Security Questionnaire.
Image credit: Original illustration

The product demo went well.

The prospect liked what they saw, the technical discussion was productive, and nobody hit a fatal integration problem along the way.

Then procurement showed up — not with another architecture question, but with a spreadsheet full of things like:

Do you require MFA for privileged systems? Do you regularly review and recertify privileged access? Do you maintain an approved information security policy?

These look like simple yes-or-no questions. Usually, they aren’t.

The hard part is rarely writing a plausible-sounding answer — a capable language model can do that in seconds. The hard part is figuring out whether the answer is actually backed by what your organization has documented, implemented, reviewed, and kept evidence of.

That distinction matters more than it sounds like it should.

For this experiment, I used AcmeFlow, a fictional SaaS company with an existing set of security procedures, operational records, supplier reviews, resilience evidence, and a completed ISO 27001 readiness assessment. The assessment wasn’t disastrous — quite the opposite: 14 controls Met, 15 Partially Met, 1 Unknown, out of 30 controls assessed in total.

So this wasn’t a case of asking AI to rescue a company with no security documentation. The more interesting question was whether an AI assistant could tell the difference between an answer that’s defensible, one that needs qualifying, and one that shouldn’t be claimed at all.


Question 1: a defensible Yes

The first question was straightforward:

Do we require MFA for privileged and important systems?

AlturaQuantera answered Yes — not because MFA sounds like something a SaaS company probably has, but because both the assessment and the underlying evidence actually supported the claim.

The latest ISO 27001 readiness assessment marked ISO27K-ACCESS-04 — MFA and authentication expectations are defined as Met. The supporting procedure states that MFA is required for identity provider access, source code, cloud console access, production tools, and support systems, and it also defines restrictions around production administrator access and shared accounts.

AlturaQuantera answering an MFA security questionnaire question using assessment and evidence context.

This is the easy case. The customer asks a question, there’s a relevant control, the control is Met, and the underlying procedure backs the claim up. You can answer Yes and actually show why — the answer isn’t just generated, it’s traceable.


Question 2: the process exists, but the evidence of execution doesn’t

Then I asked:

Do you regularly review and recertify privileged access?

This time the answer looked different. AlturaQuantera didn’t give a confident Yes.

AcmeFlow does have a defined quarterly access review mechanism — its access-control procedure describes exports from identity and infrastructure systems, review by system owners, confirmation that users still need their assigned roles, and handling of privileged-access exceptions with owners and expiry dates. So the process exists on paper.

But the readiness assessment marked ISO27K-ACCESS-03 — Privileged access is managed as Partially Met, because the evidence didn’t clearly demonstrate that the quarterly privileged-access review had actually happened. Specifically, there was no complete evidence of the most recent quarterly review, no exact current list of privileged roles and accounts, no formal approval or recertification records for current administrators, and an open gap around Entra admin-access review evidence.

AlturaQuantera explaining why privileged access recertification cannot yet be answered with a confident Yes.

This is where security questionnaires stop being a document-generation problem and start being something more interesting. A policy saying “we review privileged access quarterly” demonstrates intent and process design. It doesn’t automatically demonstrate that the last quarterly review actually ran — which accounts were in scope, who approved them, which privileges got removed, and which exceptions are still valid. Those are two different claims, and the second one needs operational evidence behind it.

That distinction is easy to lose when a questionnaire is getting filled out under sales pressure. The temptation is to glance at the procedure, spot the words “quarterly review,” and just type Yes. That answer might sound reasonable, and it might even be consistent with the documented process — but it’s not the same as being able to defend the statement with evidence that it actually happened.


Question 3: sometimes the correct answer is Unknown

The third question looked even simpler:

Do you maintain an approved information security policy that is reviewed periodically?

AcmeFlow already had an ICT risk-management procedure, an incident-response playbook, an access-control procedure, monitoring and logging documentation, supplier-security records, BC/DR evidence, and management-review notes. A generic document assistant could easily glance at all that and conclude “clearly they have security policies, Yes.” That would be the wrong conclusion.

The ISO 27001 readiness assessment marked ISO27K-POL-01 — Information security policy exists as Unknown, for a specific reason: the evidence set didn’t contain a current, approved top-level Information Security Policy defining the organization’s overall security principles and expectations. It also didn’t show a policy owner, a formal approval record, or a defined review cycle for that policy.

AlturaQuantera refusing to overstate evidence for an information security policy.

This is probably the most important of the three cases. The organization had plenty of relevant documentation — it just didn’t have evidence for the exact claim being asked, and adjacent evidence shouldn’t get quietly converted into a confident Yes just because it’s sitting nearby.

Sometimes the useful AI answer isn’t a polished response you can paste straight into the questionnaire. Sometimes it’s simply: you cannot currently prove this. Less impressive as text generation. Considerably more useful as compliance assistance.


The interesting part wasn’t generating the answer

This experiment also exposed a limitation in the first version of my own implementation.

Initially, the assistant reasoned correctly when I explicitly asked about a control by name — something like ISO27K-ACCESS-03. But real customers don’t write “please explain ISO27K-ACCESS-03.” They write “do you regularly review and recertify privileged access?” So the assistant had to learn to connect a natural-language customer question to a specific assessment finding, which sounds obvious but changes the architecture of the problem.

The flow isn’t just:

Question
→ search documents
→ generate answer

It’s closer to:

Customer question
→ identify relevant assessment finding
→ inspect supporting evidence
→ understand limitations
→ draft a defensible answer

That extra step matters. Without it, document retrieval might find several relevant procedures and still land on the wrong conclusion. With it, the assistant can reason from both what the documents say and what the latest readiness assessment already concluded about those documents.

A security questionnaire is really an evidence-reuse problem

Most security questionnaires contain questions an organization has effectively answered before — not necessarily in another spreadsheet, but scattered across an access-control procedure, a resilience test, a supplier review, a vulnerability record, an assessment finding, a management decision, or some operational record showing a process actually ran.

The problem is that those pieces are scattered, so every new enterprise customer can trigger a small archaeology project of its own. Someone searches SharePoint or Google Drive. Someone pings the infrastructure engineer. Someone remembers another customer asked the same thing six months ago. Someone copies an answer from an old questionnaire and hopes it’s still true.

AI can genuinely speed this up. But the useful version of that isn’t “generate answers faster” — it’s reusing existing evidence without overstating what that evidence actually proves. For each question, the system needs to work out whether the evidence supports a clear answer, a qualified one, or no defensible answer yet. That’s a much more interesting problem than autocomplete for security questionnaires.

Documentation is not the same as evidence

The privileged-access example illustrates this well. A procedure saying quarterly reviews must happen is documentation. A completed review showing who was reviewed, who approved the result, which privileges were removed, and which exceptions remain is operational evidence. Both matter — they just prove different things.

The same pattern shows up throughout compliance work: a backup policy is not a restore test, an incident-response procedure is not a completed post-incident review, a supplier-security process is not a supplier review record, an access-control policy is not a privileged-access recertification, and a handful of security procedures don’t automatically add up to an approved top-level information-security policy. Once an AI assistant starts distinguishing between those layers, it becomes a lot more useful than a document chatbot.

Yes, qualified, or Unknown

That’s the behavior I wanted out of this experiment. For the same company and the same evidence set: MFA got a Yes, supported — the assessment says Met, and the procedure backs the claim. Privileged-access recertification didn’t get an unconditional Yes — the process exists, but evidence of completed recertification cycles is incomplete. The Information Security Policy question couldn’t currently be established — related procedures exist, but the specific top-level policy isn’t evidenced anywhere.

There’s no universal “compliance answer.” There’s only the claim being made and the evidence available to support it — which leads to a fairly simple principle: the dangerous answer in a security questionnaire isn’t “I don’t know.” It’s a confident answer you can’t actually defend.

What I would build next

The obvious next step is treating security-questionnaire work as a reusable evidence workflow rather than a one-off chat interaction — something like customer question, relevant control or assessment finding, supporting evidence, confidence and limitations, draft answer, human review.

The final answer still needs a human owning it. But the tedious part can increasingly be automated: finding the relevant evidence, understanding what it actually supports, identifying what’s still unproven, and drafting an answer that honestly reflects those limits. Importantly, the system also has to be capable of returning Unknown when Unknown is the correct state. That’s less glamorous than generating a 200-page compliance policy pack. It’s probably a lot more useful.

Security questionnaires are not primarily a writing problem

The demo went well. The customer liked the product. Then procurement sent the questionnaire.

That doesn’t have to mean another week spent reconstructing the company’s security story out of scattered documents and somebody’s memory — but solving it takes more than generating good prose. Security questionnaires aren’t primarily a writing problem. They’re an evidence-reuse problem.


Want to see how this works in AlturaQuantera?

See the evidence-backed security questionnaire workflow, including how AQ distinguishes a defensible Yes from a qualified answer or an Unknown.

Explore the AlturaQuantera security questionnaire use case →