The Penetration Test Report Your SOC 2 Auditor Will Actually Accept

A penetration test report for a SOC 2 audit needs to show who tested, when, what was in scope, how they tested, what they found and what you did about it. Auditors accept a report from a qualified independent tester whose scope matches your system boundary, dated inside or close to the audit period, with every finding traced to remediation or a documented risk decision.

Many companies buy a penetration test because an auditor or a customer asked for one, then find out at fieldwork that the report does not answer the auditor's questions. The test was fine. The report was the problem: wrong scope, wrong date, no retest, or nothing linking findings to fixes. This guide covers what the report has to contain, and how to get one that works for SOC 2, ISO 27001 and the enterprise buyer waiting on your deal.

Does SOC 2 require a penetration test?

Not by name as a mandatory control. The AICPA Trust Services Criteria are written as outcomes, and each criterion has points of focus that describe ways to meet it. Under CC4.1, which covers ongoing and separate evaluations of whether controls are working, the points of focus list penetration testing as one of the types of separate evaluation an organization may use, alongside independent certifications and internal audit.

In practice, most SOC 2 auditors expect to see one for a software company, and most enterprise buyers ask for one separately anyway. Our article on whether you need a penetration test for SOC 2 covers the edge cases where you might not.

What a penetration test report must contain for an auditor

An auditor reads a penetration test report as evidence that a control operated. They want to know the control was designed sensibly and actually ran. Every item below answers one of their questions:

Report element	The auditor's question it answers
Tester name, firm and qualifications	Was this done by someone competent and independent of the system?
Testing dates	Did the test happen inside, or relevant to, the audit period?
Scope: applications, APIs, hosts, environments	Does it cover the system described in the SOC 2 report?
Methodology	Was it a real test against a recognised method, or an automated scan with a cover page?
Findings with severity ratings	What risk did the test identify?
Remediation status and retest results	Did the organization act on what it found, within its own policy timelines?
Exclusions and limitations	What was not tested, and why?
Executive summary	Can management show it reviewed the outcome?

Methodology deserves a sentence of its own. Reports that cite a recognised approach, such as the OWASP Web Security Testing Guide for web applications or NIST SP 800-115 for technical security testing, make the auditor's job easier. A report that cannot describe its method looks like a scan, and auditors know the difference. Our explainer on a penetration test versus a vulnerability scan sets out where that line is.

Scope: the most common reason a report is rejected

Your SOC 2 report describes a system: a product, its infrastructure, its supporting processes. The penetration test has to cover that system. Problems we see often:

• The test covered the marketing site, not the product. The marketing site is rarely in the system boundary.
• The test covered production web endpoints but not the API that customers and mobile apps actually use.
• The test ran against staging with no statement that staging matches production, and production differs.
• A major component was added after the test and is now in the system description but was never tested.

Fix this at scoping. Hand your tester the system description, or at least the list of in-scope components, before the test is quoted. Then check the final report's scope section against your description line by line.

Timing for a Type I and a Type II

For a Type I, the auditor reports on control design at a point in time, so a recent test that covers the system is what matters.

For a Type II, the auditor reports on whether controls operated across an observation period. A test dated inside that period, with remediation also inside the period, is the cleanest evidence. A test from well before the period started tells the auditor about a version of your system that may no longer exist. Plan the test so it lands early enough in the window to fix findings and retest before the window closes. Our guide to operating a SOC 2 Type II observation window shows where it fits among the other recurring work.

Findings, remediation and the retest

An auditor does not expect zero findings. A test that finds nothing on a real product is more suspicious than one that finds a handful of medium issues. What the auditor expects is that findings were handled the way your own vulnerability management policy says they will be.

That means three things are in the evidence pack:

1. The original report with findings and severities.
2. Tickets or records showing each finding was assigned, fixed or formally accepted as a risk, with dates.
3. A retest letter or updated report confirming fixes, ideally from the same tester.

If your policy says critical findings are fixed within a set number of days and the tickets show they took twice that, the auditor will note an exception, even though the test itself was fine. Write remediation timelines you can actually meet. Our article on what SOC 2 exceptions mean explains how those notes read in the final report.

What evidence an ISO 27001 auditor accepts

ISO/IEC 27001:2022 does not have a control called "penetration test" either. Testing evidence typically supports Annex A controls such as 8.8 (management of technical vulnerabilities), 8.29 (security testing in development and acceptance) and 5.35 (independent review of information security), depending on what your Statement of Applicability says you do.

The difference from SOC 2 is that an ISO auditor checks the test against your own ISMS. If your risk treatment plan says you test annually and after significant change, they look for the annual test and the test after the last significant change. The report contents that satisfy a SOC 2 auditor generally satisfy an ISO auditor too, so one well-scoped test can serve both. That is how we ran it for the data centre operator in our parallel SOC 2 and ISO 27001 case study.

Should the same firm do the pentest and the audit?

Generally, no. The audit firm has to be independent of the controls it reports on, and a penetration test is evidence those controls are working. If the audit firm also performed the test, it may end up assessing its own work. Some audit firms decline to do both for that reason. Others have their own view of what their independence rules allow.

The simple route is separation: one firm tests, another audits. It also reads better to a buyer's security reviewer, who will see the tester's name in your evidence and the auditor's name on the opinion. If you are considering one firm for both, ask the audit firm in writing how it addresses independence, and ask your largest customer whether they would accept it.

The fastest honest way to get a report before a deal closes

When a buyer's security review asks for a penetration test, the timeline is driven by scoping, the tester's calendar, the testing itself, and report writing. You can speed up the parts you control:

• Have scope ready. A list of URLs, APIs, environments, user roles and test accounts saves days of back and forth.
• Prepare a test environment and credentials before the start date, not on it.
• Ask the buyer what they need to see. Many accept an executive summary or an attestation letter while the full report stays under NDA.
• Agree retest timing up front so fixes can be confirmed quickly.

What you should not do is buy the cheapest automated scan relabelled as a penetration test to meet a deadline. Buyers' reviewers recognise them, and the next question will be harder. Read what to do when a customer wants proof of a penetration test for the conversation with the buyer, and how to vet a penetration testing firm before you commit to one.

Common questions about penetration test reports for SOC 2

How recent does a penetration test need to be for SOC 2?

For a Type II, the cleanest evidence is a test performed inside the observation period, with remediation and retesting also inside it. For a Type I, a recent test that covers the current system works. Most organizations test at least annually and after significant changes, and their auditors check the test against that stated policy.

Will an auditor accept a vulnerability scan instead of a penetration test?

A scan is valid evidence for vulnerability management, but it is not a penetration test. A scan finds known weaknesses automatically, while a penetration test has a person trying to exploit and chain them. If your controls or customer contracts say you perform penetration testing, a scan alone will not satisfy the auditor or the buyer.

Do I have to share the full penetration test report with customers?

No. Many companies share an executive summary or a letter of attestation from the tester, and provide the full report under NDA only when a buyer insists. Your auditor will see the full report. Agree with your tester at the start what summary documents they will produce for customer use.

What if the penetration test finds critical vulnerabilities right before our audit?

Fix them, retest, and keep the records. An auditor cares that findings were handled according to your vulnerability management policy, not that none were found. A critical finding fixed promptly and confirmed by retest is good evidence. One left open past your own policy deadline is what produces an exception.

Can one penetration test cover both SOC 2 and ISO 27001?

Yes, if the scope covers both the SOC 2 system boundary and the ISO 27001 scope, and the timing fits both audit calendars. The report contents auditors look for are largely the same. Map the test to each framework in your evidence register so you collect it once and use it twice.