“Have you had a penetration test?” How to answer when you haven’t

Somewhere in most security questionnaires there is a row like this: “Has an independent third party performed a penetration test of the application in the last 12 months? If yes, please provide the summary.”

If you are a small SaaS company, the honest answer is often no. That is common, and it does not have to end the review. What hurts is an answer that sounds better than the truth. This guide covers how to answer for each situation, and what to offer when you can’t attach a report.

What the question is asking

A penetration test (pen test) is an authorized, hands-on attempt by a person to break into your system, the way an attacker would, followed by a written report of what they found. The buyer asks because it is one way to learn whether someone other than your own team has looked for weaknesses.

Notice the wording in many questionnaires: “independent”, “third party”, “in the last 12 months”, “application”. Each word narrows the answer. A test your own engineer ran does not meet “independent”. A test of your office network does not meet “application”. Read the row twice before you answer.

A pen test is not a vulnerability scan

These two get mixed up, and reviewers notice.

• Vulnerability scan: automated software checks your systems or dependencies against lists of known issues. It is quick, repeatable and useful. It is not a pen test.
• Penetration test: a person (or a small team) actively tries to exploit weaknesses, chains issues together, and writes up what they found and how serious it is.

If all you have is scans, say so with the word “scan”. Something like: “We run automated dependency and vulnerability scanning. We have not had a third-party penetration test.” That is a good answer. Calling a scan a pen test is not.

If you have had an independent test

Say when, who did it (the type of provider, or the name if you’re comfortable), what it covered, and what you can share. For example:

“Yes. An independent security firm tested our web application in [month, year]. The report is available under NDA, and we have fixed the issues it rated high or critical.”

Only write that last clause if it is true, and keep the date exact. If the test is older than the period in the question, say so rather than rounding.

If you have not had one

Say no, then say what you do have. For example:

“No. We have not had a third-party penetration test. We run [automated dependency and vulnerability scanning], review code changes before release, and restrict production access to [named roles]. We can walk your security team through these controls on a call.”

Fill in the brackets only with things you actually do. If you can’t name three real practices, that is useful to know before the next questionnaire arrives, and our guide to answering a security questionnaire shows how to gather them.

If you have one planned

If a test is booked, you can say so, but only with facts you can stand behind. For example:

“No test has been completed yet. We have engaged [a provider / a provider is being selected] to test the application. We can share the summary once it’s complete.”

Don’t give a completion date unless the provider has confirmed one. Answers in questionnaires can end up referenced in contracts. Our guide on answers that invite follow-up explains why vague promises tend to bring more questions, not fewer.

What not to say

• “Yes” when you mean “we scan”. The reviewer may ask for the report, and then you have to correct yourself.
• “Our hosting provider is regularly tested.” Their testing covers their platform, not the application you built on it. You can mention it as context, but it does not answer the question.
• “We follow OWASP.” Referring to a standard shows awareness, not testing. It is fine as a supporting detail, not as a replacement for a yes or no.
• A date or scope you are unsure of. If you can’t remember what the test covered, find the report before you answer.

The same principle applies to the SOC 2 question: answer the question that was asked, then add context.

What to offer instead of a report

Buyers usually want evidence that you take security seriously and can describe it clearly. Without a pen test, these help:

• Your written security policy, and the policies it points to (access control, incident response, backups).
• A short description of how you handle vulnerabilities: how you learn about them, who triages them, how fast you aim to fix serious ones. Only state timelines you actually follow.
• Evidence of automated scanning, if you run it, described as scanning.
• A short architecture overview: where data is stored, how it’s encrypted, who can reach production.
• A call. Many small-vendor reviews end up resolved by a conversation between the buyer’s security person and whoever runs security at your company, even if that is the founder.
• A commitment you can keep, such as “we will share a summary after our first test”, only if you intend to do one.

If the buyer says a pen test is a hard requirement, you will know early, which is better than finding out at contract stage. Some regulated or high-risk buyers do require one. Ask what scope and what format they accept, because requirements vary, and a test scoped to their concern can be cheaper than a broad one.

If you decide to get one

A few practical points, without turning this into a buying guide:

• Define the scope in writing: which application, which environments, what is out of bounds.
• Test a staging environment with realistic data when you can, not production data from real customers.
• Ask what the report looks like and whether there is a shorter summary you can share with buyers. Sharing the full report with every prospect is usually not what you want.
• Plan time to fix the findings and, ideally, to have the fixes confirmed. A report with open serious issues is harder to share.
• Keep the summary and date in your answer library so the next questionnaire is a copy, not a scramble. See how to build a reusable answer library if you don’t have one yet.

Sharing a report safely

If you do have a report, don’t attach it to a spreadsheet by default. Most vendors share a summary letter or executive summary, under NDA, and offer the full report only when the buyer’s security team specifically asks. Check that your NDA covers it, and check what your testing provider’s terms say about sharing.

The short version

• Read the exact wording: independent, third party, time period, application.
• A scan is not a pen test. Call it what it is.
• If the answer is no, say no, and then give the buyer specific, true things to evaluate.
• Don’t promise dates or results you can’t confirm.
• Keep your answer, date and summary in one place so you only do this work once.

For more example wording, the 50 common questions guide has model answers you can adapt.

Answering it with Rendro

Rendro drafts questionnaire answers from your own documents and marks anything it can’t support as Needs review, so a question like this one never gets a “Yes” your policies can’t back up. There is a 14-day free trial on rendro.net.