Internal vs external vulnerability assessment: what each one proves to a regulator
Sienna VanceApril 29, 2026
Key takeaways
Internal and external vulnerability assessments produce different categories of evidence. Regulators and forensic investigators treat them as separate obligations, not interchangeable alternatives.
Authenticated internal scans surface three to five times the finding count of unauthenticated runs against the same hosts. The unauthenticated result is not wrong, it is structurally incomplete.
PCI DSS Requirement 11.3.1 mandates authenticated internal scanning. Running unauthenticated internal scans and retaining the reports as compliance evidence is a documentation gap that QSAs frequently miss because they review results, not configuration.
Scope accuracy is an evidence decision. Systems handling regulated data that were excluded from scan scope because no one mapped the data flows are not protected by compliance records that did not include them.
HIPAA, ISO 27001, and SOC 2 each treat internal and external assessment as distinct obligations with distinct evidence standards. The specific evidence each framework requires differs in ways that change how assessments should be configured and documented.
The most common internal scanning failure in Vulnox assessments is not missed findings. It is authenticated scans that were never configured as authenticated.
TL;DR
Internal and external vulnerability assessments are not the same exercise run from different vantage points. They produce different evidence, satisfy different regulatory obligations, and reveal different categories of risk. Most organizations treat them as a combined program and document them loosely. That works until a regulator or forensic investigator asks for the authenticated internal scan configuration logs and the cardholder data discovery output, which is when the gap between what was run and what was required becomes visible.
The assessment that satisfied the auditor and failed the investigation
A healthcare SaaS company operating under HIPAA completed their annual security evaluation using an external vulnerability scan from an approved vendor and an internal scan run by their IT team. Both produced clean or near-clean results. The compliance documentation was thorough. When a breach investigation opened after unauthorized access to a patient data repository, the investigator's first request was the authenticated internal scan configuration, the scan history showing which hosts were in scope, and the access control evaluation documentation required under the HIPAA Security Rule. The external scan results were reviewed and set aside. The internal scan reports were reviewed and flagged immediately: the scans had been run without authenticated credentials, which meant they had been operating in unauthenticated mode against internal hosts, producing results that looked like a clean external scan run from inside the network perimeter.
The compliance record showed a scanning program. The investigation found a scanning program that did not meet the authenticated assessment obligation the Security Rule's risk analysis implies. The gap was not a missed critical finding. It was a configuration decision made when the internal scanning tool was first deployed, never reviewed, and never questioned in any subsequent audit because no auditor had asked to see the scan configuration. The breach path ran through a misconfigured internal authentication service that an authenticated scan would have surfaced.
What each assessment type actually produces
The distinction between internal and external vulnerability assessment is not primarily about network location. It is about what each type of assessment can access and therefore what evidence it produces. External assessments operate without credentials. They examine what is visible from outside the network perimeter: open ports, exposed services, software versions detectable through banner grabbing, SSL and TLS configurations, and vulnerabilities in externally accessible applications. This is the attacker's view before they have any access to the environment. It produces evidence of perimeter exposure. Internal assessments, when configured correctly with authenticated credentials, operate with a session on each target system. They examine locally installed software inventories, service configurations, registry and file permission states, patch levels that are not detectable externally, and privilege escalation paths that depend on internal trust relationships. The finding categories are different. The evidence produced is different. And the regulatory obligation each type satisfies is different.
Example
Consider a web server running an outdated version of a service where the version number is suppressed in external responses. An external scan may identify the server as a target but cannot confirm the specific version without active exploitation. An authenticated internal scan reads the installed software inventory directly and identifies the version with certainty. The external scan produces a finding that requires follow-up. The authenticated internal scan produces a confirmed finding with remediation specificity. For a PCI DSS assessment, both findings would appear in the compliance documentation, but they carry different evidentiary weight. For a forensic investigation, only the authenticated finding tells the investigator what the software state actually was.
The authentication gap matters most in environments where patch management is inconsistent across network segments. An unauthenticated internal scan will find what is visible from the network, which on a well-segmented internal network may be considerably less than what is installed on each host. Organizations that run unauthenticated internal scans in segmented environments are producing scan results that reflect their segmentation quality more than their patch state. The compliance record looks cleaner than the actual environment.
Patterns from assessment engagements
Assessment base: Vulnox vulnerability assessment engagements across retail, e-commerce, healthcare, and SaaS environments, 2023 to 2025
Internal scans configured without authentication, documented as compliant
In Vulnox assessments where we review existing scan configurations before conducting our own assessment, we find internal scans that are running on schedule, producing reports, being retained as compliance documentation, and operating entirely in unauthenticated mode. The scan tool is pointed at internal hosts without credential configuration. The reports show findings against exposed services, which may look reasonable for a network with limited internal exposure. The authenticated software inventory, configuration state, and privilege path findings are absent because the scan never had access to produce them. The QSA reviewed the reports and saw results. The results were real and incomplete in a way that requires looking at the configuration to detect.
This is the most consequential finding type because it is invisible in the compliance record. The organization has a documented internal scanning program. The program does not satisfy PCI DSS Requirement 11.3.1's authenticated scanning obligation, or the equivalent obligation under whatever framework applies. The gap will remain invisible until an auditor specifically requests scan configuration documentation or until a forensic investigation reveals the finding category that the authenticated scan would have produced.
Scope definitions that exclude systems handling regulated data
In Vulnox assessments that include a cardholder data or personal data discovery phase, we consistently find systems outside the defined scan scope that are touching, logging, or caching regulated data. The most common sources are legacy integrations retained after technology migrations, developer and staging environments connected to production APIs during testing, and logging infrastructure that captures request bodies before tokenization or anonymization occurs. These systems were not in scope because no one mapped the data flows carefully enough to find them. The vulnerability scanning program, both internal and external, was correctly scoped to what the organization believed was relevant.
Scope accuracy is not a scanning problem. It is a data mapping problem. But it produces a scanning gap: vulnerabilities on out-of-scope systems never appear in the compliance record, and those systems are frequently assessed less rigorously than in-scope systems precisely because they are not subject to the formal scanning program. In a breach investigation, the investigator reconstructs actual data flows from logs and network captures. If regulated data appears on out-of-scope systems, the compliance record that excluded them does not provide protection.
Change-triggered internal scans that are not triggered by the changes that matter
Most compliance frameworks that require internal vulnerability scanning also require rescans after significant environmental changes. The definition of significant is left to the organization. In Vulnox assessments, the organization's documented definition consistently excludes changes that, in a post-incident review, would clearly qualify: new API integrations, third-party service additions, platform migrations between hosting providers, and major application deployments. These are classified as routine operational changes that fall below the threshold for triggering a rescan. The quarterly scan cycle continues. Changes accumulate between scans. Vulnerabilities introduced by those changes have a window of undocumented exposure that can extend to 90 days.
The combination of quarterly scanning cadence and a narrow definition of significant change means the internal scan program has a structural gap between what the compliance documentation implies and what was actually assessed. Forensic investigators who request change control logs alongside scan history can identify this gap directly: the change date falls between two scan dates, the compromise date falls in the same window, and the entry point was a vulnerability introduced by the change.
What each framework actually requires
PCI DSS v4.0
Requirement 11.3.1 requires authenticated internal scans quarterly and after significant changes, with rescans until high and critical findings are resolved and rescan results retained. Requirement 11.3.2 requires external ASV scans quarterly, producing passing certificates. The two are separate obligations with separate documentation requirements. Most organizations retain ASV certificates reliably and internal scan reports variably. The authenticated credential configuration documentation is rarely retained.
A QSA who reviews internal scan reports without requesting configuration evidence cannot determine whether the authenticated scanning obligation was met. Organizations should retain scan configuration logs alongside scan reports. If the configuration shows unauthenticated mode, the report does not satisfy Requirement 11.3.1 regardless of what findings it contains.
HIPAA Security Rule
The Security Rule's risk analysis requirement at 164.308(a)(1) requires a thorough assessment of potential risks and vulnerabilities to electronic protected health information. This is broader than a vulnerability scan and includes access control evaluation, audit log review, and system configuration assessment. The rule does not specify scan frequency or authentication requirements, which means covered entities have discretion, and that discretion is evaluated in breach investigations by reference to what a reasonable covered entity would have done.
HIPAA's flexibility is a trap for organizations that interpret it as permission to run minimal scanning programs. In breach investigations, OCR and forensic investigators assess whether the risk analysis was sufficiently thorough given the organization's size, complexity, and the sensitivity of the data. An unauthenticated external scan documented as the annual technical evaluation is unlikely to satisfy that standard for a covered entity handling significant volumes of protected health information.
ISO 27001:2022
Control 8.8 requires management of technical vulnerabilities, with the specific scanning cadence and methodology left to the organization's risk assessment. The standard does not distinguish between internal and external scanning as separate obligations. The ISMS audit will assess whether the vulnerability management process is adequate for the organization's risk profile. What adequate means depends on what risks the organization's risk assessment identified, which creates a documentation dependency between the risk assessment and the scanning program.
ISO 27001 auditors who review the risk assessment and find that external attack surface exposure was identified as a significant risk will expect external scanning evidence. If the same risk assessment identified insider threat or lateral movement as significant risks, they will expect internal authenticated scanning evidence. The scanning program should map directly to the risk assessment findings. Disconnects between identified risks and scanning program coverage are a common audit finding.
SOC 2 Type II
The Common Criteria related to logical access and system operations require evidence of vulnerability identification and remediation processes over the audit period, typically twelve months. SOC 2 auditors review scan reports, remediation tickets, and change management records to assess whether the process operated consistently. The distinction between internal and external scanning matters less than whether the process covered the systems in scope for the SOC 2 engagement and whether remediation was documented.
SOC 2 Type II auditors are reviewing process consistency over time, not technical adequacy of a single scan. An organization that ran external scans consistently but internal scans sporadically will have a process consistency gap. An organization that ran both consistently but did not document remediation for internal findings will have a remediation evidence gap. The audit covers the period, not a point in time.
The finding that looks like a scan result but is a scope failure
Common belief
Organizations treat a clean or near-clean vulnerability scan result as evidence that the environment was adequately assessed. The logic is that if the scan found nothing significant, the environment is in reasonable shape. This is how scan results are presented in compliance documentation and how most audit reviews interpret them.
What we found
The most difficult finding to communicate in a Vulnox assessment is not a critical vulnerability. It is the finding that the scan scope was materially incomplete. When we present out-of-scope systems that are handling regulated data, the initial response from internal teams is frequently that those systems were not in scope, which is accurate, and were therefore not assessed, which is also accurate, and is the problem. The compliance documentation shows a comprehensive scanning program. The coverage was not comprehensive. The documentation and the reality are not the same thing, and the documentation does not protect you when the reality is what the investigation finds.
A clean scan result tells you that what was scanned had no significant findings. It says nothing about whether what was scanned was the right set of systems. An authenticated internal scan of a well-patched set of in-scope servers can produce a completely clean report while systems outside the defined scope, handling regulated data that was never mapped, carry critical unpatched vulnerabilities. The clean report is accurate. The scope is wrong. And the compliance record built on that report has a gap that the report itself cannot reveal.
Where the evidence standard is heading
Regulators across GDPR, HIPAA, and PCI will begin requesting scan configuration documentation, not just scan results, as a standard element of breach investigation evidence requests within the next two years. Organizations that cannot produce authenticated credential logs alongside internal scan reports will face a presumption of inadequate assessment.
The pattern of unauthenticated internal scans documented as compliant is consistent enough across environments that regulators will eventually standardize the configuration evidence request. The technical sophistication of forensic investigators reviewing breach cases has increased, and the gap between unauthenticated and authenticated scan results is well understood in the forensic community. What has lagged is the formalization of configuration evidence as a standard request. That formalization is the next logical step.
Confidence: mediumIf PCI SSC, OCR, or EDPB guidance documents published after 2025 include specific references to scan configuration documentation as required evidence, this prediction is confirmed. If breach investigation outcome summaries from those regulators begin citing unauthenticated scanning as a contributing compliance failure, it is confirmed earlier.Organizations that define significant environmental change narrowly enough to avoid triggering rescans will face a named audit finding category within PCI DSS QSA guidance within three years, as the gap between change cadence and scan cadence becomes a documented breach contributing factor in enough cases to require a specific control response.
The change-trigger gap is structural. Quarterly scan cadences were designed for environments that changed quarterly. Modern environments change continuously. The mismatch between change frequency and scan frequency is visible in post-breach forensic timelines, where the entry point vulnerability was introduced between scan dates. As this pattern accumulates in published forensic reports and breach disclosures, the pressure to formalize a more specific change-trigger definition in audit guidance will increase.
Confidence: mediumPCI DSS supplemental guidance or QSA training materials published after 2026 that provide a more specific definition of significant change, or that cite change-trigger failures as a named finding category in compliance assessments.
The evidence question organizations are not asking
Most conversations about internal versus external vulnerability assessment focus on coverage, which type finds more, which type is required, how to run both efficiently. The more useful question is what each type proves to the person who will evaluate your compliance record under adversarial conditions. That person is not the annual auditor who reviews reports. That person is the forensic investigator who will reconstruct what your environment actually looked like at the time of a breach, or the regulator who will evaluate whether your risk analysis was adequate given the data you held. When you frame the question that way, the gap between running a scanning program and running a scanning program that produces durable evidence of adequate assessment becomes much clearer. The organizations that get this right are the ones that design their scanning programs by working backward from the evidence request, not forward from the compliance checklist.
Counterargument
The counterargument is that most organizations will never face a breach investigation, and designing a scanning program around the evidentiary demands of an adversarial proceeding is a disproportionate response to a low-probability event. The practical priority should be finding and fixing vulnerabilities, not producing evidence that might never be needed. That argument is reasonable for small organizations with limited resources. It becomes less reasonable as the organization grows, as the data it holds becomes more sensitive, and as the regulatory exposure from a breach increases. At a certain scale, the distinction between a scanning program that fixes vulnerabilities and a scanning program that produces evidence of having fixed them is not a luxury consideration. It is a risk management decision.
One thing to check before the next audit
Pull the configuration documentation for your last internal vulnerability scan. Not the report. The configuration. Look for the credential settings and verify whether the scan was run in authenticated mode against each host type. If that documentation does not exist, or if the scan was unauthenticated, you have a gap between your compliance record and your actual scanning obligation under whatever framework applies to your environment. That gap is fixable before an auditor or investigator finds it. Configuring authenticated scanning and retaining the configuration logs alongside the scan reports costs nothing additional in tool spend. It produces the evidence that the unauthenticated scan cannot.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentGap Analysis
framework gap analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkOWASP Testing Methodologies
OWASP testing methodologies
Frequently Asked Questions
What is the difference between internal and external vulnerability assessment for compliance purposes?
Internal vulnerability assessments examine systems behind the network perimeter using authenticated access, producing evidence of configuration state, software inventory, and privilege escalation paths. External assessments examine what is visible from the internet without credentials, producing evidence of perimeter exposure. Most compliance frameworks, including PCI DSS and ISO 27001, treat these as separate control obligations with separate evidence requirements. Running only one and documenting it as both creates an audit gap.
What evidence does an internal vulnerability scan produce that an external scan cannot?
Authenticated internal scans produce software version inventories, service configuration findings, local privilege states, and lateral movement paths that are invisible to unauthenticated external scanning. PCI DSS Requirement 11.3.1 specifically requires authenticated internal scanning for this reason. In Vulnox assessments, authenticated internal scans consistently surface three to five times the finding count of unauthenticated runs against the same hosts. That gap is what regulators and forensic investigators are looking for when they request internal scan documentation.
How often should internal vs external vulnerability assessments be performed?
PCI DSS requires both internal and external scans quarterly, plus internal scans after significant environmental changes. ISO 27001 requires scans at planned intervals with no specific cadence defined, leaving the frequency determination to the organization's risk assessment. HIPAA requires periodic technical evaluation but specifies no interval. The practical answer depends on the rate of environmental change: environments with frequent deployments need change-triggered scans between quarterly cycles, and the definition of significant change is an evidence decision as much as an operational one.
What do forensic investigators request from vulnerability assessment programs after a breach?
Based on Vulnox post-incident review experience, forensic investigators request authenticated internal scan configuration documentation, the scan history showing what was in scope, change control records showing what changed between the last scan and the compromise date, and cardholder data discovery output for PCI-relevant incidents. The external ASV certificate is noted but rarely determinative. The internal scan program documentation, specifically whether scans were authenticated and whether scope was accurate, is what drives investigation outcomes.
Why do organizations fail internal vulnerability scan requirements while passing external scans?
External scans are typically outsourced to approved vendors who produce certificates. Internal scans require the organization to configure, authenticate, and document the scanning program themselves. In Vulnox assessments, internal scans configured without authenticated credentials are a consistent finding. The scan runs, produces a report, satisfies a QSA who does not review the configuration, and is retained as compliance evidence for an obligation the organization has not actually met.
What is the regulatory risk of incomplete vulnerability scan scope?
Scope exclusions become a liability in breach investigations. If a forensic investigation finds that card data, personal data, or regulated information existed on systems outside the defined scan scope, the compliance record does not protect the organization. Regulators reconstruct actual data flows from logs and network captures, not from scope documentation. In Vulnox assessments of retail and e-commerce environments, undocumented systems handling regulated data appear in the majority of engagements.
How do internal and external vulnerability assessments differ for HIPAA compliance?
HIPAA's Security Rule requires a technical and non-technical evaluation of how the security policies and procedures meet the requirements of the rule. This is broader than a vulnerability scan and includes system configuration review, access control evaluation, and audit log assessment. External vulnerability scanning addresses perimeter exposure but does not satisfy the internal evaluation obligation. Organizations that rely solely on external scans for HIPAA technical evaluation are missing the authenticated internal assessment that the rule's risk analysis requirement implies.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.