Visit Website →
← Back to blog

Audit Ready SOC 2 Penetration Testing: Map Findings to Controls

September 14, 2026
Audit Ready SOC 2 Penetration Testing: Map Findings to Controls

SOC 2 does not explicitly require a penetration test. Auditors commonly expect one anyway, especially for Type II reports covering security-heavy Trust Services Criteria. If you're preparing for an audit, schedule testing early enough in your observation period to leave room for remediation and a documented retest, then build your evidence package around that timeline instead of treating the pentest as a last-minute checkbox.

TL;DR:

  • Penetration tests are not explicitly required by SOC 2 but are strongly recommended by auditors to demonstrate control effectiveness, especially for Type II reports.
  • Findings must be clearly mapped to specific controls, such as access restrictions or detection, to streamline audit review and avoid delays.
  • Scope should mirror the system description precisely, including all APIs and cloud configurations, with explicit exclusions documented to prevent misunderstandings.
  • Testing must occur within the observation period for Type II reports, ideally 8 to 12 weeks before the audit ends, to allow for remediation and retesting.
  • Evidence should include a detailed report, signed scope, tester credentials, testing methodology, findings with severity, remediation actions, and retest proof, stored in a centralized GRC system.
Earthshakersecurity
earthshakersecurity.com
Make Vulnerabilities Easier to Act On
Earthshaker Security combines automated testing with human verification, then explains findings and actionable fixes in clear reports.
Explore security testing

Table of Contents

Does SOC 2 Require Penetration Testing? Framework vs. Practice

Nowhere in the AICPA Trust Services Criteria does the phrase "penetration test" appear as a line-item requirement. That surprises a lot of first-time compliance leads who assume SOC 2 works like PCI DSS, which spells out testing frequency in black and white.

SOC 2 works differently. The Security criterion is mandatory for every report, but the individual criteria underneath it describe outcomes, not procedures. CC4.1 asks you to monitor and evaluate the effectiveness of controls. CC7.1 asks you to detect and respond to security events, including vulnerabilities. CC7.2 asks you to monitor systems for anomalies and security incidents. None of these say "hire a pentester." All of them describe an outcome that a penetration test happens to be one of the most direct ways to demonstrate.

That gap between what the framework states and what auditors actually accept is the whole story. An auditor reviewing your CC7.1 evidence can accept a written policy claiming you "regularly assess vulnerabilities," or they can look at a dated report showing a tester found and reproduced a specific flaw, your team fixed it, and a retest confirmed the fix held. One of those is an assertion. The other is proof.

Most auditors, especially for Type II engagements, push for the second kind. Practitioner guidance on SOC 2 penetration testing requirements consistently notes that while the standard stays silent on pentesting by name, its absence from an audit package raises immediate questions about how CC4.1 and CC7.x are actually operating in practice.

How Penetration Testing Maps to Specific Trust Services Criteria

Auditors don't grade a pentest report on its own merits. They grade it on how cleanly it ties back to a specific control. That mapping exercise is where most compliance teams either save themselves hours of back-and-forth or create a mess that drags an audit out by weeks.

Start with the most direct connections. A finding of broken access control, say, a user able to view another tenant's data by manipulating an object ID, maps straight to CC6.1, which governs logical access restrictions. An unauthenticated API endpoint that returns internal configuration data maps to both CC6.1 and CC6.6, since it touches both access control and protection against external threats. A missing rate limit that allows credential stuffing maps to CC6.8, covering prevention of unauthorized software and malicious code execution.

Findings around detection and response map elsewhere entirely. If your tester demonstrates that a simulated intrusion went unnoticed for hours because logging wasn't capturing the right events, that's a CC7.2 finding, not a CC6.x one. The distinction matters because CC7.2 is about monitoring and detection, while CC6.x is about the access controls themselves. Auditors who see findings correctly split across these categories move faster because they're not doing the mapping work themselves.

Common categories worth knowing:

  • Injection and input validation flaws (SQL injection, command injection) typically support CC6.1 and CC6.6.
  • Session management issues (predictable tokens, missing expiration) support CC6.1 and sometimes CC6.7 for data transmission controls.
  • Misconfigured cloud storage or overly permissive IAM roles support CC6.1 and CC6.3, which covers role-based access provisioning.
  • Insufficient logging or alerting gaps discovered during testing support CC7.1 and CC7.2.

