Does SOC 2 Require Penetration Testing and Vulnerability Scanning?

Does SOC 2 require penetration testing?

SOC 2 does not require penetration testing. The Trust Services Criteria list it in a point of focus of CC4.1, as one example of the separate evaluations an organization can use to check that its controls work. Whether you need a test, and how often, follows from your risk assessment and from the controls you describe in your report.

The AICPA publishes the criteria. Their current form is the 2017 Trust Services Criteria with points of focus revised in 2022, a free document that sits behind an AICPA account. The wording below comes from audit firms that reproduce it. Linford & Co, a CPA firm that performs SOC 2 audits, puts it plainly: "the simple answer is no." CC4.1 asks the organization to run ongoing or separate evaluations to make sure the components of internal control are present and working. Its point of focus lists penetration testing next to independent certifications, such as ISO, and internal audit, as kinds of evaluation management can use. Linford's post dates from June 2021, before the 2022 revision.

The 2022 revision did not turn this into a rule. BARR Advisory, another SOC 2 audit firm, quotes the AICPA on the revised points of focus: they "do not, in any way, alter the criteria in the 2017 TSC."

So the test is optional on paper, and the decision is yours to justify. Linford's advice is that any company offering its services through an interactive public-facing website should strongly consider one, with the frequency and scope set by a thorough risk assessment.

In one case the choice is already made. The audit firm TrustNet describes the system description as your own breakdown of systems, services and controls, reviewed by the auditor. The auditor's opinion then covers whether those controls are designed well (Type I) and operated over time (Type II). If your description or your policy says you run a yearly penetration test, it has become one of your controls, and the auditor will ask for the report.

Does SOC 2 require vulnerability scanning?

SOC 2 does not name vulnerability scanning as a requirement. CC7.1 asks for detection and monitoring procedures that catch configuration changes introducing new vulnerabilities, and your exposure to newly discovered ones. Its point of focus "Conducts Vulnerability Scans" describes scans run periodically and after any significant change, with the deficiencies they find fixed on a timely basis.

Linford & Co reproduces the point of focus: scans should run "on a periodic basis and after any significant change in the environment," and the organization fixes what they find on a timely basis. Its verdict is the same as for penetration testing, no requirement, with a warning attached: "it may be tough for a user organization to accept a clean SOC 2 report" with no reference to scanning.

BARR Advisory's summary of the 2022 revision does not list CC7.1 among the changes: for system operations, it names the handling of confidential information in CC7.3. The change management criterion, CC8.1, did gain points of focus on the "identification, testing, and implementation of software patches." Upgrading a vulnerable dependency is a patch, so the fix side of scanning also falls under change management.

The point of focus names no tool, frequency or scope. You decide what "the environment" covers (your code, its dependencies, containers, cloud configuration, hosts), you write it in your policy, and the auditor holds you to what you wrote.

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is automated: a tool compares your code, dependencies or hosts with known weaknesses and lists what it finds. A penetration test is done by people, who use tools and their own judgment to exploit weaknesses and show what an attacker could reach. For SOC 2, scans support CC7.1, and a penetration test supports CC4.1.

Linford & Co draws the line the same way. A vulnerability assessment "is an automated activity" run with a tool, while a penetration test is performed by one or more people who exploit vulnerabilities and configuration errors with automated tools and their own techniques. For a team that builds software, "scan" covers several kinds of tool: static analysis of the code (SAST), dependency analysis (SCA), secret scanning, and checks on infrastructure files and container images.

How often should you scan for SOC 2?

Scan as often as your policy says, and after every significant change. SOC 2 sets no fixed interval: the CC7.1 point of focus "Conducts Vulnerability Scans" asks for scans on a periodic basis and after any significant change in the environment. A scan on each pull request covers the changes, and a scheduled scan covers the rest.

CC7.1 has two halves, and each calls for its own trigger. The first is configuration changes that introduce vulnerabilities, which you catch by scanning the change itself, in CI, before the merge. The second is exposure to newly discovered vulnerabilities, which you catch by scanning code you have not touched again, on a schedule, because new advisories keep landing on old dependencies. In our scan of 3 November, four of the nine critical dependency findings came from advisories published between July and September 2026. A scan run in June, on exactly the same code, could not have reported them.

Write both triggers in your policy, with a deadline per severity for fixing what the scans find. The auditor can pick any finding from the period and compare it with your deadlines, so pick deadlines you can keep.

What evidence does a SOC 2 auditor ask for?

