PCI DSS Internal Vulnerability Scan Requirements: What You Must Scan and When

PCI DSS internal vulnerability scans must generally be performed at least once every three months, with high-risk and critical vulnerabilities resolved and rescanned to confirm remediation. Under the current PCI DSS v4.x framework, the internal scanning program also includes authenticated scanning, risk-based handling of lower-ranked vulnerabilities, and additional scans after significant changes.

Copy the asset-to-scan reconciliation record to track authentication failures, missing targets and verification results.

One of the most common mistakes is treating an internal vulnerability scan as the same thing as an external ASV scan or a penetration test. They are separate PCI DSS activities. An internal scan examines vulnerabilities from inside the environment, an external scan tests applicable Internet-facing systems under different requirements, and penetration testing evaluates security more deeply through human-led testing.

As of October 2026, PCI DSS v4.0.1 remains the current version identified through the PCI Security Standards Council’s current-version guidance. Organizations using older PCI DSS checklists should therefore make sure their internal scanning process reflects the v4.x requirements that became fully effective after 31 March 2025.

PCI DSS Internal Vulnerability Scan Requirements at a Glance

The central internal vulnerability-scanning provisions sit under PCI DSS Requirement 11.3.1 and its related sub-requirements. Together, they turn scanning into a continuing vulnerability-management process rather than a quarterly report-generation exercise.

The practical lesson is simple: PCI DSS does not ask an organization merely to schedule a scanner four times a year. The organization needs a repeatable chain of scope → scan → classify → remediate → rescan → retain evidence.

How Often Are PCI DSS Internal Vulnerability Scans Required?

Requirement 11.3.1 states that internal vulnerability scans are performed at least once every three months. A sensible operational schedule therefore distributes the scans throughout the year rather than performing several scans close together simply to create four reports.

The wording matters. PCI DSS uses “at least once every three months.” It is safer to build the compliance calendar around that requirement rather than assuming that any four dates within a calendar year automatically satisfy the intended cadence.

For example, a company could establish recurring scan windows in January, April, July, and October, with enough time after each initial scan for remediation and rescanning. The exact operational dates should fit the organization, provided the applicable PCI DSS timing requirement continues to be met.

This recurring work also has a budget implication. Scanner licensing is only one component. Staff must review findings, create remediation tickets, coordinate system owners, retest fixes, and retain evidence. Businesses estimating the broader program can compare these recurring costs with the considerations in this guide to PCI DSS compliance cost for small businesses.

Quarterly Scanning Is Not the Only Trigger

PCI DSS Requirement 11.3.1.3 adds another trigger: an internal vulnerability scan must also be performed after a significant change.

PCI SSC explains in its FAQ on significant changes that the meaning depends on the environment, but activities that must at least be evaluated include adding new hardware, software, or networking equipment to the cardholder data environment, replacing or substantially upgrading systems, changing account-data flows, changing CDE boundaries, modifying supporting infrastructure, and changing relevant third-party providers or services.

This means that a company should connect vulnerability scanning to its change-management process. If a major firewall replacement, operating-system upgrade, network redesign, payment-data-flow change, or significant infrastructure migration occurs one month after the scheduled quarterly scan, the organization should not simply wait another two months for the next routine scan.

A useful control is to add a question to the change ticket: “Does this change meet our criteria for a PCI DSS significant change, and does it trigger Requirement 11.3.1.3 testing?” That makes the scan decision part of the deployment process instead of something the compliance team discovers during the next assessment.

Authenticated Internal Scanning Is Now Part of the Requirement

Requirement 11.3.1.2 introduced one of the most important operational changes in PCI DSS v4.x: applicable internal vulnerability scans are performed using authenticated scanning. The provision was originally future-dated but became effective after 31 March 2025.

An authenticated scan is allowed to examine a system using suitable credentials rather than looking only at what is visible without logging in. That can give the scanner access to information such as installed software, patch levels, local configurations, and other details that may not be discoverable through a purely unauthenticated network probe.

PCI DSS requires organizations to document systems that cannot accept credentials for authenticated scanning. For systems that can accept them, the credentials need sufficient privileges to allow the scanner to examine the resources necessary for detecting known vulnerabilities.

