SOC 2 is an independent audit framework that demonstrates how well a company protects its customers' data. Today, it is the de facto standard for SaaS companies and cloud services operating in the US market.
During the audit, an independent auditor evaluates your system security. Optionally, he can also review service availability, data processing integrity, confidentiality, and privacy. The end result is an official report that you can share with clients and partners as proof that their data is safe in your hands.
Penetration testing (or "pentesting") is not strictly mandatory for SOC 2 requirements, it is listed merely as one example of a security assessment. In practice, however, auditors almost always expect to see one. As a result, most companies treat it as a default requirement during audit preparation.
Because of this, pentesting for SOC 2 compliance is often viewed as just another item on a pre-audit checklist: hire a vendor, get the report, drop it into the evidence folder, and move on.
This is where companies frequently make a mistake.
Ordering a pentest for SOC 2 compliance is the easiest part of the audit. The real challenge is running it in a way that provides value for your security team, your auditor, and your overall business. What should be in a scope? Is testing a web application enough? What should you do about cloud infrastructure? What will the auditor look for in the report? And most important— what happens if the pentester finds a critical vulnerability just a few days before the audit?
In this article, we break down what penetration testing actually looks like in the context of SOC 2 audit, where problems most often arise, and why simply having a pentest doesn't mean you are well-prepared for an audit.
(If you don't fully understand what a pentesting is yet, we recommend reading this article first.)
What an Auditor Actually Wants to See in a SOC 2 Pentest Report
Penetration testing is not a separate, universal SOC 2 compliance requirement that every company must complete in the exact same way. In practice, however, it often forms an important part of the evidence for the Security criterion.
Incident response policies, vulnerability management processes, access control — all of these can be described in a document. A pentest provides a practical check of some of these controls: it shows whether vulnerabilities or misconfigurations can be exploited to bypass your built-in defenses. Therefore, it is important for the auditor to understand not just the fact that testing took place, but how the results were handled: what was found, what was done about it, and who was responsible for it.
There is also a practical side. Your clients read your SOC 2 report too. When a client’s security team sees the pentest section, their first question is always the same: what exactly was tested, when was it tested, and have the identified vulnerabilities been fixed? This matters for the business as well: a pentest shows clients that security is checked in practice, not just at the level of policies and documents.
Why SOC 2 Pen Testing is Critical for SOC 2 Compliance
Technically, the pentesting methodology is the same: OWASP, PTES, NIST — the core doesn't change depending on what the report is for. The difference lies in the scope, documentation, and how the report will be read by someone who doesn't know the technical details of your product.
Scope is tied to the system included in SOC 2, not to the company's entire perimeter. If you have a product being audited and a separate internal service that has nothing to do with it, the auditor is only interested in the first one. This sounds obvious, but in practice, companies often order a pentest "for everything" and then cannot clearly show the auditor which part of the report applies to the system in the SOC 2 scope and which does not.
The SOC 2 pentesting report must be readable for an auditor, not just an engineer. SOC 2 auditors are not pentesters. They need to understand the methodology, the date of the test, who conducted it, what was in the scope, a list of found vulnerabilities by severity level, and, most importantly, the status of each: fixed, in progress, or risk accepted. The auditor is not interested in a technical proof of concept for an SQL injection. They want to know if that finding was brought to resolution.
Timing matters. SOC Type 2 evaluates whether controls operated consistently throughout the entire audit period, rather than on one specific date. Specific pentest frequency requirements can vary across different auditors and CPA firms, so this should be clarified directly with your auditor. But the logic is simple: the closer the pentest is to the start of the period and the fresher the report, the fewer questions it raises. A two-year-old report, even with findings long closed, will raise additional questions about its relevance.
What Exactly Is Checked in a SOC 2 Penetration Testing
Most often, the scope includes:
- External perimeter: everything accessible from the internet: web applications, APIs, public services;
- Internal infrastructure: if there is a significant internal network with access to sensitive data;
- Authentication and authorization mechanisms: this is where issues that directly hit the Security criterion are found most often;
- Environment segmentation: if production and staging environments are separated in reality, not just on paper.
Cloud infrastructure deserves a separate mention. A classic pentest and a cloud configuration assessment are not the same thing. A pentest mainly looks for ways to break in through an application, API or network. An exposed cloud storage bucket or excessive permissions are configuration issues, and they may not be included in a SOC 2 pentest scope at all unless explicitly specified.
For SOC 2 audit, it is important to understand this in advance: if a significant part of your infrastructure runs on AWS, GCP, or Azure, you should ask your vendor directly whether a cloud configuration review is included in the scope or if it is a separate service. This should also be recorded in the final report: the auditor should immediately see what was checked and what remained outside the scope.
The Most Common Mistake: Pentesting for the Sake of a Checkmark
A company orders a pentest two weeks before the deadline with the auditor, gets a report with critical findings, attaches it to the evidence package and hopes this will satisfy the auditor. Most often, it does not.
The auditor sees a report with critical vulnerabilities and no fix status, and asks a question: if you knew about a critical problem and did nothing about it, how does that align with your own vulnerability management process described in your policies? Here, the auditor is already evaluating how well the controls you described in your documents actually work in practice.
Therefore, the correct sequence is different: pentest → prioritization of findings → remediation → retest confirming resolution → and only then does the report with the final status go into the package for the auditor. If there is no time left for a full cycle before the deadline, it is more honest to show the auditor an intermediate status with a remediation plan and dates than to slip in a report with unclosed critical findings without explanation.
(We explained what to do after a pentest in more detail in a dedicated article.)
An Annual Pentest Is Just a Snapshot of a Single Day
No SOC 2 requirements say "do a pentest every 12 months." But the logic of Type II — evaluating whether controls worked consistently throughout the period — naturally leads to the same conclusion in practice: one test at the start of the period does not show what happened to the product afterward.
And usually, a lot happens: new releases, new APIs, updated dependencies, infrastructure changes. Each of these changes could theoretically open a new gap that the initial report knows nothing about.
That is why a simpler scheme works in practice: a full pentest before the main audit and lighter checks or retests after significant releases or infrastructure changes throughout the year. This is cheaper than ordering a full pentest "from scratch" every time, and it gives the auditor and your clients an up-to-date picture, rather than a year-old report.
Usually, no one disputes the idea itself. The problem is different: a repeat pentest costs almost as much as the first one and takes almost as long. This is precisely the problem that AI Pentest by A42 aims to solve: after the main testing, you can order a full retest of the entire scope for 50% of the initial pentest cost. Thanks to specialized AI agents, the retest results can be delivered just as fast — in up to four days.
What to Do About It
If you are preparing for SOC 2 and haven't yet decided on the pentest scope, report format, or how to fit retesting into your release cycle, it is better to resolve these questions before the audit begins.
You can discuss your specific case with the A42 technical team by booking a discovery call.
