On this page
- Why SOC 2 auditors ask for a VAPT report
- What a SOC 2 VAPT report looks like, section by section
- What SOC 2 auditors actually check in your VAPT report
- SOC 2 Type 1 vs Type 2: timing your penetration test
- What should be in scope for a SOC 2 penetration test?
- Red flags in a SOC 2 VAPT report
- How to prepare for a SOC 2 penetration test
- Report, letter or certificate: what to share with whom
- SOC 2 VAPT for SaaS companies in India
- How Summit delivers SOC 2 VAPT reports
- Frequently asked questions
Why SOC 2 auditors ask for a VAPT report
SOC 2 is an attestation report issued by an independent CPA firm under the AICPA’s Trust Services Criteria. It describes your system and gives the auditor’s opinion on whether your controls are designed well (Type 1) and operated effectively over a period (Type 2).
The criteria do not say “perform a penetration test”. They describe outcomes. Two of them are where a VAPT report usually lands:
- CC4.1 (Monitoring activities)
- The organisation selects, develops and performs ongoing or separate evaluations to check that controls are present and working. Independent penetration testing is a common separate evaluation.
- CC7.1 (System operations)
- The organisation uses detection and monitoring procedures to identify changes that introduce vulnerabilities, and susceptibility to newly discovered vulnerabilities.
- CC4.2 and CC7.4
- Deficiencies are communicated and remediated, and security incidents and weaknesses are responded to. The retest section of a VAPT report is evidence here.
That is why the honest answer to “is a penetration test required for SOC 2?” is: not by name, but almost always in practice. Most CPA firms expect it, and the enterprise customers who ask for your SOC 2 report frequently ask for the penetration test summary next. Our SOC 2 readiness guide explains how testing fits the wider audit.
What a SOC 2 VAPT report looks like, section by section
Every testing firm formats its report differently, but a report that works well for SOC 2 has the same building blocks. Below is how ours is structured, and why each part matters to the auditor reading it. You can see a full example in our sample VAPT report.
1. Cover page and document control
A short page with the client name, the report title, the testing firm, the testing window (start and end dates), the report version and the distribution list. The dates matter more than they look: a Type 2 auditor checks that the test falls within, or close to, the observation period.
2. Executive summary
One or two pages written for leadership and for your auditor. It states what was tested, the overall security posture in plain language, the number of findings by severity, and the most important risks. A good executive summary lets a non-technical reader understand the result in two minutes.
0
Critical findings
2
High findings
5
Medium findings
7 of 7
Retested and closed
The numbers above are illustrative of the kind of summary table auditors expect, not results from a real client.
3. Scope and rules of engagement
This is the section auditors read most carefully, because it decides whether the test is relevant evidence. It lists:
- Every in-scope asset: application URLs, API base paths, mobile app versions, IP ranges, cloud accounts
- What was explicitly out of scope, and why
- Test accounts and roles used, for example a standard user, an admin and a user in a second tenant
- Testing approach: black box, grey box or white box, and whether testing was authenticated
- The environment: production, staging, or a production-like copy
- Rules of engagement: testing hours, rate limits, forbidden actions such as denial of service
The most common SOC 2 problem we see
The scope does not match the SOC 2 system description. If your system description includes the customer portal, the public API and the AWS production account, but the penetration test only covered the marketing website, the auditor has little to rely on. Agree the scope with your auditor’s system boundary in mind before testing starts.
4. Methodology
A short description of how testing was done and which public standards it followed. For web applications and APIs that usually means the OWASP Web Security Testing Guide and the OWASP API Security Top 10; for infrastructure, NIST SP 800-115 and PTES. It should say which parts were manual and which were automated. Auditors and customers are wary of reports that are scanner exports with a cover page, and this section is where you show the difference.
5. Detailed findings
The bulk of the report. Each finding should be self-contained, so that an engineer can fix it and an auditor can understand it without reading anything else:
- Title and ID
- A clear name, for example "Broken object level authorisation on /api/v1/invoices"
- Severity
- Critical, High, Medium, Low or Informational, with the scoring basis (often CVSS plus business context)
- Affected assets
- Exact URLs, endpoints, hosts or app versions
- Description
- What the weakness is, in plain language
- Evidence
- Requests, responses and screenshots that prove it, with sensitive data redacted
- Impact
- What an attacker could realistically achieve in your environment
- Remediation
- Specific fix guidance for your stack, not a generic paragraph
- References
- OWASP, CWE or vendor documentation
- Status
- Open, fixed and verified, or risk accepted
The evidence is what separates a professional report from a list of guesses. Every finding we report is reproduced and confirmed by a tester, which is why false positives rarely reach the auditor.
6. Risk summary and recommendations
A table of all findings by severity and status, plus a short section on themes. Themes are often more useful to leadership than individual bugs. “Authorisation checks are implemented per endpoint rather than centrally” tells your CTO what to change in the architecture; ten separate access-control findings do not.
7. Retest results
After your team fixes the findings, the testers verify each fix and record the result: fixed, partially fixed or not fixed, with the date and the evidence. Many firms issue this as a separate retest letter or an updated report version.
For SOC 2, this section is often as important as the findings themselves. It is direct evidence for the remediation side of CC4.2 and CC7.4: you found weaknesses, you fixed them, and someone independent confirmed it.
8. Trust Services Criteria mapping
Not every firm includes this, and it is not strictly required, but it saves your compliance team and your auditor time. A simple table maps the test and its findings to the criteria they support:
- CC4.1
- Independent penetration test performed in the period (this report)
- CC6.1, CC6.3
- Access control findings and fixes (for example authorisation and role checks)
- CC6.6, CC6.7
- External attack surface and data-in-transit findings (for example TLS and exposed services)
- CC7.1
- Vulnerabilities identified and rated
- CC4.2, CC7.4
- Findings communicated, remediated and retested (retest section)
What SOC 2 auditors actually check in your VAPT report
From the auditor’s side, the penetration test report answers a handful of questions. If your report answers them clearly, the testing evidence rarely causes friction.
- Was it independent? The test was performed by a party independent of the people who build and run the system, normally an external firm.
- Was the scope right? The tested assets match the system in your SOC 2 description, including the applications, APIs and cloud environment that handle customer data.
- Was it timely? For a Type 2 report, the test falls inside or close to the observation period, and was repeated after major changes.
- Were findings rated and tracked? Each finding has a severity, an owner and a status in your ticketing or risk system.
- Were serious findings fixed? Critical and high findings were remediated within your policy’s timelines and verified by retest, or formally risk-accepted with justification.
- Does it agree with your policies? Your vulnerability management policy says what you test, how often and how fast you fix. The report and tickets show you did what the policy says.
Open findings are not automatically a problem
A report with open medium and low findings does not fail a SOC 2 audit on its own. What matters is that they are tracked, owned and handled according to your policy. An untracked critical finding is a problem; a well-managed backlog of lows usually is not.
SOC 2 Type 1 vs Type 2: timing your penetration test
Type 1 reports on control design at a point in time. A penetration test completed shortly before the report date shows that the testing control exists and that findings are handled.
Type 2 reports on how controls operated over an observation period, typically three to twelve months. The test should fall within that period, and the remediation and retest should ideally be completed within it too, so the auditor sees the whole cycle. Many teams schedule testing early in the period to leave time for fixes.
If your application changes a lot, consider a second, targeted test after a major release, a new authentication system or a cloud migration. SOC 2 does not prescribe a frequency, so your vulnerability management policy should say what you do and why, and the evidence should match it.
What should be in scope for a SOC 2 penetration test?
Start from your SOC 2 system description and include everything that stores, processes or protects customer data:
Customer-facing web application
Authenticated testing with multiple roles and at least two tenants, so cross-tenant access is tested. See web application VAPT.
Public and partner APIs
Every documented endpoint, with attention to object-level and function-level authorisation. See API security testing.
Cloud environment
Configuration review of the production AWS, Azure or GCP accounts: IAM, storage, network exposure and logging.
External network
Internet-facing hosts, VPN gateways, admin interfaces and exposed services.
Mobile apps
If customers use them to access the service, include the iOS and Android apps and their APIs.
Internal admin tools
Support consoles often have the widest data access and the weakest testing.
Our web application VAPT, API security testing and cloud security assessment pages describe what each covers.
Red flags in a SOC 2 VAPT report
If you are reviewing a report from any provider, including us, these are signs it may not hold up with a sceptical auditor or customer:
- Hundreds of findings copied from a scanner, many of them informational, with no evidence of manual verification
- No mention of authenticated testing, so access control and business logic were never tested
- Scope written as “the application” without URLs, versions or environments
- Generic remediation text that does not mention your technology
- No dates, or a testing window that does not match the period being audited
- No retest, so there is no evidence that anything was fixed
- Severity ratings with no explanation, or every finding rated high to look thorough
How to prepare for a SOC 2 penetration test
A little preparation makes the test more useful and the report more valuable to your auditor:
- Share your SOC 2 system description and data-flow diagrams with the testing firm so the scope matches.
- Create test accounts for every relevant role, in at least two separate tenants or organisations.
- Agree the environment. Production-like staging is common; if you test production, agree rules of engagement for safety.
- Brief your hosting provider or WAF team if needed, and allowlist tester IP addresses if you want to test the application rather than the WAF.
- Name a technical contact who can answer questions quickly during testing.
- Plan engineering time for fixes before the retest, ideally within the same audit period.
Report, letter or certificate: what to share with whom
A full penetration test report contains sensitive detail: exploitable weaknesses, affected endpoints and sometimes screenshots of your data. You should not send it to every prospect who asks. Most companies use three artefacts:
Full report
For your engineers, your leadership and your SOC 2 auditor. Shared under the audit engagement, never posted publicly.
Executive summary
Scope, dates, methodology and findings by severity, without technical detail. Often shared with enterprise customers under NDA.
Attestation or retest letter
A short letter from the testing firm confirming the test took place, its scope and that critical and high findings were fixed. Easy to share during security reviews.
Agree up front which of these you need, so the testing firm produces them with the report rather than weeks later when a deal is waiting.
SOC 2 VAPT for SaaS companies in India
Indian SaaS companies selling to US and European enterprises are among the most frequent buyers of SOC 2 penetration tests. A few practical points come up in almost every engagement:
- Time zones help. Testing can run during Indian business hours on production-like environments while your customers are offline, which lowers operational risk.
- One test, several uses. The same report can support SOC 2, ISO 27001 and enterprise questionnaires if the scope covers all three, and it is evidence of reasonable security safeguards under India’s DPDP Act.
- CERT-In empanelment is usually not required for SOC 2. SOC 2 auditors care about independence, competence and scope. Empanelment matters when an Indian regulator or government contract requires it.
- Plan for the customer’s own review. Large customers sometimes ask follow-up questions about specific findings. Choose a provider whose testers can answer them.
How Summit delivers SOC 2 VAPT reports
Summit’s penetration tests are manual, led by experienced testers, and written so that both your engineers and your auditor can use them. Every engagement includes a scoping call against your SOC 2 system boundary, authenticated multi-role testing, verified findings with evidence, a criteria mapping and a retest of fixed findings.
Need a SOC 2 penetration test?
Tell us about your SOC 2 timeline and system, and we will send a fixed scope and quote. See a sample VAPT report, read the SOC 2 framework guide, or get a quote.
Frequently asked questions
Is a VAPT report mandatory for SOC 2?
The Trust Services Criteria do not name penetration testing as a mandatory control. In practice most auditors and nearly every enterprise customer reviewing a SOC 2 report expect independent penetration testing as evidence for monitoring and vulnerability management controls, so most SaaS companies treat it as required.
What should a SOC 2 VAPT report include?
An executive summary, the scope with dates and exclusions, the testing methodology, each finding with severity, evidence and remediation advice, a summary of risk, and a retest section or letter showing which findings were fixed and verified. Mapping findings to the relevant Trust Services Criteria makes the auditor's job easier.
How often should a SOC 2 penetration test be done?
SOC 2 does not set a frequency. Most organisations test at least once a year, and again after significant changes to the application, infrastructure or identity setup. For a Type 2 report, the test should fall inside or close to the observation period.
Can a vulnerability scan replace a SOC 2 penetration test?
Usually not. Automated scans are good evidence for ongoing vulnerability management, but auditors and customers generally expect a manual penetration test that covers business logic and access control, which scanners cannot assess.
Does the auditor need to see every finding?
The auditor needs enough to judge whether your controls work: the scope, the findings, how you rated and treated them, and evidence that serious ones were fixed. Open findings are not automatically a problem if they are tracked with an owner and a remediation plan.
