SOC 2 vulnerability scanning: how often, and what to keep

SOC 2 does not set a vulnerability scan interval. The sources below recommend quarterly as a minimum and some say monthly for internet-facing systems, and what an auditor tests is whether you ran scans on the schedule your own policy states. This guide puts the positions side by side, separates scans from penetration tests, shows remediation deadlines you can edit and lists the evidence to keep. The sources are vendors and a consulting firm, not the AICPA, so your CPA firm has the final say.

Short answer: no fixed interval in the criteria

Intruder, a scanner vendor, says SOC 2 "requires vulnerability scanning but doesn't specify its frequency" (Intruder). Risk3sixty quotes a CC7.1 point of focus that calls for scans "on a periodic basis" and "after any significant change in the environment", and concludes that scans are mandatory to meet CC7.1 (risk3sixty). That conclusion is the firm's own reading, and its post is from 20 March 2019 (Christian White), so treat it as one view and confirm with your CPA firm.

What the sources recommend, side by side

Quarterly is the floor in every source and monthly is the stronger choice for anything reachable from the internet. Two of the four sell scanning or compliance software, so weigh the monthly advice accordingly.

Scan after significant changes

The CC7.1 wording quoted by risk3sixty includes scans after any significant change in the environment (risk3sixty). Decide in advance what counts: a new internet-facing service, a change to network rules, a new cloud account or a major dependency upgrade are reasonable examples. Write the list into the policy so the extra scans are a rule you follow, not a judgment call you reconstruct later.

Scans are not penetration tests

A scan is automated and cheap enough to run often. A penetration test is a person testing your defenses. Risk3sixty says a penetration test is not necessarily mandatory for CC4.1 when another periodic security assessment is performed (risk3sixty). We cover that question in does SOC 2 require a penetration test, and the scope template helps when you commission one.

Remediation timelines: the sources say little

Astra says high-risk findings must be fixed within a predetermined timeframe and gives no number (Astra). Konfirmity suggests critical patches often within 48 hours and high-severity patches within 30 days (Konfirmity). Intruder does not give timelines (Intruder). So the deadlines are yours to choose. The generated Vulnerability and Patch Management Policy says, in item 4.3:

Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner. Where no fix exists for a Critical finding in an internet-facing system, a mitigating control such as a firewall rule, feature disablement or configuration change is applied within 72 hours.

Those are defaults for a small team, not SOC 2 rules. Shorten them if your customers expect it and lengthen them only if you will still meet them, because the deadline you write is the one tested.

A register that closes the loop

A scan report shows what was found; the register shows what happened next. Item 4.5 of the same policy says:

All findings from every source are tracked in a single vulnerability register with asset, severity, source, owner, detection date, due date, status and closure evidence. A finding closes only when the fix is verified by rescan, retest or documented review.

If a finding cannot be fixed on time, record an exception with a reason, a compensating control and an expiry in the exception register. The security metrics report turns the register into a monthly summary.

What the generated policy says about scan frequency

Item 4.10 of the same policy reads:

Internet-facing systems are scanned at least quarterly and after significant changes, in addition to continuous pipeline scanning.

That is one example from a vendor that sells a kit, and quarterly matches the floor in the table above. Move to monthly if you can sustain it. The criterion behind all of this is CC7.1.

Evidence an auditor can sample

Konfirmity lists scan results and tool configurations, risk assessments and registers, patch records and remediation tickets among the artifacts auditors look for (Konfirmity). Across an observation window that means a report from each scheduled scan, one from each significant change, the register entries with dates, and the tickets that closed them. The evidence checklist places these among the rest, and the observation period guide explains why the whole window needs coverage. Run the mock audit to see which items are missing.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.