If a scanning account can also be used for interactive login, its management must satisfy the applicable account-control requirements referenced by PCI DSS. A service account should therefore not become an invisible compliance shortcut with an unnecessarily broad password, indefinite access, or unclear ownership.

Authenticated scanning can be performed using host-based or network-based scanning technology. What matters is whether the implementation actually provides the access required to conduct the intended vulnerability assessment, not whether a product dashboard displays an “authenticated” badge.

Do Post-Change Internal Scans Also Have to Be Authenticated?

There is an important nuance here. The applicability notes for Requirement 11.3.1.3 state that the authenticated internal scanning requirement in 11.3.1.2 is not required for internal vulnerability scans performed after significant changes.

That does not remove the post-change scan requirement. It means the specific authenticated-scanning condition attached to the recurring internal scan process is not automatically imposed on the 11.3.1.3 post-change scan.

Organizations may still choose authenticated scanning when it provides useful coverage. The compliance distinction is simply worth preserving so that the internal procedure does not accidentally turn one requirement into another.

What Systems Should an Internal PCI DSS Scan Cover?

Scan scope should follow PCI DSS assessment scope. Before configuring a scanner, the organization should understand its cardholder data environment, connected systems, security-impacting systems, segmentation boundaries, and other components to which the applicable PCI DSS requirements apply.

This is why a clean asset inventory matters. If the vulnerability scanner contains 75 targets but the PCI scope inventory contains 92 relevant components, the scan report alone does not explain what happened to the other 17.

Conversely, scanning an enormous flat corporate network without understanding PCI scope can create thousands of findings without establishing whether the required systems were actually covered. More scanner output is not automatically better compliance evidence.

A practical scan-scope record should let reviewers connect each relevant system to an asset identifier, IP address or hostname where appropriate, system owner, environment, PCI scope classification, scan method, authentication capability, and latest scan result.

This is also where network architecture can influence cost. A tightly defined CDE can make recurring scanning and remediation easier to operate, while an unnecessarily broad environment can multiply assets and evidence work. The same scope effect appears in ecommerce environments, as discussed in the guide to PCI DSS compliance costs for ecommerce stores.

What Has to Be Fixed After an Internal Scan?

PCI DSS does not reduce internal vulnerability management to a universal scanner score.

Requirement 11.3.1 requires vulnerabilities classified as high-risk or critical according to the entity’s vulnerability risk rankings under Requirement 6.3.1 to be resolved. Rescans then need to confirm that those findings have actually been resolved.

The PCI SSC guidance on vulnerability risk ranking and remediation makes an important distinction: organizations identify and rank vulnerabilities based on their own environment rather than being required to accept an external severity label without evaluation.

That does not mean an organization can casually relabel serious findings as medium risk to avoid fixing them. The ranking process needs to be defensible and based on factors relevant to the entity’s environment and risk.

Lower-Risk Findings Cannot Simply Be Ignored

Requirement 11.3.1.1 deals with applicable vulnerabilities that are not ranked high-risk or critical. These findings must be addressed according to the risk defined through the organization’s targeted risk analysis, with rescans performed as needed.

This closes a loophole that sometimes appears in immature vulnerability programs: teams focus exclusively on whatever the scanner colors red and allow everything else to live forever.

A better operating model assigns remediation expectations based on documented risk. Teams building that process can use a vulnerability remediation SLA to think through ownership, severity, exposure, deadlines, verification, and approved exceptions. The internal policy should still be mapped back to the actual PCI DSS requirements rather than treating a generic SLA as a substitute for them.

Rescanning Is Part of the Requirement, Not an Optional Cleanup Step

Finding a critical vulnerability and closing a remediation ticket is not enough by itself. Requirement 11.3.1 requires rescanning that confirms applicable high-risk and critical vulnerabilities have been resolved.

That creates an evidence chain:

1. Initial scan identifies the vulnerability.
2. The finding receives the required risk classification.
3. A responsible owner remediates the issue.
4. A rescan evaluates the affected system again.
5. The rescan demonstrates that the relevant finding is no longer present or otherwise satisfies the applicable resolution requirement.

