06 Vulnerability Management

Vulnerability management is the process of identifying, assessing, prioritizing, remediating, and validating security weaknesses across systems that support the Cardholder Data Environment (CDE).

A PCI vulnerability management program should answer:

What assets are in scope?

Which vulnerabilities affect them?

How serious are those vulnerabilities?

Who owns remediation?

How quickly must they be fixed?

What happens when they cannot be fixed?

How do we prove remediation?

A practical lifecycle looks like:

CDE Asset Inventory
      ↓
Vulnerability Discovery
      ↓
Risk Classification
      ↓
Remediation Priority
      ↓
Patch / Mitigation
      ↓
Exception if Required
      ↓
Retesting
      ↓
Closure
      ↓
Continuous Monitoring

Learning Objectives

By the end of this lesson, you will be able to:

Explain PCI vulnerability management.
Understand asset coverage requirements.
Identify vulnerability sources.
Understand vulnerability severity and risk.
Build remediation SLAs.
Understand patch management.
Understand malware protection.
Understand internal vulnerability scanning.
Understand external ASV scanning.
Understand scan failures.
Understand vulnerability exceptions.
Understand compensating controls.
Understand retesting.
Build vulnerability registers.
Build patch-compliance dashboards.
Track overdue vulnerabilities.
Collect PCI vulnerability evidence.
Identify common PCI vulnerability-management gaps.
Support assessors during vulnerability-control testing.

1. Why Vulnerability Management Matters

Payment systems are exposed to vulnerabilities across:

Operating Systems

Applications

Databases

Cloud Services

Containers

Network Devices

Libraries

Web Applications

Attackers routinely exploit known weaknesses.

A basic attack path may look like:

Known Vulnerability
      ↓
Exploit
      ↓
CDE System Compromise
      ↓
Privilege Escalation
      ↓
Payment Data Exposure

2. Vulnerability Management Is More Than Scanning

Weak model:

Run Scanner
      ↓
Generate Report
      ↓
Done

Strong model:

Discover
      ↓
Prioritize
      ↓
Assign
      ↓
Remediate
      ↓
Retest
      ↓
Close

3. Start With Asset Inventory

You cannot reliably manage vulnerabilities on systems you do not know exist.

Your vulnerability program should align with:

PCI In-Scope Asset Register

Ask:

Are all CDE assets scanned?

Are cloud resources included?

Are network devices included?

Are containers included?

Are internet-facing systems included?

4. Build Vulnerability Coverage Register

Create:

01 PCI Vulnerability Coverage Register

Use:

Asset	In Scope	Scanner Coverage	Last Scan	Owner

5. Coverage Target

For applicable in-scope assets:

Target:
100% Coverage

Unknown or unscanned systems create assurance gaps.

6. Vulnerability Sources

Organizations may identify vulnerabilities through:

Internal Vulnerability Scans

External Scans

ASV Scans

Penetration Testing

Application Security Testing

Cloud Security Tools

Container Scanning

Vendor Advisories

Threat Intelligence

Security Research

7. Internal Vulnerability Scanning

Internal scanning helps identify weaknesses within the environment.

Examples:

Missing Patches

Weak Services

Unsupported Software

Misconfiguration

Known CVEs

8. External Vulnerability Scanning

External scanning focuses on:

Internet-Facing Systems

such as:

Payment Websites

VPN

Public APIs

Remote Access Gateways

9. ASV Scanning

An Approved Scanning Vendor, or:

ASV

performs external vulnerability scans used for applicable PCI validation requirements.

Typical flow:

Internet-Facing PCI Assets
      ↓
ASV Scan
      ↓
Findings
      ↓
Remediation
      ↓
Rescan
      ↓
Passing Result

10. ASV Is Not the Entire Vulnerability Program

ASV scanning does not replace:

Internal Scanning

Patch Management

Application Testing

Penetration Testing

Continuous Vulnerability Management

11. Build ASV Scan Register

Create:

02 ASV Scan Register

Use:

Scan Date	Scope	Result	Findings	Rescan	Status

12. Scan Scope

Before scanning confirm:

Public IPs

Public DNS

Internet-Facing Applications

