Key Findings (2026 from Cybersecify SOC 2 pentest engagements):
- SOC 2 auditors typically accept pentests covering CC6.1 (logical and physical access controls) and CC7.1 (vulnerability detection) when methodology and findings include explicit per-control mapping.
- Scanner-only reports (Nessus PDF, Burp baseline) are rejected by most US-based SOC 2 auditors as evidence; manual pentest is the expectation.
- Cybersecify Growth Pentest reports include explicit SOC 2 Trust Services Criteria mapping per finding, which the auditor uses directly as evidence.
- Schedule the pentest 8 to 10 weeks before the audit window so there is time to remediate findings within the same evidence period.
SOC 2 does not explicitly mandate a penetration test, but most auditors expect one as evidence for CC7.1 (vulnerability detection) and CC7.2 (anomaly monitoring). Vulnerability scans alone are usually rejected. Your pentest report needs scope definition, methodology reference (OWASP WSTG, PTES), tester qualifications, findings with CVSS severity ratings, remediation status, and proof that critical and high findings were fixed. The report should fall within your audit observation period (typically 12 months for Type 2). Schedule the pentest at least 8 to 10 weeks before the audit so you have time to remediate findings.
Cybersecify is a founder-led penetration testing and security consulting firm based in Bengaluru, India, serving AI-first and API-first SaaS startups. SOC 2 pentest scoping is one of our most-asked engagement types: our Growth Pentest plan includes explicit SOC 2 Trust Service Criteria mapping per finding, executive summary formatted for auditor review, and a free retest to verify remediation before the audit deadline. For an example of the pentest deliverable that documents this format, see our SOC 2 + ISO 27001 ready pentest report sample.
Your SOC 2 Type 2 observation window ends in 10 weeks. Your auditor sends a preliminary evidence request. Line 14: “Most recent penetration test report.”
You do not have one. Or you have a vulnerability scan from 8 months ago that your DevOps engineer ran. You are not sure if that counts.
It probably does not. Here is what your auditor actually expects, how to get a pentest that satisfies the requirement the first time, and the mistakes that cause startups to scramble at audit time.
Does SOC 2 Require a Penetration Test?
Technically, no. The SOC 2 Trust Service Criteria do not contain a line that says “conduct a penetration test.” But in practice, most auditors treat it as expected evidence for two criteria:
- CC7.1: The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities and susceptibilities to newly discovered vulnerabilities.
- CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives.
A penetration test is the most direct way to demonstrate that you are proactively identifying vulnerabilities in your systems. Without one, your auditor will ask how you know your controls work. “We do code reviews” is not a sufficient answer.
Some auditors are flexible about this. Most are not. If you are going through your first SOC 2 audit, assume you need a pentest report.
What Auditors Look For in the Report
Your auditor is not reading every finding in detail. They are checking whether the report demonstrates that security testing was done properly and that you acted on the results. Here is what they evaluate:
Scope
The pentest must cover the systems included in your SOC 2 scope. If your SOC 2 covers your SaaS platform and customer-facing API, the pentest needs to test those specifically, not your marketing website or an internal tool that is out of scope.
Common mistake: getting a pentest on one application when your SOC 2 scope includes three. Your auditor will flag the gap.
Methodology
The report should reference a recognized testing framework. OWASP WSTG v5.0 for web applications and PTES for broader engagements are the standards auditors expect. A report that says “we tested the application for vulnerabilities” without explaining the methodology looks like a scanner run.
Tester Qualifications
Auditors want to see that the testing was done by someone qualified. This means certifications (OSCP, CREST, CompTIA PenTest+) and evidence that the tester has relevant experience. A report from an unknown company with no credentials listed will get questioned.
Findings and Severity
Every finding should have a clear severity rating (Critical, High, Medium, Low). Auditors care most about Critical and High findings. They want to see:
- What was found
- What the business impact is
- What the severity rating is and how it was determined
They do not need to understand every technical detail. They need to see that vulnerabilities were identified, categorized, and communicated clearly.
Remediation Evidence
This is where most startups fail. Finding vulnerabilities is half the job. Your auditor wants to see that you fixed them.
For Critical and High findings, you need evidence of remediation: a retest confirming the fix, a code commit addressing the issue, or a documented risk acceptance with justification.
If your pentest report has 3 Critical findings and no evidence that any were addressed, your auditor will flag it as a control deficiency. That is worse than not having a pentest at all.
Control Mapping
This is not required but significantly reduces back-and-forth with your auditor. If the pentest report maps findings to SOC 2 Trust Service Criteria (CC6.1 for logical access, CC6.6 for protection against external threats, CC7.1 for vulnerability detection, CC7.2 for anomaly monitoring, CC8.1 for change management), your auditor can cross-reference directly instead of interpreting technical findings.
Vulnerability Scan vs Penetration Test: What Auditors Accept
| Vulnerability Scan | Penetration Test | |
|---|---|---|
| What it is | Automated tool checks for known issues | Human-led assessment simulating real attacks |
| What it finds | Outdated libraries, missing headers, weak configs | Business logic flaws, access control bypasses, chained exploits |
| Accepted by most SOC 2 auditors | As supplementary evidence only | Yes, as primary evidence |
| Tester required | No, any engineer can run it | Yes, certified professional expected |
| Report quality | Tool-generated, generic remediation | Custom findings with specific reproduction steps |
Some auditors accept vulnerability scans for Type 1 (point-in-time). Almost none accept them as the sole evidence for Type 2 (observation period). If you are doing Type 2, get a manual pentest.
For a deeper comparison, read manual penetration testing vs automated scanning.
Timing: When to Schedule the Pentest
The most common mistake is scheduling the pentest too late. Here is the timeline that works:
8-10 weeks before your audit window closes: Schedule and complete the pentest. This gives you time to receive the report, remediate findings, and get a retest done before the auditor reviews evidence.
4-6 weeks before audit: Remediate Critical and High findings. Get retest confirmation.
2 weeks before audit: Compile evidence package: original report, remediation evidence, retest results. Hand it to your auditor as a single package.
What happens if you schedule it 2 weeks before the audit: You get the report, find 4 High-severity findings, and have no time to fix them before the auditor reviews. Now you have documented evidence of unfixed vulnerabilities sitting in your SOC 2 audit file. Your auditor flags it as a control deficiency.
Plan ahead. A pentest is not a checkbox you tick at the last minute.
5 SOC 2 Pentest Anti-Patterns We See Founders Fall Into
These five mistakes show up repeatedly when startups scramble at audit time. Recognizing them saves a control deficiency in the SOC 2 report.
Anti-pattern 1: Scheduling the pentest 2 weeks before the audit. Pentest finds 4 High-severity findings. No time to remediate. The original report goes into the audit file with documented unfixed vulnerabilities. The auditor flags it as a control deficiency, which lands in the final SOC 2 report visible to your customers. Fix: schedule the pentest 8 to 10 weeks before the audit window closes. That gives 4 weeks for remediation + retest + evidence packaging.
Anti-pattern 2: Submitting a Nessus or Burp baseline scan as your SOC 2 pentest evidence. The auditor opens the report, sees it is a scanner export with no manual testing, and rejects it. You re-pay for a real pentest under deadline pressure. Total cost: the scanner license plus the real pentest plus 4 weeks of stress. Fix: before signing with any pentest vendor, ask for a redacted sample report. If it does not include reproduction steps, business impact framing, and remediation guidance, walk away. Scanner output is supplementary evidence at best, never primary.
Anti-pattern 3: Pentesting only the customer-facing web app and skipping the API. SaaS SOC 2 scope almost always includes the API. The auditor asks “what about your API surface” mid-audit, the pentest report says “web app only”, and you have a scope gap. Fix: before scoping the pentest, email your auditor: “Here is what we plan to test. Anything else you expect covered?” Costs nothing. Saves a scope gap.
Anti-pattern 4: Not getting a retest done within the audit window. The pentest finds 8 findings. Engineering fixes 6. The report still shows all 8 as open because no retest verified the fixes. The auditor counts 6 of them as “remediation not verified by independent third party” and either asks for a paid retest (often 30 to 50 percent of original engagement cost) or accepts only the 2 verified findings as closed. Fix: pick a pentest vendor whose engagement includes the retest in the base price. Cybersecify includes 1 full retest within 30 days in both Startup and Growth plans at no extra charge.
Anti-pattern 5: Skipping Trust Service Criteria mapping in the report. Auditor receives a generic pentest report with findings but no SOC 2 control mapping. Auditor has to manually map every finding to TSC themselves, which adds audit cost and increases the chance of a missed control. The auditor may go back to you asking for clarification, which extends the audit timeline. Fix: ask the pentest vendor to map every finding to specific Trust Service Criteria (CC6.x, CC7.x, CC8.x) directly in the report. Cybersecify Growth Pentest includes per-finding TSC mapping in the standard deliverable.
Scope It Right the First Time
Before engaging a pentest company, align the scope with your SOC 2 boundary:
- List every system in your SOC 2 scope. Your SaaS platform, APIs, customer-facing portals, admin panels, mobile apps if applicable.
- Identify which systems handle customer data. These are the highest priority for testing.
- Check with your auditor. Ask them what they expect covered before you scope the pentest, not after. A 5-minute email saves you from discovering a scope gap during the audit.
- Include your cloud infrastructure if it is in scope. IAM misconfigurations and storage bucket permissions are common findings that auditors care about.
If your SOC 2 scope covers a web application and an API, you need both tested. A single-scope pentest covering only the web application leaves a gap your auditor will find.
What a SOC 2-Ready Pentest Report Looks Like
A report your auditor will accept without follow-up questions includes:
- Scope definition: What was tested, what was excluded, and why
- Methodology: OWASP WSTG, PTES, or equivalent framework referenced
- Tester credentials: Names, certifications, and company
- Executive summary: High-level findings for leadership and auditors
- Detailed findings: Each finding with severity, reproduction steps, business impact, and recommended fix
- SOC 2 control mapping: Findings mapped to relevant Trust Service Criteria
- Remediation status: Which findings are fixed, which are in progress, which are accepted risks
- Retest results: Confirmation that remediated findings are verified closed
See a sample report that includes this format.
How We Handle SOC 2 Pentests
Our Growth Pentest plan (INR 1,79,999) is built for startups going through SOC 2 or ISO 27001 audits. It includes:
- 2 scopes (web app + API, or web app + mobile) tested over 10 calendar days
- SOC 2 + ISO 27001 compliance control mapping in the report
- Executive summary formatted for auditor review
- Free retest to verify remediation before your audit
If you only need one scope tested, the Startup Pentest plan (INR 74,999) covers a single application in 7 days with a detailed report and free retest. Note: SOC 2 control mapping is included with the Growth plan only.
Both plans are founder-led. Rathnakara (OSCP, CompTIA PenTest+, M.Sc Cyber Security) leads all testing. Reports are delivered in a format your auditor can use directly as evidence.
Timing tip: If your SOC 2 audit is in 3 months, now is the right time to schedule the pentest.
View pricing | See a sample report | Read our SOC 2 readiness guide | Audit & compliance services | Web application pentest | Book a 30-min SOC 2 pentest scoping call
Frequently Asked Questions
Is a penetration test required for SOC 2?
SOC 2 does not explicitly mandate a penetration test, but most auditors expect one as evidence for CC7.1 (vulnerability detection) and CC7.2 (anomaly monitoring). If you show up without a pentest report, your auditor will likely flag it as a gap. For SOC 2 Type 2 specifically, the pentest must fall within the observation period (typically 12 months).
Can I use an automated vulnerability scan instead of a pentest for SOC 2?
Most auditors will not accept a vulnerability scan alone. Scanners miss business logic flaws, access control issues, IDOR vulnerabilities in financial flows, and chained exploits. Auditors want evidence of manual testing by a qualified professional (OSCP, CREST, or equivalent), not a tool-generated PDF. Some Type 1 auditors are flexible on this; almost none are for Type 2.
How recent does the pentest report need to be for SOC 2?
Your pentest report should be from within the audit observation period, typically the last 12 months. For Type 2 audits, the pentest should fall within the observation window. Schedule your pentest at least 8 to 10 weeks before the audit so you have time to remediate findings, get a retest done, and document everything within the same evidence period.
What should a SOC 2 pentest report include?
Your auditor expects: scope definition, testing methodology reference (OWASP WSTG, PTES), tester qualifications, findings with CVSS severity ratings, reproduction steps, business impact framing, remediation status, retest verification, and evidence that critical and high findings were fixed. Compliance control mapping to SOC 2 Trust Service Criteria per finding is a strong signal of auditor-ready preparation.
How much does a SOC 2 pentest cost?
Pentest pricing for SOC 2 splits into three tiers in 2026. Budget tier (USD 1,500 to 3,000 / INR 50,000 to 1 lakh) is usually scanner output rebranded and often rejected by SOC 2 auditors. Professional tier (USD 3,000 to 10,000 / INR 1 lakh to 3 lakh) is methodology-driven manual testing accepted by most US-based SOC 2 auditors. Enterprise tier (USD 10,000+ / INR 3 lakh+) is multi-week multi-scope. Cybersecify Growth Pentest at INR 1,79,999 (USD ~2,150) includes explicit SOC 2 control mapping per finding.
How long does a SOC 2 pentest take?
A single-scope SOC 2 pentest (web app OR API) typically takes 7 to 10 calendar days for testing plus 2 to 3 days for report writing. Multi-scope engagements (web app + API + cloud, common for SaaS) run 10 to 15 calendar days. Add 2 to 4 weeks for remediation cycle and retest. Total elapsed time from kickoff to auditor-ready evidence package: 6 to 8 weeks.
What SOC 2 Trust Service Criteria does a pentest cover?
A pentest provides direct evidence for CC7.1 (vulnerability detection) and CC7.2 (anomaly monitoring). It can also support CC6.1 (logical and physical access controls) when authentication and authorization testing are in scope, CC6.6 (logical access for users) for IDOR and role-based access findings, and CC8.1 (change management) when retest verification is included. Map findings to specific TSC in the report so the auditor uses it directly as evidence.
Does the pentest need to be Type 1 vs Type 2 specific?
The methodology is identical for Type 1 and Type 2 SOC 2 audits. The difference is timing and observation period. For Type 1 (point-in-time), the pentest needs to be recent (within the last 6 to 12 months). For Type 2 (observation period, typically 12 months), the pentest must fall within the observation window. If you are doing a Type 2 audit with a January to December observation period, your pentest must happen between January and December of that year.
Can my dev team do an internal pentest instead?
No, almost all SOC 2 auditors require an independent third-party pentest. Internal testing by your own engineering team does not satisfy the independence requirement of CC7.1. The exception is supplementary internal testing (e.g., continuous DAST scanning) which can be evidence alongside an annual third-party pentest, but never as a replacement.
What is included in the Cybersecify SOC 2 pentest engagement?
Growth Pentest at INR 1,79,999 plus taxes includes 2 scopes (typically web app plus API, or web app plus mobile) tested over 10 calendar days. PTES plus OWASP WSTG v5.0 methodology. Technical and executive reports with SOC 2 Trust Service Criteria mapping per finding. CVSS risk ratings with reproduction steps and remediation guidance. 1 full retest within 30 days to verify Critical and High fixes before the auditor reviews. Letter of Attestation from the lead pentester (OSCP). Founder led by both co-founders.
What happens if findings are still open at audit time?
Open Critical or High findings at audit time become a control deficiency the auditor must report. The fix is to either (a) close them before evidence submission via retest, (b) document a formal risk acceptance signed by management for findings you cannot fix within the window, or (c) demonstrate a documented remediation plan with a target date for the auditor to monitor. Best case is to close everything Critical and High before the auditor sees the evidence package.
Related: Vanta vs Drata vs Secureframe vs Sprinto 2026, SOC 2 Readiness for Indian Startups, comparing ISO 27001 and SOC 2 for startups, SOC 2 + ISO 27001 ready pentest report sample.