Keeping the original result and the validating rescan together makes assessment evidence much easier to review. A ticket marked “fixed” is useful operational evidence, but a ticket and a successful technical verification tell a stronger story.

Does an Internal PCI Scan Have to Be Performed by an ASV?

No. PCI DSS does not require an Approved Scanning Vendor to perform the internal vulnerability scan under Requirement 11.3.1.

The scan can be performed by qualified internal personnel or by an external specialist. However, the personnel need appropriate qualifications and organizational independence from the systems they are testing.

For example, having the individual who administers a network also act as the sole independent scanner of that same network can create the kind of independence problem PCI DSS is trying to avoid. A separate security engineer, security team, or suitably independent external provider may provide a cleaner arrangement.

A QSA is also not inherently required simply because the activity is an internal vulnerability scan. QSA involvement may be appropriate for a broader assessment or when an organization needs specialist help, but the internal scanning requirement itself does not automatically require one.

Internal Scan vs ASV Scan vs Penetration Test

These activities are related, but they are not interchangeable.

A vulnerability scanner generally identifies known weaknesses at scale. A penetration test uses human analysis to investigate how weaknesses can be exploited, combined, or used to cross security boundaries. For a broader explanation of that distinction, see penetration testing vs vulnerability scanning.

The dangerous shortcut is assuming that paying for an annual penetration test eliminates quarterly internal scanning, or that running an internal scanner satisfies an applicable external ASV requirement. Each activity needs to be mapped to the requirement it is intended to satisfy.

Keep the Vulnerability Scanner Up to Date

Requirement 11.3.1 also requires the scanning tool to remain current with the latest vulnerability information.

This sounds obvious until an assessment uncovers a scanner whose application is current but whose vulnerability plugins, signatures, feeds, or detection content have not updated properly for months.

The scan procedure should therefore include a way to verify scanner currency before or as part of each scan cycle. Depending on the product, that might involve documenting the engine version, plugin or feed update timestamp, subscription status, scan policy version, and evidence that required updates completed successfully.

What Evidence Should You Keep?

A technically correct scanning program can become surprisingly painful during an assessment if nobody can reconstruct what happened six months earlier.

Useful evidence commonly includes:

• Internal vulnerability scan reports for each required scan cycle.
• Rescan reports showing remediation of applicable findings.
• The asset inventory and scan-scope records used for each cycle.
• Evidence that authenticated scanning was successfully performed where required.
• Documentation identifying systems unable to accept authenticated-scan credentials.
• Scanner configuration and evidence that vulnerability information was current.
• Risk rankings and the methodology supporting those rankings.
• The targeted risk analysis used to determine handling of other applicable vulnerabilities.
• Remediation tickets and system-owner records.
• Change records showing whether significant changes triggered additional scanning.
• Evidence supporting the qualifications and appropriate independence of the personnel performing the scan.

The objective is not to manufacture an enormous evidence archive. It is to preserve enough information to demonstrate that the process actually operated as required.

Common PCI DSS Internal Scanning Mistakes

Scanning Only Before the Annual Assessment

A once-a-year cleanup does not replace the recurring internal scanning cadence. The calendar should exist before the assessor asks for reports.

Using Only Unauthenticated Scans

Organizations that built their process around older PCI DSS versions may still be running network-only scans without confirming that the current authenticated-scanning requirement is met.

Scanning the Wrong Asset List

A beautifully configured scanner cannot compensate for an outdated PCI scope inventory. Reconcile scope, asset inventory, and scanner targets before each cycle.

Fixing Findings Without Rescanning

A remediation ticket shows that someone performed work. The required rescan provides technical verification that the applicable vulnerability was resolved.

Ignoring Medium and Lower Findings Forever

The fact that high-risk and critical vulnerabilities receive explicit resolution treatment does not make all other vulnerabilities disposable. Requirement 11.3.1.1 establishes risk-based handling for other applicable findings.

Confusing ASV Requirements With Internal Scanning

Buying an ASV service may satisfy an applicable external scanning need, but it does not automatically demonstrate that the internal scanning process is operating correctly.

Forgetting the Significant-Change Trigger

A major migration or CDE change can create a scanning obligation between ordinary quarterly scan dates. Connect the vulnerability process to change management so that those events are visible.

