PCI DSS 11.3.1.2: Internal Vulnerability Scans After Significant Changes
PCI DSS 11.3.1.2 requires organizations to perform internal vulnerability scans immediately after any significant change to their network or systems. This control ensures that new vulnerabilities introduced during changes are detected and remediated before attackers can exploit them. For SMBs managing complex infrastructures, automating this scanning process is essential to maintain continuous compliance.
What this means
Significant changes—such as system patches, software updates, configuration modifications, or infrastructure deployments—can inadvertently introduce new vulnerabilities. This control mandates that your organization conduct internal vulnerability scans promptly after each significant change to verify that the change didn't weaken your security posture. The scans must be thorough enough to identify both known vulnerabilities and configuration weaknesses that could expose cardholder data.
How to comply
- 1.Define what constitutes a 'significant change' in your change management policy (e.g., OS patches, application updates, firewall rule changes, server migrations)
- 2.Establish a scanning schedule that triggers automatically or manually within a defined window (typically 24-72 hours) after each significant change
- 3.Configure your vulnerability scanner with the appropriate credentials and scope to assess all affected systems post-change
- 4.Document each scan—including date, systems scanned, vulnerabilities identified, and remediation actions taken
- 5.Establish a baseline of acceptable vulnerabilities pre-change and compare post-change results to identify new risks
- 6.Assign responsibility for initiating scans and reviewing results to prevent oversight
- 7.Track remediation of any vulnerabilities introduced by the change until closure is verified
Evidence auditors look for
- Change management log entries linked to vulnerability scan dates and results
- Vulnerability scan reports generated within 72 hours of each significant system or application change
- Before-and-after scan comparisons showing no new critical or high-severity vulnerabilities
- Remediation tickets for vulnerabilities found post-change with completion dates
- Quarterly vulnerability scan summaries demonstrating consistent post-change scanning coverage
- Audit trail from your scanning tool showing automated or manual scan triggers tied to change requests
- Policy documentation defining significant changes and mandatory scan timing
Frequently asked questions
When will FAQs be available?
The FAQ for this control is currently being prepared.
GRCWatch automates post-change vulnerability scanning by triggering scans automatically when changes are logged, consolidates scan results with your change management system, and generates audit-ready compliance evidence—eliminating manual coordination and ensuring no change slips through without verification.
See how GRCWatch handles this control automatically
Start free trial