Vulnerability management for SOC 2: the monthly scan review

What auditors look for in vulnerability management for SOC 2

Vulnerability management is the ongoing cycle of finding weaknesses in your systems, deciding how serious each one is, fixing it (or consciously accepting it), and confirming the fix worked. In a SOC 2 program it mainly supports CC7.1 in the Common Criteria, which in general terms asks you to use detection and monitoring procedures to spot configuration changes that introduce new vulnerabilities, and to find out when your systems are exposed to newly discovered ones.

The criteria don't name a scanning tool, a frequency or a deadline. Your Vulnerability Management Policy sets those, and the auditor tests whether you did what it says. In practice, for a Type 2 report they usually want to see:

• that scanning covers the systems in scope for your report;
• that someone reviews the results on the schedule your policy sets, every time, across the observation period;
• a recorded decision for each significant finding: fix it, accept the risk, or dismiss it as a false positive, with a reason;
• that fixes were made within the timeframes your policy promises, or that exceptions were approved;
• proof of closure, such as a later scan showing the finding gone.

Sample sizes and evidence format are the auditor's call, so ask early.

What to scan: the usual sources of vulnerabilities

Most small software companies need several kinds of scanning, because each one catches a different class of problem.

• Infrastructure and cloud configuration. Hosts and virtual machines for missing patches and exposed services, plus your cloud accounts for risky settings: public storage, overly broad network rules, unencrypted resources, logging switched off.
• Container images. Base images and installed packages in the images you build and run. An image that was clean last month may not be clean today.
• Dependencies. The open-source libraries your applications pull in, which need continuous checking as new flaws are published.
• Application scanning. Static analysis of your own code, dynamic scanning of your running web application and APIs, or both.
• Endpoint patching. Company laptops and other managed devices: operating system and browser updates, and the ones that fall behind.

An annual penetration test complements all of this, but it doesn't replace routine scanning: a test is a snapshot, and scanning is what catches the flaw published the week after the testers leave.

A monthly vulnerability scan review, step by step

Scanners run on their own schedules, but the review that turns results into decisions works well as a monthly control. Here is a process a small team can sustain.

1. Collect the results

Confirm that every scan ran as planned during the month, and investigate any that failed or were skipped. Then export the results from each source, dated, so the review shows exactly what you were looking at.

2. Triage and confirm severity

Go through new findings, starting with the most severe. Scanners assign a default severity, often from a public scoring system such as CVSS, but adjust it for your context: is the affected system reachable from the internet, is the flaw known to be exploited, does the system hold customer data? A critical score on an isolated test machine may be a lower priority than a high score on your public API.

3. Assign an owner

Every finding you will act on gets a named owner, usually whoever owns the affected system or service, and a ticket in your normal work tracker with a due date that meets your policy.

4. Decide and record the reason

Each significant finding gets one of three outcomes, and each needs a reason someone else can follow:

• Fix: patch, upgrade, reconfigure or remove the affected component.
• Accept: the risk is tolerable, or a fix isn't possible yet, so it goes through your exception process (below).
• False positive: the finding doesn't apply, for example because the vulnerable code path isn't used. Write down why you concluded that and who checked.

Here is an example of a triage record you could keep for each month:

5. Track to closure

Review the findings from earlier months that are still open. Check that fixed items really are fixed, ideally with a fresh scan rather than a closed ticket, and escalate anything past its due date. A finding is closed when the scan says so, not when someone says so.

6. Sign off

Record who did the review and when, and have a second person approve it. That sign-off turns a month of scanner output into evidence of a working control.

Remediation SLAs by severity

Your policy should say how quickly each severity must be fixed. SOC 2 doesn't prescribe these numbers. The table below is a common pattern, shown only as an example: your policy sets your own timeframes, and your auditor will test you against them.

Decide when the clock starts (usually when the finding is first identified) and write it down. Then pick numbers your team can actually meet. A 7-day critical SLA you keep is worth more in an audit than a 48-hour one you miss every month.

Risk acceptance and exceptions

Some findings can't be fixed in time: the vendor hasn't released a patch, the upgrade breaks something important, or the system is about to be retired. That is normal. What auditors look for is that the decision was made deliberately, by the right person, and written down. A workable exception record includes:

