Customer security questionnaire: which claims can your product support?

The customer asks whether its data is isolated, whether AI retains documents and who exported a file. Your team has diagrams, provider documentation and previous answers. Which answers describe the product running today?

For a CTO reviewing a B2B product with an AI feature, the useful outcome is a set of defensible commitments. Some questions need better evidence. Others reveal a missing control that engineering must correct. A carefully worded response cannot make that control exist.

On a call with a CTO, we put it this way: “A convincing questionnaire describes the product you intend to have. A working control is one you can show on the product you run today.”

The short answer: take each consequential claim through the relevant source code, deployed configuration and a bounded runtime check. State the product, paths and conditions those checks cover. When the evidence stops, narrow the answer or record the gap. Keep specialist assurance and the customer’s acceptance as separate decisions.

1. Fix the product scope before filling the questionnaire

Consider an illustrative document portal. Each customer has a workspace. Users upload files, request AI summaries and download exports. The product uses Supabase for its database, authentication and file storage, and calls an AI model through a backend service. This is an explanation of what to inspect, not a tested product or an IZZY client case.

The Cloud Security Alliance’s CCM and CAIQ provide a cloud-control framework and assessment questions. They help organise a review; the customer’s exact requirement still needs an answer about your implementation.

For this portal, distinguish the browser, customer API, export worker, support access, model provider and stored copies. Record the reviewed deployment and build, the configuration date, the roles involved and the evidence you can disclose. A production claim cannot rest solely on a staging screenshot.

Use three evidence layers together:

• Source code shows where a control should apply, including exceptional paths.
• Deployed configuration shows the settings, policies and identities in effect.
• Runtime evidence shows what happened for specified actions under those conditions.

None automatically substitutes for the others. A successful test of one path does not establish every path. The CNIL’s development guidance (in French) recommends testing and backend protections; a hidden button in the interface is an incomplete answer to an access-control question.

2. “One customer cannot download another customer’s files”

Suppose the evidence pack contains database row-level security policies and a test showing that a user from workspace A cannot read workspace B’s document row. That supports an important boundary. It leaves the export worker to examine.

In this illustrative design, the worker receives a document identifier and uses a privileged credential to retrieve the file. If it trusts the identifier without checking workspace membership, the database test does not establish that the download route is isolated.

This distinction follows the platform’s documented controls. Supabase’s RLS documentation describes privileged paths that can bypass row-level policies; the exact request identity matters. Storage has its own access-control policies on its objects table, and a service key bypasses them entirely. Database-policy evidence alone cannot settle file access through your backend.

Trace the claim through:

• Code: where the worker binds the requesting identity, workspace and document; how it authorises export before retrieving bytes.
• Configuration: the deployed worker identity, database policies, file policies and permitted credential use.
• Runtime: an authorised user’s successful download, a cross-workspace request and a request after membership removal, using controlled test accounts and data.

If the worker lacks that authorisation, classify the issue as a control gap. Implement the check at the effective access boundary and retest the affected paths. Adding the policy screenshot to the questionnaire would leave the defect in place.

For this hypothetical evidence set, the bounded answer is: “Database isolation is evidenced for the checked route. Export authorisation remains unverified; application-wide isolation is not established.” After correction, update the answer against the dated retest scope, keeping support access separate.

The full customer-boundary check, across requests, exports and realtime delivery, is in Can customer A access customer B’s data?.

3. “Customer documents are not used to train AI models”

This statement needs a data-flow check as well as provider documentation. Identify the production organisation, project, API route, selected features and applicable account controls. Inspect what the backend sends and whether an intermediary receives the same content.

For example, OpenAI’s API documentation states that API data is not used for model training unless the customer explicitly opts in. The same page separately describes abuse-monitoring logs and application state. An absence-of-training claim does not establish absence of storage.

In the portal, the application might also retain summaries or send failed requests to an error-monitoring service. The model provider’s default says nothing about those copies.