A Practical Quarterly Internal Scan Workflow

A small or midsize team can turn the requirement into a manageable operational routine.

1. Confirm scope. Reconcile the current PCI scope and asset inventory with the scanner target list.
2. Check scanner currency. Verify that the scanning engine and vulnerability information are current.
3. Check authentication. Confirm that eligible systems can be scanned with sufficient credentials and investigate failed authentication.
4. Run the scan. Preserve the original results and scan configuration.
5. Review and rank findings. Apply the organization’s documented vulnerability-risk process.
6. Remediate critical and high-risk findings. Assign owners and track the work to completion.
7. Address other applicable vulnerabilities. Use the targeted risk-analysis process and defined remediation approach.
8. Rescan. Confirm resolution of the findings for which verification is required.
9. Archive evidence. Store reports, rescans, tickets, scope records, and relevant scanner evidence together.
10. Repeat after significant changes. Do not let the ordinary three-month schedule suppress event-driven scanning.

This workflow is intentionally uncomplicated. Compliance gets brittle when scanning lives only in one person’s memory or in a vendor portal nobody opens until assessment week.

Scan cycle or change ID / date / scope inventory version:
Asset ID / system owner / scope basis:
Expected scan method and authorized scan window:
Scanner version / detection-feed date / scan reference:
Reachability result / skipped or incomplete checks:
Authentication supported? / basis and documented limitations:
Authentication actually succeeded? / result evidence:
Credential-management reference (no password or secret):
Scan coverage status / missing assets or resources:
Finding IDs / entity risk ranking / rationale reference:
Remediation or treatment record / owner / target date:
Rescan date / actual verification result / remaining limits:
Unresolved coverage issue / rerun owner / next action:
Reviewer / evidence location / next scheduled scan:

Frequently Asked Questions

Does PCI DSS require internal vulnerability scans every 90 days?

The standard’s wording for Requirement 11.3.1 is at least once every three months. Rather than substituting a different numerical interval, schedule the process so that the three-month requirement is clearly satisfied and retain evidence of each completed cycle.

Can our own security team perform the internal scans?

Yes, provided the personnel are qualified and the required organizational independence exists. Internal scanning does not inherently require a QSA or ASV.

Do internal vulnerability scans have to be authenticated?

For the applicable recurring internal scanning process, Requirement 11.3.1.2 requires authenticated scanning for systems capable of accepting credentials. Systems that cannot accept such credentials must be documented. The applicability notes separately state that 11.3.1.2 authenticated scanning is not required for scans performed after significant changes under Requirement 11.3.1.3.

Do medium- and low-risk vulnerabilities have to be fixed?

They cannot simply be ignored because they are below high or critical. Requirement 11.3.1.1 requires other applicable vulnerabilities to be addressed according to the risk and timeframe established through the entity’s targeted risk analysis, with rescanning as needed.

Is an internal vulnerability scan the same as a penetration test?

No. Vulnerability scanning and penetration testing serve different purposes and sit under different PCI DSS requirements. A scanner primarily identifies known vulnerabilities, while penetration testing adds human-led evaluation of exploitable weaknesses and attack paths.

Build the Process Around Evidence, Not the Audit Date

The cleanest way to meet PCI DSS internal vulnerability scan requirements is to make scanning part of normal security operations rather than a compliance-season project.

Know which systems are in scope. Run the required recurring scans. Make authenticated access work where required. Keep vulnerability content current. Resolve critical and high-risk findings and verify them through rescanning. Apply documented risk treatment to the rest. Trigger additional scanning when significant changes occur.

Finally, keep the reports, scope evidence, remediation records, and rescans connected. A scanner produces findings. A PCI DSS vulnerability-management process demonstrates what the organization did about them.

For the current PCI DSS standard, supporting guidance, assessment documents, and related resources, use the PCI SSC PCI DSS v4.x Resource Hub and the Council’s official document library rather than relying on an older third-party checklist.

Coverage workflow reviewed: 2026-10-23. Added an asset-to-scan record and checked the linked PCI SSC FAQs 1317 and 1597. No scan was run and no system was assessed for this update.