# Security questionnaire pentest questions: what buyers ask and how to answer

Source: https://penetrationtestservices.com/guides/security-questionnaire-pentest-questions/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Pentest questions in security questionnaires (SIG, CAIQ, custom): 14 common questions with honest answer patterns, the evidence to attach, and what to avoid.

> **Short answer:** Security questionnaires ask the same pentest questions: do you test, how often, who tests, what scope, how fast you fix, and can we see a report. A table pairs each question with an answer pattern you fill in with facts, plus the evidence to attach. Never claim more than your last report shows.

Security questionnaires ask about penetration testing in a few standard ways. Buyers want to know whether you test, how often, who tests, what the scope was, and whether you fix what you find. The table in the common-questions section pairs each question with an answer pattern and the evidence to attach.

Cobalt's State of Pentesting Report 2025 found that third-party pentest reports are the most common assurance that customers and regulators ask for, at 59% of 450 survey respondents. It is a vendor survey, so treat it as one data point.

> **Note:** Treat the answer patterns as templates and fill them with facts from your own last report. A pentest does not prove that a system is secure, and no answer should say so.
## Which questionnaires ask about pentests?

The common sets are SIG, CAIQ and custom spreadsheets.

- CAIQ is the Consensus Assessments Initiative Questionnaire from the Cloud Security Alliance. It accompanies the Cloud Controls Matrix (CCM) v4. CCM control TVM-06, "Penetration Testing", asks you to define, implement and evaluate processes and technical measures for the periodic performance of penetration testing by independent third parties. Check the exact question wording in the current CAIQ file from CSA.
- SIG is the Standardized Information Gathering questionnaire from Shared Assessments. It is licensed, so the full question text is not public. Use the copy your customer sends.
- Custom questionnaires come from enterprise procurement teams. They often reuse SIG or CAIQ wording and add their own lines.

## What are the common pentest questions and good answers?

Each row gives the question, the answer pattern and the evidence to attach. Replace the brackets with facts. If a fact is not true, change the answer.

| # | Common question | Answer pattern | Evidence to attach |
|---|---|---|---|
| 1 | Do you perform penetration testing? | "Yes. Our last test was [month, year], on [web app and API]." | Letter or report summary |
| 2 | How often? | "[Once a year] and after [defined changes]." Say what triggers a test. | Policy excerpt |
| 3 | Who performs it? | "[An independent third party / internal team separate from engineering], [name]." | Provider name, tester role |
| 4 | What is in scope? | List apps, APIs, roles, environments. State what was excluded and why. | Scope section of the report |
| 5 | Is it black, grey or white box? | State the type. See [black box vs grey box vs white box](/guides/black-box-grey-box-white-box-testing/). | Report scope page |
| 6 | Does it cover the OWASP Top 10? | "Testing covered access control, authentication, injection and [list], as the report's method section shows." Do not claim full coverage. | Method section |
| 7 | When was the last test? | Give the date. If older than your stated interval, say so and give the next date. | Report date |
| 8 | Were critical or high findings found? | "Yes/No. [N] critical, [N] high. [N] fixed and retested; [N] open with dates." Counts only. | Remediation tracker |
| 9 | How fast do you fix? | State your policy targets by severity, then your actual record for this test. | Policy, ticket dates |
| 10 | Do you retest fixes? | "Yes. Fixed findings were retested on [date]." | Retest note |
| 11 | Can we see the report? | "We share [a summary / the report under NDA / a letter]." | Document |
| 12 | Do you test third-party components? | State how: scope of the test, your supplier review process. Do not claim to test a vendor's systems. | Vendor policy |
| 13 | Do you test after major releases? | State the trigger list. See [how often should you pentest](/guides/how-often-should-you-pentest/). | Release process |
| 14 | Is the tester certified? | Name the experience. Certifications are optional in most standards. | Tester bio |

## How do you write honest answers?

Apply these rules to every pentest answer:

