Scanning quarterly when your vendors patch monthly
A quarterly vulnerability scan is a compliance interval, not a detection cadence. PCI DSS asks for internal and external scans at least once every three months. Microsoft ships a security update on the second Tuesday of every month. The same standard also demands a scan after any significant change, and that clause is the one nobody runs.
- The quarterly interval comes from the payment-card standard. PCI DSS sets internal and external vulnerability scans at least once every three months.
- The same requirement also demands a scan after any significant change. That clause has no calendar behind it, so it is the one that gets skipped.
- The CIS Controls ask for external scans monthly and internal scans quarterly, so the attack surface an attacker can reach gets looked at three times more often.
- A deadline to look is not a deadline to fix. The federal cloud program gives high-risk findings 30 days from discovery, and many managed agreements name neither clock.
- Continuous monitoring of your internet-facing addresses may already be free. CISA runs it at no cost for eligible organizations and sends weekly reports.
Where does the quarterly vulnerability scan requirement come from?
The quarterly interval comes from the payment-card standard, not from security research. PCI DSS requires that internal vulnerability scans are performed at least once every three months, and that external vulnerability scans are performed at least once every three months, by a PCI SSC ASV, the council's term for an Approved Scanning Vendor.
That compliance requirement traveled a long way from card payments. Auditors reuse it. Cyber insurance questionnaires reuse it. A provider writing a proposal for a dental practice reuses it, because it is the number the buyer has already heard. None of those documents inherited the reasoning. They inherited the interval.
Guidance that is free to recommend rather than mandate splits the number by where the asset sits. The CIS Controls ask organizations to perform automated vulnerability scans of internal enterprise assets on a quarterly, or more frequent, basis and to conduct both authenticated and unauthenticated scans. For anything facing the internet they ask for three times as much, to perform automated vulnerability scans of externally-exposed enterprise assets on a monthly, or more frequent, basis. Same framework, same page, a different interval for the half of your attack surface an attacker can reach from a laptop.
Read PCI's own Requirement 11 end to end and the quarterly number looks stranger still. The same requirement sets a change-detection mechanism to perform critical file comparisons at least once weekly, and payment page tamper detection to run at least once every seven days. A standard that put a weekly clock on two controls put a quarterly clock on the one your provider sells. The interval is not a statement about how fast risk arrives. It is a statement about what an outside assessor can reasonably audit four times a year.
The clause nobody runs: scan after any significant change
To find the real gap in your scanning, look for a scan that a change triggered rather than the calendar. PCI DSS requires internal vulnerability scans performed after any significant change, and separately requires that external vulnerability scans are performed after any significant change, with anything scored 4.0 or higher by the CVSS resolved.
A date-driven scan schedules itself. An event-driven scan does not. So a provider with four calendar entries a year holds a complete-looking record and no evidence that anybody scanned after the new firewall went in, after the accounting system upgrade, or after the office move that re-addressed half the network.
New York's financial regulator dropped the fixed interval altogether and kept the trigger. Its rule requires covered entities to run automated scans of information systems, and a manual review of systems not covered by such scans at a frequency determined by the risk assessment, and promptly after any material system changes. Two independent regimes, one prescriptive and one risk-based, both pair looking with changing. Neither treats the calendar as sufficient on its own.
Four evenly spaced scan dates are not evidence of a working program. They are evidence that only the calendar ever triggered a scan.
The check costs one email. Ask for the date of every scan in the last 12 months, then set that list beside your own list of changes. Four dates roughly 90 days apart, with nothing next to the upgrade you remember paying for, tells you the change clause has never been operated.
A deadline to look is not a deadline to fix
A scanning clock and a remediation clock are two different instruments, and plenty of managed agreements name neither in writing. A scanning clock says how often somebody looks. A remediation clock says how long a finding may stay open once it has been seen.
The federal cloud program publishes both. It sets scanning under its traditional process at monthly operating system/infrastructure, monthly web applications (including APIs) and databases, and gives high-risk vulnerabilities mitigated within thirty (30) days from date of discovery, moderate-risk vulnerabilities mitigated within ninety (90) days and low-risk vulnerabilities mitigated within one hundred and eighty (180) days. It adds that the KEV remediation date supersedes the FedRAMP parameter requirement, so a flaw confirmed as exploited in the wild jumps the queue.
New York attaches the same duty without a number, requiring entities to timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose to the covered entity. What happens to a finding after it lands is covered in our guides to your patch compliance rate and who approves a patch window. The point here is narrower. A quarterly scan with no remediation clock behind it produces a list four times a year, and a list is not a fix.
What your vendors ship between two scans
Between two quarterly scans your vendors ship at least three monthly security releases, plus every unscheduled fix in between. Microsoft publishes its monthly security update on the second Tuesday of each month, typically at 10:00 AM Pacific Time, and issues an out-of-band update outside of the monthly schedule when there's an exceptional need, reserved for atypical cases when an issue is detected and can't wait for the next monthly update. One major vendor genuinely does work to your scanning interval, which is worth knowing before you argue the point: Oracle states that Critical Patch Updates are released on the third Tuesday of January, April, July, and October. If your estate is mostly Oracle, a quarterly scan lines up with the thing it is looking for. If it is mostly anything else, it does not.
Apple runs a second track for the same reason, describing background security improvements as applying security fixes to users more frequently by not requiring a full software update. The pattern repeats across the stack. A predictable monthly release is the floor, and a fast irregular release exists for the flaws that will not wait for it.
Now do the arithmetic on your own estate. A flaw published the day after your quarterly scan has up to 89 days before anything looks for it, and three Patch Tuesdays land inside that window. CISA's catalog of vulnerabilities confirmed as exploited in real attacks held 1,754 entries when we checked it on October 22, 2026, and it grows continuously rather than quarterly.
Volume is not the whole story, and the honest counterweight belongs here. The EPSS project reports that in any given 30 day period, we are tracking anywhere from 1.5% to 3% of published vulnerabilities with exploitation activity. Most published flaws are never attacked at all. That is an argument for looking more often and triaging harder, not for looking less often, because the small share that matters does not wait for your quarter to end.
What happens in the gap between two scans
Nothing closes on its own, and that part has been measured. Verizon published a survival analysis of 7,513 third-party, cloud-based multi-factor authentication exposures, with 58 percent still unresolved after 7 days, 50 percent after 28 days and 42 percent after 90 days. That is a narrow population and the only day-indexed curve of its kind in the report, so read it as a shape rather than a rate. The shape is nearly flat. An exposure does not decay while nobody is looking at it.
Every authority that has revisited the interval since has moved toward days. CISA requires federal agencies to perform automated asset discovery every 7 days and to initiate vulnerability enumeration across all discovered assets every 14 days, including all discovered nomadic/roaming devices (e.g., laptops). Discovery comes first in both, because an asset inventory that is three months old produces a scan that is three months old. The federal cloud program's proposed replacement for monthly scanning goes further, asking a moderate-impact system for a look at representative samples at least once every 3 days and a high-impact system for one at least once per day.
Line those up and the quarterly interval is the oldest surviving number in the set. It was written to be auditable by a third party four times a year. Every regime that has revisited the question since has shortened it, and it is still the interval a small business is quoted. Your scan is not too infrequent because your provider is careless. It is too infrequent because an audit cadence is being sold to you as a detection cadence, and those are not the same product.
Authenticated, continuous, or just more often? What the upgrade buys
An authenticated scan is a different measurement rather than a faster one, and the standards treat it as required rather than optional. PCI DSS requires that internal vulnerability scans are performed via authenticated scanning, that systems that are unable to accept credentials for authenticated scanning are documented, and that sufficient privileges are used for those systems that accept credentials for scanning. CIS asks for both authenticated and unauthenticated scans on internal assets.
What no primary source publishes is how much more a credentialed scan finds. We looked for a figure at NIST, CISA and the standards bodies and did not find one. The multipliers that circulate come from scanner vendors and cite no study, so judge the upgrade on the documented difference instead. An unauthenticated scan probes from outside and infers what is running. An authenticated scan logs in and reads the installed version. Only the second can see a vulnerable component on a machine that exposes no network service at all, which describes most of your laptops.
Before you buy continuous external scanning, check whether you qualify for it free. CISA's Cyber Hygiene service continuously monitors and assesses internet-accessible network assets, is available at no cost, and sends weekly reports of all findings plus ad-hoc alerts about urgent findings. Eligibility runs to US government bodies and to public and private sector critical infrastructure organizations, which reaches further into ordinary small business than most owners expect. Enrollment is an email to vulnerability@cisa.dhs.gov.
That free service covers the outside only. It will not see the laptop, the unpatched line-of-business server, or the firewall's own firmware, and it cannot authenticate to anything. The internal half still needs a scanner with credentials, and it needs to disagree with your patch management report sometimes, which is the whole reason to run both.
Six questions to ask about the scan you already pay for
Send these six requests in one email. Each takes minutes to answer when the control is operated and days when it is not. The delay is the finding.
- Ask for the date of every vulnerability scan in the last 12 months, with the number of days between each one.
- Ask whether the internal scan was authenticated, and for the documented list of systems that could not accept credentials.
- Ask which scan a change triggered rather than the calendar, and name the change you have in mind.
- Ask for the scope in writing, naming the IP ranges and asset classes the scan covered and what it excluded.
- Ask for the remediation clock by severity, in days from discovery, and who signs off a missed one.
- Ask whether any finding in the current report sits in CISA's Known Exploited Vulnerabilities catalog.
Then change two lines in the agreement rather than the proposal deck. State the scanning interval for internal and for internet-facing assets separately, and require a scan after any significant change. State the remediation clock in days by severity, counted from discovery, so your provider can prioritize the list rather than present it, and require them to verify each fix on the asset rather than in the ticket.
None of this buys perfect security, and no honest provider offers that. It buys an interval you chose on purpose, a record of the scans your own changes triggered, and a clock on every finding. For the test that goes further than a scan and tries to use what it finds, read our guide to vulnerability assessment vs penetration testing.
FAQ
How often should a small business run a vulnerability scan?
Monthly for anything facing the internet and at least quarterly inside, plus a scan after any significant change. The CIS Controls ask for external scans on a monthly, or more frequent, basis and internal scans on a quarterly, or more frequent, basis. PCI DSS adds the change trigger on top of the interval.
Is a quarterly vulnerability scan enough?
Only for the compliance box it was written for. PCI DSS requires internal vulnerability scans at least once every three months and the same requirement demands one after any significant change. Microsoft ships a security update on the second Tuesday of each month, so a quarterly scan looks once for every three monthly releases.
Who requires quarterly vulnerability scanning?
The payment-card standard does. PCI DSS sets internal vulnerability scans at least once every three months and external vulnerability scans at least once every three months, by a PCI SSC ASV. Auditors, insurers and provider proposals borrow that interval. The federal and New York rules we checked set shorter or risk-based intervals instead.
What is the difference between an authenticated and an unauthenticated vulnerability scan?
An unauthenticated scan probes a system from outside and infers what is running. An authenticated scan signs in and reads installed versions and settings directly. PCI DSS requires internal scans performed via authenticated scanning and requires systems that are unable to accept credentials for authenticated scanning to be documented. Ask your provider for that list.
Can I get vulnerability scanning for free?
For your internet-facing addresses, often yes. CISA's Cyber Hygiene service continuously monitors and assesses internet-accessible network assets and is available at no cost, with weekly reports of all findings, open to public and private sector critical infrastructure organizations. It does not cover internal assets, laptops or firmware.
Best IT MSP is the independent directory of vetted managed IT and cybersecurity providers across North America. Organic ranking is earned on rating and verified data, and paid placement is always labelled. Take the six questions above to three merit-ranked firms in your city and compare the answers side by side.