Requirements 5 and 6 address the two primary mechanisms by which attackers gain access to cardholder data through software vulnerabilities: malicious software (malware) that exploits existing systems, and security vulnerabilities in applications that allow direct exploitation. Together they form the vulnerability management program that keeps the CDE protected against evolving threats.
Requirement 5 — Protecting Against Malicious Software
Anti-Malware Coverage
Anti-malware solutions must be deployed on all system components in the CDE — not just Windows systems. v4.0 clarified that organizations must evaluate which system types are commonly affected by malware and deploy anti-malware on all such systems. Linux systems, which are increasingly targeted, must be evaluated and typically require anti-malware protection.
Anti-Malware Configuration Requirements
Anti-malware solutions must: be maintained as current (automatic updates), perform periodic scans or continuous real-time monitoring, generate audit logs, and be protected from being disabled by users. If a system cannot support anti-malware (e.g., certain network devices), the reason must be documented and alternative compensating controls applied.
Anti-Phishing (New in v4.0)
Requirement 5.4.1 is new in v4.0 and requires anti-phishing mechanisms to protect all users who access cardholder data. This goes beyond email filtering — it includes URL filtering, user training, and technical controls that prevent users from accessing known phishing sites.
| KEY IDEA | Requirement 5.4.1 (anti-phishing) is one of the new future-dated requirements now active from March 2025. Email filtering alone is insufficient — PCI DSS requires a multi-layered approach including URL filtering (blocking known malicious websites), email authentication (SPF, DKIM, DMARC), and documented anti-phishing training as part of the security awareness program. |
Requirement 6 — Secure Systems and Software
Security Vulnerability Identification and Classification
Organizations must have a process for identifying new security vulnerabilities — subscribing to threat intelligence feeds, vendor security advisories, CVE publications. Vulnerabilities must be ranked (high, critical) using a risk-ranking process, and critical patches must be installed within one month of release.
Patch Management
All system components must receive security patches. Critical patches must be installed within one month. For less critical patches, a documented risk-based timeline. Patches must be tested before production deployment. Systems that cannot be patched require compensating controls (documented WAF rules, IPS signatures, isolation).
| Patch Criticality | Required Installation Timeline | Testing Requirement |
|---|---|---|
| Critical (CVSS 9.0+) | Within 1 month of release | Tested in non-production before CDE deployment |
| High (CVSS 7.0–8.9) | Risk-based timeline — typically 3 months | Tested in non-production before CDE deployment |
| Medium/Low | Risk-based timeline — typically quarterly | Change management process followed |
| End-of-life systems | Compensating controls required | Isolation, WAF/IPS coverage, documented justification |
Secure Development Lifecycle (SDL)
Software developed internally or by third parties for the CDE must follow a secure development lifecycle. Key requirements: security awareness training for developers, security is part of design (threat modeling), code reviews for security vulnerabilities, testing for common vulnerabilities (OWASP Top 10), and a process for resolving security vulnerabilities discovered in deployed applications.
Web Application Firewall (WAF) for Public-Facing Applications
All public-facing web applications that handle CHD must be protected by a WAF or web application vulnerability assessment. The WAF must be configured to detect and block OWASP Top 10 attacks and must be kept updated. Alternatively, a regular manual or automated application vulnerability assessment may substitute, with all vulnerabilities remediated before the application goes live.
Script Management on Payment Pages (Requirement 6.4.3 — New in v4.0)
This is one of the most operationally significant new requirements. For payment pages that are served by the organization or load scripts from external sources, all scripts must be: inventoried, authorized (with business justification), and verified for integrity (using SRI hashes, CSP headers, or other mechanisms). This directly addresses Magecart-style JavaScript skimming attacks.
| IMPORTANT | Requirement 6.4.3 applies to ANY script loaded by a payment page — regardless of whether it was loaded intentionally or indirectly (a script loaded by a script). Organizations using Google Tag Manager, third-party chat widgets, analytics tools, or A/B testing platforms on payment pages must inventory and authorize all scripts and verify their integrity. This is a significant operational change for e-commerce organizations. |
| The two most operationally impactful new requirements in v4.0 for Indonesian e-commerce organizations are 6.4.3 (JavaScript management) and 11.6.1 (payment page change detection). Together, they require organizations to both inventory and authorize scripts AND have a mechanism to detect unauthorized changes to payment pages. Organizations using hosted payment pages via a compliant PSP may be able to reduce their scope for these requirements. |