3 Common Pentesting Pitfalls That Lead to SOC 2 Audit Findings
Most SOC 2 audit friction does not come from technical issues or catastrophic security failures. It usually comes from a breakdown between what a company says it does and the evidence it actually produces.
I recently spoke with an auditor, and after walking through how penetration testing evidence is reviewed, they gave me the top three things that frequently go wrong with their SOC 2 clients and how to avoid those traps.
While SOC 2 covers a broad range of controls, these specific pitfalls center on the penetration testing process. In most audits, penetration testing is evaluated under the Common Criteria related to system operations and vulnerability management, particularly CC7. These criteria require organizations to identify, assess, and remediate vulnerabilities in a structured and repeatable way.
Here are the top three pitfalls auditors see across SaaS companies, healthcare technology providers, and growing teams navigating compliance for the first or second time.
1. Remediation SLAs That Fail to Reflect Risk
After reviewing a penetration test report, auditors rarely start with the vulnerability list itself. They look at how the organization responded.
Many companies define remediation SLAs that feel reasonable internally but do not reflect a risk-based view of security. A common example is allowing 45, 60, or even 90 days to remediate a high or critical vulnerability.
That timeline raises immediate questions among auditors. If a vulnerability is truly high or critical, why is the organization comfortable accepting that risk for that long?
SOC 2 and the AICPA Trust Services Criteria are grounded in risk management. Auditors evaluate whether risks are identified, assessed, and actively addressed. Long remediation windows for serious findings often suggest that severity ratings are being applied mechanically rather than strategically.
This does not mean auditors expect everything to be fixed immediately. They understand engineering constraints, release cycles, and operational realities.
They expect visible risk ownership.
It is acceptable, and even expected, for you to contextualize your findings. If a vulnerability is initially rated high but poses a lower risk in your specific environment, an auditor will find that adjustment reasonable. You should document the technical reasoning, update the severity rating, and ensure the remediation SLA is met for that revised risk level.
If a vulnerability cannot be remediated quickly, it will not necessarily derail your audit, but auditors expect to see that you are actively managing the risk rather than ignoring it.
This means moving the issue into your risk register, ensuring leadership has reviewed the exposure, and implementing compensating controls to mitigate the threat where possible. The goal is to prove the risk is being managed, even if the patch is not live.
What does not hold up well is leaving a vulnerability labeled as high or critical while also allowing it to remain unresolved for months with no additional context.
Auditors frequently push organizations to improve SLAs as part of process maturity. Many expect those SLAs to tighten over time, especially if SOC 2 is the organization’s entry point into broader compliance efforts like HIPAA, ISO 27001, or NIST-aligned programs.
Strong programs treat SLAs as part of risk governance, not a formality.
2. Policies That Claim Penetration Testing When the Evidence Does Not Support It
This is one of the most common audit issues, and it has a subtle but important nuance.
A policy might claim the organization has penetration testing performed. When the auditor asks for proof, the company hands over a vulnerability scan or a list of bug bounty payouts.
It is important to understand that auditors have a strict definition of what constitutes a penetration test. They generally will not accept vulnerability scans, bug bounty reports, or automated tool exports as a substitute for a formal engagement.
Automated scans are effective for providing breadth across a large environment, but they lack depth. They cannot replicate the human logic required to understand the specific context of your application or the value of the “loot” an attacker might find. While a scan identifies a vulnerability, a penetration tester understands the business impact of exploiting it.
Similarly, crowdsourced security programs surface opportunistic findings from independent researchers, but they do not replace a scoped, focused, and methodical assessment.
A professional penetration test follows a structured framework. By utilizing a recognized methodology and testing against a spec like the OWASP ASVS, you ensure the assessment is thorough and systematic rather than accidental.
What is performed may be technically valuable, but it does not meet the definition of penetration testing. To an auditor, this is a control failure because the activity does not match the commitment.
From an audit perspective, this can be resolved cleanly by updating the policy to reflect reality. It is better to have a modest policy that you follow than an ambitious one you ignore.
If a pentest isn’t going to take place, update the policy to accurately describe the vulnerability management and scanning activities that actually occurred. An auditor can accept a policy that matches the evidence, allowing the SOC 2 opinion to remain clean while you plan for a more comprehensive assessment later.
If the organization continues to claim penetration testing without evidence that meets the standard, it becomes an audit exception.
That said, a clean audit does not eliminate business risk. Enterprise customers and procurement teams frequently expect penetration testing as a baseline requirement, especially if you are selling software-as-a-service, handling sensitive data, or integrating with regulated environments. While a clean SOC 2 report is a great milestone, it does not necessarily satisfy every expectation. You may still face the “Where is the pentest?” hurdle during every major contract negotiation.
Web Application vs External Network Testing
This pitfall is also often seen when a policy promises a specific type of penetration test, but the provided evidence does not reflect that commitment.
For example, policies may state that the organization undergoes web application penetration testing, but the actual work delivered is only an external network scan of the application infrastructure. While an auditor will recognize the value of a network-level test, they will also recognize that it completely ignores the application layer. If your documentation promises one and you deliver the other, the auditor will flag it as a control failure.
An external network assessment evaluates exposed services, ports, and known vulnerabilities in internet-facing components. A web application penetration test evaluates authentication flows, authorization controls, session management, input handling, and business logic.
From an auditor’s perspective, adjusting the policy and documenting the scope change can resolve the issue.
Customers, however, may still expect assurance that the application itself was evaluated. If your policy says web application penetration testing, then a web app pentest is the only activity that aligns with expectations.
Frequency Mismatches
The same dynamic applies to frequency. Policies often claim biannual penetration testing, but in practice, only one engagement occurs per year. While updating the policy to reflect annual testing can resolve the auditor’s concern, you must consider any ripple effect on your business relationships.
Typically, I see an annual testing schedule supplemented by assessments of major changes as sufficient for most clients to maintain compliance. While most updates in a modern dev cycle are incremental, true “major changes” do happen from time to time and require a fresh look. This approach satisfies the auditor while ensuring that significant shifts in your codebase or infrastructure are properly vetted.
However, your enterprise partners may have their own expectations. If you reduce the frequency in your policy to satisfy a specific audit requirement, you may still find yourself out of alignment with the security addendums in your largest contracts.
3. Penetration Tests That Occur Outside the Observation Window
This issue has nothing to do with testing quality and everything to do with audit mechanics. SOC 2 auditors only care about what happened during the “observation window” or “audit period.” For first-time audits, this is typically a three-month period, but it can vary based on the specifics of your engagement.
Auditors can only opine on controls that operated during the observation period. A penetration test that occurred outside that window cannot be relied upon, regardless of how thorough it was.
This surprises teams more often than it should.
A penetration test may have been completed earlier in the year. Findings were remediated, documentation is clean, and the team feels confident in the work. Then the audit begins, the observation window is defined, and that test is suddenly out of scope.
At that point, the auditor’s hands are tied. Even excellent testing cannot be used if it did not occur within the observation period. This leads to a predictable scramble where teams try to schedule a new test, only to discover that many reputable firms are booked months in advance.
While a last minute test seems impossible, short notice SOC 2 timelines are more common than teams like to admit. Mergers, delayed audits, or customer pressure can all compress the window unexpectedly.
Expedited penetration testing is possible, but not every firm is structured to support it. The difference is the operational model.
Some firms rely on throughput, rigid structures, and large engagement queues. They are built for volume, which often means tight deadlines become difficult to accommodate.
Others operate with small, tester-led teams and minimal bureaucracy. There are no layers of sales or project managers slowing communication, and no volume quotas driving shortcuts. By limiting engagements to what they can execute well, they retain the flexibility to fit in emergency penetration tests without compromising quality.
Consistent annual scheduling remains the cleaner solution. But when timing shifts, having a partner who can adapt without sacrificing rigor prevents unnecessary audit delays.
The Pattern Auditors See
All three of these issues share the same root cause. Security work is being done with good intentions, but without fully considering how auditors evaluate controls and evidence.
SOC 2 does not require perfect security; it requires consistency. The goal is to do what you say you do, manage risk deliberately, and produce evidence that aligns with both your internal controls and the audit framework.
Many organizations pursue SOC 2 because customers demand it. That is normal, and compliance as a primary motivator is not a flaw.
The teams that struggle are rarely careless. Most are simply operating under assumptions that do not hold up once an auditor is involved. Getting these three areas right, alignment between policy and evidence, realistic remediation, and proper timing, removes a surprising amount of friction from the process. It also tends to improve real-world security outcomes at the same time.
The Checklist Your Auditor Wishes You Had
If your current reports leave auditors asking follow-up questions, it is time to raise your expectations.
Our free guide, Audit-Proof Your Pentest, gives you 17 questions that reveal whether you are working with a real security partner or just another checkbox vendor.
Learn how to spot shallow testing hidden behind polished reports, identify red flags in communication, and choose a partner who delivers evidence your auditor will actually trust.