Remote Access Systems

are correctly included.

13. Scope Gap Example

Actual:

12 Internet-Facing CDE Assets

ASV scope:

Result:

2 Assets Missing From Scan

This is a PCI vulnerability-management gap.

14. Internal Scan Register

Create:

03 Internal Vulnerability Scan Register

Use:

Scan	Environment	Assets	Findings	Pass / Fail	Owner

15. Scan Frequency

Vulnerability scans should occur according to applicable PCI requirements and after significant changes where required.

A mature program may scan more frequently:

Daily

Weekly

Monthly

Continuous

depending on technology and risk.

16. Significant Change

Examples:

New Server

Major Application Release

Firewall Change

New Cloud Account

New Payment Service

Network Redesign

may trigger additional vulnerability assessment.

17. Vulnerability Identification

Each vulnerability record should contain:

Vulnerability ID

Asset

Description

Severity

Discovery Date

Owner

Remediation Target

Status

18. Build CDE Vulnerability Register

Create:

04 CDE Vulnerability Register

Use:

ID	Asset	Severity	Discovered	Due	Owner	Status

19. CVE

Many vulnerabilities are identified through:

CVE

or Common Vulnerabilities and Exposures identifiers.

Example:

CVE-20XX-XXXXX

20. CVSS

Severity may be supported by:

CVSS

or Common Vulnerability Scoring System values.

However:

CVSS
≠
Complete Enterprise Risk

21. Risk Context

Consider:

CVSS

CDE Exposure

Exploitability

Internet Exposure

Privilege Required

Data Sensitivity

Active Exploitation

Compensating Controls

22. Example — Same CVE, Different Risk

Asset A:

Internal Test Server

Asset B:

Internet-Facing Payment API

Same vulnerability.

Different business risk.

23. Vulnerability Classification

A practical classification model:

Critical

High

Medium

Low

The organization should define how findings map to remediation requirements.

24. Remediation SLA

Create documented remediation timelines.

Example organizational model:

Severity	Target
Critical	15 Days
High	30 Days
Medium	60 Days
Low	90 Days

Actual PCI obligations and organizational policies should be aligned appropriately.

25. Build Vulnerability SLA Tracker

Create:

05 Vulnerability SLA Tracker

Use:

Vulnerability	Severity	Open Date	Due Date	Days Open	SLA

26. Critical Vulnerability Example

Discovery:

01 June

Target:

15 June

Remediated:

25 June

Result:

SLA Missed

27. Why SLA Monitoring Matters

Without monitoring:

Finding
      ↓
Ticket
      ↓
Forgotten

With monitoring:

Finding
      ↓
Due Date
      ↓
Reminder
      ↓
Escalation
      ↓
Closure

28. Patch Management

Many vulnerabilities are remediated through security patches.

A practical patch lifecycle:

Vendor Patch
      ↓
Risk Review
      ↓
Testing
      ↓
Approval
      ↓
Deployment
      ↓
Validation

29. Patch Management Scope

Include relevant:

Operating Systems

Network Devices

Databases

Applications

Libraries

Containers

Hypervisors

30. Patch Inventory

Maintain visibility of:

Current Version

Available Security Update

Patch Status

Owner

31. Build Patch Compliance Dashboard

Create:

06 Patch Compliance Dashboard

Track:

Metric	Target
Critical Patches Within SLA	100%
High Patches Within SLA	100%
Unsupported CDE Systems	0
Unknown Patch Status	0

32. Patch Testing

Patches may affect payment systems.

Strong process:

Patch
      ↓
Test
      ↓
Approve
      ↓
Deploy
      ↓
Verify

Do not use:

Testing Risk

as a permanent excuse for not remediating critical vulnerabilities.

33. Emergency Patching

Critical vulnerabilities may require expedited processes.

Example:

Active Exploitation
      ↓
Emergency Change
      ↓
Patch
      ↓
Validation

34. Zero-Day Vulnerability

A zero-day may have:

No Vendor Patch

Immediate controls may include:

Disable Service

Restrict Network Access

WAF Rule

IPS Signature

Configuration Change

Enhanced Monitoring

35. Compensating / Mitigating Controls

