SOC 2 penetration testing: what auditors look for

A SOC 2 report is an examination of your controls by an independent CPA firm, measured against the AICPA's Trust Services Criteria (2017, with the points of focus revised in 2022). Security is the category every SOC 2 report covers. Its common criteria state what your controls must achieve and leave the method to you, and none of them makes a penetration test a requirement.

Two criteria are where a pentest usually lands. In our words:

Points of focus are guidance. The AICPA offers them as characteristics to consider, and an entity does not have to address every one. So SOC 2 does not require a pentest by name, and a pentest remains common evidence for CC4.1 and CC7.1.

A Type 2 report covers how your controls operated over an audit period, so the auditor reads dates. A single pentest in month one shows how the application looked in month one. Two other points of focus under CC4.1 deal with exactly this: weighing the rate of change in the business, and setting the scope and frequency of evaluations by risk. If you ship every week, a yearly test is a weak answer to both.

Rheono runs the test as a standing hunt on the web app and API inside your written scope. On the continuous plans it hunts hard after each release and keeps a quieter watch in between. Starter is one deep hunt a month. Every run is timestamped in your portal, so the evidence spreads across the audit period.

For CC7.1 the useful evidence is the whole loop: the finding, the ticket, the fix, and a retest that shows it closed. Once you connect GitHub, Jira or Linear, Rheono files each finding there as a ticket. It retests the finding after your fix and puts the result in the next signed report. A vulnerability scanner covers part of CC7.1 as well. The pentest adds a working exploit for each finding and a retest that shows the fix holds.

• Scope: the hosts and APIs tested, the test window and the exclusions, as you authorized them in writing
• Method: how the hunt ran, and the verification bar every finding cleared before it shipped
• Findings: each with a CVSS score, a CWE, a working proof of concept, a remediation and its control references
• Retests: a dated result for every finding you fixed
• Signature: Advanced electronic signature (eIDAS, PAdES-B-T) + RFC 3161 timestamp, so anyone can check who issued the report and that it has not changed
• Evidence pack: the signed reports, a findings register and a SHA-256 manifest, exported from your portal

The sample report shows the format with made-up data. Send it to your auditor before the first run and ask whether it meets their bar.

The report is evidence. The opinion belongs to the CPA firm that signs your SOC 2 report, and these questions are theirs:

• whether the tested scope covers the systems inside your audit boundary
• whether the test dates and the retests fall inside the audit period
• whether the way you handled the findings shows the control operating
• what other testing they expect, such as internal networks or cloud configuration, which a web app and API pentest does not cover

Rheono does not audit you and does not write any part of the SOC 2 report.

A pentest report helps the audit once someone maps it to the controls in your program and follows each fix to the end. That is the work of cSquare GRC, our GRC partner. cSquare GRC runs your SOC 2 program, maps the signed report to CC4.1, CC7.1 and the other criteria you carry, tracks remediation until the retest closes it, and gives your auditor a read-only workspace.

Rheono tests and signs. Your auditor decides. The pentest-to-audit page walks through the loop step by step, with a joint scoping call if you want both of us on it.