A report that labels each finding with its corresponding TSC reference, rather than leaving that translation to the auditor, is the single fastest way to shrink review time on a SOC 2 engagement.

What Should Your SOC 2 Pentest Scope Actually Cover?

Scope creep, or worse, scope gaps, is one of the most common reasons a pentest fails to satisfy an auditor even when the testing itself was competent. The fix is straightforward: your scope has to mirror your system description, not your marketing team's idea of what counts as "the product."

Before you sign a statement of work, pull your SOC 2 system description and cross-reference it line by line against the proposed test scope. If your system description references a customer-facing API, that API needs to be in scope. If it references a specific cloud environment, that environment's configuration needs review too, not just the application running inside it.

A working scoping checklist looks like this:

  • Production web applications and any customer-facing portals referenced in the system description.
  • APIs and endpoints, including internal services that handle authenticated customer data, tested against guidance like OWASP API Security.
  • External network perimeter: exposed ports, VPN gateways, and any internet-facing infrastructure.
  • Cloud configuration review covering IAM policies and role assignments, storage bucket permissions, security group rules, encryption at rest and in transit, and centralized logging coverage.
  • Authentication and session management across every user role described in the system boundary.
  • Any third-party integrations that touch in-scope customer data.

Document what's excluded just as carefully as what's included. If your marketing site sits on a separate, unauthenticated infrastructure with no connection to customer data, note that exclusion explicitly in the SOW rather than letting an auditor wonder why it's absent. Auditors are far more comfortable with a documented, reasoned exclusion than with an unexplained gap. A scope approval sign-off from both your security lead and your auditor before testing starts saves you from redoing work after the fact.

When Should You Run a Pentest Relative to Your SOC 2 Audit Window?

Timing trips up more organizations than scope does. A Type I report is a snapshot: it evaluates whether your controls are designed appropriately as of a single date. A Type II report evaluates whether those controls operated effectively across an observation period, typically three to twelve months. That distinction changes everything about when your test needs to happen.

For a Type I report, testing any time before the as-of date generally works, since there's no operating window to prove. For Type II, the pentest and its remediation evidence need to fall inside the observation period itself. A test run one month before your audit fieldwork wraps up gives you no time to fix findings and prove the fix worked, which leaves your evidence package incomplete right when the auditor needs it most.

Practical scheduling guidance from SOC 2 audit preparation resources recommends running the pentest 8 to 12 weeks before audit fieldwork concludes. That window gives you roughly two to four weeks for testing itself, a few weeks for remediation on anything critical or high severity, and time left over for a retest that confirms the fix actually closed the gap, all before the observation period ends.

Beyond the audit calendar, most organizations settle into annual testing as a baseline cadence, with an additional test triggered by any material change: a new production environment, a significant architecture change, or an acquisition that brings new infrastructure into scope. Waiting a full year after a major platform rewrite to test it again is a gap an auditor will notice.

When Should You Run a Pentest Relative to Your SOC 2 Audit Window? — overview diagram

Penetration Testing vs. Vulnerability Scanning: What Auditors Actually Accept

These two terms get used interchangeably by people who haven't had to defend the difference to an auditor, and that confusion causes real audit delays. A vulnerability scan is automated. It checks systems against a database of known signatures and misconfigurations and flags matches. A penetration test uses that scan as one input among several, then adds manual exploitation, chaining findings together, and testing business logic that no scanner understands.

NIST's definition of penetration testing draws this line clearly: it's a security testing methodology that uses adversarial techniques to actively exploit weaknesses, not just enumerate them. That distinction is exactly what auditors are checking for when they review a report.

A scanner will flag an outdated library version. It won't tell you that an attacker can chain a broken access control issue with a predictable session token to fully take over another customer's account. Practitioner guidance on SOC 2 evidence warns that scanner-only PDFs, often submitted as pentest evidence by teams trying to cut corners, tend to get rejected outright for Type II reports because they don't demonstrate manual verification or business-logic testing.