When immediate patching is not possible, temporary mitigation may reduce risk.

Example:

Vulnerable Service
      ↓
Restricted to Admin Network
      ↓
WAF / IPS
      ↓
Enhanced Monitoring

But the underlying vulnerability should still be tracked.

36. Vulnerability Risk Exception

If remediation cannot meet the required timeline, use formal risk governance.

Create:

07 Vulnerability Risk Exception Register

Use:

Vulnerability	Reason	Risk	Mitigation	Approver	Expiry

37. Exception Should Not Be Permanent

Every exception should include:

Owner

Business Reason

Risk

Mitigation

Approval

Expiry

Review

38. Weak Exception

System Too Important to Patch

with:

No Expiry

No Mitigation

No Owner

is not strong risk governance.

39. Strong Exception

Example:

Patch cannot be deployed until vendor certification is completed. External access has been blocked, IPS controls applied, enhanced logging enabled, and remediation is scheduled within 30 days.

40. Exception Expiration

When:

Expiry Date Reached

the exception should:

Close

Renew Through Approval

Escalate

not silently continue.

41. Malware Protection

PCI vulnerability management also includes protection against malicious software where applicable.

Malware-related controls may include:

Endpoint Protection

EDR

Anti-Malware

Behavior Monitoring

Application Control

42. Build Malware Protection Coverage Register

Create:

08 Malware Protection Coverage Register

Use:

Asset	Malware Risk	Protection	Current	Owner

43. Malware Coverage

For systems commonly affected by malware:

Protection
→ Required / Expected

depending on applicable requirements and system risk.

44. Systems Not Commonly Affected by Malware

Where a system is assessed as not commonly affected, the organization should still maintain an appropriate periodic evaluation rather than simply state:

Linux
→ No Malware Risk

45. Malware Evaluation

Consider:

Platform

Threat Landscape

Software Installed

Exposure

Use Case

46. Anti-Malware Configuration

Review:

Real-Time Protection

Signature Updates

Behavior Detection

Tamper Protection

Logging

47. Malware Gap Example

Population:

40 Applicable CDE Servers

Protected:

Gap:

3 Unprotected

Investigate immediately.

48. Vulnerability Scan Credentialing

Internal vulnerability scanning may use authenticated scans.

Authenticated scanning can identify:

Missing Patches

Installed Software

Configuration Issues

more accurately than unauthenticated scans.

49. Scanner Credentials

Protect scanning credentials with:

Least Privilege

Secure Storage

Monitoring

Rotation

50. Scanner Coverage

A scanner itself is not enough.

Ask:

Can It Reach Every CDE Asset?

Are Cloud Assets Included?

Are Short-Lived Assets Included?

Are Containers Included?

51. Cloud Vulnerability Management

Cloud environments may include:

VMs

Containers

Serverless Functions

Managed Databases

Container Images

The vulnerability approach must match the technology.

52. Cloud VM Scanning

Traditional scanners can assess:

Operating Systems

Installed Packages

Open Services

53. Container Vulnerability Management

Container environments require scanning:

Base Images

Libraries

Packages

Application Dependencies

54. Container Lifecycle

Strong workflow:

Code
      ↓
Build Image
      ↓
Scan
      ↓
Block Critical Findings
      ↓
Registry
      ↓
Deploy

55. Build-Time Scanning

Do not wait until:

Vulnerable Container
      ↓
Production

Shift detection earlier.

56. Container Registry

Track:

Approved Images

Image Age

Vulnerabilities

Owner

57. Kubernetes Vulnerability Management

Include:

Worker Nodes

Container Images

Control Plane Components

Ingress Controllers

Add-Ons

depending on platform responsibility.

58. Managed Kubernetes

Cloud provider may manage:

Control Plane

while customer manages:

Nodes

Images

Workloads

Configuration

Understand shared responsibility.

59. Application Vulnerabilities

PCI payment applications may face:

SQL Injection

Cross-Site Scripting

Authentication Issues

Authorization Issues

Injection

Insecure APIs

60. Application Security Testing

Potential techniques include:

SAST

DAST

SCA

Manual Testing

Penetration Testing

