PCI Vulnerabilities: Finding Them Is Easy — Proving You Fixed Them Is the Hard Part

PCI vulnerability requirements look simple on a slide: scan, fix, rescans until clean.

In practice, teams drown in CVEs, argue about false positives, lose track of which hosts are in CDE scope, and scramble for evidence the week the QSA arrives. The scanners worked. The program didn't.

Vulnerability management for PCI is less about discovering more issues and more about running a closed loop: inventory → scan → triage → remediate → verify → evidence — with scope that matches reality.

What PCI actually expects (in plain language)

Depending on your SAQ or ROC path, you are generally expected to:

• Run internal and external vulnerability scanning on a defined cadence.
• Use an Approved Scanning Vendor (ASV) for external scans where required.
• Address high-risk / critical issues on a timeline that matches the standard and your policies.
• Keep proof: scan reports, exceptions with rationale, remediation tickets, and clean rescans.

The standard does not reward the largest backlog. It rewards a program that can show the environment was assessed, risk was handled, and verification happened.

Where programs break

Scope fog. If you can't say which systems are in scope for PCI, every scan result is debatable. Shadow assets and "temporary" cloud projects quietly become reportable gaps.

Scan ≠ program. Exporting a PDF from the ASV portal is not vulnerability management. Without owners, SLAs, and verification, it's a screenshot collection.

Severity theater. Treating every CVSS 9.8 as equal — including issues on non-exploitable paths or out-of-scope segments — burns the team and trains leadership to ignore the queue.

Exception limbo. Risk acceptances without expiry, owner, or compensating control become permanent holes that still look "managed" in a spreadsheet.

Rescan amnesia. Fixed in prod, never rescanned, still open in the auditor's eyes. If it isn't verified, it isn't closed.

Tool sprawl. Cloud provider findings, container scanners, ASV output, and endpoint agents all speak different languages. Nobody consolidates into one remediation spine.

Build a PCI-ready vuln loop

1. Freeze a living inventory

Maintain an authoritative list of in-scope assets: hosts, URLs, APIs, containers, and shared services that touch account data or segment the CDE. Inventory drift is the root cause of most "surprise" ASV failures.

2. Separate discovery from duty

Let scanners find everything they're good at finding. Then map each finding to:

• In scope or not
• Exploitability in your environment
• Owner and due date
• Fix, mitigate, or accept (with expiry)

PCI cares that in-scope, relevant risk is handled — not that you personally remediated every informational finding on a marketing microsite.

3. Triage with a written rulebook

Write down how you promote or demote severity: network exposure, auth boundaries, compensating controls, asset criticality. When the QSA asks why a CVSS critical was treated as medium, you answer with policy — not improvisation.

4. Remediate through the same system engineering already uses

If fixes live only in the scanner UI, they die there. Ticket the work in Jira/Linear (or equivalent), link the CVE and asset, and require a verification note on close.

5. Rescan like it's part of the fix

Closing a ticket should mean: change deployed and scanner/ASV no longer reports the issue (or an approved exception is on file). Build rescans into the definition of done.

6. Keep evidence boring and complete

For each cycle, retain:

• Scope list used for the scan
• Raw and attested reports (ASV and internal)
• Ticket exports for highs/criticals
• Exceptions with approver and expiry
• Final clean / residual-risk summary

Boring evidence is good evidence. Creative storytelling is what happens when the loop was broken.

ASV-specific reality checks

External ASVs will fail you for issues that feel "not our app" — shared hosting headers, mail servers, forgotten subdomains. Treat DNS and attack-surface hygiene as part of PCI prep, not a last-minute surprise.

Schedule ASV runs early enough to allow remediation + rescan before deadlines. A first scan three days before card-brand reporting is a self-inflicted incident.

Exceptions without self-owning

Some findings can't die on the PCI timeline (vendor dependency, platform limitation). An acceptable exception includes:

• Precise finding and asset
• Business rationale
• Compensating control
• Named approver
• Expiry and revisit date

An exception without an ending date is just an open vulnerability with better formatting.

What "good" looks like to a QSA

You can explain scope. You can show cadence. You can show that highs were fixed or formally accepted. You can show rescans. You aren't discovering brand-new in-scope subnets in the interview.

That bar is operational excellence, not heroics.

Start this sprint

• Reconcile ASV targets with your current DNS and inventory.
• Define SLA by severity for in-scope assets only.
• Require rescan proof on ticket close.
• Expire every standing exception older than 90 days — renew deliberately or fix.
• Assign a single owner for the vuln loop (not "the security team").

Do those five and the next ROC/SAQ conversation gets shorter — because the story is already true in the tooling.

Need vulnerability management that stays audit-ready between ASV runs?

At Episki, we help teams connect scanning, ownership, and evidence so PCI requirements show up as an operated program — not a quarterly fire drill.

Let's talk →

Scanners find vulnerabilities. Programs close them — and can prove it.