SOC 2 Vulnerability Management: Evidence Auditors Ask For

The thing that surprises almost every first-time auditee: neither SOC 2 nor ISO 27001 tells you how often to scan.

There is no mandated frequency, no required tool, no prescribed severity threshold. What there is instead is an objective, and an auditor whose job is to test whether you did what your own policy says you would do.

That has a consequence most teams get backwards. An unambitious policy you actually follow is strictly better than an aspirational one you do not. Promising weekly scans and 7-day critical remediation, then missing them for a quarter, produces findings. Promising monthly review and 30-day critical remediation, and hitting it every period, produces a clean report.

What SOC 2 Actually Says About Vulnerabilities

SOC 2 is not a technical checklist. It is an attestation against the AICPA Trust Services Criteria, written as objectives with points of focus rather than prescriptions. There is no line item that says "run a scanner".

This is why two organisations with wildly different tooling can both pass. The report describes your controls and the auditor's opinion on whether they operated effectively.

CC7.1 and Its Neighbours

The criteria that matter here, with the caveat that mappings vary slightly between audit firms:

• CC7.1: procedures to detect configuration changes and newly introduced vulnerabilities. This is the primary hook.
• CC7.2: monitoring for anomalies and indications of malicious acts.
• CC7.3 and CC7.4: evaluating security events and responding to identified incidents.
• CC8.1: change management, which is where your patch deployments get tested.
• CC6.6: boundary protection, often cited alongside when external exposure is in question.

Note the phrase in CC7.1: newly introduced. That word is doing work. It implies an ongoing process, which is precisely why a single annual assessment does not satisfy it.

ISO 27001:2022 Annex A 8.8, and the New A.5.7 Threat Intelligence Control

The ISO equivalent is Annex A control 8.8, Management of technical vulnerabilities, which in the 2022 revision consolidates what the 2013 version split across A.12.6.1 and A.18.2.3. The detailed implementation guidance lives in ISO/IEC 27002:2022, and it is worth reading because it is far more concrete than the Annex A statement: obtain timely information about vulnerabilities, evaluate exposure, and take appropriate action.

The genuinely underreported change is A.5.7, Threat intelligence, which is new in the 2022 revision.

Subscribing to and acting on vulnerability intelligence is now an explicit control, not an optional maturity signal. Organisations recertifying against the 2022 standard frequently discover this one late, because it does not map cleanly onto anything they were doing under the 2013 version. In practice, a documented feed of vulnerability information that is matched against your estate and demonstrably acted upon satisfies both A.5.7 and a large part of A.8.8 with the same artefact.

The Rule Nobody Tells You: The Auditor Tests Your Policy, Not a Standard

Say it plainly, because it changes how you should write the policy: the auditor's test is conformance to your stated policy.

So write the policy you can sustain on your worst month, not the one that sounds impressive in a sales questionnaire. You can always tighten it later; a tightened policy with a version history reads as maturity, while a missed commitment reads as a control failure.

The Control That Fails Audits Is Asset Inventory

Here is the sharper claim, and it is the one worth acting on this week.

Teams prepare for these audits by worrying about scanning. The control that actually fails is inventory.

Every vulnerability control silently assumes you can enumerate the estate, and ISO 27002 makes that precondition explicit. When an auditor asks the question that stalls most first audits, it is never "which scanner do you use". It is:

"How do you know this list is complete?"

If the answer is a spreadsheet somebody exported nine months ago, the vulnerability control cannot be evidenced no matter how good the tooling above it is. You cannot demonstrate coverage of an estate you have never enumerated.

A One-Page Policy Skeleton in Five Testable Sentences

Each sentence maps to something an auditor can test. Fill in your own numbers.

1. Scope. "This policy covers all production systems, the third-party software components listed in the technology inventory, and all internet-facing services."
2. Identification and cadence. "New vulnerabilities affecting inventoried technologies are identified continuously through a monitored CVE feed, and the inventory itself is reviewed monthly."
3. Severity to deadline. "Critical vulnerabilities are remediated within 30 days, high within 60, medium within 90, and low at the next maintenance window. Confirmed active exploitation overrides these deadlines and requires remediation or mitigation within 7 days."
4. Exceptions. "Any deadline exception must be approved by the engineering lead, must record a compensating control, and expires after 90 days."
5. Review. "This policy is reviewed and re-approved annually, and after any incident involving a known vulnerability."

Sentence 3 is where our patch management framework does the work for you: it already sets out tiers, triggers and deadlines you can lift directly rather than inventing numbers you will regret.

Five Artifacts That Pass

1. A dated technology or asset inventory, with an owner per entry and a review date.
2. The policy itself, with a version number and an approval date and approver.
3. Per-item remediation records: detection date, severity decision, action taken, closure date. One record per vulnerability.
4. Documented exceptions: time-bounded, approved by a named person, with the compensating control written down.
5. Evidence of periodic review: meeting notes with dates, or a ticket showing the review ran.

Artifact 3 is the one that takes real effort to produce retrospectively and almost no effort to produce as a by-product. Our per-CVE workflow states, open, in progress, deferred, risk accepted and closed, with free-text notes on each transition, are exactly that dated per-item record. Ticketing and workflow are Premium and Max features on the pricing page; the free tier covers two technologies and a 100-CVE backlog, which is enough to prove out the process but not to cover a real estate.

Evidence That Does Not Pass

An annual penetration test report offered as the vulnerability management control. A pentest is a point-in-time assessment by a third party. It is excellent evidence for a different objective. It is not a procedure for detecting newly introduced vulnerabilities, and offering it as one signals that no such procedure exists.

An undated dashboard screenshot. If it does not carry a date and a scope, it evidences nothing. Auditors have seen the same screenshot submitted in three consecutive years.

A tool licence with no records of use. Owning a scanner is not a control. Running it and acting on the output is.

Control, Artifact, Source: The Mapping Table

Doing This Without a Vulnerability Management Team

Nothing above requires a dedicated function or an expensive platform. It requires four things: a list, a feed, a policy and a paper trail.

If your auditor asks why you have no scanner agents deployed, the answer is in our agentless vulnerability management piece: for an estate whose composition you declare rather than discover, matching published CVEs against a maintained inventory covers the same objective without touching a host. And if you want to assemble the whole thing from free tools before spending anything, our zero-budget guide walks through it.

The one step worth automating first is the continuous match between new disclosures and your declared stack, because it is the step that produces dated evidence as a side effect. That is what stack-matched CVE alerts are for: an alert with a date, tied to a technology you declared, is artifact 3 writing itself.

What Changes for Type II Versus Type I

Type I tests design at a point in time. You can pass with a well-written policy and evidence that the controls exist.

Type II tests operating effectiveness over a period, typically 3 to 12 months, and the auditor samples individual items from across that window.

This is why the artifacts have to be produced continuously rather than assembled. In a Type II, three months of missing remediation records cannot be back-filled, and a policy you started following the week before fieldwork will show its start date.

Start the paper trail before you need it. That is the whole trick.