SaaS pentest for enterprise security questionnaires (SIG, CAIS)

The questionnaire that stalls the deal

The demo went well, the buyer’s engineers liked the product, and then the security team’s spreadsheet arrives: SIG, CAIS or a custom third-party risk questionnaire with 150 questions. Somewhere in it sits the line that sets the pace of the deal: "Do you perform independent penetration tests? When was the last one? Can you share the results?"

Vendors who answer "yes, we do" with no attachment usually get a follow-up question. Vendors who answer "yes, in March, here is the executive summary with retest status" move to the next row. This guide shows how to build that second answer before the questionnaire lands.

While the spreadsheet sits unanswered, the contract sits too. Sales keeps chasing, engineering says "we have a pentest, I just need to find the PDF", and the customer’s analyst marks the item as pending. The security review is often the last step before signature, and every question-and-answer round pushes out the date of the first payment.

What the customer’s risk team actually wants to know

The third-party risk analyst will not read your full technical report. They need to tick a defensible box for their own internal auditor. In practice they look for five things:

Independence: the test was run by a third party, not by your own developers.
Recency: usually within the last 12 months, or after a significant product change.
Relevant scope: it covers the application and API the customer will use, not just the marketing site.
Finding handling: critical and high findings were fixed and retested.
Method: a named methodology (OWASP WSTG, OWASP API Security, PTES, NIST SP 800-115), not just a list of items.

If your material answers those five points on one page, most of the friction disappears.

What to share: attestation letter, executive summary or full report

You almost never send the full report. It contains vulnerability details, internal paths and exploitation proof. In the wrong inbox it becomes an attack roadmap. The common market pattern has three layers:

Document	What it contains	When to send
Attestation letter	Who tested, when, scope, methodology, severity summary, retest status. One page.	Default answer to questionnaires and first due-diligence contact
Executive summary	Risk overview, counts by severity, confirmed fixes, test limitations. 2 to 4 pages.	Enterprise customers, security requests during negotiation
Retest letter	Confirms, finding by finding, what was fixed and what remains open, with dates.	When the customer asks whether the serious issues were resolved
Full report	Detailed findings, evidence, reproduction steps.	Only under NDA, for specific customers with a formal request; prefer supervised reading

Two practical rules: never send open findings without a remediation plan, and keep a version of the summary without endpoint names, test accounts or credentials. Talk to legal about the NDA before the request arrives, not during it.

How to answer the question in the questionnaire

An answer that usually passes without a follow-up has this structure:

Yes, with a defined frequency ("annually and after significant architecture changes").
Date of the latest test and who ran it (independent firm).
Scope: web application, API, authentication and tenant isolation.
Methodology: OWASP WSTG and OWASP API Security Top 10.
Finding status: critical and high issues fixed and retested on date X.
Attachment: attestation letter or executive summary.

Avoid vague wording like "we regularly perform security testing". Also avoid promising coverage the test did not have: if the scope was the API only, say it was the API only.

Sample answers to adapt

Question: "Does the company perform independent penetration tests?"

Yes. We run an independent penetration test annually and after significant architecture changes. The latest was completed in [month/year] by [company], covering the web application, API, authentication and tenant isolation, following OWASP WSTG and the OWASP API Security Top 10. Critical and high findings were fixed and retested on [date]. The attestation letter is attached.

Question: "Can you share the full report?"

The full technical report contains exploitation detail and is shared only under NDA on formal request. We provide an attestation letter and an executive summary, and can walk through findings in a supervised reading session.

If the first test has not happened yet:

Independent penetration test engaged, scheduled for [month]. We will send the attestation letter once the retest is complete.

Never invent a test date that does not exist. The analyst may ask for the attachment, and an honest answer with a timeline usually lands better than a "yes" with no proof.

Scoping a pentest for B2B SaaS

SaaS sold to businesses carries a risk a marketing site does not: many customers inside the same application. A good scope covers:

Web application (every authenticated function, per user role).
API used by the front end and by integrations, including undocumented endpoints. See our API pentest guide.
Authentication and session handling: login, MFA, password reset, SSO/SAML/OAuth, token expiry.
Multi-tenant isolation: can a user from customer A read or change customer B’s data? It is the finding enterprise buyers fear most, and the most common one in APIs (BOLA).
Authorization and roles: privilege escalation between roles (regular user to admin).
File uploads, exports, webhooks and integrations with third-party systems.
AI components, if you have them (assistants, RAG, agents), treated as part of the attack surface.

Cloud infrastructure testing belongs in scope if the customer asks about it, but for SaaS the core is application, API and tenant isolation.

In practice the weak spots of B2B SaaS are predictable: objects fetched by identifier without checking the owner (BOLA/IDOR), admin functions reachable by ordinary users, SSO with weak assertion or token validation, uploads that accept executable content, and exports that leak another customer’s data. Ask the vendor to test every user role and at least two accounts from different customers, so tenant isolation is proven rather than assumed. The internal admin panel belongs in scope too: it is where one mistake exposes every tenant at once.

