What does SOC 2 say about vulnerability scanning?

TL;DR

1. SOC 2 never says "you must scan monthly." In practice, though, you'll struggle to meet CC7.1 without regular vulnerability scans.
2. CC7.1 covers finding vulnerabilities, both from configuration changes and from newly discovered flaws. Its point of focus mentions scanning "periodically and after any significant change."
3. CC4.1 covers checking that your controls work. Penetration tests are one common way to meet it.
4. "Regular" usually means at least quarterly external and internal scans, more often for critical systems, plus a scan after any big change.
5. Auditors want proof: a written policy, scan reports from the whole audit period, and tickets showing you fixed what the scans found within the timelines your policy set.

Somewhere in your SOC 2 project, someone asks, "How often do we need to run vulnerability scans?" Then everyone goes quiet, because the honest answer is that SOC 2 doesn't give a number.

The Trust Services Criteria cover every kind of company, from a five-person startup to a bank. So they say things like "periodic" and "timely" and leave the details to you and your auditor. This post translates those criteria into a concrete scanning schedule you can include in a policy.

Does SOC 2 actually require vulnerability scanning?

Not in so many words, but you'll almost certainly need it.

SOC 2 is built on criteria, which describe outcomes. You won't find a line that says "thou shalt run Nessus on the first Monday of each month." You decide which controls meet each criterion, and the auditor tests whether they work.

The catch is that CC7.1 asks you to find vulnerabilities in your systems. Risk3sixty, an audit and advisory firm, puts it bluntly: vulnerability scans are needed to meet CC7.1, and audit firms can decline to issue a report without them. You could try to meet CC7.1 by having someone read every security advisory and check it against your systems by hand. You'd also need a very patient person.

What does CC7.1 actually say?

CC7.1 sits in the System Operations section of the Trust Services Criteria. The criterion says 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.

In plain English, that covers two jobs:

1. Notice when your own changes create a weakness. Someone opens a port, turns off encryption on a storage bucket or deploys an old library.
2. Notice when the world finds a weakness in something you use. A new CVE drops for your web server, database or a package in your code.

The AICPA adds "points of focus" under each criterion. These are examples of what good looks like, and auditors read them closely. One of CC7.1's points of focus says the entity "conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis", and after any significant change in the environment, and fixes what it finds in a timely way.

That sentence is the closest SOC 2 comes to a scanning requirement. It contains three words that cause most of the arguments: "periodic," "significant" and "timely."

Where does CC4.1 come in?

CC4.1 sits in the Monitoring Activities section and comes from COSO Principle 16. It says the entity "selects, develops, and performs ongoing and/or separate evaluations" to check that its controls are present and working.

CC7.1 asks whether you look for vulnerabilities. CC4.1 asks whether you check that your security controls work at all. Its points of focus list different kinds of evaluation, including penetration testing, internal audits and independent certifications.

For vulnerability management, CC4.1 matters in two ways:

1. Your scanning program is itself an ongoing evaluation. Running scans, reviewing the results and tracking fixes shows you're monitoring your controls.
2. A penetration test is a common separate evaluation. Risk3sixty notes a pen test isn't strictly required for CC4.1 if you do another regular security assessment. Many enterprise buyers ask for a yearly pen test summary anyway, so most SaaS companies do one.

A useful way to tell them apart: a scanner checks whether doors are unlocked. A pen tester tries the handles and climbs in through the window you forgot about.

What does "regular" mean in practice?

SOC 2 leaves it to you, so your policy defines it and the auditor holds you to it. Risk3sixty's reading of CC7.1 is scans at least quarterly, plus after significant changes. Here's what most small SaaS teams settle on:

1. External scans of internet-facing systems: at least quarterly. Monthly is easy to automate and looks better to buyers.
2. Internal and cloud scans: at least quarterly. Continuous scanning is common if your cloud provider or compliance platform includes it.
3. Code and dependency scans: on every pull request or build, since tools like Dependabot or Snyk make this nearly free.
4. After a significant change: a new product, a new cloud region, a major infrastructure change or a big release. Write down what counts as "significant" so you're not arguing about it during the audit.
5. A penetration test: once a year, covering your main application.

Then there's "timely," which means fix-by dates for each severity level. SOC 2 doesn't set these either. Linford & Co. says to set them in your policy based on your own risk appetite. A common starting point looks like this:

These are example targets, not SOC 2 rules. Pick numbers you can actually hit. An auditor would much rather see you meet a 30-day target every time than miss a 7-day target half the time.

What evidence do auditors ask for?

For a Type II audit, the auditor wants proof that your scanning process ran the whole observation period, rather than the week before they arrived. Expect requests like these:

1. A vulnerability management policy. It sets out scan frequency, what's in scope, who reviews results, severity ratings and fix-by targets.
2. An asset inventory. The auditor checks that your scans actually cover the systems in it. Scanning 3 servers when you run 30 is a finding.
3. Scan reports from across the period. These are usually dated reports or exports for each quarter or month your policy promises. The auditor will often sample a few.
4. Tickets for the findings. Each critical and high finding should link to a ticket showing who fixed it and when, so the auditor can check it against your fix-by targets.
5. Exceptions and accepted risks. If you decided not to fix something, they'll want a written reason and an approver's name.
6. Pen test report and follow-up. The summary, plus proof you fixed the important findings.
7. Change-triggered scans. For any major change during the period, they'll want the scan that followed it.

The pattern is simple: the policy makes a promise, and the evidence shows you kept it. Most findings happen when the two don't match.

What are the most common mistakes?

These are the ones that turn up in audit reports again and again:

1. Promising more than you can deliver. The policy says weekly scans and 7-day fixes for criticals. Reality is a scan whenever someone remembers. Write the policy around what you actually do, then improve it.
2. Running scans that nobody reads. Automated scans with no review are only half a control. Keep a record that someone looked at the results and made decisions.
3. Scanning the wrong things. The scan covers last year's servers but misses the new Kubernetes cluster. Check your scan scope against your asset inventory every quarter.
4. Missing gaps in the record. One missed quarter in a 12-month Type II window is enough for an exception.
5. Leaving old findings open. A medium-severity finding open for 400 days, with no risk acceptance, raises questions about the whole program.
6. Forgetting what was promised in the sales cycle. If your security questionnaire said "we scan continuously," make sure that's still true.

FAQs

Which SOC 2 criteria cover vulnerability scanning?

Mainly CC7.1, which covers finding vulnerabilities and misconfigurations. CC4.1 covers evaluating whether your controls work, and is where penetration testing usually fits.

How often does SOC 2 require vulnerability scans?

SOC 2 doesn't set a number. CC7.1's point of focus says "periodic" and "after any significant change." Most auditors are comfortable with at least quarterly scans when they're backed by a written policy and consistent evidence.

Do we need both internal and external scans?

Most auditors expect both. External scans cover what attackers can see from the internet. Internal and cloud scans cover what they could reach once inside.

Is a penetration test required for SOC 2?

The criteria don't explicitly require one. Many companies use a yearly pen test to support CC4.1, and buyers often ask for the summary.

Does dependency scanning count?

It helps. Tools that flag vulnerable libraries in your code support CC7.1. Most auditors expect infrastructure scanning as well.

What if a scan finds something we can't fix in time?

Record it as an exception. Write down the reason and any measures that reduce the risk, have the right person approve it, and set a new date. An approved exception is fine. An unexplained overdue finding is not.

Want someone to do this with you?

Book a free 45-minute gap analysis with CloudSapio. We'll check your scan coverage, cadence and fix-by targets against what auditors look for under CC7.1 and CC4.1, and tell you what to change before your observation window starts.

Book my free gap analysis

Ready to move faster?

Too much to do,

too important to ignore.