.svg)
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
- Why one-size-fits-all scanning breaks down for on-prem environments
- The three-tier asset classification model for vulnerability management
- Three scanning methods and which device types each covers
- What evidence the auditor actually wants to see (and how it differs by tier)
- The weekly, quarterly, and annual operating cadence
- How to write a vulnerability policy that matches your real operations
Why One-Size-Fits-All Scanning Fails On-Prem
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 Tiered Scanning 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.
Internet-Facing and Production Systems
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.
- Critical and high severity: 48 hours
- Medium severity: 7 days
- Low severity: 30 days
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.
Internal Infrastructure
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.
- Critical and high severity: 7 days
- Medium severity: 30 days
- Low severity: Next maintenance window
Quarterly scan reports showing detection and remediation status, agent deployment confirmation across Tier 2 assets.
Network Appliances and Low-Risk Devices
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.
- Authenticated scanning where management interfaces allow it (SNMP, SSH, HTTPS). This covers a growing number of managed switches and storage controllers.
- Manual firmware version verification against vendor security advisories and CVE databases for devices that do not support authenticated access.
- CVE alerting through vendor notification lists or services that track firmware vulnerabilities for specific hardware platforms.
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.
- Critical firmware vulnerabilities: next maintenance window (typically within 30 days)
- Standard firmware updates: next quarterly review cycle
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.
Scope: What Gets Scanned and What Does Not
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 |
Technology: Three Scanning Methods
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 |
Agent-Based Scanning
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.
Authenticated Scanning
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.
Network-Based Vulnerability Scanning
For devices that do not support agents or full authenticated scans, network-based vulnerability scanning fills the gap. Two tools worth knowing:
- FLAN Scan (by Cloudflare) is a lightweight wrapper around nmap that runs vulnerability checks against network hosts and produces formatted reports. It is designed for exactly this use case: scanning a set of IPs on a schedule and outputting a report suitable for compliance evidence.
- nmap with the vulners script queries detected service versions against the Vulners CVE database, turning a standard port scan into a basic vulnerability assessment. This is not a substitute for agent-based or authenticated scanning, but it provides documented evidence for devices where nothing else works.
Both produce repeatable, timestamped output that an auditor can verify.
Manual Check
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.
Evidence: What the Auditor Wants to See
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
- Configuration evidence showing the scanning program is set up and running. A screenshot of the scanner configuration, the scan schedule, and the alert thresholds. This proves the control exists.
- Execution history showing the program has been operating on its expected cadence. A list of scans executed over the observation period, the number of vulnerabilities detected and remediated per cycle, and trend data showing the posture over time. This proves the control operates continuously.
- Representative sample showing the output is meaningful. One full scan report for each tier, one remediation ticket showing the complete lifecycle (detection, triage, remediation, verification), and any risk acceptance documentation for vulnerabilities that were not remediated.
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.
Process: The Operating Cadence
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.
People: Who Owns What
In small on-prem teams, vulnerability management ownership typically sits with the system administrator or infrastructure lead.
Ownership Model
- Owner: The person responsible for reviewing scan results, triaging findings, and ensuring remediation happens on schedule. This is usually the same person who manages the infrastructure day to day.
- Reviewer: Someone who reviews the quarterly evidence package before it goes to the GRC platform. In small teams, this might be the CTO or the engagement lead from the consulting partner.
- Backup: A designated person who can cover vulnerability management responsibilities during absences. Without a backup, a two-week vacation creates a two-week gap in the evidence trail.
The Policy That Actually Works
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.
Running on-prem and need SOC 2?
Talk to us about building an effective security program for your on-prem infrastructure.
Free Assessment →Further Reading: On-Prem SOC 2 Cluster
- SOC 2 Readiness for Bare Metal SaaS: the overview post for this cluster
- SOC 2 Scoping: defining the boundary before you can classify assets by tier
- Security Logging and Monitoring Architecture Guide: the SIEM layer that feeds into vulnerability detection
- SOC 2 Ticketing and SLA Management: how to track remediation in a way auditors can verify
Frequently Asked Questions
Does SOC 2 require a specific vulnerability scanning tool?
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.
How do we handle devices that cannot run scanning agents?
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.
What remediation SLAs do auditors expect for SOC 2?
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.
Can one tool cover both vulnerability scanning and SIEM?
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.
How much time does vulnerability management take for a small on-prem team?
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.
Ready to Build Your SOC 2 Roadmap?
Our free, no-obligation assessment will give you a clear, actionable plan to achieve compliance.
.png?width=155&height=82&name=Arrow%205%20(1).png)