Vulnerability Scanning Frequency: How Often Should You Scan?

Short answer: Scan internet-facing systems at least monthly and internal systems at least quarterly, and rescan after every significant change. PCI DSS requires internal and external scans at least once every three months. SOC 2, ISO 27001 and the current HIPAA Security Rule set no fixed number, so your own documented policy becomes the standard auditors test you against.

Related guides:

• Vulnerability scanning: what it is and how it works
• Vulnerability scanning tools
• Penetration testing vs vulnerability scanning

Key takeaways

• PCI DSS is the main compliance framework that sets a hard number: internal and external scans at least once every three months, with external scans run by an Approved Scanning Vendor (ASV), plus scans after significant changes.
• CIS Controls v8 gives the most useful benchmark for everyone else: external assets monthly or more often, internal assets quarterly or more often.
• SOC 2, ISO 27001 and HIPAA ask for a working vulnerability process, not a calendar. Pick a frequency, write it down, and prove you followed it.
• The HIPAA Security Rule update that would require scans at least every six months is still a proposed rule as of October 2026.
• Frequency is only half the story. Auditors also look at how quickly you remediate and whether you rescan to confirm fixes.

What does each framework say about scan frequency?

Only PCI DSS, CIS Controls and FedRAMP put a number on it; the others leave the cadence to you. Here is what each source actually says, as of October 2026.

Framework	What it says about scan frequency	Source
PCI DSS v4.0.1, Req 11.3.1 (internal)	At least once every three months, and after any significant change	PCI SSC FAQ 1152
PCI DSS v4.0.1, Req 11.3.2 (external)	At least once every three months by a PCI SSC Approved Scanning Vendor, and after any significant change	PCI SSC ASV resource guide
SOC 2 (TSC CC7.1)	No fixed frequency. Point of focus: scans "on a periodic basis and after any significant change"	AICPA Trust Services Criteria
ISO/IEC 27001:2022, Annex A 8.8	No fixed frequency. Requires managing technical vulnerabilities based on risk	ISO/IEC 27001:2022
HIPAA Security Rule (current)	No scan frequency. Requires risk analysis and "periodic" technical evaluation	45 CFR 164.308
HIPAA Security Rule NPRM (proposed)	Would require scanning at least every six months and penetration testing at least every 12 months	HHS NPRM fact sheet
CIS Controls v8, Safeguard 7.5	Internal assets: quarterly or more frequently, authenticated and unauthenticated	CIS Control 7 assessment spec
CIS Controls v8, Safeguard 7.6	Externally exposed assets: monthly or more frequently	CIS Control 7 assessment spec
FedRAMP Rev5 continuous monitoring	OS, web applications and databases scanned at least monthly; container images scanned before deployment and within a 30-day window	FedRAMP vulnerability scanning playbook

A few details worth knowing:

• PCI DSS wants four passing quarters, not four scans. The PCI SSC is explicit that if you do not have four passing scans for the last 12 months, because scans were missed, incomplete or vulnerabilities carried over from one period to the next, you have not met the requirement (PCI SSC FAQ 1152). Our PCI DSS vulnerability scans guide covers ASV mechanics.
• FedRAMP is mid-transition. FedRAMP's 2026 Vulnerability Detection and Response rules set detection timeframes by certification class (for example, at least every 14 days for drift-prone resources in one class) and become required on December 7, 2026. If you sell to US federal agencies, check which rule set applies to your authorization.
• The HIPAA update is not law yet. HHS published the NPRM in the Federal Register on January 6, 2025. The most recent Unified Agenda entry lists it under long-term actions with a final action date of July 2027. HHS states that the current Security Rule remains in effect while rulemaking continues (HHS).

What if your framework has no fixed frequency?

Then you set the frequency in policy, and the auditor tests whether you followed it. This is how SOC 2, ISO 27001 and HIPAA work in practice.

SOC 2 criterion CC7.1 asks that you use "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" (AICPA TSC). In a Type 2 examination, the auditor samples your scan evidence across the review period and compares it to what your policy promises. If your policy says monthly and you have a three-month gap, that is an exception, even though SOC 2 itself never said monthly.

ISO/IEC 27001:2022 control 8.8 works the same way: you obtain information about technical vulnerabilities, evaluate your exposure and take appropriate measures. The certification auditor checks that your chosen cadence is justified by your risk assessment and actually operating.

HIPAA's current rule requires an accurate and thorough risk analysis and a periodic technical evaluation (45 CFR 164.308). Regular scanning is one of the most practical ways to feed both.

Three practical rules for policy-driven frameworks:

1. Do not promise more than you can deliver. A written "weekly" schedule you miss twice a quarter is worse than an honest "monthly" schedule you hit every time.
2. Borrow a recognised benchmark. Anchoring your policy to CIS Safeguards 7.5 and 7.6 gives an auditor a reason to accept your choice.
3. Plan ahead for HIPAA. If you handle ePHI, a schedule that already meets or beats the proposed six-month cadence means a final rule would not force a rewrite. See our vulnerability management policy guide for wording.

How often should you scan each type of asset?

Scan what attackers can reach most often, and scan what changes most often at the point of change. The schedule below is an example built from the CIS benchmarks, not a regulatory requirement.

