Datadog for SOC 2 Vulnerability Scanning: Datadog vs Wazuh vs Nessus On-Prem

A bare-metal SaaS company already paying for Datadog asked us a simple question before its first SOC 2 audit: Can Datadog be our vulnerability scanner of record, or do we need Nessus too? Datadog can be the scanner of record for every server and container that runs the Datadog Agent. It does not scan firewalls, switches, hypervisors or server management controllers, so a SOC 2 program on its own hardware pairs one agent-based tool for hosts (Datadog or Wazuh) with a periodic network scan (Nessus or similar) for the devices that cannot run an agent.

What Does SOC 2 Require From a Vulnerability Scanner?

SOC 2 requires a vulnerability scanning process that covers every in-scope asset and produces dated evidence, and it names no tool. Criterion CC7.1 reads: To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. Its point of focus Conducts Vulnerability Scans adds that scans run on a periodic basis and after significant changes are made to the environment, and states: Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity's objectives.

In practice, an auditor tests five things against the scanner of record:

The SOC 2 vulnerability scanning guide for on-prem servers covers the tiered scan cadence and remediation SLAs. This post covers which tool produces that evidence.

Datadog vs Wazuh vs Nessus for SOC 2: Side-by-Side Comparison

Datadog, Wazuh and Nessus each meet CC7.1 for the assets they can see, and they see different assets. Datadog and Wazuh read software inventory from an agent on each host. Nessus connects over the network, with or without credentials.

What Datadog Cloud Security Vulnerabilities Covers On-Prem

Datadog Cloud Security Vulnerabilities covers on-prem hosts and containers through the Datadog Agent. Datadog's documentation describes it as continuously scanning container images, hosts, host images, and serverless functions for vulnerabilities, and lists the Agent-based method as supported on AWS, Azure, GCP, on-prem, etc. The agentless option covers AWS, Azure and GCP only, so a bare-metal environment depends on the Agent.

Host scanning needs Agent 7.46 or later with sbom.enabled and sbom.host.enabled set to true in datadog.yaml. Findings are ranked with the Datadog Severity Score, which combines CVSS with risk factors, and Datadog can create Jira tickets automatically and export vulnerabilities through its public API.

For a company already running the Datadog Agent on every server, that covers most of the host inventory with no new tool. The gap sits outside the hosts. Datadog Network Device Monitoring collects SNMP metrics and tracks configuration changes on routers, switches and firewalls, and its documentation describes no CVE detection for those devices.

What Wazuh Vulnerability Detection Covers

Wazuh vulnerability detection covers every endpoint that runs the Wazuh agent, and the same agent feeds the Wazuh SIEM, file integrity monitoring and configuration assessment. The agent's Syscollector module sends the operating system and package inventory to the Wazuh server, which flags a package when its version falls within the affected range of a CVE. When the CVE content updates, the server re-evaluates every agent.

Two details matter on-prem:

• Offline feed. Wazuh can use a locally hosted copy of its vulnerability repository, which suits networks with restricted outbound access.
• Agentless monitoring is a separate feature. Wazuh connects over SSH to routers, firewalls and switches to monitor files, configuration and command output. That supports change detection for CC7.1, and the documentation does not describe it as vulnerability detection.

Wazuh is the lowest-cost option in licence terms and the highest in operating effort, since the team operates the Wazuh server, indexer and dashboard. The SOC 2 logging and SIEM guide for bare metal covers the SIEM side of the same deployment.

What Nessus Covers That Agent-Based Scanners Miss

Nessus covers any device it can reach over the network, which is why it fills the gap agent-based scanners leave on-prem. Tenable's documentation states that for targets that are not standard Windows, macOS, or Linux operating systems, such as network appliances or management APIs, Tenable Nessus still performs credentialed checks.

Nessus credentialed coverage relevant to a bare-metal SOC 2 scope includes:

• SSH-based appliances: Cisco hardware, Palo Alto firewalls, F5 BIG-IP and Fortinet, where Nessus reads the device version and runs local checks
• Management APIs: VMware vCenter, VMware ESX SOAP API, NetApp API, Nutanix Prism and Palo Alto PAN-OS over HTTPS
• Servers: Linux over SSH and Windows over SMB, the same depth an agent provides

Devices with no supported credential type, such as most BMCs and UPS network cards, still get unauthenticated network checks on the services listening on their network interfaces. Nessus scans can be scheduled on a fixed frequency, and scan reports export to PDF, HTML or CSV with dates, which is the format an auditor samples. Tenable also offers Nessus Agents, which link to Nessus Manager or Tenable Vulnerability Management for hosts that are hard to reach over the network.

Which On-Prem Assets Do Agent-Based Scanners Miss for SOC 2?

Agent-based scanners miss every in-scope device built on vendor firmware with no agent package. In a typical bare-metal SOC 2 scope, that list is:

• Edge and internal firewalls
• Core and top-of-rack switches, and routers
• Hypervisor hosts such as VMware ESXi (Linux-based hypervisors such as Proxmox or KVM hosts can run a Linux agent)
• Server BMCs: Dell iDRAC, HPE iLO, Supermicro IPMI
• Storage arrays and their controllers
• UPS and PDU management cards, and out-of-band console servers

These devices hold some of the highest-impact vulnerabilities in a data center. A BMC gives full control of a server below the operating system, and a firewall CVE can open the whole network. An auditor who reconciles the asset inventory against scan results will see these devices missing from a Datadog-only or Wazuh-only report.

Recommended SOC 2 Scanner-of-Record Setup: One Agent for Hosts Plus a Periodic Network Scan

The SOC 2 scanner-of-record setup that works on-prem is one agent-based tool for hosts and containers plus a scheduled network scan for agentless devices. It splits the work by what each tool sees best.