The auditor asks for records: that scans ran when your policy said, what they covered, what they found, and what happened to each finding, fixed before its deadline or accepted as an exception with a reason and an approver. In a Type II report the opinion covers a whole period, so the records have to cover it too.

A SOC 2 report is an examination performed by a licensed, independent CPA under the AICPA's attestation standards, in the words of the AICPA's own release. For a Type II, the CPA's opinion covers how your controls operated over a period. For vulnerability management, that turns into a short list of questions:

Can open-source scanners produce SOC 2 evidence?

Open-source scanners produce the detection half of SOC 2 evidence. On 3 November 2026 we ran Trivy, Gitleaks and Opengrep on OWASP Juice Shop and got 383 raw findings in four JSON files, in 56 seconds. None of the files names the commit scanned, an owner, a deadline or a status, and the auditor samples exactly that record.

We used OWASP Juice Shop version 20.3.0, released on 11 October 2026. Its README calls it "probably the most modern and sophisticated insecure web application", so the counts below say nothing about a normal codebase: they show the shape of what the tools hand you. Juice Shop ships no lockfile, so for the dependency scan we resolved one on the day from a copy of its package.json, with npm's install scripts turned off. Then we ran four commands:

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Results of four open-source scans of OWASP Juice Shop 20.3.0, run on 3 November 2026. We scanned tag v20.3.0 at commit f189f52, with the Opengrep community rules at commit f1d2b56, default Trivy settings and no tuning. The four runs took 56 seconds of wall time, Trivy's database update included:

Each tool found what it was built to find. Four things still stand between these files and SOC 2 evidence:

1. Duplicates. The five secrets Trivy found are among Gitleaks' 69, at the same file and line. Of Opengrep's 54 Terraform findings, 17 sit on the same line as a Trivy finding and 34 within three lines of one. Without a merge, one problem becomes two tickets and two deadlines.
2. Three severity scales. Trivy grades from critical to low, Opengrep from error to info, and Gitleaks not at all. A policy that says "critical findings fixed within N days" needs one scale, so someone has to map the other two.
3. Coverage. Opengrep scanned 1,306 files and logged 32 parse errors and partial parses, in an errors section you only see if you read the file. An auditor who asks whether the scan covered the code needs that line.
4. The record itself. Trivy's files carry a creation timestamp and the path scanned. Opengrep's carry no timestamp at all. In directory mode, Gitleaks leaves its commit and date fields empty. No file has an owner, a deadline or a status.

The open-source scanners themselves hold up well. Our tests of open-source SAST tools we checked on GitHub and of six open-source secret scanners tested on one seeded repository show that you can cover code and secrets without paying for a scanner. The volume is the other half of the job, and our piece on what turns SAST findings into noise explains why a raw count of 149 code findings is a triage queue, not 149 vulnerabilities.

To turn the files into evidence, you need one queue per repository, where findings from every tool are merged, each one gets an owner and a deadline from your policy, and its history stays: opened, fixed, accepted as an exception. Teams build it with an open-source vulnerability management tool such as DefectDojo, with tickets, or with a platform. CybeDefend Open Source does this part: it runs the scanners you choose, any tool that writes SARIF, and puts what they find in one deduplicated queue, free and on your servers. It launches soon, and the waitlist is open.

What changes when AI agents write the code?

The SOC 2 criteria stay the same when AI agents write the code, and significant changes become more frequent, so the CC7.1 scan has to run on each change, not only on a schedule. The AICPA's proposed 2027 criteria add points of focus on AI, and they would be required only for engagements beginning on or after 31 December 2027.

The share of agent-written code can be large. On 3 November 2026, 482 of the 509 commits merged to the main branch of our own website repository over the previous 90 days carried a Claude Code co-author trailer. At that rate, three things shift for SOC 2:

• The scan does the line-by-line reading. A merge gate that scans each pull request is the check that runs on every change, which is what CC7.1 and CC8.1 ask. Our article on the security checks for an AI agent's pull request goes through that gate.
• Dependencies arrive with features. An agent that adds a package adds an entry for the scheduled scan to watch, and every upgrade it makes is a patch under CC8.1.
• Green tests prove less. An agent often writes a feature and its tests in the same session. Its tests check what it meant to build, so a rule it missed in the code can be missing from the tests too, and CI stays green. A scanner run from CI is a check the agent did not write.