61. Software Composition Analysis

SCA helps identify vulnerable:

Open-Source Libraries

Dependencies

Packages

62. Dependency Example

Application uses:

Library v1.2

Vendor releases:

Critical CVE

Remediation:

Upgrade Library

63. Unsupported Software

Unsupported software is especially risky.

Example:

Operating System
      ↓
End of Life
      ↓
No Security Patches

64. Unsupported CDE Assets

Track:

09 Unsupported Technology Register

Use:

System	Technology	EOL Date	Risk	Migration

65. Legacy System Example

Payment Server
→ OS Unsupported

Possible response:

Network Restriction

Enhanced Monitoring

Migration Plan

Risk Escalation

But long-term remediation should remove unsupported technology.

66. Vulnerability Prioritization

A mature model may prioritize using:

Severity

Exposure

Exploitability

Asset Criticality

Threat Intelligence

Business Context

67. Active Exploitation

If threat intelligence shows:

Vulnerability Actively Exploited

priority may increase significantly.

68. Internet Exposure

A High severity vulnerability on:

Internet-Facing Payment Server

may require faster action than the same issue on a tightly isolated internal system.

69. CDE Criticality

All CDE systems warrant heightened scrutiny because of their payment-data role.

70. Vulnerability Ownership

Every finding should have:

Technical Owner

Remediation Owner

71. Assignment Workflow

Scanner
      ↓
Finding
      ↓
Asset Owner
      ↓
Remediation Ticket
      ↓
Due Date

72. Vulnerability Ticket

Include:

Asset

CVE

Severity

Evidence

Required Action

Due Date

73. Vulnerability Deduplication

Multiple scanners may identify the same issue.

Build a process to avoid:

Scanner A Finding

Scanner B Finding

Scanner C Finding

becoming three unrelated records.

74. False Positives

A scanner finding may be incorrect.

Use:

Validate
      ↓
Evidence
      ↓
False Positive Approval

Do not simply close based on owner opinion.

75. False Positive Register

Create:

10 Vulnerability False Positive Register

Use:

Finding	Validation	Evidence	Reviewer	Status

76. Retesting

After remediation:

Finding
      ↓
Fix
      ↓
Rescan
      ↓
Validate

77. Retest Is Essential

Do not close based only on:

Engineer Says Patched

Confirm through:

Scanner

Version Check

Configuration Validation

Penetration Test

78. Build Vulnerability Retest Register

Create:

11 Vulnerability Retest Register

Use:

Finding	Fix Date	Retest Date	Result	Reviewer

79. Retest Failure

If vulnerability remains:

Reopen Finding

and determine whether:

Patch Failed

Wrong Asset Patched

Service Restart Missing

Multiple Instances Exist

80. ASV Failed Scan

If ASV result is:

Fail

workflow:

Review Findings
      ↓
Remediate
      ↓
Rescan
      ↓
Passing Result

81. ASV Dispute

Sometimes an ASV finding may require technical dispute or validation under applicable ASV processes.

Maintain:

Evidence

Vendor Communication

Resolution

82. Scan Evidence

Retain:

Scan Date

Scanner

Scope

Assets

Findings

Status

Rescan

83. Vulnerability Evidence Package

For a sampled vulnerability, evidence may include:

Scanner Finding

Ticket

Patch Evidence

Change Record

Retest

Closure

84. Patch Evidence Package

Example:

CVE-XXXX/
├── Scanner-Finding
├── Remediation-Ticket
├── Change-Approval
├── Patch-Deployment
└── Retest

85. Scan Completeness

A clean report is not useful if the scanner covered only half the CDE.

Validate:

Asset Inventory
      ↓
Scanner Inventory
      ↓
Reconcile

86. Coverage Reconciliation

Example:

CDE Inventory:
125 Assets

Scanner:
118 Assets

Difference:

Investigate.

87. Ephemeral Assets

Cloud environments may create short-lived systems.

Examples:

Auto-Scaling VMs

Containers

Temporary Build Systems

Traditional monthly asset inventories may miss them.

88. Modern Vulnerability Coverage

Use:

Cloud Inventory

Container Registry

Runtime Discovery