• the finding, the affected system and its severity;
• why it can't be fixed within the SLA;
• any compensating controls, such as restricting network access or adding monitoring;
• who approved the exception (someone more senior for critical and high findings);
• an expiry date, after which the exception must be renewed or the finding fixed.

Keep accepted vulnerability risks in your risk register as well, so they are visible beyond the security team and get revisited.

Evidence to keep each month

For each monthly review, keep the following together so you can hand it over without searching:

• the dated scan results, and confirmation that scans ran across everything in scope;
• the triage decisions for each significant finding, with the reason and who decided;
• the tickets for findings being fixed, with owners and due dates;
• proof of closure, such as a later scan, for findings fixed that month;
• any exceptions approved, with their expiry dates;
• the reviewer, the approver and the date of sign-off.

For a structure that works across all your controls, see SOC 2 evidence collection: building an audit-ready library. To see how the monthly review fits with your quarterly and annual controls, see the SOC 2 compliance calendar.

Common vulnerability management mistakes

• Scans run but are never reviewed. The scanner's dashboard fills up, but nobody can show a review happened in March. Running a tool is not the control.
• No record of decisions. Findings vanish with no note of whether they were fixed, accepted or dismissed.
• SLAs the team doesn't meet. The policy promises a 48-hour fix for criticals, copied from a template, and the tickets show three weeks. Either meet the policy or change it through your normal approval process.
• Exceptions that never expire. An accepted risk from two years ago with no renewal is a finding waiting to happen.

Running the scan review in Confluence with Compliance in a Box

Compliance in a Box turns one Confluence space into your SOC 2 program, and vulnerability management is part of the SOC 2 content it provides: a Vulnerability Management Policy and a monthly Vulnerability Scan Review, both mapped to CC7.1 in the app's controls matrix (the Penetration Test activity is mapped there too). See the SOC 2 content reference for the full list.

The Vulnerability Scan Review activity

• An evidence page every month. The scan review is a recurring activity with an activity page that holds the procedure. Before each calendar month is due, the app creates that month's evidence page under the activity page, 14 days ahead by default. With the default, the October 2026 period is due on 31 October and its evidence page appears on 17 October. The page starts with a checklist and a heading for each item to provide: the scan results and the triage decisions. You fill it in and attach your exports there.
• An owner and approvers. Compliance Admins assign the owner, who does the review, and one or more approvers under Settings → Owners & approvers. Only the owner and Compliance Admins can edit the activity's pages.
• A version-bound approval. The owner selects Submit for approval on the evidence page, and every approver must approve. The approval is tied to the exact page version submitted, so editing the page before approval cancels the submission. If the owner approves their own evidence, it is flagged as a self-approval.
• Reminders. The owner is reminded when the month's evidence page opens and 3 days before it is due, and approvers are reminded while a submission waits for them. Reminders arrive as Confluence tasks; see when reminders are sent.
• Overdue stays visible. A month that isn't approved by its due date shows as overdue on the Activities tab, in the evidence page's byline, on the Dashboard and in My Tasks, and the controls matrix shows CC7.1 as a gap. A Compliance Admin can skip a month that genuinely didn't need a review, but only with a written reason that is kept for auditors.

A Compliance Admin can change the days of notice with Edit schedule, and the generated Activity Completion Report links each month to exactly the evidence page version that was approved.

The Vulnerability Management Policy

The policy is provisioned as a page in your compliance space from a template with the standard sections, including Policy Statements and Exceptions. Tailor it before approval: this is where your severity levels, remediation SLAs and exception process belong. Like every policy in the app, it has an owner and approvers, each new version is approved against the exact page version, and it comes up for review every 12 months. The periodic reviews section of the guide explains how that works, and which SOC 2 policies you need shows where it fits among the others.

FAQ

Does SOC 2 require monthly vulnerability scans?

No. SOC 2 doesn't set a scanning frequency. Your policy defines it and the auditor tests whether you followed it. Many teams scan continuously or weekly and review the results monthly.

What remediation SLAs does SOC 2 require?

None specifically. You set them in your Vulnerability Management Policy. What matters is that they are realistic and that your tickets show you meeting them, or approved exceptions where you didn't.

What if a month's scan finds nothing new?

Record it anyway: the scan results, a note that nothing significant was new, the status of open items, and the sign-off. An uneventful month is still evidence.

← All articles