1. Hosts and containers: one agent. If the Datadog Agent is already on every server, enable Cloud Security Vulnerabilities and name it as the host scanner. If Wazuh is already the SIEM, use its vulnerability detection. Running both on the same hosts doubles triage work for the same CVEs.
2. Agentless devices: a network scan. Run a credentialed Nessus scan (or an equivalent network scanner) of firewalls, switches, hypervisors, BMCs and storage on the policy's cadence, typically quarterly, plus after firmware changes.
3. Devices nothing can authenticate to: a firmware review. Record firmware versions each quarter, check vendor advisories, and document a risk acceptance for anything unsupported.
4. One remediation queue. Send findings from both tools into the same ticket system with the same severity SLAs, so the auditor samples one process.
5. Name both tools in the policy. The vulnerability management policy and the system description should state which tool covers which asset class, at what frequency.

For the bare-metal company that asked the question, the answer was to keep Datadog for its Linux fleet and add a quarterly credentialed network scan of its firewalls, switches and BMCs. External scans and penetration testing are separate controls; the SOC 2 penetration testing guide for on-prem covers that requirement.

Which GRC Platforms Pull Findings From Datadog, Wazuh and Nessus?

Vanta and Drata both pull vulnerability findings from some of these tools, and an integrated scanner cuts manual evidence uploads. The table reflects each vendor's help documentation checked on 2026-10-17.

Where a tool has no integration, the evidence goes in as dated uploads: scan reports, scan schedules and remediation tickets. The guide to SOC 2 evidence collection on-prem covers that workflow. A GRC platform tracks the evidence; the program decides what gets scanned and how fast findings close.

How to Document a SOC 2 Scanner of Record for the Auditor

A SOC 2 scanner of record is documented as a mapping from asset class to tool, frequency and owner. Give the auditor these items at the planning meeting:

• Asset-to-scanner map: each in-scope asset class (servers, containers, firewalls, switches, hypervisors, BMCs, storage) with its tool and method
• Coverage reconciliation: the asset inventory compared against agent lists and scan targets, with any gaps explained
• Scan schedule: screenshots or exports of the configured schedules in each tool
• Dated results: scan reports or dashboard exports across the observation period
• Remediation evidence: tickets for sampled findings, with open and close dates against the SLA
• Risk acceptances: signed decisions for findings or devices that cannot be fixed or scanned

Datadog, Wazuh or Nessus: Pick the SOC 2 Scanner That Covers the Whole Inventory

The best SOC 2 vulnerability scanner for an on-prem company is the combination that covers the whole asset inventory with the least duplicate work. For most bare-metal teams, that means the agent already on the hosts (Datadog or Wazuh) plus a scheduled network scan for the devices no agent can reach. Coverage you can prove beats a longer tool list. The SOC 2 for bare metal and on-prem infrastructure page lists the other controls that change when you run your own hardware.

Related Guides

• SOC 2 Vulnerability Risk Acceptance: What to Do When There Is No Vendor Fix
• SOC 2 Automatic Patching: Do Unattended Security Updates Need a Change Ticket?

Frequently Asked Questions

Is Datadog enough for SOC 2 vulnerability scanning?

Datadog is enough for servers and containers that run the Datadog Agent, since Cloud Security Vulnerabilities detects CVEs in their packages. Datadog does not detect vulnerabilities on firewalls, switches, ESXi hosts or BMCs. On-prem companies add a periodic network scan, such as Nessus, for those devices, or document a firmware review and risk acceptance.

Can Wazuh be used for SOC 2 vulnerability scanning?

Wazuh can serve as the SOC 2 vulnerability scanner for every host running the Wazuh agent. Its vulnerability detection module matches the agent's package inventory against CVE data from the Wazuh CTI feed or an offline copy. Network devices and hypervisors without an agent need a separate network scan or firmware review.

Do we need Nessus for SOC 2?

SOC 2 names no scanning tool, so Nessus is optional. An on-prem company needs some way to check network devices, hypervisors and BMCs, and a credentialed network scanner such as Nessus is the usual choice. Companies with only cloud or agent-capable hosts can often meet CC7.1 with an agent-based tool.

How often should we run vulnerability scans for SOC 2?

The SOC 2 criteria require scans on a periodic basis and after significant changes, and set no fixed interval. A common cadence is continuous or weekly agent-based detection on production hosts, quarterly network scans of infrastructure devices, and a scan after major changes. Scan at the frequency the policy states.

Does Vanta or Drata integrate with Datadog, Wazuh or Nessus?

Vanta imports CVE findings from Datadog Cloud Security and connects to Tenable cloud accounts. Drata connects to Tenable Vulnerability Management, and its vulnerability connection list does not include Datadog, Wazuh or standalone Nessus. Findings from tools without an integration are uploaded as dated scan reports and tickets.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• Datadog, Cloud Security Vulnerabilities
• Datadog, Cloud Security setup on Linux with the Agent
• Datadog, Network Device Monitoring
• Wazuh, Vulnerability detection
• Wazuh, How vulnerability detection works
• Wazuh, Agentless monitoring
• Tenable, Nessus credentialed checks on network devices and APIs
• Tenable, Nessus credential types
• Tenable, Nessus vulnerability scans and compliance audits
• Tenable, Nessus scan schedule settings
• Tenable, Nessus scan reports
• Tenable, Link Nessus Agents to Nessus Manager
• Vanta, Integrating Vanta and Datadog
• Vanta, Vulnerability scanner integrations (checked 2026-10-17)
• Vanta, Connecting Vanta and Tenable Vulnerability Management (FedRAMP)
• Drata, Supported vulnerability connections (checked 2026-10-17)
• Drata, Tenable Vulnerability Management connection
• Drata, Datadog connection