A client is asking for security assurances about my application: what do I need
By Kike Gandia · Co-Founder & CEO, OSCP
It is the conversation that shows up as soon as you start selling to companies, and it usually arrives without warning: your client's procurement or security team sends a questionnaire, or asks directly for "the security report". If you built the product with AI and have never been through this, the usual reaction is to improvise. This guide explains what they will actually ask for, what you can answer today at no cost, and what you need to obtain if you want to close the deal.
What they will ask for, in order of likelihood
A security questionnaire. A form, sometimes a hundred questions long, covering encryption, access control, backups, incident handling and sub-processors. By far the most frequent.
A recent penetration test report. Usually from the last twelve months, and increasingly they require it to come from an independent third party rather than a self-assessment.
A data processing agreement (DPA). If your application processes personal data belonging to your client's customers, this is not optional: it is a GDPR obligation on both sides.
Certifications. ISO 27001 or SOC 2. The most expensive and slowest to obtain, and normally required only by large companies or regulated sectors.
Architecture detail: where data is hosted, in which country, which sub-processors are involved and how data is segregated between clients.
What you can answer today at no cost
More than you would think. Much of the questionnaire is answered with information you already have and have simply never written down:
- Where data is hosted and in which region. You know this: it is your provider configuration.
- Which sub-processors you use. Your data provider, email, payments, analytics. Build the list once and reuse it.
- How users authenticate and whether a second factor is available.
- What data you actually store. This exercise usually reveals fields nobody uses, and removing them improves the answer and reduces risk.
- Your backup policy, even if it is the provider default.
Answering "I don't know" to these is what sinks a review. Answering "we use the provider automated backups, with seven-day retention" is a perfectly valid answer.
What you cannot improvise
Two things cannot be solved by writing.
The penetration test report. There is no way to manufacture one: either somebody has tested your application or they have not. And stating in a questionnaire that you have run security testing when you have not is a false contractual declaration, with consequences very different from admitting you have not done it yet.
The certifications. ISO 27001 or SOC 2 take months and require operating evidence accumulated over time. If your client treats them as a hard requirement and you do not have them, the realistic route is negotiating a plan with dates, not promising them for next month.
In both cases what works is honesty paired with a plan: "we have no certification; we do have a technical audit from June and this is the remediation plan" is a defensible position. "Yes, all fine" with nothing behind it collapses at the first follow-up question.
The order that closes the most deals
If you are mid-sale and have weeks rather than months:
1. Run the basic checks on your own application, so you know whether you have a serious problem before your client finds it.
2. Close whatever critical issue appears. An access flaw found by the client during evaluation usually ends the conversation.
3. Write the inventory: what data you store, where, sub-processors, access.
4. Commission an external technical audit with a deliverable report. That is what turns the questionnaire into a formality.
5. Leave certification for after the contract, unless it is an entry requirement.
The expensive mistake is the reverse: starting with certification, taking eight months and losing the client along the way.
Why this resembles investor due diligence
The questions are almost the same and the moment is equally bad for improvising. A Series A or B investor reviews exactly this: what data you process, who has access, whether anybody has tested the product and what they found.
The difference is the consequence. A client who is not satisfied does not sign; an investor who finds a security problem rarely walks away, but uses it in the negotiation. In both cases the material you need is the same, so it is worth preparing once and keeping it current rather than rebuilding it for every conversation.
FAQ
Is a two-year-old pentest report acceptable?
Almost never. The usual reference is twelve months, and many questionnaires say so explicitly. The logic is sound: if your product has changed since then, the report describes an application that no longer exists. An older report paired with a recent re-test of the findings is usually accepted.
My client wants ISO 27001 and we are a three-person company, what now?
First ask whether it is a hard requirement or a preference, because it is often the latter and can be replaced by an external technical audit plus a dated certification commitment. If it is hard and the contract justifies it economically, the path exists, but plan for six to twelve months and real dedication from somebody on the team.
Do I have to show the full pentest report?
Not necessarily, and it is usually a bad idea: it contains the exploitation detail of your vulnerabilities. The norm is to provide an attestation letter or an executive summary issued by whoever ran the audit, confirming scope, dates, methodology and remediation status without publishing the technical detail. Ask for that format when commissioning the audit.
Related service
Related content
- What investors ask for in security due diligence
- Check in 15 minutes whether your app leaks data
- Is an app built with AI secure?
- Cybersecurity for startups