Security questionnaires, SOC 2 and the pentest your customers will ask for

The deal is nearly done when the buyer's security team sends a long spreadsheet. Somewhere in it is a question that can hold up signature for weeks: can you provide a penetration test report from an independent third party, dated within the last twelve months? The answer has to exist before procurement asks, and a first test with its fixes and retest takes six to eight weeks from the first call to the letter.

What enterprise security reviews ask

Questionnaires arrive in three forms: the buyer's own spreadsheet, a portal run by a third-party risk platform, or a standard questionnaire such as the Shared Assessments SIG or the Cloud Security Alliance's CAIQ, now at version 4.1, a set of yes or no questions a cloud customer may ask of a provider. Whatever the format, the testing questions cluster around the same points:

• When was your most recent independent penetration test, and which systems did it cover?
• Who performed it, and are they independent of the people who build and run those systems?
• Can you share the report, an executive summary or a letter from the tester?
• Were critical and high-severity findings fixed, and was each fix verified by a retest?
• How often do you test, and what kind of change triggers an extra test?
• Do you scan for vulnerabilities between tests, and how quickly do you patch?
• Do you hold a SOC 2 Type 2 report or an ISO/IEC 27001 certificate, and does its scope include the product we are buying?

A reviewer is usually checking four things rather than judging your code: that the evidence exists, that it is recent, that it covers what they are buying and that the findings were closed. Evidence that answers all four on its first page shortens the review; evidence that does not invites a second round of questions.

SOC 2: what the criteria require and what auditors look for

A SOC 2 report is a CPA firm's opinion on your controls, measured against the AICPA's Trust Services Criteria: the 2017 criteria, with points of focus revised in 2022. There are five categories, Security, Availability, Processing Integrity, Confidentiality and Privacy, and Security is the one every report must include. The criteria describe outcomes rather than prescribing controls, which leaves each organisation to choose the specific controls that fit its circumstances.

That flexibility settles a frequent question. SOC 2 does not, by itself, require a penetration test. What your auditor tests is whether the controls you describe for risk assessment, monitoring and vulnerability management exist and operate. An independent test with tracked remediation is one of the most direct forms of evidence for those controls, and it is the evidence your customers' questionnaires ask for by name. If your control descriptions commit you to an annual penetration test, the auditor will test that commitment like any other.

ISO/IEC 27001 and PCI DSS: where testing is named

ISO/IEC 27001:2022 sits between the two. Its Annex A lists 93 controls in four groups, and you decide which apply in your Statement of Applicability. Control 8.8, management of technical vulnerabilities, requires you to identify technical vulnerabilities, evaluate your exposure to them and act on them, and guidance on the control lists periodic, documented penetration tests by internal staff or a third party alongside vulnerability scanning as ways to find them. A certification auditor will want to see the process, the records of tests and scans, and the risk decisions that followed.

PCI DSS is the explicit one. Version 4.0.1, a limited revision published in June 2024, replaced version 4.0 when that was retired on 31 December 2024, and the requirements that had been future-dated became mandatory on 31 March 2025. Requirement 11.4 states that external and internal penetration testing is regularly performed and that exploitable vulnerabilities and security weaknesses are corrected. Tests run at least once every 12 months and after significant change, performed by a qualified internal resource or a qualified third party that is organisationally independent of the systems under test.

• 11.4.1: a penetration testing methodology is defined, documented and implemented.
• 11.4.2 and 11.4.3: internal and external penetration testing are performed.
• 11.4.4: exploitable vulnerabilities and security weaknesses found during testing are corrected, and testing is repeated to verify the corrections.
• 11.4.5: where segmentation isolates the cardholder data environment from other networks, the segmentation controls are tested.
• 11.4.6: an additional segmentation testing requirement applies to service providers.
• 11.4.7: multi-tenant service providers support their customers' external penetration testing.

Attestation letters and what they prove

An attestation letter is a short statement from the testing firm that summarises what was tested, when and how, and the current status of the findings, without the technical detail that would help an attacker. It is the tester's own statement rather than a certificate, so its value depends on the scope it states and the retest behind it. Ours is issued after the retest, so it reflects what has actually been fixed, and anything we have not verified as fixed stays open in the letter.

The PCI Security Standards Council's penetration testing guidance suggests a report outline built around an executive summary and statements of scope, methodology and limitations. A letter a reviewer can rely on carries the same essentials:

• Who tested, and their independence from your engineering team
• The dates of testing and of the retest
• The scope: named targets, environments, roles and the kind of test, such as grey-box
• The methodology and standards followed, such as the OWASP Web Security Testing Guide
• Findings by severity, with each one's status after the retest
• Limitations: anything excluded, blocked or left untested

Scoping a test that satisfies procurement

1. 1

   Get the requirement in writing

   Copy the exact questionnaire line, contract clause or auditor request, including any recency window such as within 12 months and any named standard.

2. 2

   Map it to what the customer will use

   The web application, the API, single sign-on, admin functions and the cloud account the product runs in. A reviewer compares your scope with their integration.

3. 3

   Choose the depth deliberately

   Grey-box authenticated testing, with accounts for every role, is our default for applications because it reaches tenant isolation and authorisation flaws that an unauthenticated test cannot see.

4. 4

   Match the audit boundary

   For SOC 2, the systems inside your report's scope; for PCI DSS, the cardholder data environment and any segmentation that keeps other systems out of it.

5. 5

   Plan the retest before the test starts

   Book engineering time for fixes before the report arrives, so they are ready for the free retest of every fixed finding within 30 days of report delivery and the letter can follow straight after.

6. 6

   Agree what you will share

   Decide in advance whether reviewers get the letter, the executive summary or the full report under NDA, so nobody improvises in the middle of a deal.

All six steps come up on the scoping call. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email. The compliance overview shows in more detail how each framework treats testing, and how penetration testing works explains what a test is and is not.

Timeline planning before a deal closes

Work backwards from the date the customer needs the evidence. The stages below follow our standard engagement for a web application; a larger scope adds testing days without changing the shape.

Added up, plan on six to eight weeks from first call to letter for a first test with a verified retest, and remember that the fixing stage is the one you control. If the deal is closer than that, say so on the call: we will give you the earliest date we can start, and the scope can be focused on the surfaces the customer will actually use.

• The last test falls inside the buyer's recency window, and the next one is booked.
• The scope in the letter matches the product the customer is buying.
• Every critical and high finding is fixed and retested, or carries a documented risk decision.
• The attestation letter is dated after the retest.
• Your SOC 2 report period is current, or a bridge letter covers the gap.
• Questionnaire answers, the letter and your SOC 2 control descriptions say the same thing about how often you test.
• A named person can answer the reviewer's follow-up questions within a day.

If you are starting from nothing, begin with an authenticated web application test of the product the customer will use, and add a cloud configuration review when your SOC 2 scope or the questionnaire reaches the infrastructure underneath it.