CI/CD Scanning

to supplement traditional scanners.

89. Patch Compliance Monitoring

Useful metrics:

Critical Within SLA

High Within SLA

Overdue Findings

Average Age

Unsupported Systems

90. Vulnerability Aging

Track:

0–15 Days

16–30 Days

31–60 Days

61–90 Days

>90 Days

91. Critical Aging KRI

Example:

Critical CDE vulnerabilities
older than remediation SLA

Target:

92. Vulnerability Backlog

A large backlog may indicate:

Weak Ownership

Insufficient Resources

Poor Prioritization

Legacy Technology

93. Repeat Vulnerabilities

A vulnerability repeatedly reappearing may indicate:

Image Not Updated

Patch Not Persistent

Asset Rebuilt From Old Template

94. Root Cause Example — Repeat Vulnerability

Problem:

Patched Server
      ↓
Vulnerability Reappears

Why?

Auto-Scaling Instance
Built From Old Image

Root cause:

Golden image lifecycle is not integrated with vulnerability remediation.

95. Corrective Action

Patch Golden Image

Update CI/CD

Rebuild Instances

Verify New Deployments

96. Root Cause Example — Missed Asset

Problem:

ASV Missed Public Server

Why?

Asset Not in Scan Scope

Why?

New Public IP Not Added

Root cause:

Cloud provisioning workflow does not automatically update the PCI external scanning inventory.

97. Corrective Action

Cloud Asset Discovery
      ↓
Automatic PCI Asset Tag
      ↓
ASV Scope Update

98. Root Cause Example — SLA Miss

Problem:

Critical Vulnerability
Past Due

Why?

Owner Didn't Know

Why?

Scanner Did Not Create Ticket

Root cause:

Vulnerability scanning is not integrated with remediation workflow and escalation.

99. Corrective Action

Scanner
      ↓
Ticketing
      ↓
Owner
      ↓
SLA
      ↓
Escalation

100. Build PCI Vulnerability Management Standard

Create:

12 PCI Vulnerability Management Standard

Include:

Scope

Roles

Scanning

Severity

Remediation SLA

Exceptions

Retesting

Evidence

Escalation

101. Roles and Responsibilities

Example:

Role	Responsibility
Security	Vulnerability discovery
System Owner	Remediation
GRC	Compliance tracking
Change Team	Controlled deployment
Management	Risk acceptance

102. Vulnerability Escalation

Use:

Critical Past SLA
      ↓
Security Leadership

High Past SLA
      ↓
System Owner Management

Expired Exception
      ↓
Risk Owner

103. Critical Escalation

Escalate immediately for:

Active Exploitation

Internet-Facing Critical CDE Vulnerability

Known Payment-System Exploit

Malware Infection

Unsupported Critical CDE System

104. Vulnerability Dashboard

Track:

Metric	Target
CDE Scan Coverage	100%
Critical Vulnerabilities Within SLA	100%
High Vulnerabilities Within SLA	100%
Overdue Critical Findings	0
Passing ASV Scans	100%
Malware Protection Coverage	100%
Unsupported CDE Assets	0

105. KPI — Scan Coverage

Percentage of CDE assets
covered by vulnerability scanning

Target:

100%

106. KPI — SLA Compliance

Percentage of critical/high findings
remediated within defined SLA

107. KRI — Critical Overdue

Critical CDE vulnerabilities
past remediation target

Target:

108. KRI — Scan Failure

Required ASV scans
without passing result

109. KRI — Malware Coverage

Applicable CDE systems
without approved malware protection

110. KRI — Unsupported Systems

Unsupported technologies
operating in the CDE

111. Practical Activity — Build Vulnerability Register

Use fictional organization:

CloudShop

Add findings across:

Payment Web

Payment API

Database

Jump Host

Firewall

Container Image

Use severities:

Critical

High

Medium

Low

112. Practical Activity — Build SLA Tracker

Create 15 fictional vulnerabilities.

Include:

3 Critical

5 High

4 Medium

3 Low

Determine which are:

On Track

Due Soon

Overdue

113. Practical Activity — Review ASV Scan

Assume:

10 Public CDE Assets

Results:

