SOC 2 auditors check four things in a pentest report: scope coverage of in-scope systems for the audit, Trust Services Criteria mapping per finding (CC6, CC7, CC8, CC9 most commonly), remediation evidence for Critical and High findings within 30 to 60 days, and vendor independence with documented credentials. Reports missing any of these typically result in audit qualifications or require re-work before the audit can close. The pentest engagement itself is the same for SOC 2 Type 1 and Type 2; the difference is in evidence collection and retest cadence over the observation period.
You are six weeks from your SOC 2 audit date. Your CPA firm asks for evidence of independent security testing. You hand them your most recent pentest report. The auditor reviews it for forty minutes and comes back with a list: where is the Trust Services Criteria mapping, why are these Critical findings still open, who was the lead tester, did you retest after remediation.
These are not random questions. They are the four checks every SOC 2 auditor runs on every pentest report. The good news is that they are knowable in advance. The bad news is that most pentest reports in the market do not address them, and founders learn this only when the audit hits.
At Cybersecify, our Growth Pentest plan (INR 1,79,999) is built specifically to satisfy these audit checks on first read. The report includes Trust Services Criteria mapping per finding, named methodology (PTES + OWASP WSTG v5.0), reproduction steps, business impact in plain language, one free retest within 30 days so remediation is verified, and a Letter of Attestation that auditors recognise. Reports have been accepted by SOC 2 Type 1, SOC 2 Type 2, and ISO 27001 auditors. We are India-anchored and serve AI-first and API-first SaaS startups globally.
This article is the auditor’s view of what a pentest report needs to contain. If you are heading into a SOC 2 audit in the next 6 months, this is what you should ensure your existing or upcoming pentest delivers.
Key Findings
- Four checks SOC 2 auditors run on every pentest report: scope coverage of in-scope systems, Trust Services Criteria mapping per finding, Critical/High remediation evidence within 30 to 60 days, named vendor credentials and methodology.
- SOC 2 Type 1 and Type 2 use the same pentest engagement. Difference is evidence collection cadence and retest verification over the Type 2 observation period.
- CC6, CC7, CC8, CC9 are the most commonly mapped Trust Services Criteria for pentest findings. Reports without this mapping require the auditor to do the mapping work, which slows the audit.
- Open Critical or High findings without compensating controls typically result in audit qualifications. Run the pentest with enough lead time for remediation and retest before the audit date.
- DAST scans alone do not satisfy SOC 2 pentest requirements. Auditors distinguish between scanning (CC7 ongoing) and pentest (independent third-party). Both are needed.
What SOC 2 Auditors Actually Check
A SOC 2 auditor is testing whether your security program operates as described in your System Description. The pentest report is one piece of evidence among many (vulnerability scans, access reviews, change management logs, incident response artifacts). The pentest specifically provides evidence that an independent third party tested your security controls and found what they found.
Here is what the auditor reads for.
Check 1: Did the scope cover in-scope systems for the audit?
Your SOC 2 audit has a defined scope: the systems, applications, and infrastructure that process customer data or affect the Trust Services Criteria you committed to (Security is mandatory, Availability, Confidentiality, Processing Integrity, and Privacy are optional). The pentest must cover those in-scope systems.
What auditors flag: pentests of marketing websites when the in-scope system is the SaaS application, pentests of a staging environment when production is in scope, pentests of a feature subset when the audit covers the whole product. The scope section of the report should explicitly list what was tested and confirm alignment with the audit boundary.
If your pentest scope is smaller than your audit scope, the auditor will ask you to either expand the pentest or document compensating evidence for the uncovered systems. This is fixable but adds time.
Check 2: Are findings mapped to Trust Services Criteria?
Your SOC 2 audit evaluates controls against specific criteria. The pentest report should identify which criteria each finding relates to. This is the mapping work that distinguishes audit-ready reports from generic pentest output.
Most commonly mapped:
- CC6 Logical and Physical Access Controls. Authentication bypasses, authorisation flaws, IDOR, broken access control, session management issues, multi-tenancy boundary violations.
- CC7 System Operations. Unpatched libraries (vulnerability management), missing security monitoring, exposed administrative endpoints, weak server configurations.
- CC8 Change Management. Exposed development endpoints in production, configuration drift between environments, missing security review of changes.
- CC9 Risk Mitigation. Identified vulnerabilities and their treatment, risk acceptance documentation, compensating controls.
Reports without this mapping force the auditor to do the mapping work or accept ambiguity. Some auditors will do the mapping; others will return the report and ask the company to get it mapped. Either way, the audit slows down. Reports that ship the mapping included accelerate the audit.
Check 3: What is the remediation evidence?
The auditor is testing whether your security program closes findings, not just identifies them. For each Critical and High severity finding, the auditor wants to see:
- Status: Open, In Progress, Remediated, or Risk-Accepted
- If Remediated: evidence that a retest verified the fix
- If Risk-Accepted: documented justification and compensating controls
- If In Progress or Open: documented remediation timeline and progress tracking
The expected remediation window is 30 to 60 days for Critical and High. Medium findings should have a documented timeline (typically 60 to 90 days). Low and informational can stay open indefinitely with risk acceptance documentation.
The most common audit qualification reason in this category is “Critical or High pentest findings remained open at the audit date without compensating controls or risk acceptance documentation.” This is preventable by running the pentest with enough lead time for the remediation and retest cycle to complete before the audit.
Check 4: Are the vendor credentials and methodology documented?
The auditor needs to confirm the pentest was performed by an independent third party with appropriate qualifications. The report should include:
- Lead tester name and certifications (OSCP, CREST, CompTIA PenTest+) with certification numbers
- Vendor company name and any relevant credentials (CERT-In empanelment is one specific credential but is not required for most SaaS scope)
- Named methodology (PTES, OWASP WSTG v5.0, NIST SP 800-115)
- Description of methodology phases executed (reconnaissance, threat modeling, vulnerability identification, exploitation attempts, post-exploitation, reporting)
- Tools used (Burp Suite, Nuclei, custom scripts) without overstating their role
What auditors flag: phrases like “our certified team” without naming the lead tester or their credentials, methodology references without a specific named standard, reports that look like reformatted DAST scanner output without business logic findings or chained exploits.
SOC 2 Type 1 vs Type 2: What Changes for the Pentest
The pentest engagement itself does not change between Type 1 and Type 2. What changes is the evidence demands and retest cadence.
SOC 2 Type 1 is point-in-time. The auditor verifies that controls existed and operated as described at a specific date. A single pentest report from within the prior 12 months, with remediation evidence on Critical and High findings, is typically sufficient evidence of independent security testing at that date.
SOC 2 Type 2 tests whether controls operated over a period (typically 6 to 12 months). The auditor wants evidence that security testing happened during the observation period, not just at a single point. That usually means:
- Annual pentest minimum, scheduled within the observation period
- Continuous monitoring tools running through the observation period (DAST scanning, dependency scanning, infrastructure scanning)
- Retest verification on Critical and High findings during the period
- Documentation of any vulnerabilities discovered and remediated through monitoring tools during the period
For Type 2, the retest section of the pentest report becomes more important. The auditor specifically tests whether findings identified during the observation period were actually remediated during the period, not just by the audit date.
How Cybersecify Maps Findings to Trust Services Criteria
The Growth Pentest plan (INR 1,79,999) includes Trust Services Criteria mapping per finding. The mapping appears in two places in the report.
Per-finding metadata: Each finding identifies the specific CC sub-criterion. Example: a finding “Authentication bypass via JWT signature verification skip” maps to CC6.1 (Logical Access Controls) because it allows access without authentication. A finding “Outdated express library with known RCE CVE” maps to CC7.1 (Vulnerability Management) because it represents a known vulnerability not patched. A finding “Production endpoint exposes development debug data” maps to CC8.1 (Change Management) because it indicates a development artifact reached production.
Trust Services Criteria coverage matrix: A summary table in the report appendix shows which CC criteria the engagement covered and which it did not. This helps the auditor quickly identify gaps. If the pentest did not test physical access controls (because the SaaS is fully cloud-hosted with no on-premise infrastructure), the matrix says so. If the pentest tested logical access controls thoroughly, the matrix shows the coverage.
The Startup Pentest plan (INR 74,999) does not include the explicit Trust Services Criteria mapping in the report. The report itself is still acceptable for most SOC 2 Type 1 evidence purposes; the mapping can be done by the auditor or by the company internally. For Type 2 audits or for engagements where audit speed matters, the Growth plan’s included mapping is the right fit.
Common Findings That Cause SOC 2 Audit Qualifications
These are the categories of pentest findings that, if left unremediated at the audit date, most commonly result in audit qualifications or exception findings.
| Finding category | Trust Services Criteria | Why auditors flag it |
|---|---|---|
| Broken authentication (JWT, session, password reset flows) | CC6.1, CC6.2 | Allows unauthorised access; undermines all access control claims |
| Broken access control (IDOR, multi-tenant boundary violations) | CC6.3, CC6.6 | Customer data exposed across tenants; breaches confidentiality criterion |
| Unpatched critical libraries with known CVEs | CC7.1, CC7.2 | Demonstrates vulnerability management process not operating |
| Sensitive data exposure (API keys, secrets in client bundles, debug data in production) | CC6.7, CC8.1 | Indicates change management failure and information protection gap |
| Missing or broken audit logging | CC4.1, CC7.3 | Undermines monitoring criterion; security incidents may not be detected |
Reports that show these findings as remediated with verified retest evidence by the audit date have no qualification impact. Reports that show them open at the audit date typically require either remediation before the audit closes or an audit qualification noting the exception.
What to Do Next
If your SOC 2 audit is within 6 months and your pentest is older than 9 months, or your existing pentest report does not include Trust Services Criteria mapping, or Critical and High findings are still showing open, address those gaps now. Cybersecify Growth Pentest is sized for SOC 2 audit prep: two scopes, 10 calendar days, audit-acceptable report with TSC mapping per finding, free retest within 30 days, Letter of Attestation included.
For the cost breakdown, see pentest cost in India 2026. For the report structure auditors expect, see our sample report and how to read a VAPT report. For the empanelment question (CERT-In empanellment is generally not required for SaaS SOC 2 audits), see when you do not need a CERT-In empanelled vendor.
Book a discovery call to scope your SOC 2 audit pentest. We will walk through your audit timeline, in-scope systems, and TSC commitments before quoting.
The audit will read your pentest report on its own. Your job is to make sure it answers all four checks on the first read. That is what we ship.