Every SOC 2 vulnerability scanning guide assumes the same starting point: connect a cloud-native scanner, enable automated assessments, and let the platform pull evidence into the compliance dashboard. For companies running production on bare metal servers in a colocation facility, that starting point does not exist.
The scanner built into Vanta or Drata expects AWS Inspector, Azure Defender, or GCP Security Command Center as the data source. It does not know how to scan a firewall appliance sitting in a rack, a managed switch running firmware from three years ago, or a hypervisor hosting production VMs on dedicated hardware. The compliance automation gap that exists for on-premise SOC 2 readiness is widest in vulnerability management, because this is the domain where cloud-native tooling does the most heavy lifting and where on-prem teams are left with the least guidance.
This post covers how to build a vulnerability scanning program for on-prem infrastructure that satisfies SOC 2 CC7.1 and CC7.2, produces clean audit evidence, and is actually sustainable for a small team to operate.
What This Article Covers
16 questions mapped to Common Criteria. See your strengths, find your gaps, get a prioritized action plan.
The instinct is to find a single tool that scans everything on a single schedule. For cloud environments, this roughly works because the infrastructure is homogeneous enough that one scanner covers most of it. On-prem environments are different. A typical production footprint includes Windows servers, Linux servers, a hypervisor, network switches, a firewall appliance, a storage array, and possibly specialized hardware like load balancers or database appliances.
Some of these systems accept scanning agents. Some do not. A firewall appliance does not run a Wazuh agent. A managed switch does not support authenticated vulnerability scans. A storage controller might have a web interface for firmware updates, but no API that a scanner can query.
The gap we see on almost every on-prem SOC 2 engagement
A team writes a vulnerability management policy that says all systems are scanned weekly, installs agents on the servers, and then quietly ignores the network appliances and storage devices because they cannot figure out how to scan them. The auditor eventually asks for evidence of scanning across all in-scope assets, and the team has a gap they cannot close retroactively.
The fix is not a better tool. It is a better classification model.
The approach that works in practice is tiered asset classification with risk-proportional scanning cadences. Each tier gets a different scanning method, a different cadence, and a different evidence pattern. SOC 2 CC7.1 requires vulnerability identification. It does not prescribe a single cadence for every asset class.
Production application servers, database servers, web servers, VPN gateways, bastion hosts, external-facing firewall appliances, and any system directly exposed to the internet or that processes sensitive data.
Agent-based scanning for servers, authenticated scanning for firewall appliances. Agents run on each server, pulling vulnerability signature updates and comparing installed packages against CVE databases. For companies already using a SIEM agent for logging and monitoring, adding vulnerability detection is often a configuration toggle, not a separate deployment. External firewalls are scanned via authenticated connections to their management interfaces using a dedicated service account.
Weekly automated scans minimum. Many implementations run continuous detection (the agent checks on every signature update), with weekly scheduled scans producing the formal compliance evidence.
Scan results dashboards showing weekly execution history, remediation tickets for critical and high findings (showing who did what and when), and quarterly snapshots uploaded to the GRC platform.
Common mistake: setting the critical SLA at 24 hours
Small teams cannot reliably patch within a day, especially for changes requiring testing windows or maintenance coordination. A 48-hour SLA is aggressive enough for auditors and achievable enough that the team will not violate their own policy. Missing your own SLA repeatedly is a worse audit outcome than a slightly longer SLA that you consistently hit.
Hypervisors, internal firewall appliances, internal management servers, staging environments, build servers, monitoring infrastructure, and internal systems that are not directly internet-facing but sit within the production or management network.
Agent-based scanning where agents can be installed, authenticated scanning for internal firewalls and appliances with management interfaces. For systems that run on minimal OS footprints (some hypervisors, embedded management interfaces), authenticated scanning via SSH or SNMP covers the gap.
Quarterly automated scans with continuous agent-based detection where agents are deployed.
Quarterly scan reports showing detection and remediation status, agent deployment confirmation across Tier 2 assets.
This is the tier that trips up most on-prem teams, because many of these devices have limited scanning options. A managed switch may not support full authenticated scans. A storage controller might only expose a web interface for firmware updates. The instinct is to either exclude them from scope (risky) or claim they are scanned weekly (dishonest). Neither approach works.
Managed switches, storage controllers, UPS management interfaces, and other network appliances on isolated or low-exposure segments that have limited management interfaces.
Quarterly review with ad-hoc checks when vendor advisories are published. For appliances on truly isolated networks with no production data exposure, annual review is acceptable with documented risk acceptance.
Quarterly firmware inventory showing current versions mapped against known CVEs, authenticated scan results where available, vendor advisory monitoring subscription confirmation, and documented risk acceptance for any devices running unsupported firmware.
The tiered model only works if the scope is defined clearly. Every in-scope system needs to land in a tier. Systems that are genuinely out of scope for the SOC 2 audit (marketing websites hosted externally, personal devices not connecting to the production network, third-party SaaS tools) do not need to be classified.
The asset inventory from the SOC 2 scoping exercise feeds directly into the vulnerability management program. Each asset gets classified into a tier, assigned a scanning method, and mapped to a remediation SLA. This classification lives in the Security Program Manual as the Vulnerability Management section.
A practical inventory for a typical on-prem SOC 2 engagement looks something like this:
| Asset Type | Example | Tier | Scanning Method |
| Production servers | Application, database, web | 1 | Agent |
| VPN / bastion host | Remote access gateway | 1 | Agent |
| External firewall | Internet-facing perimeter | 1 | Authenticated scan |
| Internal firewall | Inter-VLAN, management | 2 | Authenticated scan |
| Hypervisor | VMware ESXi, Proxmox | 2 | Agent or authenticated scan |
| Build / staging servers | CI/CD, test environments | 2 | Agent |
| Managed switches | Network infrastructure | 3 | Authenticated scan or manual check |
| Storage controllers | SAN, NAS management | 3 | Authenticated scan or manual check |
Cloud SOC 2 guides list AWS Inspector, Azure Defender, and Qualys as the default tools. On-prem environments need a different stack. The scanning program uses three methods, each suited to different device types.
| Method | Best For | Example Tools | Tiers |
| Agent-Based | Servers with OS access | Wazuh, Tenable, Nexpose, ConnectSecure | 1, 2 |
| Authenticated | Firewalls, switches, appliances with management ports | Tenable, Nexpose, Wazuh | 1, 2, 3 |
| Network-Based | Devices with no agent or auth support | FLAN Scan, nmap vulners | 3 |
| Manual Check | Legacy devices, unsupported hardware | Vendor advisories, CVE alerting | 3 |
A lightweight agent installed on each server pulls vulnerability signature updates and compares installed packages against CVE databases. This is the primary method for Tier 1 and Tier 2 servers. Tools that support agent-based on-prem scanning include Wazuh, Tenable (Nessus), ConnectSecure, and Nexpose (Rapid7). Some of these also handle CIS benchmark scanning, file integrity monitoring, and log collection from the same agent, which reduces deployment overhead for small teams.
The choice depends on what the team already runs. A team using Wazuh for SIEM adds vulnerability detection with a configuration toggle. A team that needs polished audit reports and broad device coverage invests in Tenable. A small MSP-style operation may get the most value from ConnectSecure. OpenSCAP is a lightweight open-source option focused on CIS benchmark and STIG compliance scanning for Linux environments.
One agent, multiple SOC 2 domains
Wazuh agents collect logs, run vulnerability detection, perform file integrity monitoring, and check CIS benchmarks from a single deployment. For small on-prem teams that want one agent covering multiple SOC 2 control domains, this consolidation reduces both operational overhead and the evidence collection surface.
This is the method that makes firewall and appliance scanning practical. The scanner connects to the device's management interface via a dedicated service account (SSH, HTTPS, or SNMP), pulls firmware versions and running configurations, and checks them against CVE databases. The output is a standard vulnerability report, the same format the auditor sees for agent-based server scans.
Authenticated scanning covers external firewalls (Tier 1), internal firewalls (Tier 2), managed switches, storage controllers, and any appliance that exposes a management port. Setting it up requires a read-only service account per device class. Most enterprise scanning platforms (Tenable, Nexpose, Wazuh, and others) support authenticated scanning for common network appliance vendors.
For devices that do not support agents or full authenticated scans, network-based vulnerability scanning fills the gap. Two tools worth knowing:
Both produce repeatable, timestamped output that an auditor can verify.
For the small number of devices that support none of the above, manual firmware version verification against vendor security advisories and CVE databases is the fallback. Some older managed switches, UPS management interfaces, and specialized hardware still require it.
Vendor advisory subscriptions complement manual checks by alerting the team when a firmware vulnerability is published for hardware in the environment.
Vulnerability management evidence for SOC 2 follows a three-part pattern that applies across all continuous controls. Understanding what auditors look for by tier makes the evidence packaging much more straightforward.
The Three-Part Evidence Pattern
Tier 3 evidence looks different, and that is acceptable
For network appliances, the quarterly firmware review document, authenticated scan results where available, vendor advisory monitoring confirmation, and risk acceptance forms for unsupported firmware serve as the evidence package. Auditors understand that network appliances have different scanning constraints. The key is documenting what you do and why, not pretending these devices go through the same scanning pipeline as servers.
For a closer look at how remediation tickets and SLA tracking feed into audit evidence, the ticketing and SLA guide covers the workflow in detail.
The vulnerability management process integrates into the team's existing workflow rather than creating a parallel compliance activity.
Review the vulnerability dashboard for Tier 1 systems. Triage any critical or high findings. Create remediation tickets for SLA-critical vulnerabilities. This takes 15-30 minutes for a team managing a typical on-prem footprint.
Run Tier 2 scans and Tier 3 authenticated scans or firmware reviews. Review vulnerability trends across all tiers. Upload quarterly evidence snapshots to the GRC platform. Conduct the quarterly firewall rule review, which overlaps with network security controls.
Update the asset inventory. Review and adjust remediation SLAs if the current timelines are not working. Update the vulnerability management section of the Security Program Manual.
When a vendor publishes a security advisory for hardware in the environment, the team triages the advisory against the asset inventory and follows the Tier 3 remediation SLA.
In small on-prem teams, vulnerability management ownership typically sits with the system administrator or infrastructure lead.
Ownership Model
The vulnerability management policy needs to describe what the team actually does, not what an aspirational enterprise program looks like. For on-prem environments, the policy should explicitly describe the tiered approach, the different scanning methods per tier, and the different remediation SLAs. An auditor reading the policy should be able to predict exactly what the evidence will look like.
The policy that creates audit friction
A generic template that says all systems are scanned weekly for vulnerabilities and remediated within 24 hours. If the team cannot actually do that, every scan cycle produces evidence of a policy violation. Auditors are trained to find exactly this gap.
The policy that works
A tiered policy that says Tier 1 systems are scanned weekly with a 48-hour critical SLA, Tier 2 quarterly with a 7-day critical SLA, and Tier 3 quarterly with authenticated scans and firmware verification. This is both achievable and defensible. It is also the difference between a policy matched to real operations and a generic template retrofitted onto infrastructure it was not designed for.
Our vCISO service builds effective security programs for on-prem infrastructure. Talk to us about yours.
Further Reading: On-Prem SOC 2 Cluster
No. SOC 2 CC7.1 requires that organizations identify vulnerabilities using appropriate tools. It does not prescribe a specific product. Wazuh, Tenable, Nexpose, and even nmap are all acceptable depending on the asset type and scanning tier. What matters is that the tool produces documented, repeatable results that the auditor can verify.
Most network appliances (firewalls, managed switches) support authenticated scanning through their management interfaces. Tools like Tenable and Nexpose connect via service accounts over SSH, HTTPS, or SNMP to check firmware versions and configurations against CVE databases. For devices that do not support even authenticated scanning, use manual firmware version verification against vendor advisories, CVE alerting subscriptions, and documented risk acceptance. Auditors understand these constraints when they are documented.
There is no prescriptive SLA in SOC 2. The standard requires that vulnerabilities are identified and responded to. In practice, a 48-hour SLA for critical findings on internet-facing systems, 7 days for medium, and 30 days for low is well-received by auditors. The critical point: set SLAs the team can actually meet. Missing your own SLA repeatedly is worse than having a slightly longer SLA that you consistently hit.
Yes, if the tool supports it. Wazuh agents collect logs, run vulnerability detection, perform file integrity monitoring, and check CIS benchmarks from a single deployment, making it efficient for small teams that want one agent covering multiple SOC 2 control domains. Tenable and ConnectSecure also consolidate multiple scanning functions (vulnerability detection, configuration compliance, reporting) into a single platform. The trade-off is breadth versus depth: a consolidated tool reduces operational overhead, while dedicated tools for each function may produce more detailed results in specific areas.
After initial setup, the weekly operational burden is 15-30 minutes for Tier 1 dashboard review and triage. Quarterly activities add a few hours for Tier 2 and Tier 3 scanning and evidence packaging. The tiered model concentrates effort on high-risk assets and avoids burning time on low-value scanning that produces noise instead of actionable findings.