1. Answer the question asked. Do not answer a vulnerability scan question with pentest facts, or the reverse.
2. Use dates and counts. "Tested in September 2026; 0 critical, 1 high fixed and retested" is a fact. "Regularly tested" is not.
3. State scope limits. If staging was tested and production was not, say so.
4. Do not promise results. Never write "no vulnerabilities" or "secure". A test finds issues in the time and scope it had.
5. Match the report. If the questionnaire answer and the report disagree, the buyer will find it.
6. Name open items. Say how many are open and when you plan to close them.

## What evidence should you attach?

Offer the lightest document that fits the question. A buyer who needs more will ask for it.

- A summary letter of the test: date, scope, tester and result counts. See [pentest attestation letter](/guides/pentest-attestation-letter/) for contents and limits.
- The executive summary of the report.
- The full report, under NDA, when the buyer asks for it.
- Your policy for testing frequency and fix targets.
- A retest note that shows closed findings.

Check what the testing agreement lets you share. Reports often hold details about your own system and sometimes about third parties.

## Why does the same question get asked three ways?

Questionnaires overlap because they come from different sources. One may ask for "annual third-party penetration testing", another for "independent testing", another for "technical testing of applications". Answer each with the same facts in the words of the question. Keep one page in your own docs with your test dates, scope, provider and counts, and update it after each test. The next questionnaire then becomes a copy-and-check job.

The service page for [customer security reviews](/customer-security-review/) describes how a test report fits this flow.

## How do you answer when the answer is no?

A "no" is better than a stretched "yes". Use this pattern: state the fact, state what you do instead, and give a date.

- "We have not had a third-party penetration test. We run [dependency scans and code review]. A third-party test of [web app and API] is planned for [month, year]."
- "Our last test was in [month, year], which is outside our 12-month target. The next test is booked for [month, year]."

Do not describe other work as a pentest. If you have a test from another source, such as a bug bounty program, say that exactly. See [bug bounty vs pentest](https://pentestcompare.com/guides/bug-bounty-vs-pentest/) for how the two differ.

## How do you keep answers consistent across customers?

Keep one internal record and copy from it. Include:

- Date, scope and provider of each test.
- Counts by severity at the report date and now.
- The policy text on frequency and fix targets.
- A list of documents you may share, and under which terms.
- The name of the person who approves security answers.

Review the record after every test, major feature release or incident, so sales answers from the same facts as the security team.

## What should you avoid?

- Claiming a standard "requires" the test when it does not.
- Claiming that an auditor or customer accepted your report before they said so.
- Saying "continuous" testing when you test on a schedule.
- Copy-pasting an old answer after the facts changed.
- Listing exploit details or open weaknesses in a questionnaire.

## A short checklist before you submit

- [ ] The test date and scope in the answer match the report.
- [ ] Counts by severity match the tracker.
- [ ] Open findings have owners and dates.
- [ ] You checked the sharing terms of your testing agreement.
- [ ] A second person read the answers.

## Questions

### Should we send the full pentest report to a customer?

Usually not by default. A full report lists weaknesses and reproduction steps. Share it only under an NDA, or share a summary or letter first. Check your contract and your testing agreement before you share anything.

### What if our last pentest is older than a year?

Say so, with the date. Then state what you did since: scope of recent tests, fixes and your plan for the next test. A dated, honest answer beats a vague one.

### Can we answer yes if we only ran a vulnerability scan?

No. A scan is not a pentest, and buyers know the difference. Answer the scan question as scans and the pentest question as pentest. If you did not run a pentest, say no and give the date you plan one.

### How do we handle open findings in an answer?

State the count by severity and the fix status, not the details. For example: no open critical findings, two medium findings with fixes scheduled. Do not describe open weaknesses in the questionnaire text.

## Sources

- [Cloud Security Alliance: Cloud Controls Matrix v4 and CAIQ v4](https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4)
- [Shared Assessments: SIG Questionnaire](https://sharedassessments.org/sig/)
- [Cobalt: State of Pentesting Report 2025](https://resource.cobalt.io/state-of-pentesting-2025)
- [PCI SSC: Information Supplement, Penetration Testing Guidance v1.1](https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)