8 Pass

2 Fail

Findings:

Outdated TLS Configuration

Critical Web Server Vulnerability

Document:

Finding

Owner

Remediation

Rescan

Final Status

114. Practical Activity — Asset Coverage

PCI asset inventory:

60 Systems

Scanner inventory:

55 Systems

Identify:

5 Missing Assets

Determine:

Why Missing?

Risk?

Corrective Action?

115. Practical Activity — Patch Compliance

Use:

40 CDE Servers

Results:

32 Fully Patched

5 High Patches Overdue

2 Critical Patches Overdue

1 Unsupported OS

Create management summary.

116. Practical Activity — Malware Coverage

Population:

30 Applicable CDE Assets

Protected:

Unprotected:

Perform:

Risk Assessment

Correction

Corrective Action

Retest

117. Practical Activity — Vulnerability Exception

Critical vulnerability cannot be patched for:

21 Days

because of vendor certification.

Create an exception with:

Business Reason

Risk

Mitigation

Owner

Approver

Expiry

Patch Date

118. Practical Activity — Container Vulnerability

Container image has:

Critical OpenSSL Vulnerability

Image exists in:

Production

Registry

Golden Base Image

Determine:

Immediate Correction

Root Cause

Corrective Action

Retest

119. PCI Vulnerability Management Checklist

Scope

CDE assets identified.
connected systems considered.
internet-facing systems identified.
cloud resources identified.
containers included where applicable.

Scanning

internal scans completed.
external scans completed.
applicable ASV scans completed.
scan scope validated.
authenticated scanning used where appropriate.
scan failures tracked.

Vulnerability Classification

severity assigned.
risk context considered.
asset criticality considered.
active exploitation considered.
remediation priority assigned.

Remediation

owners assigned.
due dates defined.
patches tested.
patches deployed.
mitigation used where necessary.
overdue findings escalated.

Exceptions

business reason documented.
risk documented.
compensating controls documented.
approver identified.
expiry date defined.
exception reviewed.

Retesting

vulnerability retested.
patch confirmed.
failed retests reopened.
closure evidence retained.

Malware Protection

applicable systems identified.
protection deployed.
updates current.
tamper protection considered.
exclusions reviewed.

Technology

unsupported systems identified.
container images scanned.
application dependencies scanned.
cloud workloads monitored.

Evidence

scan reports retained.
ASV reports retained.
remediation tickets retained.
change records retained.
exception approvals retained.
retest evidence retained.

120. Common PCI Vulnerability Management Mistakes

Mistake 1 — Scanner Equals Vulnerability Program

Findings are generated but not remediated.

Mistake 2 — Scan Coverage Assumed

Assets are missing from scanning.

Mistake 3 — ASV Scan Treated as All Vulnerability Testing

Internal and application risks are ignored.

Mistake 4 — CVSS Used Without Context

CDE exposure is ignored.

Mistake 5 — Patch SLA Has No Escalation

Critical findings remain open.

Mistake 6 — Risk Exceptions Never Expire

Temporary acceptance becomes permanent.

Mistake 7 — Engineer Says Fixed

No retest is performed.

Mistake 8 — Containers Ignored

Vulnerable packages deploy repeatedly.

Mistake 9 — Unsupported Systems Accepted Indefinitely

No migration plan exists.

Mistake 10 — Malware Protection Coverage Not Reconciled

New assets remain unprotected.

121. Weak Vulnerability Management

Quarterly Scan
      ↓
Export PDF
      ↓
Store for Audit

122. Strong Vulnerability Management

Asset Inventory
      ↓
Continuous Discovery
      ↓
Risk Classification
      ↓
Ownership
      ↓
Remediation SLA
      ↓
Patch / Mitigation
      ↓
Exception Governance
      ↓
Retest
      ↓
Metrics
      ↓
Continuous Improvement

123. GRC Analyst Responsibilities

A GRC professional supporting PCI vulnerability management may:

Maintain PCI vulnerability-control mappings.
Reconcile CDE assets with scanner coverage.
Track internal scans.
Track ASV scans.
Maintain vulnerability registers.
Monitor remediation SLAs.
Review overdue findings.
Coordinate risk exceptions.
Track exception expiry.
Review malware coverage.
Track unsupported systems.
Coordinate retesting.
maintain evidence.
prepare vulnerability dashboards.
support assessor requests.

