Is a penetration test required for SOC 2?
Short answer: the Trust Services Criteria never say "you must do a penetration test". A SOC 2 audit tests your controls against criteria that describe outcomes, and none of the Common Criteria (CC1 to CC9) names a pen test as a required control.
Yet most companies get one, because two criteria are hard to meet convincingly without independent testing:
- CC4.1 asks you to run ongoing and separate evaluations to check that your controls are present and working. The points of focus that accompany it list penetration testing as one example of a separate evaluation.
- CC7.1 asks you to detect vulnerabilities and configuration weaknesses in your systems. Automated scanning covers part of this, and a pen test covers the part scanners can't reach.
Points of focus are guidance, not requirements, so in principle you can meet both criteria in other ways. In practice, many auditors expect a SOC 2 penetration test for a software company, and many enterprise customers ask for one in their security reviews whether or not your report mentions it. Your auditor decides what evidence satisfies each criterion, so ask them early. If they say a pen test is expected, plan for one every year.
Tip: If your own policy says you run an annual penetration test, the auditor will test that you did. A Vulnerability Management Policy that promises a yearly test turns the pen test from "nice to have" into a control you must evidence.
Penetration testing for SOC 2 vs a vulnerability scan
The two are often confused, and you probably need both.
| Vulnerability scan | Penetration test | |
|---|---|---|
| Who does it | An automated tool | A skilled person, usually outside the team |
| How often | Continuously, or at least monthly | Commonly once a year, and after major changes |
| What it finds | Known vulnerabilities, missing patches, common misconfigurations | Logic flaws, broken authorization, chained weaknesses, what an attacker could actually reach |
| Output | A list of findings to triage | A report with exploited paths, severities and recommendations |
A scanner tells you a library is out of date. A tester tells you that one customer can read another customer's invoices by changing a number in a URL. Scans give you breadth between tests; the pen test gives you depth once a year.
Scoping the test
Scope decides most of the value. Start from your SOC 2 system description: the services, infrastructure and data your report covers. The test should cover what the report covers; a test of your marketing site does little for a report about your product.
Typical areas to consider:
- The customer-facing application. Authentication, session handling, authorization between users and between tenants, input handling and business logic. This is usually the most important part for a software company.
- APIs. Public and partner APIs, and the internal APIs your front end calls, which often have weaker checks than the user interface suggests.
- Cloud configuration. Identity and access management, storage permissions, network exposure and secrets handling in your cloud accounts.
- External network perimeter. Everything reachable from the internet: hosts, ports, admin panels, forgotten test environments.
- Internal network. Relevant if you run offices or on-premises infrastructure in scope. Many cloud-only startups leave it out.
Write down what you deliberately exclude and why. "Mobile app excluded: not part of the system description" is a sentence your auditor and your customers will both understand. An unexplained gap invites questions.
Give the tester credentials for several user roles and at least two test tenants, so they can try to cross between them. That usually finds far more than a test that starts with nothing.
Choosing a tester
The test has to be credible to your auditor and to customers who read the summary. Questions worth asking before you sign:
- Independence. Is the tester independent of the people who build and run the systems? An internal security engineer testing their own work is weak evidence of a separate evaluation.
- Methodology. Do they follow a recognized, documented methodology for web applications, APIs and cloud, and will they describe it in the report?
- Manual effort. How much of the engagement is hands-on testing rather than a scanner run with a cover page? Ask for a sample report.
- Retest included. Is a retest of fixed findings part of the price, and within what time window?
- Deliverables. Will you get a full technical report and a short summary letter you can share with customers?
- Data handling. How do they store your report and any data they see, and when do they delete it?
Timing the test within your audit period
For a Type 2 report, the test should fall inside the observation period, so the auditor can see that it happened and what you did about the findings. Running it early leaves time to fix and retest before the period ends; a test in the last week leaves open findings with no evidence of remediation. If you are still deciding between report types, our Type 1 vs Type 2 comparison explains how the period works.
For a Type 1 report, the test should be recent as of the report date. Your auditor decides what "recent" means for you.
Pen tests take planning. Good testers are often booked weeks ahead, and you need time to agree scope, set up test accounts and brief the team. Work backwards from the date you want the report, and start talking to testers a couple of months before that. Put the test on your compliance calendar so it doesn't collide with audit fieldwork.
Preparing for the test
Agree the rules of engagement in writing before testing starts. They protect both sides and are evidence in their own right. Cover:
- The test window: dates, hours and time zone.
- The targets in scope, by hostname, IP range or account, and what is off-limits.
- Prohibited techniques, such as denial of service.
- Source IP addresses the testers will use, so you can recognize their traffic.
- Contacts on both sides, including who to call if something breaks or the tester finds a critical issue mid-test.
Then choose the environment. Production gives the most realistic result but carries some risk. A staging environment that truly matches production is a reasonable alternative. Record the choice in the scope.
Create dedicated test accounts for every role in scope, with no real customer data, and disable them when the test ends. Tell the people who need to know (on-call engineers, support, your hosting provider if its terms require notice), and keep monitoring on. Whether your alerts fire during the test is useful information about CC7 detection too.
What the report should contain
A useful penetration test report usually includes:
- The scope, test dates, approach and the methodology followed.
- An executive summary of the overall risk in plain language.
- Each finding with a severity rating, the affected asset, how it was found, evidence such as requests or screenshots, and a recommendation.
- What was tested and found sound, not only what failed.
- The names or firm of the testers and the date the report was issued.
Ask the tester to correct factual errors in the draft, but don't ask them to downgrade a severity without a good technical reason.
Remediation and retesting
The report is where the control starts, not where it ends. An auditor looking at CC4.1 also wants to see deficiencies communicated and corrected. For each finding:
- Create a ticket with an owner and a target date based on severity. Use the remediation timeframes in your own vulnerability management policy, and stick to them.
- Fix it, and link the fix (the change or release) to the ticket.
- Ask the tester to retest critical and high findings, and get the retest result in writing.
- For anything you decide not to fix, record the reason, any compensating control, and who accepted the risk.
A pen test that keeps finding the same class of bug is telling you something about your development process, so feed significant findings into your risk register.
Evidence to keep for the audit
Keep one record per test, in one place:
- The agreed scope and rules of engagement.
- The final report.
- The list of findings with severities, and the remediation ticket for each.
- Retest results, and any accepted risks with their approval.
- A sign-off that the test and its follow-up are complete.
The auditor decides the exact format and may sample tickets. For habits that make this easy, see SOC 2 evidence collection.
Sharing results with customers
Prospects will ask for your pen test results. You rarely need to hand over the full report, which is effectively a map of your weaknesses. Common practice is to share one of these instead, often under a non-disclosure agreement:
- A summary or attestation letter from the tester, stating the scope, dates and that findings were reported.
- The executive summary, plus a statement of remediation status for critical and high findings.
How much you share is a business decision, but never describe findings as fixed before the retest confirms it.
Scheduling the annual pen test in Confluence
If your compliance program lives in Confluence, Compliance in a Box provisions Penetration Test as one of its SOC 2 recurring activities: annual, in the Security category, and mapped to CC4.1 and CC7.1 in the app's controls matrix. In practice:
- Long notice, set per activity. Each annual period follows your fiscal year and is due on its last day. The evidence page opens a set number of days before the due date: 14 by default, and a Compliance Admin can set anywhere from 0 to 90 days for this activity alone with Edit schedule. The guide recommends more notice for work that takes a long time to organize, such as a penetration test. The owner is reminded when the page opens, and again as the due date nears.
- An evidence page per year. The page is created under the Penetration Test activity page with a checklist and a heading for the report, the findings and the remediation tickets. You attach the report and fill in the rest. The app never writes to it after creating it.
- An owner and approvers. Assign them under Settings, Owners & approvers. The owner completes the page and selects Submit for approval; every approver must approve. The approval is bound to the exact page version submitted, so editing the page before approval cancels the submission. Approving evidence for an activity you own is flagged as a self-approval.
- A visible record. The generated Activity Completion Report links each year to the approved evidence page version, and an overdue test shows as a gap against CC4.1 and CC7.1 in the controls matrix.
Important: Anyone who can view the compliance space can read an evidence page; only the owner and Compliance Admins can edit it. Decide whether the full report belongs there or only the summary, with the full report kept somewhere more restricted.
The SOC 2 content reference lists every activity with its cadence and evidence checklist, and the SOC 2 readiness checklist shows where the pen test fits in your wider preparation.
FAQ
Is a pen test required for SOC 2?
Not by name. The criteria don't require one, but a penetration test is a common way to evidence CC4.1 and CC7.1, and many auditors and customers expect it. Your auditor makes the call for your report.
How often should we do a SOC 2 penetration test?
Once a year is the common choice, plus after major changes to the product or its architecture. Whatever you write in your policy is what the auditor will test against.
Can our own engineers run the pen test?
Internal testing is valuable, but it is weak evidence of an independent evaluation. Most teams use an outside tester for the annual test.
What if the test finds critical issues just before the audit?
Fix them, retest, and keep the evidence. A finding that was found, tracked and fixed shows the control working. Hiding it, or skipping the test, is the bigger problem.