Answering a Security Questionnaire When AI Built Your Product

Do security questionnaires ask whether AI wrote your code?

Usually not directly. We checked two published references, and neither mentions AI coding tools:

• The CAIQ. The Consensus Assessments Initiative Questionnaire (CAIQ) from the Cloud Security Alliance is a set of yes or no questions that many cloud and software vendors complete. Version 4.0.2 has no questions about AI.
• The UK Software Security Code of Practice. The Software Security Code of Practice from the Department for Science, Innovation and Technology (DSIT) and the National Cyber Security Centre (NCSC) sets out 14 principles for software vendors. It is voluntary, and it refers to a separate code of practice for AI cyber security rather than covering AI itself.

Both ask about how software is developed, tested and maintained. Those questions apply to every line of your code, whether a developer typed it or an AI tool generated it. That is good news, because you do not need a special answer for AI. It also removes an excuse, because ‘the AI wrote it’ does not answer a question about review or testing.

Some buyers add their own questions about AI. Our guide to the security evidence enterprise buyers ask for covers the questions about AI services inside your product, such as whether customer data is used to train a model. This guide covers how the product was built. If the questionnaire is from your first large customer, our guide to moving from MVP to your first enterprise customer covers what else tends to change.

Which questions are hardest for an AI-built product?

The questions about process and evidence cause the most difficulty. Here are the relevant CAIQ v4.0.2 questions, word for word:

• AIS-04.1: ‘Is an SDLC process defined and implemented for application design, development, deployment, and operation per organizationally designed security requirements?’
• AIS-05.2: ‘Is testing automated when applicable and possible?’
• AIS-07.1: ‘Are application security vulnerabilities remediated following defined processes?’
• TVM-05.1: asks whether processes are in place ‘to identify updates for applications that use third-party or open-source libraries’.
• TVM-06.1: asks whether processes are in place ‘for periodic, independent, third-party penetration testing’.

The Software Security Code of Practice covers the same ground. Its principles include ‘Follow an established secure development framework’ (1.1) and understanding ‘the composition of the software’ and the risks of third-party components (1.2). Principle 1.3 is ‘Have a clear process for testing software and software updates before distribution.’

Why AI-built products find these hard

None of these questions is harder because AI tools were involved. They are harder when the way the product was built leaves no process to describe. That can happen when one or two people build quickly with AI tools:

• No defined process. Changes go from a prompt to production without a pull request, so there is no software development lifecycle (SDLC) to describe.
• No independent review. The person who prompted the change is the person who merged it.
• Thin tests. In our experience, AI coding tools leave predictable gaps, such as tests that run without asserting much, secrets in the code and missing authorisation checks.
• Unknown components. Nobody has a list of the third-party packages the tools pulled in, or a process for updating them.
• No records. Even where checks happen, nothing dated shows that they did.

Should you say that AI tools wrote the code?

Describe your development process accurately, and if AI tools are part of it, say where they fit and what checks follow. A description of your SDLC that leaves out the tools that wrote most of the code is not an accurate description, and reviewers compare answers across questionnaires and over time.

The buyer’s concern is control, not the tool. A statement that AI tools draft changes, that every change goes through a pull request with automated checks, and that a second person approves it before release is a strong answer. It is stronger than a vague description of a process that does not mention how most of the code was produced.

Two related questions may follow, and it helps to have answers ready:

• Data. Has customer or production data been shared with an AI coding tool? Check the terms of the plan your team uses, including whether prompts and code are used for training, and keep production data out of prompts.
• Ownership and licensing. Who owns AI-generated code, and how do you check it for licence problems? Our guide to AI code attribution for enterprise procurement covers how to record which tools produced which code.

What does a credible answer look like?

A credible answer names the control, the tool that enforces it and the evidence you can show. The examples below are for a fictional product. Adapt them only where they are true for yours.

Describe your SDLC (CAIQ AIS-04.1)

Weak: ‘Yes, we follow industry best practice.’

