When an enterprise buyer sends you a security questionnaire, the application-security section almost always asks whether you follow or test against the OWASP Top 10. The best answer is not a bare "yes". It is a short, honest description of what you actually do to manage those risks, backed by evidence. Overclaiming is the most common mistake, and it is the one that costs you trust when a buyer digs in.
What the buyer is actually asking
Most questionnaires are built from a standard framework, such as the Shared Assessments SIG, the Cloud Security Alliance CAIQ, or a bespoke spreadsheet, and the web-application section references the OWASP Top 10 directly. CAIQ's application security section, for example, asks about input validation, API security and OWASP.
The buyer is not asking for a certificate. OWASP is a nonprofit awareness project, and the Top 10 is an awareness document, not a certification, so there is no such thing as being "OWASP certified". What a procurement or security team wants to see is that your engineering team understands these risks and actively manages them. Increasingly they want evidence rather than a self-attested "yes", and an unexplained "yes" or a bare "N/A" tends to read as evasive.
The three risks your answer should show you manage
The full list has ten categories, but for a small SaaS team three come up most often. Using a standard business dashboard as an example, here is each risk and the one honest thing you should be able to say you do about it.
- Broken access control (the number one risk). This is when a user can act outside their permissions, for example changing a web address that ends in
client_id=44to45and seeing another organisation's data. What to be able to say: you enforce a check on the server for every request, confirming the logged-in user is allowed to see that specific data. - Exposed secrets and keys (authentication failures). This is usually a hardcoded API key or token left in the source code, which is exposed the moment that code reaches a public repository. OWASP treats a leaked key as a stolen credential. What to be able to say: secrets live in environment variables or a secrets manager, never in the code, and any file that holds them is kept out of version control.
- Injection. This is when user input is treated as a command rather than as data, letting an attacker manipulate your database. What to be able to say: you use your framework's parameterised queries, or an Object-Relational Mapper (ORM), rather than building database commands by hand.
How to answer honestly
A strong answer is specific, truthful, and backed by something. A weak one is a vague "yes" that falls apart under a follow-up question. A few principles:
- Describe what you actually do, in plain terms. For example: "We follow secure development practices aligned to the OWASP Top 10, including server-side access-control checks, parameterised database queries, and keeping application secrets out of our source code."
- Be honest about gaps. A clear "not yet, and here is our plan and timeline" builds more trust than a hollow "yes" a buyer can puncture. Never leave an unexplained "N/A".
- Offer evidence. The strongest backing is an independent application security review and the report that comes with it, which shows a buyer you have checked your app against these risks rather than just asserting it.
- Do not claim what you do not have. There is no OWASP certification, so do not imply one. If a buyer specifically requires a formal certification such as SOC 2 or ISO 27001, a security review is not a substitute for those, and it is far better to say so than to imply you hold something you do not.
Turning your answer into evidence
The most convincing way to answer the OWASP question is to point to work you have actually done. That is what we do at Secvura. We carry out an application security assessment that checks your app against the OWASP risks, give you a clear report you can put in front of a buyer or insurer, and, with our find and fix approach, help you remediate what it turns up rather than just handing you a list.
If you have a security questionnaire to answer and want your app reviewed first, you can get in touch through our website at www.secvura.com.