Why this matters
SOC 2 is an attestation report about controls, not a security score. Under the Trust Services Criteria, CC7.1 asks you to detect changes that create new vulnerabilities and to watch for newly discovered ones. An auditor will ask what you scan, how often, who fixes what, and how you prove it happened. A scanner you bought last quarter does not answer those questions.
For a Type II report, the auditor samples months of activity. They want to see scans that ran on schedule, tickets that match findings, fixes that were verified, and exceptions that someone approved. Missing months or empty ticket queues are findings. So is a policy that says every critical issue is fixed in 24 hours when nothing shows that.
The goal is a repeatable loop: find, rank, assign, fix, verify, report. Keep it small enough to run every week. The evidence falls out of the loop when the tools are connected.
Before you start
Start with an asset list you trust. Vulnerability management fails when scans cover half your estate. Include servers, laptops, network gear, cloud accounts, containers, and code dependencies. Tag each asset with an owner, environment, and criticality. Pull the list from your cloud provider, MDM, and configuration management database if you have one. Reconcile gaps before you pick a scanner.
Choose tools that fit the assets. Agent-based scanners work well on servers and endpoints that move. Network scanners need credentials and a route. Cloud tools such as Amazon Inspector, Microsoft Defender for Cloud, or Google Security Command Center cover managed services and images. Dependency scanners such as Dependabot, Snyk, or Trivy catch libraries in code and containers. Teams often need two or three tools, not one.
Write the policy before the first scan. Name the scan frequency, severity scheme, remediation timelines, exception process, and who reviews results. Get it approved by whoever owns security. Set up a ticket project and a place to keep reports. Decide how long you will retain scan output and tickets. Auditors usually look at a period, so retention must cover it.
How to do it
Run the program as a weekly operating rhythm, not a project. The steps below assume you already have the policy and asset list. Adjust the timelines to your risk, then keep them.
Keep the loop tight. A finding with no owner and no date is not a control. A ticket that closes without a rescan is a claim, not evidence. The weekly review should take under an hour when the automation works.
- Write the vulnerability management policy. Define scope, scan cadence, severity levels, remediation targets, exception rules, and review cadence. State who can accept risk and what evidence a closure needs. Get sign-off and publish it where staff can find it.
- Map every asset to an owner. Load servers, cloud accounts, repositories, and endpoints into one list. Add owner, environment, and business criticality. Set a rule that new assets get tagged at creation, not found later by a scan.
- Run authenticated baseline scans. Use credentialed scans for servers and network devices, and agent or cloud-native scans where credentials are awkward. Scan source repositories and container images in the build pipeline. Save the first full report as your baseline.
- Set severity and fix times. Use CVSS as an input, then adjust for exposure, data sensitivity, and known exploitation. Set separate targets for internet-facing and internal assets. Critical issues need a short clock and a named owner, not a queue.
- Open a ticket for each real finding. Connect the scanner to Jira, Linear, or GitHub Issues with an automation rule. Put the asset, severity, due date, and scan evidence in the ticket. Deduplicate findings that appear on many hosts under one fix task when the fix is the same.
- Triage false positives and exceptions. Review findings with the asset owner. Mark false positives only with a reason and a reviewer. For accepted risk, record the business reason, compensating control, owner, and expiry date. Review exceptions before they expire.
- Fix, rescan, and close. Fix the issue, then rerun the scan that found it. Attach the clean scan or the changed configuration to the ticket before closing. If a fix needs a maintenance window, keep the ticket open with a date.
- Report monthly to management. Show open findings by severity, overdue items, exceptions, and scan coverage. Note any asset that was not scanned and why. Keep the report with the other SOC 2 evidence.
How to check it worked
Pick five findings from the last quarter. Trace each one from the scan report to the ticket, the fix, the rescan, and the closure. If any link is missing, the program has a gap. Do the same for one exception and one false positive. Check that the approver had authority and that the reason is specific.
Check coverage. Compare the scanner asset count with your cloud inventory and endpoint list. Look for assets added during the period that never appeared in a scan. Confirm scheduled scans ran during holidays and staff changes. A scan schedule that depends on one person's laptop is fragile.
Review the monthly reports. They should show trends, overdue items, and exceptions, not just a raw count. Ask the asset owner to explain one overdue critical item. If the answer is that the ticket was never assigned, fix the routing rule.
Test the auditor sample. Pull the same evidence an auditor would request: policy, scan reports, tickets, rescan output, exception approvals, and management review notes. If you can produce it in an hour, you are ready.
Mistakes to avoid
Scanning only before the audit is the common one. A Type II report covers a period, so a clean scan in month six does not explain months one to five. Run scans on a schedule from day one and keep the output.
Treating CVSS as the only priority. A medium issue on an internet-facing login page can matter more than a high issue on an isolated test box. Rank with exposure and data sensitivity. Write the reason down.
Closing tickets without a rescan. The ticket says fixed, the scanner still finds it, and the auditor sees the mismatch. Also avoid a policy with 24-hour fixes that no team can meet. Set targets you can hit, then track exceptions.
Letting the scanner become the program. A tool does not assign owners, approve risk, or review reports. Those are the controls. The scanner only supplies input. If you want help shaping the program and the evidence, the Cloudverg SOC 2 readiness assessment is a fixed price $7,500 engagement that runs three weeks and includes a gap assessment and a remediation roadmap. It is one option among others, such as a compliance platform or an independent consultant.
Frequently asked questions
What does SOC 2 require for vulnerability management?
The Trust Services Criteria do not name a specific scanner. CC7.1 expects you to detect new vulnerabilities and changes that create them. You need a documented program, scheduled scans, remediation records, and evidence of review. The auditor tests whether the program ran as described.
How often should we scan for SOC 2?
Many programs scan at least monthly, with weekly or continuous scans for internet-facing systems. The policy sets the cadence and the evidence must show it ran. More frequent scans are fine if you can triage the output. A cadence you miss is worse than a slower one you keep.
Do we need to fix every vulnerability?
No. You need a risk-based decision for each finding. Fix what matters within your stated timelines. For the rest, record an exception with a reason, owner, and expiry date. An auditor will look for consistent decisions, not zero findings.