Credible: ‘Yes. Engineers raise every change as a pull request against a protected main branch. AI coding tools draft some changes, and the same controls apply to them. Each pull request runs automated tests, static analysis and dependency scanning, and needs approval from an engineer who did not write it. Releases go through an automated pipeline. Our SDLC policy is reviewed annually and is available on request.’

Is testing automated? (CAIQ AIS-05.2)

Weak: ‘Yes, we have tests.’

Credible: ‘Yes. Unit and integration tests run on every pull request and must pass before merge. Critical user journeys have automated end-to-end tests that run before each release. We can share a recent pipeline run.’

How do you manage third-party libraries? (CAIQ TVM-05.1)

Weak: ‘We keep our packages up to date.’

Credible: ‘Dependency scanning runs on every pull request and weekly on the main branch. Critical and high-severity updates are applied within 14 days. We hold a software bill of materials for each release.’

Do you use AI tools in development?

Weak: ‘No.’ (when the answer is yes)

Credible: ‘Yes. Engineers use AI coding assistants on a business plan whose terms exclude our code and prompts from model training. Production and customer data are never included in prompts. AI-drafted changes follow the same pull request, testing and approval process as all other code.’

What if the honest answer is no?

Say so, and give a dated plan. Reviewers expect young products to have gaps. What they need to see is that you understand each gap and have a plan to close it.

The enterprise buyer guide sets out how to handle gaps without overstating. For each gap, state the current position, any compensating control, and the remediation with a date. Claiming a control you do not have does more harm than the gap itself, because it surfaces later in an audit or an incident.

Partial answers are allowed. ‘Yes for the web application, not yet for the mobile app, scheduled for June’ is more useful to a reviewer than an unqualified yes.

How do you close the gaps before the next questionnaire?

Most of these controls can be switched on quickly if your code is on a platform such as GitHub. The longer work is fixing what they find. In rough order:

1. Protect the main branch. Require a pull request and at least one approval from someone other than the author before anything merges.
2. Switch on scanning. Turn on dependency alerts, secret scanning and static analysis. On GitHub, Dependabot alerts are included, while secret scanning and code scanning on private repositories need a paid licence.
3. Add tests where the risk is. Start with the business logic and the user journeys that would hurt most if they broke, and make sure the tests check results rather than just running.
4. Write the SDLC down. One or two pages describing how a change goes from ticket to production, including where AI tools fit.
5. Get an independent view of the code. A review against the OWASP Application Security Verification Standard (ASVS) gives you a dated record of what was checked and what was found.
6. Commission a penetration test if the buyer asks for one. Our guide to choosing between a penetration test and a production readiness review explains which to do first.

If you are a team of one, step 1 is the hard one, because a review needs a second person. A part-time engineer or an external reviewer for each release can fill that role. AI review tools are useful as an extra check, but do not describe them as peer review in a questionnaire.

What evidence should you attach?

Attach evidence that is dated and specific, and offer the rest on request. Useful items include:

• Your SDLC policy, with a date and an owner
• A screenshot or export of your branch protection rules
• A recent pipeline run showing tests and scans passing
• A dependency report or software bill of materials
• A dated code review report listing what was checked and what was out of scope
• A penetration test summary letter, if you have one
• Your Cyber Essentials or Cyber Essentials Plus certificate, which covers your infrastructure but not your application code

Keep these with your maintained set of questionnaire answers. Each new questionnaire then becomes a matter of mapping questions to evidence you already hold.

How can we help?

Our Production Readiness Review gives you dated evidence about the code itself. It is a fixed-fee, two-week review for AI-built and AI-generated applications. Senior engineers validate the code against OWASP ASVS, Level 2 by default for business-critical systems, alongside our own suite of checks built from the findings of penetration tests on previous projects. Static code analysis runs with GitHub Advanced Security and our in-house rules.

You receive an evidence pack listing what was checked, what was out of scope and every finding by severity, with a prioritised plan. Our production readiness checklist for AI-built apps shows the items it covers. Fixes run as tickets under managed support for AI-built software or as a separately quoted piece of work.