Asset type	Example frequency	Why
Internet-facing hosts, APIs and web apps	Weekly to monthly, plus quarterly ASV scans if in PCI scope	Directly reachable; CIS 7.6 sets monthly as the floor
Cloud workloads and configuration	Daily or continuous via cloud-native or agentless scanning	Infrastructure changes constantly and misconfigurations appear between scheduled scans
Container images	Every build in CI, and rescan images in your registry on a schedule	New CVEs are published against images you already shipped
Endpoints (laptops, workstations)	Continuous via device agent, reviewed at least monthly	Devices leave the network and miss network-based scans
Internal network and servers	Monthly to quarterly, authenticated where possible	CIS 7.5 sets quarterly as the floor; authenticated scans find more
Third-party code dependencies	Every pull request or build	Software composition issues are cheapest to fix before merge

For a HealthTech SaaS company, the systems that store or process ePHI and the internet-facing APIs that front them deserve the tightest cadence. In our experience, most small teams can run weekly external scans and per-build container scans with little extra effort once the tooling is in place.

When should you scan outside the schedule?

Run an extra scan whenever something changes your attack surface or a serious new vulnerability lands. PCI DSS requires scans after significant change, and the SOC 2 points of focus describe the same practice, so auditors will usually expect it.

Common triggers:

• Significant infrastructure change: new network segments, firewall rule changes, new cloud accounts or regions.
• New internet-facing service: a new API, subdomain, load balancer or public storage bucket.
• Major release or architecture change: new authentication flow, new third-party integration that handles sensitive data.
• High-profile vulnerability disclosure: for example, when a CVE affecting your stack is added to CISA's Known Exploited Vulnerabilities catalog.
• After remediation: rescan to confirm the fix. For PCI DSS, rescans are how you turn a failing quarter into a passing one.
• Before an audit window closes or a customer security review: fresh evidence beats a three-month-old report.

Write these triggers into your change management process so the scan is a checklist item, not something someone has to remember.

Is continuous scanning better than scheduled scans?

Continuous scanning catches more and reduces exposure time, but you still need scheduled, reportable scans as evidence. Most teams benefit from both.

	Continuous / agent-based	Scheduled network scans
Detection speed	Hours to days after a new CVE or change	Only at the next scheduled run
Coverage	Strong for cloud, endpoints, containers	Strong for network-reachable services
Audit evidence	Needs point-in-time exports or reports	Naturally produces dated reports
PCI ASV requirement	Does not replace it	ASV scan required quarterly
Noise	Higher, needs triage rules	Lower, batched

A sensible pattern: run continuous scanning for cloud, containers and endpoints, then export a dated report on the cadence your policy states. Keep scheduled external scans, including ASV scans if you are in PCI scope. Scanning also does not replace testing; see penetration testing vs vulnerability scanning for how the two fit together.

How fast should you fix what scans find?

Set remediation deadlines by severity and exploitability, and treat them as part of your scanning policy. Scanning monthly means little if findings sit open for a quarter.

What the sources say:

• CIS Safeguard 7.7 calls for remediating detected vulnerabilities "on a monthly, or more frequent, basis, based on the remediation process" (CIS).
• PCI DSS expects high-risk and critical vulnerabilities from internal scans to be resolved and confirmed with rescans, and a passing external scan each quarter (PCI SSC FAQ 1152).
• US federal context: according to FedRAMP's notice on BOD 26-04, CISA released Binding Operational Directive 26-04 on June 10, 2026, and it prioritises vulnerability remediation by public exposure, Known Exploited Vulnerability status, automatability and technical impact. Binding operational directives apply to federal agencies, not private companies, but the same factors are a useful model for your own remediation order.

An example SLA table you could adapt (these are examples, not requirements):

Severity	Example target to remediate
Critical, or listed in CISA KEV and internet-facing	7 days or less
High	30 days
Medium	90 days
Low	Next maintenance cycle or risk-accepted

Document exceptions with an owner, a compensating control and an expiry date. Auditors are generally comfortable with risk acceptance when it is written down and reviewed, and uncomfortable when findings simply age.

How SecureSlate helps

SecureSlate helps you turn a scanning schedule into evidence you can show. Multi-framework control mapping links one vulnerability management control to PCI DSS, SOC 2, ISO 27001, HIPAA, NIST CSF and FedRAMP requirements, so a single policy and scan cadence serve every audit. Agentless read-only cloud integrations and the device agent surface cloud and endpoint posture, while code security and secrets detection cover your repositories. Risk management tracks accepted vulnerabilities with owners and review dates, and audit management keeps dated evidence organised for your auditor. Anything without a built-in framework, such as CIS Controls or an internal scanning standard, can be set up as a custom framework.

Start your free SecureSlate trial

FAQ

How often does PCI DSS require vulnerability scans?

At least once every three months for both internal scans (Requirement 11.3.1) and external scans by an Approved Scanning Vendor (Requirement 11.3.2), plus after any significant change. You need four passing quarters in the last 12 months, not just four scans.

Does SOC 2 require quarterly vulnerability scans?

No. SOC 2 sets no fixed frequency. The CC7.1 points of focus describe scans on a periodic basis and after significant changes. Your auditor tests against the frequency in your own policy, so choose one you can meet consistently.

Does HIPAA require vulnerability scanning every six months?

Not under the current rule. The six-month scanning requirement appears in the HIPAA Security Rule NPRM published January 6, 2025, which is still proposed as of October 2026. The current rule requires a risk analysis and periodic evaluation without naming a scan frequency.

Is monthly vulnerability scanning enough?

For internal systems, monthly exceeds the CIS quarterly benchmark. For internet-facing systems, monthly matches the CIS minimum, but many teams scan external assets weekly or continuously and scan containers on every build, because exposure time matters more there.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.