Check the backend integration in source, the actual account settings and a sanitised trace of a controlled request. Avoid capturing a customer’s confidential document merely to demonstrate the flow. Compare the observed destinations with the declared supplier list; the CNIL’s subcontracting guidance (in French) is a useful reference for examining security measures and responsibilities.

The correction may be to disable unintended sharing, remove unnecessary content from monitoring, or change the integration. Without account-level evidence, a bounded answer is: “The API’s published training default is documented. Our account settings and full retention path remain unconfirmed.” Provider documentation does not prove your configuration or settle the applicable contract.

4. “We can identify who exported a document”

An HTTP success log with a timestamp and worker identity may show that an export endpoint responded. It may leave the initiating customer user unknown.

For this claim, inspect the source that creates the export event, the deployed logging destination and access controls, and a sanitised event from a controlled export. Can the reviewer connect the initiating user, workspace, document reference and outcome? If the work is asynchronous, can the request be linked to the worker’s eventual result rather than merely its acceptance into a queue?

The CNIL’s logging guidance (in French) separates application traces of users’ activity from technical traces, including administrators’ interventions, and warns against excessive duplication of personal data in logs. Recording the full document or prompt to fill a logging gap can create another problem.

If the sample identifies only the worker, the correction is to preserve appropriate attribution across the handoff. Then check that the event is produced, retrievable and protected as intended. Retention settings and a named person responsible for reviewing anomalies also need evidence; do not infer them from the existence of a log service.

For the worker-only log in this example: “Current HTTP logs identify the worker. Attribution to the initiating user is not yet demonstrated.” After correction, name the events and period evidenced; do not claim every action is audited.

5. “Deleting an account removes its data and access”

Treat this as several linked claims. Does the operation remove the login identity, application rows, uploaded files, derived summaries and search entries? What happens to pending jobs, existing access tokens and retained copies?

Supabase’s user-management documentation gives concrete reasons to inspect the sequence: deleting a user does not automatically invalidate an already issued JWT before expiry, and ownership of Storage objects can prevent user deletion. Those behaviours do not define your entire deletion process.

In the illustrative portal, inspect the deletion handler and background jobs, then compare them with deployed storage and retention settings. Use a controlled account containing a file and an AI summary. Check each relevant store and attempt the previously permitted actions after deletion. Distinguish immediate loss of access from later scheduled erasure.

Suppose the handler deletes the database row but never invokes file cleanup. That needs an implementation correction and a failure/retry path, not a more persuasive description. Test a cleanup failure as well as success so that a partial deletion cannot silently be reported as finished.

For that incomplete handler: “Application-row deletion exists; complete file removal is not established.” The corrected answer must identify what is deleted, when and under which exceptions. Privacy and contractual owners confirm those commitments; engineering evidence does not provide a general legal-compliance verdict.

6. Approve the supported answer, or fund the missing work

Bring the four claims back to the technical review. The result should change a decision:

Advice we argue with: “answer yes now, fix it before the audit.” If the control does not exist today, we state its current limit and propose the fix or a narrower commitment. We do not write a yes the running product cannot show.

The CTO owns the technical description. Other authorised owners approve contractual, privacy and commercial commitments. The customer’s reviewer decides whether the evidence meets its requirement. A technically accurate response may still fall short of the assurance that customer requires.

Share a redacted, scoped account of the evidence through the agreed channel. Raw credentials, customer content and exploitable implementation details do not belong in an unrestricted answer pack. Keep the submitted answer and reopen it when the relevant implementation changes.

For the broader question of checking AI-written software, see how to verify AI-generated code. For this review, start with the customer’s most consequential unsupported sentence and trace it to the running product.

Sources and limits

Sources checked on 10 November 2026. The portal, gaps, checks and possible answers are illustrative; no runtime test or customer review was conducted for this article. Public guidance and product documentation support the specific distinctions cited. Actual configuration, disclosure permission and specialist assurance requirements need checking for the reviewed product.