Penetration Testing for SOC 2: Is It Required, and What to Show Your Auditor
Somewhere in your first SOC 2 Type II, someone will ask, “Have you had a pen test?” It might be a customer’s security reviewer. It might be your auditor. Either way, the room goes a little quiet, because nobody is sure whether the honest answer is yes, not yet, or “we ran a scanner.”
We run penetration tests for SaaS and fintech companies in that spot. Two things first, so you know where we stand. Snipeyes is not a CPA firm and we don’t issue SOC 2 reports; your auditor does that, and your auditor decides what is enough. What we can do is run the test and hand you evidence that is easy to follow. The rest of this piece is about what that evidence is.
So, does SOC 2 require a pen test?
No. SOC 2 doesn’t name a penetration test as a requirement. It is built on trust services criteria, and CC4.1 is the criterion that brings penetration testing into the picture. CC4.1 is about monitoring: checking that your controls work, through what it calls separate evaluations. The supporting guidance lists penetration testing as one example of such an evaluation, alongside independent certifications and internal audit assessments (AICPA, Trust Services Criteria with revised points of focus, 2022).
Those examples are called points of focus, and they are illustrative. The criteria set no test frequency. So the useful reading is this: you need some way of evaluating your controls that you can show, and a pen test is one the criteria themselves name. If you choose a different evaluation, you should be able to explain why it covers the same ground.
We have only read this through the published criteria, and your auditor may read it more firmly for your scope. Ask early.
Where the report fits, and what else goes beside it
A pen test report is a single document. The questions around it are what make it evidence. The table below is how we would line up the pieces for a reviewer. The right-hand column is our suggestion, not an auditor’s checklist.
| Piece | Criterion it may support | What we would keep in the file |
|---|---|---|
| The penetration test report | CC4.1, as an example of a separate evaluation | The signed-off report, the test dates, the scope in plain words (which product, which environments), the name of the testing company |
| Vulnerability scan results | CC7.1, where the point of focus is running vulnerability scans | Scan outputs on the schedule you set, kept apart from the pen test |
| What happened to each finding | No criterion cited here | For each issue, an owner, a fix date and how the fix was verified |
| The retest | No criterion cited here | The retest date and result, so a finding is closed on a record and not on someone’s word |
| A short summary for leadership | No criterion cited here | Half a page on what was tested, what mattered and what changed; the page a customer will actually read |
A scan and a pen test answer different questions, and it helps a reviewer if your file keeps them apart. A scanner lists known weaknesses it can recognize. A tester tries to use them, chains them, and shows which ones lead somewhere that matters. Label each set of evidence honestly and you can answer a customer’s “testing” question for both.
Why Type II changes how you plan
A Type II report looks at how your controls worked over a period, not on a single day. We can’t speak for how your auditor samples, but the practical effect is that a test dated long before the period ends leaves a gap you may have to explain to your auditor.
One of our bank engagements shows what a finding and a fix look like on the clock. On an open-banking API we tested 27 endpoints and found a flaw that could divert funds, plus signed requests that could be replayed. The critical chain was fixed in 4 days. A payment module we tested for a digital bank ended with a retest that confirmed the fixes. Neither story is about SOC 2, but a finding, a fix and a date are what a file like yours holds.
A retest is included in our work. A fix that nobody has tried again is still a claim.
What to do before you book a test
Tell us which system the audit covers and we scope to that. A test of your marketing site may not help if the audit scope is your customer-facing application and its API. Our report is a single document and the findings in it are mapped to SOC 2, so you aren’t building the link between a finding and a criterion yourself. If your audit period has a date you’re working toward, tell us early; the report comes within 10 business days of testing.
Ask your auditor one question while you are at it: “If we bring you a penetration test report, a fix log and a retest record, is that the evidence you would want for CC4.1?” Their answer beats anything we can tell you about your audit.
If you’d like to talk through scope, you can book a free 90-minute scoping session. More on how a test report holds up across PCI DSS, ISO/IEC 27001:2022 and SOC 2 is in our guide to penetration testing evidence for audit, and the testing itself is described on our penetration testing page.