GRC connects:

Security

Infrastructure

Cloud

Network

Engineering

DevOps

Application Security

SOC

System Owners

Risk Owners

ASV

Assessors

124. Vulnerability Management Maturity Model

Level 1 — Scan Driven

Periodic Scan
      ↓
Manual Findings

Level 2 — Managed

Severity

Owners

SLA

Tickets

Level 3 — Risk Based

Exposure

Threat Intelligence

Exceptions

Retesting

Level 4 — Automated

Continuous Scanning

CI/CD Integration

Automated Ticketing

Patch Metrics

Level 5 — Continuous Vulnerability Assurance

Real-Time Asset Discovery

Continuous Risk Scoring

Automated Remediation

Continuous Control Validation

125. PCI Vulnerability Management Mindset

For every CDE vulnerability ask:

Which asset is affected?

Is the asset really in scan coverage?

What is the severity?

Is it internet facing?

Is exploitation active?

Does it expose payment data?

Who owns the asset?

When is remediation due?

Can it be patched now?

If not, what mitigation exists?

Who approved the exception?

When does the exception expire?

Was remediation independently retested?

Could the issue reappear from an old image?

For every scan ask:

Did we scan the complete environment?

For every closed vulnerability ask:

What evidence proves
the vulnerability is actually gone?

When these questions can be answered consistently, vulnerability management becomes a continuous payment-security control rather than a periodic scanning exercise.

Key Takeaways

PCI vulnerability management begins with complete CDE asset visibility.
Scanning alone is not sufficient; findings must be owned and remediated.
Internal and external vulnerability scanning serve different purposes.
ASV scanning supports applicable external PCI validation requirements.
Scan scope completeness is as important as scan results.
Vulnerabilities should be prioritized using both technical severity and business risk.
Remediation SLAs should be defined, monitored, and escalated.
Patch management is a core vulnerability-remediation mechanism.
Zero-day risks may require temporary mitigating controls before a patch exists.
Vulnerability risk exceptions should be documented, approved, time-bound, and reviewed.
Malware protection coverage should be assessed across applicable CDE systems.
Cloud, container, Kubernetes, and application environments require technology-specific vulnerability approaches.
Unsupported technologies should be identified and actively migrated.
Vulnerabilities should be retested before closure.
Automated scanning, ticketing, CI/CD integration, and asset discovery improve continuous assurance.
GRC coordinates vulnerability evidence, SLA tracking, exceptions, remediation, metrics, and assessor support.

Knowledge Check

Before continuing, make sure you can answer:

What is vulnerability management?
Why is asset coverage important?
What is the difference between internal and external scanning?
What is an ASV?
Why is ASV scanning not enough by itself?
What is CVSS?
Why should CVSS be combined with risk context?
What is a remediation SLA?
Why should overdue vulnerabilities be escalated?
What is patch management?
How should zero-day vulnerabilities be managed?
What is a vulnerability risk exception?
What should an exception contain?
Why should exceptions have expiry dates?
Why should malware protection coverage be validated?
Why are container images important?
What is an unsupported technology risk?
Why should findings be retested?
What is scan coverage reconciliation?
What role does GRC play in PCI vulnerability management?

What’s Next?

➡️ Next: 07 — Secure Configuration

In the next lesson, you will move from finding vulnerabilities into preventing them through secure configuration and system hardening.

You will work through:

System Inventory
      ↓
Configuration Standard
      ↓
Secure Baseline
      ↓
Default Account Removal
      ↓
Unnecessary Service Removal
      ↓
Hardening
      ↓
Configuration Validation
      ↓
Drift Detection
      ↓
Exception Management
      ↓
Continuous Compliance

You will also build practical artifacts including a PCI Secure Configuration Standard, CDE Hardening Baseline, Configuration Compliance Register, Default Account Review Register, Security Configuration Exception Register, Configuration Drift Dashboard, Hardening Evidence Catalog, and PCI Configuration Testing Checklist.