SOC 2 Penetration Testing: What Auditors Expect

If you are working towards SOC 2, someone has probably told you that you need a penetration test. Someone else may have told you that you don’t. Both are partly right.

This guide explains what SOC 2 actually says about penetration testing, what auditors look for when they read a pentest report, how to scope and time the test, and the mistakes that cause the most trouble. Treat this as practical guidance and confirm specifics with your audit firm.

What SOC 2 actually says

SOC 2 is an attestation report produced by an independent CPA firm. The auditor assesses whether your controls meet the AICPA’s Trust Services Criteria. Those criteria describe outcomes you need to achieve, not a list of activities you must perform.

That is why you won’t find a line in SOC 2 that says “perform a penetration test every year”. The framework leaves it to you to decide how to meet each criterion, and to the auditor to judge whether your approach is good enough.

Two criteria are where penetration testing usually fits.

CC4.1: evaluating whether controls work

CC4.1 expects you to perform ongoing or separate evaluations to check that your controls are present and functioning. The AICPA’s points of focus for this criterion list penetration testing as one kind of evaluation management can use.

Points of focus are guidance rather than requirements. Still, when the guidance names an activity, many auditors expect to see it, or to see a clear reason why you chose something else.

CC7.1: finding vulnerabilities

CC7.1 is about detection and monitoring. It expects you to identify configuration changes that introduce new vulnerabilities, and your susceptibility to newly discovered ones.

Automated scanning supports this criterion day to day. A penetration test adds depth: it shows how vulnerabilities could actually be exploited, including flaws in logic and access control that scanners can’t see.

What auditors look for in a pentest report

Auditors are not there to re-run your test. They are there to decide whether the test is credible evidence that your controls work. That means they look at the report as a document, and they ask a few predictable questions.

Is the scope right?

The first thing an auditor checks is whether the test covered the system described in your SOC 2 report. If your system description includes a web application, its APIs and the cloud account it runs in, a test that only covered a marketing website is not much help.

A good report states the scope precisely: which applications, environments, hosts, accounts and user roles were tested, and what was deliberately excluded.

Is the methodology credible?

Auditors want to see that the test followed a recognised approach and was more than an automated scan with a cover page. A clear methodology section, referencing standards such as the OWASP Web Security Testing Guide or NIST SP 800-115, shows how the testing was done and how deep it went.

Are the findings dated and rated?

Each finding should have a clear description, a severity rating, evidence, and remediation guidance. Dates matter: the auditor needs to see when testing happened, so they can place it within the audit period.

Were the findings fixed?

This is the question that matters most. A report full of findings is not a problem in itself. Finding things is the purpose of the test. What draws attention is high-severity findings with no evidence they were fixed or formally accepted as risk.

A retest closes this loop. It shows which findings were verified as fixed and when.

Was the tester independent?

Auditors generally expect the evaluation to be performed by people independent from those who built and run the system. An external testing firm meets this naturally. If you use an internal team, be ready to explain how independence is maintained.

The table below summarises what auditors usually look for and where it should appear in the report.

What the auditor checks	Where they look in the report
The test covered the in-scope system	Scope section: targets, environments, roles, exclusions
The testing was rigorous	Methodology section and standards referenced
The test happened in the audit period	Test dates on the cover and in the findings
Risks were understood	Severity ratings and impact descriptions
Issues were dealt with	Retest status for each finding, or documented risk acceptance
The tester was independent	Who performed the test

Scoping your SOC 2 penetration test

Start from your SOC 2 system description, not from a list of everything you own. The system boundary defines what the auditor is assessing, so it should define what you test.

For most SaaS companies, that means:

• The product your customers use. Usually the core of the test. See our web application testing.
• The APIs behind it. Public APIs, and internal APIs that handle customer data. See API testing.
• The cloud environment it runs in. The AWS, Azure or GCP accounts that host the in-scope system. See cloud security testing.
• Internet-facing infrastructure. Admin interfaces, VPNs and other exposed services. See external network testing.

Mobile apps, internal networks and corporate identity systems may also be in scope, depending on how your system boundary is drawn.

