How Often Should an 11 to 50 Person SaaS Run Vulnerability Scans?

TL;DR

1. PCI DSS is the only framework here with a hard number: internal and external scans at least every three months, plus after significant changes.
2. HIPAA's proposed Security Rule update would require scans at least every six months and a pen test every 12 months. It's still a proposal, so check the status.
3. SOC 2 and ISO 27001 don't set a number. Most auditors are comfortable with quarterly scans backed by a written policy.
4. Internet-facing systems need more scanning than internal ones. For most small SaaS teams, that means continuous or weekly external scans and monthly internal scans.
5. The more often you ship, the more often you should scan.
6. If you deploy daily, scan your code dependencies on every build.

Ask five security people how often to run vulnerability scans and you'll get six answers. One says quarterly. One says continuously. One says "it depends" and then leaves for another meeting.

For a SaaS company with 11 to 50 people, the answer depends on three things: which frameworks you're accountable to, what kind of system you're scanning, and how often that system changes. This post walks through each one and ends with a schedule you can copy into your policy.

What does each framework actually require?

Four frameworks, four different levels of detail. PCI DSS gives you a calendar. ISO 27001 gives you a philosophy.

A few details matter:

1. PCI DSS requires external scans by an Approved Scanning Vendor and, since March 31, 2025, authenticated internal scans. You also have to rescan until high-risk and critical findings are fixed.
2. HIPAA's current rule doesn't set a scan frequency. The proposed update would require vulnerability scanning at least every six months and penetration testing at least once every 12 months. Its final rule has been delayed, so check the status before quoting it to customers.
3. ISO 27001 control 8.8 asks you to get "timely information about technical vulnerabilities" and leaves the schedule to you.

If you have more than one framework, follow the strictest one. Whatever schedule PCI DSS requires will also satisfy SOC 2.

How should scan frequency change by environment?

Different parts of your setup face different levels of risk, so they shouldn't all be scanned on the same schedule.

Here's a sensible split for a small SaaS company:

1. Internet-facing systems (your app, APIs, login pages, VPN): continuous or weekly. These are what attackers see first, and automated tools scan the internet for them around the clock.
2. Cloud configuration (AWS, GCP or Azure settings, storage buckets, IAM): continuous. Most cloud security tools check this all the time at little extra cost, and one misconfigured bucket can undo everything else.
3. Internal servers and containers: monthly. They're harder to reach, but an attacker who gets in through a phishing email will look for them.
4. Code dependencies: on every pull request or build. Tools like Dependabot or Snyk make this nearly free.
5. Staff laptops: continuous patch monitoring through your device management tool. Laptops are where phishing lands, and they're easy to forget.
6. Staging and test environments: the same as production if they hold real customer data. If they don't, monthly is fine.

That last point catches a lot of teams out. "It's only staging" stops being true the day someone copies the production database there to debug a bug.

How should change rate affect scan frequency?

A scan tells you what was true on the day it ran. The more often your systems change, the faster that information goes stale. Match your scans to how fast you move:

Whatever your pace, scan after any significant change. SOC 2's CC7.1 and PCI DSS both call this out. Examples include a new cloud region, a new public endpoint, a major framework upgrade or a new third-party integration.

Write down what "significant" means for you, so nobody has to debate it later. A good rule: if the change needed a design review or touched your network, it counts.

So what schedule should an 11 to 50 person SaaS use?

If you want one schedule that satisfies all four frameworks and doesn't need a dedicated security team, use this:

1. Code dependencies: every pull request or build.
2. Cloud configuration: continuous, through your cloud provider's tools or your compliance platform.
3. External scans of internet-facing systems: weekly or continuous. If you handle card data, add quarterly scans by a PCI Approved Scanning Vendor.
4. Internal and authenticated scans: monthly.
5. After significant changes: a targeted scan within a few days.
6. Penetration test: once a year, and after major changes if you're under PCI DSS.
7. Policy review: once a year, to check the schedule still matches what you actually do.

Most of this runs on its own once it's set up. The work that needs a person is reviewing results, opening tickets and fixing things within your fix-by targets. Plan for a few hours a week for a team your size, more after a big release.

Whatever you choose, write it in your policy and stick to it. An auditor would much rather see quarterly scans that happened every quarter than weekly scans that happened twice.

FAQs

Is quarterly scanning enough for SOC 2?

For most auditors, yes, as long as your policy says quarterly and you have reports for every quarter. Many teams scan monthly anyway because it's easy to automate.

Does PCI DSS apply to us if we use Stripe?

It depends on how you take payments. If card data never touches your systems, your PCI scope may be small. Check with your payment provider and a qualified assessor before you assume you're out of scope.

Is the HIPAA six-month scanning rule in force?

Not yet. It's part of a proposed Security Rule update that hasn't been finalized. Scanning quarterly covers you either way.

What's the difference between authenticated and unauthenticated scans?

An unauthenticated scan looks at a system from the outside. An authenticated scan logs in and checks installed software and settings, so it finds much more. PCI DSS now requires authenticated internal scans.

Do we need a separate tool for each framework?

No. One scanning setup can cover all of them. The difference is in scope, frequency and reporting, such as an Approved Scanning Vendor for PCI external scans.

How long does scanning take to set up?

For a small cloud-based SaaS company, the tools can be running within days. Agreeing on scope, fix-by targets and who reviews the results usually takes longer.

Want hands-on help without the long contract?

Book a free 45-minute gap analysis with CloudSapio. We'll show you where you stand, what it will take to get audit-ready, and how we'd work with you, with terms you can actually read.

Ready to move faster?

Too much to do,

too important to ignore.