Does SOC 2 require a penetration test? What the criteria say
No: the SOC 2 Trust Services Criteria do not require a penetration test, but CC4.1 names one as an example of a monitoring evaluation, so your auditor may ask for one and a customer contract can make it mandatory.
That answer comes from the criteria text and from two CPA firms that audit SOC 2 reports. Below you will find the criteria that a pentest can support, the evidence to keep, how often to test, and how Type I and Type II differ. Every quote has a source in the source list, with the date we read it.
The criteria that mention testing
The criteria come from the AICPA, the US accountancy body that sets the SOC 2 standard. Each criterion has "points of focus". The AICPA says of them: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." The word "penetration" appears once in the whole document we read, in one point of focus under CC4.1. Nothing in the text sets a test interval.
The third column is our reading of what a pentest gives you for that line. It is not an auditor statement.
| Criterion | Quoted text (AICPA, 2017 criteria) | Evidence a pentest gives |
|---|---|---|
| CC3.2 | "The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed." | A list of weaknesses an attacker could use, each with a severity. You can feed it into your risk register. |
| CC4.1 | "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." | A pentest is a separate evaluation. The report shows whether your access controls and session handling worked when someone attacked them. |
| CC4.1 point of focus: types of evaluation | "Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments." | The one place the criteria name a penetration test. It is an example in a list. |
| CC4.1 point of focus: scope and frequency | "Management varies the scope and frequency of separate evaluations depending on risk." | A written scope and a reason for the test date. You pick both. |
| CC4.1 point of focus: objectivity | "Separate evaluations are performed periodically to provide objective feedback." | A tester outside the team that built the system. The report names who did the work. |
| CC4.2 | "The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action." | Findings with an owner for each fix. The point of focus under CC4.2 reads: "Management tracks whether deficiencies are remedied on a timely basis." |
| CC7.1 | "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." | A pentest finds weaknesses at one point in time. CC7.1 asks for a repeating procedure, so a pentest supports it and does not replace it. |
| CC7.1 point of focus: scans | "The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment." | This line names scans, not pentests. A scan finds known issues. In our scanner test, the best of six setups found 3 of 27 known flaws. |
Which version did we read? The AICPA revised the points of focus in 2022. The AICPA download for that version needs a free account, and we did not create one. We read the AICPA-hosted file TSP Section 100, 2017 Trust Services Criteria (Red-lined Version, includes March 2020 updates), through an Internet Archive copy dated 17 January 2022, on 12 November 2026. The wording above is from that file.
The 2022 version changed the CC4.1 point of focus on types of evaluation. Linford & Company, a CPA firm, quotes the new wording: management "uses a variety of ongoing and separate risk and control evaluations" and these "may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessments, penetration testing, and third-party assessments." Penetration testing is still one item in a list. The CC4.1 criterion text on the Linford page matches the 2017 text above. We could not check the other rows against the 2022 file.
What CPA firms say
Two CPA practices that audit SOC 2 reports answer the question in public. We name them so you can read the full pages.
- Linford & Company LLP, in a page by partner Lois Colby (16 June 2021): "the performance of a vulnerability scan or penetration test, whether conducted as an internal or external facing activity is not required in order to meet the Trust Services Criteria for a SOC 2 report."
- Linford again, in a page by partner Mark Larson (23 June 2021): "Does SOC 2 Require Penetration Testing? Again, the simple answer is no. Is it a good idea? Absolutely." The same page says "The frequency and scope should be determined based on a thorough risk assessment."
- MJD Advisors, a CPA firm that focuses on SOC reports, in a page by Mike DeKock, CPA (republished by the Cloud Security Alliance on 2 February 2024): "there are no explicit requirements for penetration testing (or any controls) within a SOC 2 report." The page lists one case that changes the answer: "Do you have any customer contracts requiring a penetration test? If yes, then it's required."
A compliance software vendor, Secureframe, adds a point about auditors in its support article (13 July 2026): "The pen test requirement may vary from auditor to auditor." Secureframe is not an audit firm. The sentence is consistent with the two firms above: ask your auditor before you schedule the test.
Evidence checklist for your auditor
The list below is ours. It is built from the criteria lines in the table and from Linford's description of what a pentest report holds. Your auditor decides what they accept, so send them this list before the test.
- Scope. List the applications, APIs, environments and accounts that were tested, and what was left out. Match the list to the system in your SOC 2 description.
- Dates. Record the first and last day of testing and the date of the report. Linford notes that "a penetration test is a point in time test." For a Type II report, see the section on Type I and Type II below.
- Tester. Record the firm, the people who did the work and how they relate to your team. The criteria ask for "objective feedback" and for evaluators who have "sufficient knowledge to understand what is being evaluated." Linford adds a rule for monitoring in general: "A person cannot monitor or check their own work."
- Findings. The report should detail, in Linford's words, "activity attempted, any penetration obtained, vulnerabilities identified, and risk level of each vulnerability." Proof steps for each finding let your engineer reproduce it.
- Fix tracking. Keep one ticket per finding with an owner and a due date. This is the evidence for "Management tracks whether deficiencies are remedied on a timely basis."
- Retest. Keep a note for each finding that was fixed, with the date and the result. None of the sources we read says a retest is required. A retest note is the simplest proof that a fix worked.
Our sample report shows one report format: a cover with the target and a count of findings by severity, a summary in plain words, and one page per finding with Risk, Where, Cause and Fix rows and proof-of-concept steps. The client in it is fictional.
How often to test
The criteria text we read sets no interval for a penetration test. The point of focus on scope and frequency leaves the choice to you, based on risk. Auditors and vendors give a floor:
- Linford (page updated 11 August 2026): "At a minimum, annually for compliance purposes. In practice, testing should align more closely with how often your environment changes."
- Secureframe (13 July 2026) lists "Perform a third-party penetration (pen) test at least annually from a reputable vendor or firm" as one way to meet the scanning control.
Plan on one test a year, and add one after a large change such as a new login flow, a new role model or a new integration. Say that in your policy.
Type I and Type II
The AICPA text defines the two reports. A Type II report covers controls "throughout a specified period" and includes "an opinion on the operating effectiveness of controls." A Type I report "does not contain an opinion on the operating effectiveness of controls." Linford says of Type II reports: "Most reports cover a 12 month period, but can be as short as six months."
| Report | What the auditor opines on | Where the pentest date should fall (Secureframe) |
|---|---|---|
| Type I | Design of controls at one date | "Pen test can have taken place anytime in the prior 12 months from the report date" |
| Type II | Design and operating effectiveness over a period | "Pen test has to occur during the audit period" |
The timing column is Secureframe's guidance, and Secureframe says it varies with the auditor. Pick your auditor first, then book the test.
FAQ
Does SOC 2 require a penetration test?
No. The criteria name a penetration test only as an example, and the AICPA says its points of focus do not all have to be addressed. Two CPA firms say the same in public. A customer contract can still require one.
Can a vulnerability scan replace a penetration test?
The CC7.1 point of focus names scans, and Linford says neither a scan nor a pentest is required. Your auditor decides what satisfies CC4.1 for you. A scan and a pentest find different things: in our scanner test, six setups together found 4 of 27 known flaws and missed 21.
How often should we test?
The criteria set no interval. Linford answers: "At a minimum, annually for compliance purposes." It adds that testing should follow how often your environment changes.
Must a third party run the test?
The criteria text does not use the words "third party" for a pentest. It asks for objective feedback and for evaluators with enough knowledge. Secureframe recommends a third-party test. Linford says a person cannot check their own work. A tester outside your team meets all three.
Will your report satisfy my auditor?
Our report states the scope, method, findings and retest results. Your auditor decides what evidence they accept, so ask them first. We do not certify anything.
Next step
Open the sample report to see the format. To scope a test, read about penetration testing or web application penetration testing. For how providers charge, see penetration testing cost in 2026. For what a scanner can and cannot cover, see vulnerability scanner vs penetration test.
Sources and dates checked
We read all pages on 12 November 2026. A fetch of the AICPA file at its original address returned a web page and not the PDF, and the current AICPA download page needs a login, so we used the Internet Archive copy of the AICPA file for criteria text. Everything about the 2022 wording is second-hand, from Linford.
- AICPA, "TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, Red-lined Version, includes March 2020 updates": Internet Archive copy of 17 January 2022. Read 12 November 2026.
- AICPA download page for the 2022 revised version (free account needed, not opened): AICPA download page. Checked 12 November 2026.
- Linford & Company LLP, "SOC 2 Criteria for Monitoring Activities" (25 January 2023), 2022 wording of the CC4.1 point of focus: Linford, monitoring activities. Read 12 November 2026.
- Linford & Company LLP, "Penetration Testing for SOC 2 Reports: What is a Pentest?" (16 June 2021): Linford, what is a pentest. Read 12 November 2026.
- Linford & Company LLP, "Vulnerability Assessment vs Penetration Testing for SOC 2" (23 June 2021): Linford, assessment vs pentest. Read 12 November 2026.
- Linford & Company LLP, "The 351-Day Risk Window: Why Annual Pentests Fail" (22 April 2026, updated 11 August 2026): Linford, annual pentests. Read 12 November 2026.
- Linford & Company LLP, "What Period Is Covered In A Type II SOC Examination?" (10 January 2017): Linford, Type II period. Read 12 November 2026.
- MJD Advisors (Mike DeKock, CPA), "SOC 2 Reports and Penetration Tests", republished by the Cloud Security Alliance on 2 February 2024: Cloud Security Alliance copy. Read 12 November 2026.
- Secureframe (compliance software vendor, not an audit firm), "Pen Testing Requirements" (13 July 2026): Secureframe support article. Read 12 November 2026.
The same list, with notes, is in the evidence file.