Agree the scope with your auditor first

The simplest way to avoid a scope argument is to have it before testing starts. Share the proposed scope with your audit firm and ask whether it matches their expectations. It takes one email and can save weeks.

Test with realistic access

Ask for accounts at each user role, and in more than one customer tenant if your product is multi-tenant. Many of the most serious SaaS findings involve one customer reaching another customer’s data, and that can only be tested with two tenants.

Timing the test around your audit window

Timing causes more SOC 2 pentest problems than anything else. The right timing depends on the type of report you are working towards.

Type I

A Type I report assesses the design of your controls at a single point in time. Your pentest should be recent relative to that date, with findings fixed or in hand before the auditor looks at it.

Type II

A Type II report assesses whether your controls operated effectively over an observation period, often several months to a year. Here the pentest needs to fall inside that period, and ideally so does the retest.

A practical plan for a Type II looks like this:

1. Early in the period: run the penetration test.
2. Next few weeks: fix the findings, starting with the most severe.
3. Before the period ends: retest and get an updated report showing remediation status.
4. During fieldwork: give the auditor the report, the retest results and any risk acceptances.

How often to test

Most SOC 2 programmes test at least annually, plus after significant changes to the in-scope system, such as a new product area, a major architecture change or a move to a new cloud environment. Each audit cycle should have evidence that is current.

Common mistakes

These are the issues we see most often when companies use a pentest for SOC 2.

Testing the wrong thing

The test covers whatever was easy to scope rather than what is in the system description. The auditor then has evidence about a system they are not assessing.

Treating a scan as a pentest

An automated scan report, however long, is not the same as a manual penetration test. Many auditors and customers can tell the difference, and some will not accept scan output as evidence of CC4.1-style evaluation. Our guide to the difference between a pentest and a vulnerability scan covers this in more detail.

Leaving findings open

High-severity findings with no fix, no retest and no documented risk acceptance are the most common cause of awkward audit conversations. Fix them, retest them, or formally accept the risk with a reason.

Testing too late

A test in the final weeks of a Type II period leaves no time to fix and retest. The report then shows open findings at the end of the period.

No retest evidence

Teams fix the issues but never get them verified. The auditor sees the original findings and has no independent evidence that they were resolved.

A report written only for engineers

Technical detail matters, but auditors and customers also need a clear executive summary, an explicit scope and dated results. A report that is hard to read as evidence makes everyone’s job harder.

What to hand your auditor

When fieldwork starts, have a small, tidy evidence pack ready. It usually includes:

• The final penetration test report, with scope, dates, methodology and findings.
• The retest report or updated findings table, showing which issues were verified as fixed and when.
• Risk acceptances for any findings you chose not to fix, with the reason and who approved them.
• Tickets or change records linking each fix to your normal change process, if your auditor asks for them.
• The attestation letter, if you plan to share testing evidence with customers.

Keeping these together saves back-and-forth during fieldwork. It also shows that the test is part of a working vulnerability management process rather than a one-off exercise, which is what CC4.1 and CC7.1 are really about.

Choosing a provider for SOC 2 testing

When you speak to testing providers, ask questions that map to what the auditor will check:

• Will the report clearly state scope, dates and methodology?
• Is a retest included, and will the report be updated with remediation status?
• Do you provide an attestation letter we can share with customers?
• How much of the testing is manual, and how are findings verified?
• Can we see a sample report before we commit?

At Rudranetra, every engagement includes a retest and an attestation letter, and our reports are structured to be read as audit evidence. You can request a sample report to see the format, read how we work, or see our SOC 2 testing page for the scope we usually recommend.

Summary

SOC 2 doesn’t name a mandatory penetration test, but it expects you to evaluate your controls and manage vulnerabilities, and a pentest is one of the clearest ways to show both. Auditors read the report as evidence: they check scope, method, dates, severity and remediation.

Get the scope to match your system boundary, test early in the observation period, fix and retest before it closes, and keep the paper trail clear. Do that, and the pentest becomes one of the easiest parts of your audit.