Penetration Test vs Vulnerability Scan: What SOC 2 Auditors Actually Expect

A vulnerability scan uses an automated tool to flag known weaknesses. A penetration test is a human-led exercise that tries to exploit them the way an attacker would. SOC 2 auditors and enterprise customers expect both, plus proof that you fixed what each one found.

You usually end up comparing a penetration test with a vulnerability scan when an enterprise customer asks for your pen test report and you are not sure the scans you already run count.

Our clients asked us some version of this question 10 times this year, across 5 companies. Nothing in the Trust Services Criteria sets a specific interval for either. The usual expectation is scanning on a schedule and an independent pen test at least once a year.

Penetration test vs vulnerability scan: what is the difference?

A vulnerability scan is an automated check against known weaknesses, run often and across everything. A penetration test is a human-led, point-in-time exercise where a tester tries to exploit weaknesses to show real impact. You need both, because one does not replace the other.

A tester tries to chain findings the way an attacker would: two medium findings into a patient-data leak, or a misconfigured S3 bucket into access to your production database.

Scan and pen test side by side

Our guide to application vulnerability management covers how to run the scanning side.

Does SOC 2 require a penetration test?

No criterion in the AICPA Trust Services Criteria requires a penetration test. In practice, most auditors still expect an annual pen test report as part of SOC 2 compliance, and enterprise customers ask for one. If your customer is already asking for the report, that request settles the question. If you have no report yet, book the test, give the customer the date, and send the executive summary when the report arrives.

Penetration testing appears once in the criteria, in the points of focus under CC4.1, as one example of a separate evaluation of your controls, next to ISO certifications and internal audits. Scanning has its own point of focus under CC7.1, which asks for scans on a periodic basis and after any significant change, with timely remediation. Points of focus are guidance, not requirements. HITRUST is a separate framework with its own requirements, so check the HITRUST CSF before you assume this answer carries over.

Is your compliance platform's bundled pen test enough?

It can be. What auditors care about is that someone independent of the people who built the system ran the test, that it covered production, and that it produced a report with findings and retest evidence. A bundled test is usually cheaper and fine for a straightforward SaaS product. Pay for a specialist firm when your product has unusual attack surface, or when a customer's contract names the firm it wants.

AI-led testing firms are another option now, and they can be fast. One of our legal tech clients needed a pen test quickly, used one, and it satisfied the requirement. If you work in a regulated industry or hold very sensitive data, choose a well-reputed firm, because results vary widely and you want real feedback from the test. If your product holds patient data, you are in that group, so check who runs a bundled or AI-led test before you rely on it.

How often should you scan, and how often should you pen test?

Scan on a schedule you can keep and again after any significant change. Pen test at least once a year with an independent tester. Write both cadences into your controls and keep every report, because a Type 2 audit looks at months of history and a missing scan shows up as a gap.

Your report type sets how much history the auditor reviews: see SOC 2 Type 1 vs Type 2.

The remediation and retest window

Pen test firms typically give you about a quarter to remediate findings and then retest. Most include at least one free retest, and the retest itself typically takes two to three weeks.

Plan backward from the date your auditor will ask for the report. Leave room for the test, up to a quarter to fix findings, and two to three weeks for the retest. Otherwise you will have open findings to explain when the auditor asks.

For the rest of your audit prep, our free SOC 2 Readiness Checklist has 70 items in ten sections to score yourself against.

Which pen test report should your auditor see?

All of it, in order: the original report, how you remediated or re-rated each finding, whether each fix landed inside your own remediation deadlines, and the retest. That is the whole chain. Auditors are skeptical of a retest-only report or a report with no findings, and we have seen clients share only the clean retest and then have to justify the whole process again.

The fix needs its own evidence. On one client's audit this year, the auditor asked how the team had remediated the single high-risk finding in its pen test report. The report proved the test happened. We asked the client's team for evidence of the fix, such as a screenshot or a written explanation, and had it ready for the auditor.

The same rule applies to post-audit remediation: every finding needs a fix you can document with a ticket, a commit or a screenshot of the change.

Can you re-rate a finding's severity?

Yes, if you write down why. A tester scores severity without the wider context of your stack or the compensating controls you run, which is why re-rating is justified. Record the original rating, your reason and the new rating, and have someone other than the person doing the work approve it. Auditors object to a downgrade with no written justification.

What if a finding has no vendor fix yet?

Accept the risk on paper and keep a ticket open. What we do:

1. Log the vulnerability in your risk register with the treatment set to accept.
2. Write the justification: the compensating controls you rely on until a patch exists.
3. Open a ticket so the patch goes on as soon as the vendor releases it.

The auditor is looking at how you treated the risk and how you documented it.

What do you share when a customer asks for your pen test?

Send the executive summary: the findings, their ratings and their current status. A customer asking for your pen test wants to know that nothing serious is still open, and the summary answers that. The full report describes your tech stack in detail, so hold it back until a customer needs it for due diligence, often late in a deal, and then share it with an NDA in place.

Do you need a bug bounty program?

No. A public bug bounty program is not required for SOC 2. What your auditor looks for is a channel through which outside researchers or users can report a vulnerability they find.

That channel could be a security@yourcompany.com address, a responsible disclosure page on your website, or a simple form.

Set up the reporting channel first, because it is among the SOC 2 requirements your auditor will check. Add a bug bounty program when you can.

How do you scope a penetration test so it covers what customers care about?

Put the systems that handle your customers' data in scope: usually the web application and its APIs, plus the mobile app if it is a real way in to customer data. Agree that scope with your biggest customers before the test by asking for their requirements early. SOC 2 does not prescribe what a pen test covers, so you can phase it, but document what was left out, why, and when it will be tested, because buyers and auditors will ask.

If a customer finds its systems were out of scope, be open about it. Explain why those systems were in or out, and commit to covering them in the next cycle.

A vCISO can help you make these scoping decisions when you don't have a full-time security leader.

Need help getting audit-ready?

We work as your embedded security and compliance team. When you need a pen test, we bring in testing firms we work closely with, collect the remediation evidence for each finding, keep the chain from original report to retest in order, and take you through the audit. Anterior, a healthcare AI company, reached HITRUST in 7 weeks with us to meet a customer's security demands after due diligence questionnaires had stalled its healthcare deals.

If you are preparing for your first SOC 2 or HITRUST and want help, talk to an expert.

Cancel anytime. If you're not saving 100+ hours, you don't pay.