Methodologies auditors look for referenced in a report include:

  • NIST SP 800-115, the technical guide most commonly cited for structured testing methodology.
  • OWASP WSTG (Web Security Testing Guide) for web application coverage.
  • PTES (Penetration Testing Execution Standard) for overall engagement structure.
  • OWASP API-Security guidance specifically when APIs are in scope.

Scans still have a place. Running automated scans continuously between annual pentests, and citing that cadence in your evidence, supports CC7.1's monitoring requirement well. Just don't submit scan output as a substitute for the manual test itself.

What Auditors Look for in a Pentest Report and Evidence Package

A report that reads like a fifty-page dump of raw scanner findings tells an auditor nothing about how the test was actually conducted. What they want is a package that answers five questions in order: who tested, what was tested, how, when, and what happened after.

  1. Statement of work and rules of engagement. This should define scope boundaries, testing windows, and any restrictions (no denial-of-service testing, for example), signed off before testing began.
  2. Tester qualifications and independence. Credentials such as OSCP or CREST, or accreditation from a recognized testing body, along with confirmation the tester wasn't also responsible for building the system under test.
  3. Methodology reference. A named standard (NIST SP 800-115, OWASP WSTG, or PTES) rather than a vague claim of "industry best practices."
  4. Testing dates falling inside the observation period, stated explicitly rather than implied by the report's publish date.
  5. A findings register with severity ratings (often mapped to CVE or CVSS scoring via the NVD), reproduction steps, and business impact written in plain language.
  6. Remediation tickets linked to each finding, showing assignment, status, and closure date.
  7. Retest evidence confirming the fix actually worked, not just that a ticket was closed.
  8. TSC mapping for each finding, tying it back to the specific control it supports.

Synack's guidance on what auditors expect from SOC 2 pentest evidence echoes this same structure. Store this package in whatever GRC platform you already use for audit evidence collection, cross-referenced by control ID, so an auditor pulling evidence for CC7.1 finds the relevant pentest section without hunting through an unrelated appendix.

Remediation and Retesting: Making Fixes Count as Evidence

A finding without a documented fix is just a liability sitting in a PDF. Auditors care less about how many vulnerabilities your tester found and more about what happened in the weeks after.

Set remediation SLAs based on severity and document them somewhere your auditor can see the policy, not just its results. A common structure ties critical findings to a 7 to 14 day fix window, high severity to 30 days, and medium or low findings to 90 days, though your actual numbers should reflect your own risk tolerance and be applied consistently.

  • Log every finding as a ticket in your existing tracker (Jira, Linear, or similar), never in a spreadsheet disconnected from engineering workflow.
  • Link each ticket to the specific commit or pull request that resolved it.
  • Capture retest screenshots or logs showing the exploit path no longer works, and attach them to the same ticket.
  • For anything you choose not to fix immediately, document a formal risk acceptance: who approved it, why, and what compensating control offsets the exposure.

Pro Tip: Don't wait for your annual pentest to close out old tickets. If a finding sits open for six months with no activity, an auditor will ask why, and "we were busy" is not an answer that satisfies a CC7.1 review.

Risk acceptance only holds up if it's specific. "We accept this risk" with no named approver and no compensating control reads as a team that skipped remediation, not one that made a documented decision.

How to Prepare Pentest Evidence for Your SOC 2 Audit: A Step-by-Step Checklist

Most of the friction in a SOC 2 audit comes from evidence assembled reactively, after the auditor asks for it, rather than built alongside the testing itself. A tighter process looks like this:

  1. Confirm scope against your system description and get written sign-off from your security lead before the SOW is finalized.
  2. Require the SOW to specify methodology, tester credentials, and testing dates that fall inside your observation window.
  3. Schedule testing 8 to 12 weeks before fieldwork ends, leaving buffer for remediation and retest.
  4. Run the test and get the findings register within one to two weeks of completion.
  5. Ticket every finding immediately, assign owners, and set SLA deadlines by severity.
  6. Remediate and retest, capturing artifacts (screenshots, logs, commit references) as you go.
  7. Map each finding to its TSC control and compile the final package: SOW, report, tickets, retest evidence, and any risk acceptances.
  8. Store everything in your GRC tool, organized by control ID, ready to hand an auditor without a scramble.

