What it is
Penetration testing is an authorized attempt to break into a system, network or application to find exploitable weaknesses. It differs from a vulnerability scan. A scan lists known issues. A pen test chains issues together and shows what an attacker could do. The output is a report with findings, evidence and fixes.
SOC 2 is an attestation report from an independent CPA firm. It covers controls at a service organization against the Trust Services Criteria. The Security criterion is always in scope. Availability, processing integrity, confidentiality and privacy are optional.
SOC 2 does not name a required pen test frequency, method or vendor. The Trust Services Criteria are outcome based. Your controls have to show that you monitor for vulnerabilities, evaluate security events and respond to incidents. A pen test is one common way to produce that evidence. It is not a box you can check once and forget.
How it works
Start with scope. List the systems in your SOC 2 boundary: production web app, APIs, admin console, cloud accounts, internal network, and the people and tools that support them. Decide what is out of scope and why. The test should match the systems your report covers. If your SOC 2 scope excludes the corporate office network, say so in the rules of engagement.
Write rules of engagement before anyone runs a tool. Set test dates, source IP addresses, an emergency contact, allowed techniques and prohibited techniques. Get written authorization from the system owner. Decide how the tester handles a serious finding, such as a live credential leak or a path to customer data. Agree on a communication channel and a stop condition.
The tester works through the agreed targets. Common work includes external network testing, web application and API testing, internal network testing, and cloud configuration review. Good reports include an executive summary, the method, each finding with severity, affected assets, reproduction steps, business impact, and a fix. They also include raw evidence such as requests and responses.
After the report, open a ticket for every finding. Assign an owner and a due date based on severity. Fix what you can. Retest the critical and high findings. Save the retest letter, the tickets, the pull requests and the sign off. The auditor wants to see the test, the result, and what you did about it.
Why it matters for a business
A pen test gives your auditor evidence for controls such as vulnerability monitoring, event evaluation and incident response. It also gives you a record that management reviewed the results. That record matters more than the test itself.
Customers ask for pen test summaries in security questionnaires and vendor reviews. A clear report and a clean remediation trail answer those questions faster. They also show that you test what you claim to protect.
A test can find problems before an attacker does. It can show a weak patch process, a missing authentication check, or an overbroad cloud role. Those are useful findings even when no customer asks for a report.
Do not treat the report as a pass or fail grade. SOC 2 is about controls that run over time. One test is a snapshot. Your audit evidence should also include scanning, patch records, access reviews and incident tickets.
Common mistakes
The first mistake is calling a vulnerability scan a penetration test. A scan output is useful, but it does not show exploitation or business impact. Auditors and customers can tell the difference when they read the method section.
The second is a vague scope. A report that says "external test" without listing domains, IP ranges or applications is hard to map to your SOC 2 boundary. It also makes it hard to show that all in scope systems were covered.
The third is no remediation trail. A report full of open high findings with no owner or retest is worse than a smaller report with fixes. Auditors will ask what you did after the test.
The fourth is timing. A test done three days before fieldwork may not show that your process runs over the audit period. It may also leave no time to fix critical issues. Schedule the test early enough to fix and retest. The fifth is using a tester who does not understand your stack. A generic checklist misses cloud identity issues, API authorization flaws and data flows between services.
How to get started
Pick the systems in scope from your SOC 2 report. If the report is not written yet, start with the systems that hold customer data and the accounts that can reach them. Write a one page scope note. Then ask two or three pen test firms for a statement of work that matches it.
Ask for a sample report with the client name removed. Check that it lists the method, the findings, the evidence and the fix advice. Ask how the firm handles critical findings during the test. Ask who will do the work and whether they will provide a retest letter. Book the test with enough time to fix high findings before your audit period closes.
Run the test. Track findings in your normal ticketing system. Add the report, the tickets, the retest letter and the management sign off to your evidence folder. Map that folder to the relevant criteria in your control matrix.
You can handle this internally, hire a specialist pen test firm, or use a readiness service to sort out the SOC 2 side first. The Cloudverg SOC 2 readiness assessment is a fixed price of $7,500 and takes three weeks. It scopes your systems, checks your controls against the Trust Services Criteria and gives you a remediation roadmap.
Frequently asked questions
Does SOC 2 require a penetration test?
SOC 2 does not name a penetration test as a required control. Auditors often ask for one as evidence of vulnerability monitoring and incident response. If your control matrix says you test, you need to do it and keep the report and remediation records.
How often should we run a pen test for SOC 2?
There is no fixed rule in the Trust Services Criteria. Set a schedule that fits your risk assessment. Once a year and after major changes, such as a new public API or a cloud migration, is a workable baseline.
What should we give the auditor after a pen test?
Give the final report, the rules of engagement, the tickets for each finding, the fixes you made, any retest results, and a sign off that management reviewed the findings. If you accepted a risk instead of fixing it, include the approval and the reason.