Security questionnaires (SIG, CAIQ, or a customer's custom form) ask whether you run real, recurring, independent penetration testing on the systems that hold customer data. Answer honestly: a vulnerability scan is not a pentest, and claiming one when you only scan collapses deals. Attach the least sensitive sufficient evidence — usually an attestation letter or executive summary, not the full report (share that under NDA only). Keep a test within twelve months and after significant change. If a deal is blocked on this row, a well-scoped pentest with an attestation letter usually unblocks it fast. The question-by-question decode is below.
// 01 Why these questions are on the form
Enterprise buyers run third-party risk management: before they trust you with their data, they check that you test your own defences. The penetration-testing rows exist because a vendor breach becomes their breach. They're not trying to trip you up — they're trying to size the risk of onboarding you. That framing matters, because it tells you how to answer: with enough specificity to demonstrate a real programme, and enough honesty that nothing unravels when they ask for proof. A confident, evidenced “here's exactly what we do” de-risks you faster than a vague “yes to everything.” This is often the same trigger as a customer asking for your pentest report.
// 02 The common questions, decoded
| The question | What they're really asking | How to answer |
|---|---|---|
| Do you perform regular penetration testing? | Independent, human-led, recurring test of relevant systems | State frequency, who performs it, and scope |
| How often is testing performed? | At least annually and after significant change | Give the cadence honestly; note post-change testing |
| Is testing performed by an independent third party? | Not just self-assessed by the dev team | Name third-party use, or explain internal independence |
| Are findings remediated and retested? | You close criticals, not just log them | Describe remediation SLA and retest |
| Can you provide a report or attestation? | Evidence, not just a checkbox | Offer an attestation; full report under NDA |
| Do you test web apps / APIs / cloud / network? | Coverage matches where their data lives | Map scope to the relevant asset types |
// 03 How to answer without over-committing
The two failure modes are opposite. Under-committing — leaving rows blank or answering “no” where you actually have a partial programme — makes you look less mature than you are. Over-committing — ticking “yes, annual third-party pentest” when you ran one scan two years ago — is worse: it's a written misrepresentation that can breach the contract and detonate the relationship the moment they ask for the report. The safe path is precise honesty: describe exactly what you do, at what frequency, on what scope, and where you're strengthening it. “We perform an annual third-party web and API penetration test, last completed in [month], with criticals remediated and retested” beats a bare tick every time.
// 04 The scan-vs-pentest trap
The most common honest mistake is answering the penetration-testing row based on your vulnerability scanning. They are different activities, and mature questionnaires ask about each separately. A scan runs a tool against known-vulnerability signatures; a pentest is a human chaining weaknesses to prove real impact. If you only scan, say so on the scanning row and answer the pentest row truthfully — either “planned, by [date]” or “not yet, here's our approach.” If a deal genuinely hinges on it, that's your cue to run your first real pentest; it's a far cheaper fix than a lost enterprise contract.
// 05 What evidence to attach — and what not to
Default to the least sensitive artifact that satisfies the ask. For most questionnaires that's an attestation letter or an executive summary: it confirms a test happened, its scope and date, and that findings were remediated — without handing over a step-by-step map of your weaknesses. Reserve the full technical report for NDA, and even then share it only when genuinely required and ideally redacted of live exploit detail. Handing the complete report to every prospect is a quiet data-leak of your own attack surface. A clean, recent attestation clears the vast majority of forms without that exposure.
// 06 Getting ahead of the questionnaire
The teams that answer these fastest treat the pentest as a standing sales asset, not a fire drill. Keep a test within the last twelve months and refresh it after any significant release; hold a current attestation letter ready to attach; and if you're selling into regulated GCC customers, scope the engagement so one test also covers your local obligations. That way the questionnaire becomes a two-minute copy-paste with an attachment, and the pentest row — often the one that stalls deals — becomes the one that closes them. Plan the cadence with how often you need a pentest.
// 07 Frequently asked questions
What does "Do you perform regular penetration testing?" really mean?
Whether an independent, human-led test runs on a recurring basis — typically at least annually and after significant change — against the systems holding the customer's data. A scan isn't the same thing. Answer honestly with frequency, who performs it, and scope, and be ready to attach an attestation or summary.
Can I answer "yes" if I only run automated scans?
No. Scanning and pentesting are different activities and most forms ask about them separately. Claiming a pentest when you only scan is a misrepresentation that can breach the contract and collapse the deal when they ask for the report. Answer the scan row honestly and either arrange a real pentest or explain your plan and timeline.
What evidence should I attach?
The least sensitive artifact that satisfies the customer — usually an attestation letter or executive summary confirming the test, scope, date and remediation, not the full technical report. Share the full report only under NDA and only when genuinely required. A recent attestation clears most questionnaires cleanly.
How recent does the test need to be?
Most customers expect one within the last twelve months, and many want one after any significant change. If your last test is older than a year or predates a major release, expect to be asked to run a new one. An annual cadence plus post-change testing keeps you ahead of the question.
// 08 Related reading
- The penetration test attestation letter — the evidence to attach.
- A customer is asking for our pentest report and how to read it.
- Pentest vs vulnerability assessment and how often you need one.