Following this order, rather than testing first and figuring out evidence packaging afterward, is what separates a smooth audit cycle from one that runs long because the auditor keeps asking for documents nobody thought to prepare.

How Earthshaker Security Runs SOC 2 Ready Penetration Tests

Earthshaker Security builds every engagement around the reality that a finding is only useful once it's verified, fixed, and provable. Testing combines automated scanning with manual verification, so every reported vulnerability, from broken access control to injection flaws, has been hand-checked rather than passed through as raw scanner output.

Reports are written for two audiences at once: the engineer who needs reproduction steps and the compliance lead who needs to know what it means for their Trust Services Criteria coverage. Every engagement includes remediation guidance specific to each finding and a follow-up retest to confirm the fix actually closed the gap, giving you the artifact an auditor wants to see instead of a ticket marked "resolved" with nothing to back it up.

Why Pentesting Should Be a Program, Not a Compliance Checkbox

Treating a pentest as something you do once a year to satisfy an auditor is the single most common way organizations waste the money they spend on it. The real value shows up when findings feed back into how your engineering team builds things, not just when they get filed away in an evidence folder.

Compliance and security owners who coordinate before the SOW gets signed, agreeing on scope, timeline, and who owns remediation, avoid the scramble that happens when a critical finding surfaces two weeks before fieldwork ends. Continuous testing approaches tend to serve fast-moving engineering teams better than a single annual snapshot, since they catch regressions between audit cycles instead of after them.

Map every finding to a control. Don't bury an uncomfortable one. Auditors notice gaps far more than they notice honestly documented weaknesses with a clear remediation path.

— caleb*

Get Audit Ready Testing Without the Guesswork

Some security testing providers offer pentest evidence aimed at satisfying auditors, beyond generic scan reports that can raise additional questions. Every finding gets mapped to the control it supports, verified by hand instead of left as scanner noise, and paired with a retest artifact you can drop straight into your evidence package.

Earthshakersecurity

The service catalog covers web application penetration tests, API and endpoint testing, external attack surface reviews, and configuration and hardening audits, whichever combination matches what's actually described in your system boundary. Pricing typically ranges from entry-level one-off engagements to monthly retainers and custom day rates for larger or more complex scopes. Check the provider's website for current pricing and engagement details. Check current pricing and engagement details and get a scope conversation started before your next audit window closes in on you.

Standards and Resources Worth Bookmarking

The AICPA Trust Services Criteria is the primary document defining the control objectives your pentest evidence needs to support. NIST SP 800-115 lays out the technical methodology most auditors expect a report to reference. OWASP API Security covers testing guidance specific to API endpoints, increasingly relevant as more SOC 2 scopes include API-first products. The National Vulnerability Database provides the CVE and severity scoring conventions used to classify findings consistently across reports.

Sources

FAQ

Is Penetration Testing Legally Required for SOC 2?

No. SOC 2 does not legally or contractually mandate penetration testing by name, but auditors commonly expect it as evidence supporting security-related Trust Services Criteria like CC7.1 and CC7.2, particularly for Type II reports.

How Hard Is It to Get SOC 2 Compliant?

Difficulty depends heavily on your existing control maturity, but most first-time organizations spend several months building policies, implementing access controls, and gathering evidence before an audit begins, with a Type II report requiring an observation period of three to twelve months.

What Is the Difference Between SOC 1, SOC 2, and SOC 3?

SOC 1 reports on controls relevant to a client's financial reporting, SOC 2 reports on security, availability, processing integrity, confidentiality, and privacy controls, and SOC 3 is a public-facing summary version of a SOC 2 report with less technical detail.

What Counts as Acceptable Pentest Evidence for a SOC 2 Auditor?

Acceptable evidence includes a signed statement of work, tester qualifications, a named methodology like NIST SP 800-115, testing dates within the observation period, a findings register with severity and reproduction steps, remediation tickets, and documented retest results.

When Should I Schedule My Pentest for a Type II Audit?

Schedule testing well in advance of your audit fieldwork to allow sufficient time for testing, remediation of findings, and a retest that confirms fixes hold, all within your observation window.

Made with BabyLoveGrowth to get found by Gemini