Let’s talk about the internal vulnerability scan — the process regulators expect firms to use to identify cybersecurity risks in systems that handle client data.
Under SEC expectations for investment advisers, firms are required to maintain written cybersecurity policies and procedures and implement safeguards to protect client information (Reg S-P Safeguards Rule). Advisers must also conduct periodic reviews of the adequacy and effectiveness of their policies (Advisers Act Rule 206(4)-7). In practice, that means firms must be able to demonstrate they are identifying vulnerabilities, assessing risk, and taking corrective action — not just running antivirus and hoping for the best.
That is where vulnerability scanning comes in. It is one of the core operational controls that supports those regulatory obligations. It is also where many firms have a blind spot.
There are two reasons I consistently find vulnerabilities your IT staff or MSP does not.
- They are ignoring issues and not telling you the truth. If that is happening, it becomes obvious very quickly during an audit.
- They are performing the scan incorrectly.
Your “IT guy” may be internal staff or an outside MSP. In both cases, their primary job is keeping systems operational — not performing attacker-level security measurement. That difference is where risk hides.
This article is written for non-IT executives. You do not need to run the tools yourself. But you do need to understand enough to ask the right questions.
Real-World Test Case: Internal Scanning vs. Remote Scanning
The vast majority of IT folks perform these audits remotely. Why? Because it is much easier to do it that way and they are choosing the lazy method.
I ran the same vulnerability assessment two different ways for an RIA with one office location:
- A physical scanner deployed inside the office network by connecting it to a switch inside the office
- A scanner running remotely through a secure tunnel from the cloud to the local network
The remote method is how many IT providers attempt scanning today, using a setup that involves a cloud server, an offsite VM, a laptop over VPN, or an overlay connection such as Tailscale or WireGuard.
The issue is not effort. It is network mechanics. A scanner inside the network sits in the broadcast domain. A remote scanner is routed in. That difference breaks major discovery and enumeration mechanisms that internal vulnerability scanning depends on.
If you have gone through an audit with MTradecraft, you have seen one of the small NUC devices we ship to offices so that we can run Nessus and perform the vulnerability scan locally. Those boxes are how we ensure we are seeing everything on the internal network and building compliance reports that reflect the full environment.
Here is what gets lost when the scanner is not Layer-2 adjacent to the environment it is assessing and is operating from the cloud through a tunnel:
- ARP-based host discovery (you cannot reliably “see” everything alive)
- Broadcast discovery (many devices only show up here)
- SMB/NetBIOS enumeration reliability
- mDNS/LLMNR visibility
- Printer and IoT discovery
- Management interface detection for switches, cameras, appliances
- Ephemeral port observations and service fingerprinting accuracy
In one head-to-head test — a NUC inside the network versus a Nessus deployment on a cloud provider connected through WireGuard — that blindness showed up as:
- 21 devices that were not even detected remotely
- 40 fewer plugin families triggered (121 versus 81)
- 1,820 fewer findings reported
- 121 fewer medium-severity issues uncovered
That is not insignificant. That is the difference between seeing the internal attack surface and missing it.
Why This Matters for Non-IT Executives
If you lead a firm, you do not need to become a vulnerability engineer. You need to be able to ask questions that force operational clarity.
Instead of asking, “Are we doing vulnerability scans?” — which always gets a “yes” — you want questions that force both technical clarity and documented proof. Ask your IT team or MSP:
- Where is the scanner physically running from — inside our office network or remotely? And can you provide documentation (scan configuration, deployment notes, or architecture diagrams) showing how the scanner is positioned for internal assessments?
- How are hosts being discovered? Are you using ARP and broadcast discovery inside the LAN, or just scanning a static IP list? Can you produce scan logs or reports that show discovery methods and the full list of assets identified during the last scan cycle?
- How many hosts were discovered during the last scan compared to our expected asset inventory? Can you provide historical scan reports that demonstrate asset discovery trends and document how newly found devices are tracked and resolved?
- Are non-PC devices being scanned — printers, switches, cameras, NAS devices, and other infrastructure? Can you show reports or scan scopes proving these device classes are included, not just user workstations?
- What changed between the last scan and this one? What new devices appeared, what new services were exposed, and what vulnerabilities were added or remediated? Do you maintain documented scan histories and remediation tracking that we could provide to an examiner?
- How often are internal vulnerability scans performed, and where is that schedule documented? Is this part of our written cybersecurity procedures, and do we retain evidence of scan execution?
- Who reviews scan results and how is remediation tracked? Can you provide tickets, change logs, or remediation reports tied to actual scan findings?
- If the SEC asked for proof that we are monitoring internal vulnerabilities on an ongoing basis, what documents would we hand them? Do we have archived scan reports, logs, and summaries organized in a way that supports an examination?
These questions shift the conversation with IT from “we run scans” to “can you prove it, show coverage, and demonstrate operational follow-through?” That is the difference between IT activity and regulator-defensible cybersecurity operations.
Bottom Line
If your IT provider is performing vulnerability scans remotely and labeling them as internal assessments, you are operating with an incomplete view of risk — and incomplete evidence for compliance.
The test case makes that clear. A remote scan can look thorough on paper while missing entire device classes, services, and vulnerabilities that exist inside your network.
That gap is why firms pass routine IT reviews yet struggle to demonstrate real operational cybersecurity during audits and examinations.
It is also why I consistently uncover exposures others miss. Not because the tools are different — but because the vantage point is.
Real internal visibility only comes from scanning inside the network, where attackers operate after initial access. That is the perspective that reveals the true attack surface and produces documentation that actually supports a defensible cybersecurity program.
If your IT provider runs scans remotely through a tunnel and you are not certain what that misses, an internal scan from inside the network will show you. Producing that evidence, mapped to your SEC obligations, is part of the work we do.