PCI DSS v4.0 Container Compliance: What Changed and What You Need to Do

PCI DSS v4.0 became mandatory in March 2025. The changes from v3.2.1 include significant updates to vulnerability management, system configuration, and logging requirements that directly affect containerized cardholder data environments.

If your organization processes card payments using containerized applications, your QSA will be evaluating these updated requirements in your next assessment.


The Key v4.0 Changes for Container Environments

Requirement 6.3: Vulnerability Identification and Management

PCI DSS v4.0 Requirement 6.3 significantly expands vulnerability management obligations:

6.3.1: All system components are protected from known vulnerabilities, and components not directly exposed to the internet are also protected. This removes the previous implicit exception for internal components.

6.3.2: An inventory of bespoke and custom software is maintained. For containers, this extends to your image inventory and the packages contained within each image.

6.3.3: All software components are protected from known vulnerabilities with the latest security patches. For containers, this means your images must be updated when packages within them have available security patches — not just when new base images are published.

This is the requirement change that most significantly affects container environments. Your QSA will ask for evidence that your container images are assessed for vulnerabilities and that high-severity findings are remediated within your defined SLA.

Container vulnerability scanner integration that provides structured, timestamped scan records for all images in scope satisfies the evidentiary requirements of 6.3.

Requirement 5: Anti-Malware

v4.0 expanded anti-malware requirements to address behavioral anomaly detection. For containers, this means:

  • Running processes in containers should be monitored for malicious behavior
  • Deviations from expected behavior should trigger investigation

Traditional signature-based anti-malware does not apply cleanly to containerized environments. Runtime behavioral monitoring that detects anomalous process execution, unexpected network connections, and unusual system calls satisfies the intent of these requirements for container workloads.

Requirement 10: Logging and Monitoring

v4.0 strengthened logging requirements, with specific language about detecting and responding to anomalous behavior. For containers:

10.7: Failures of critical security controls are detected, alerted on, and addressed promptly. For containers, this means your security monitoring must detect when a container security control (scanner, hardening pipeline, admission controller) fails or is bypassed.

10.4: Log files are reviewed to identify anomalies or suspicious activity. Container runtime behavioral logs must be included in the review process.


What QSAs Are Evaluating in Container CDE Assessments?

Based on current QSA practice, assessors evaluating containerized cardholder data environments are focusing on:

Image inventory completeness: Can you produce a complete list of all container images in your CDE? Are all images included in your vulnerability scanning program?

Vulnerability management evidence: When a High or Critical CVE is found in a container image in your CDE, what happens? How quickly? Who is responsible? What is the evidence?

Runtime monitoring: Is there any detection capability for anomalous container behavior in your CDE? Behavioral monitoring is increasingly expected, not just application-layer logging.

Hardening evidence: Are your CDE containers configured to the CIS Docker Benchmark or similar hardening standard? Is there documented evidence of the hardening applied?

Change management for images: When a container image is updated in your CDE, does it go through your change management process? Is the updated image scanned before deployment?



Frequently Asked Questions

What changed in PCI DSS v4.0 that affects container compliance?

PCI DSS v4.0 significantly expanded Requirement 6.3 to require that all system components — not just internet-facing ones — are protected from known vulnerabilities, that an inventory of all software components including container images is maintained, and that images are updated when packages have available security patches, not just when new base images are published. Requirement 5 also added behavioral anomaly detection requirements that traditional signature-based anti-malware cannot satisfy for containerized environments.

What steps must you take to comply with PCI DSS v4.0 for containerized cardholder data environments?

The required steps are: explicitly scope your image inventory to include all containers that process, store, or transmit cardholder data; implement automated scanning with SLA enforcement for every image build; add runtime behavioral monitoring to detect anomalous process execution and network behavior; document your container hardening baseline with your CVE threshold and required security settings; and produce structured evidence in machine-readable formats rather than screenshots.

What is a significant change in PCI DSS v4.0 for container vulnerability management?

The most significant change for containers is that Requirement 6.3.3 now requires all software components to be protected from vulnerabilities using the latest security patches — this means images must be updated when packages inside them have patches available, not just when the base image vendor publishes an update. This shifts responsibility from passive base image tracking to active per-package vulnerability management across every container in your cardholder data environment.


Building a PCI DSS v4.0 Ready Container CDE

Scope your image inventory explicitly. Your scope documentation must include all container images that process, store, or transmit cardholder data, or that are on systems that do. Undocumented containers discovered during the assessment expand your scope unexpectedly.

Implement automated scanning with SLA enforcement. Container image security scanning that runs on every image build and enforces remediation SLAs produces the continuous vulnerability management evidence Requirement 6.3 expects.

Add runtime monitoring to your CDE containers. Runtime behavioral monitoring that detects anomalous process execution and network behavior satisfies both the v4.0 anti-malware and logging requirements for container workloads.

Document your container hardening baseline. Define and document the security configuration baseline for CDE containers: minimum CVE threshold, required security settings, prohibited capabilities. Your QSA will review this documentation.

Produce structured evidence, not screenshots. QSAs are increasingly asking for API-accessible or structured-format evidence rather than screenshots. Tooling that produces JSON or CSV output from scan and remediation records satisfies this expectation.

PCI DSS v4.0 made container compliance more demanding. Organizations that build systematic, automated security programs will pass assessments more cleanly than those relying on periodic manual checks.

By Admin