The criteria themselves are moving. On 28 October 2026 the AICPA put out for comment an exposure draft of new SOC 2 Trust Services Criteria. Its release lists new points of focus on "AI governance, model monitoring, prompt manipulation, data poisoning," the transparency of AI-generated outputs, training data management and automated decision-making. Comments are open until 15 January 2027. If approved, the new criteria would apply to engagements beginning on or after 31 December 2027, with early adoption permitted. The release does not say whether these points of focus reach coding agents, and the draft itself needs an AICPA account, so we have not read it. Until the new criteria are final and in force, your audit uses the 2017 criteria with the 2022 points of focus.

What should you have ready before the SOC 2 audit?

Have a written vulnerability management policy, scans that run on a schedule and on every change, one record per finding with an owner, a deadline and its outcome, approved exceptions, and a penetration test report if your risk assessment calls for one, all of it covering the whole audit period.

1. The policy says what, when and how fast. The scope of scanning, the schedule, the triggers, a deadline per severity, and who may approve an exception.
2. Every change is scanned. Code, dependencies, secrets and infrastructure files on each pull request, whether a person or an agent opened it, behind a gate that refuses a critical finding.
3. The schedule catches new advisories. A nightly or weekly scan of the main branch and of the images you run, for the vulnerabilities published after the code was written.
4. One finding, one record. Merged across tools, on one severity scale, with an owner, a deadline, a status and its history.
5. Exceptions are written down. The scope, the reason, the approver and the expiry date.
6. The penetration test is planned. A scope drawn from your risk assessment, the report kept, the serious findings fixed and checked again.
7. The report covers the period. One document built from the records, not a spreadsheet assembled the week before the auditor arrives.

Scan on each changeOne record per findingOwner and deadlineFixed, or exception approvedIn the period's report

Points 2, 5 and 7 are what CybeDefend's AppSec platform does. It scans each repository for code weaknesses (SAST), dependencies (SCA), secrets, infrastructure as code, containers and CI/CD pipelines. A security policy written as code blocks the merge on a critical finding and lets lower risk ship with a warning, and an exception is scoped to a path, dated, justified and approved by name, each one leaving an audit line. Security reports map the findings to the OWASP Top 10 and the CWE Top 25, by organization, team or project, exported in PDF for the auditor or in JSON for a GRC tool. We are going through the same exercise ourselves: CybeDefend's SOC 2 Type II audit is in progress. If you are preparing yours with a team that codes with agents, we can walk through it with you.

Frequently asked questions

Does SOC 2 Type 2 require penetration testing?

No. Type I and Type II reports use the same criteria, and none of them requires a penetration test. A Type II tests that your controls operated over a period, so if your policy includes a yearly penetration test, the auditor checks that it took place within the period and that its findings were handled.

How often should you run a penetration test for SOC 2?

The criteria set no interval. Your risk assessment and your policy set it, and the auditor checks that you kept to what you wrote. A big change in what your system exposes, such as a new public API or a new product, is a good reason to test again before the next planned date.

Is a vulnerability scan enough for SOC 2?

For CC7.1, a scanning program is what auditors expect to see, with records of how each finding was handled. A scan does not replace the evaluation of your controls under CC4.1, which can be a penetration test, an internal audit or an independent certification.

Does SOC 2 require SAST or code scanning?

No criterion names SAST. CC7.1's point of focus covers vulnerabilities and misconfigurations in your environment, and CC8.1 asks that changes to software be tested and approved before they are implemented. If you build software, scanning the code and its dependencies on each change is the simplest way to show both.

Can you use open-source scanners for SOC 2?

Yes. The criteria name no tool, and the auditor checks that scans ran as your policy says and that findings were handled. Open-source scanners work if you keep the record around them: the dates, the commit scanned, findings merged across tools, owners, deadlines and outcomes.

What is SOC 2 CC7.1?

CC7.1 is the common criterion on detection and monitoring. It asks an organization to use procedures that identify configuration changes introducing new vulnerabilities and its exposure to newly discovered vulnerabilities. One of its points of focus is conducting vulnerability scans periodically and after significant changes.

What is SOC 2 CC4.1?

CC4.1 is the common criterion on monitoring activities. It asks an organization to run ongoing or separate evaluations to confirm that the components of internal control are present and functioning. Its point of focus names penetration testing, independent certifications such as ISO, and internal audit as examples of those evaluations.

What changes with the proposed 2027 SOC 2 criteria?

The AICPA released an exposure draft on 28 October 2026 that restructures parts of the criteria and adds points of focus on AI, including AI governance, prompt manipulation, data poisoning and the transparency of AI-generated outputs. Comments close on 15 January 2027. If approved, the criteria would be required for engagements beginning on or after 31 December 2027, with early adoption permitted.