When to test so the deal is not delayed

The worst time to buy a pentest is after the questionnaire arrives. A test takes days, the report a few more, and fixing plus retesting takes more again. A realistic timeline:

Before you start selling to enterprise: run the first test and have the attestation letter ready.
Every 12 months, or after a major change (new authentication architecture, new payments module, cloud migration).
When a large customer asks for its own scope: tell your vendor early, because scope changes and test windows take time.

A 2023 pentest presented in 2026 after two migrations becomes a question, not an answer.

The cost of delaying the test

Compare the price of the pentest with the cost of delay, not with zero. Every week a negotiation stalls postpones recurring revenue that only starts after signature, keeps sales and engineering in rework, and gives room to a competitor who already has the answer ready. There is no universal figure, but you can estimate it from your own data: take the annual value of your last three enterprise deals that stalled on security, multiply by the weeks of delay and divide by 52. Put that number next to the test quote.

Retest: the evidence that closes the conversation

The risk analyst does not need a report with zero findings. They know tests find problems. What they want to see is that serious issues were fixed and verified by the people who found them. That is why retesting matters:

Retest date and which findings were confirmed fixed.
Residual findings, with a documented risk acceptance or remediation plan.
A mention in the executive summary, not buried in an appendix.

A summary showing "3 high findings, 3 fixed and retested" is stronger than a clean report with no retest.

Keeping the evidence current between tests

An attestation letter ages. To keep it useful through the year:

Log significant changes in your release history (new payment module, new login method, cloud migration) and decide whether each needs a supplementary test.
Prefer a targeted test of what changed over redoing everything when the base architecture is the same.
Update the letter with the date of the latest retest whenever a new round happens.
Keep residual findings with an owner and a deadline, and review the backlog quarterly.
Use continuous scanning and dependency review as a complement. They help hygiene but do not replace manual testing.

How this speeds up deals and ties to SOC 2 and ISO 27001

Having the attestation letter and summary ready takes your security and sales teams out of the email queue. Instead of "let us check with the technical team" and a two-week wait, the answer goes out the same day, and the customer’s risk analyst has what they need to approve.

A pentest does not replace certification. SOC 2 and ISO 27001 show that you have security processes; the pentest shows that the product withstands attack. They complement each other, and many controls in both call for periodic independent testing. Our post on pentesting for ISO 27001, SOC 2 and GDPR details what each requires. If you have no certification yet, a recent pentest already helps you pass most questionnaires.

On cost, our pentest pricing guide explains what moves the price. For a SaaS with a web app and API, the investment is usually smaller than the cost of an enterprise sales cycle that stalls for lack of an answer.

Checklist: ready for the next questionnaire

[ ] Independent pentest in the last 12 months covering web app, API, authentication and tenant isolation
[ ] One-page attestation letter reviewed by legal
[ ] Executive summary with severity counts and retest status
[ ] Retest of critical and high findings documented with a date
[ ] Standard answer text for the pentest question
[ ] NDA policy defined for sharing the full report
[ ] Calendar for the next test (annual or after a major change)

Frequently asked questions

Can I send the full pentest report to a customer?

You can, but it should not be the default. Prefer the attestation letter and executive summary. Share the full report only under NDA, for a specific customer with a formal request, ideally as supervised reading.

My pentest is more than 12 months old. Is it still valid?

Many customers accept up to 12 months and ask what changed since. After a major change in architecture, authentication or cloud, plan a new test or a supplementary test of what changed.

Do I need SOC 2 or ISO 27001 to sell to enterprise?

Not necessarily. Many customers accept a recent pentest, documented policies and consistent questionnaire answers. Certification helps when the customer requires it in the contract.

Does an automated scanner count as evidence?

Usually not. Reviewers can tell a scan from a manual test. See the difference in scanner, pentest or bug bounty.

How long does it take to get the executive summary?

It depends on scope. Agree on the format of the attestation letter and executive summary with your vendor up front, so they ship together with the report and retest.

Who signs the attestation letter?

The company that performed the test, stating date, scope, methodology and retest status. Your own legal team should review the wording before the first send.

Should the test run on production or staging?

Ideally on an environment equivalent to production with fictitious data, or on production with an agreed window and safeguards. The letter should say which environment was tested, because the risk analyst will ask.

Can a customer demand to test our product themselves?

Some ask. It usually works to define the window, scope, test accounts and a ban on denial of service in the contract, and to offer the independent report as the alternative.

Prepare your answer before the next questionnaire

Pentest Machine delivers SaaS pentests with enterprise-ready deliverables: attestation letter, executive summary, full technical report and retest of fixed findings. Define the scope with us before the questionnaire arrives. Request a quote.