PCI DSS 4.0.1: Technical Requirements for Modern Payment Environments

An in-depth article for security, engineering, compliance, and payments leaders

Based on publicly available information as of October 2026. Original work, free to share, adapt, and republish without restriction. The PCI DSS standard itself is published by the PCI Security Standards Council (PCI SSC); always consult the official document for authoritative wording.

Executive Summary

The Payment Card Industry Data Security Standard (PCI DSS) is the global baseline for protecting payment account data. Version 4.0 was published in March 2022 and introduced the biggest overhaul in a decade. Version 4.0.1, published in June 2024, is a limited revision: it adds no new requirements and removes none, but clarifies wording, corrects errors, and aligns supporting documents. Version 4.0 was retired at the end of 2024, and on 31 March 2025 the 51 future-dated requirements became mandatory. Every assessment today is performed against v4.0.1.

For teams running modern payment environments (cloud platforms, containers, APIs, e-commerce checkouts with third-party scripts, tokenization, and mobile acceptance), v4.0.1 is not just an audit exercise. It pushes organizations toward continuous security: stronger authentication, tighter control of scripts on payment pages, automated log review, documented scope, and risk-based decisions backed by written analysis.

This article explains the structure of the standard, what changed, the technical requirements that matter most, how they apply to cloud-native and e-commerce architectures, how to reduce scope, how validation works, and how to build a practical implementation roadmap. The central message: treat PCI DSS as an engineering and operations discipline, not a yearly paperwork event.

Background and Timeline

1.1 Why PCI DSS exists

PCI DSS was created by the major card brands and is maintained by the PCI SSC. It applies to any entity that stores, processes, or transmits cardholder data (such as the primary account number, or PAN) or sensitive authentication data (SAD), and to entities that can affect the security of the cardholder data environment (CDE). This includes merchants, payment processors, acquirers, issuers, payment gateways, and many service providers.

1.2 Key milestones

1.3 Who enforces PCI DSS

The PCI SSC writes and maintains the standard, but it does not directly fine or certify merchants. Compliance is enforced through contracts: card brands and acquiring banks set validation requirements and may apply fees, higher monitoring, or termination of acceptance for non-compliance or after a breach. Validation requirements depend on merchant or service provider level and on the programs of each card brand and acquirer.

2. What Changed in v4.0 and v4.0.1

2.1 Goals of version 4.0

The PCI SSC described four goals: continue to meet the security needs of the payments industry, promote security as a continuous process, add flexibility for different methodologies, and enhance validation methods and procedures.

2.2 Major themes

• Customized approach: Organizations can meet a requirement’s stated objective using controls that differ from the prescribed ones, supported by documented analysis and assessor validation. The traditional approach is now called the defined approach.

• Targeted risk analysis (TRA): Some requirements let entities decide how often to perform an activity, but only after documenting a risk analysis.

• Stronger authentication: Longer passwords and multi-factor authentication (MFA) for all access into the CDE.

• Ongoing security: Expectations for automated monitoring, role-based reviews, and operational discipline.

• E-commerce threats: New controls aimed at skimming and script-based attacks on payment pages.

• Roles and responsibilities:  Each requirement now expects defined, documented owners.

2.3 What v4.0.1 actually did

Version 4.0.1 clarified language, fixed formatting and typographical issues, and corrected a few inconsistencies. It also clarified how some requirements apply, for example around payment page scripts and change detection. It did not create new obligations beyond v4.0, which is why organizations that implemented v4.0 are largely aligned with v4.0.1.

2.4 SAQ A and e-commerce payment pages

Two requirements drew the most attention: 6.4.3 (managing scripts loaded on payment pages) and 11.6.1 (detecting unauthorized changes to payment pages). In January 2025, the PCI SSC updated the SAQ A reporting template: Requirements 6.4.3, 11.6.1, and the supporting 12.3.1 risk analysis were removed from SAQ A, and a new eligibility criterion was added. Merchants must now confirm that their site is not susceptible to attacks from scripts that could affect e-commerce systems. The requirements themselves remain in the standard and continue to apply to entities validating with SAQ A-EP, SAQ D, or a full Report on Compliance. Merchants should read the current SAQ A eligibility wording and the related PCI SSC FAQ carefully rather than assuming they are exempt.

Structure of the Standard

PCI DSS is organized into six goals and twelve principal requirements.

Three appendices cover additional scenarios: A1 (multi-tenant service providers), A2 (legacy SSL/early TLS for card-present POS POI terminals), and A3 (Designated Entities Supplemental Validation, or DESV, for entities designated by brands or acquirers).

Technical Requirements That Matter Most

Requirement numbers are given so that teams can map directly to the official document.

4.1 Network security controls (Requirement 1)

Network security controls (NSCs) include firewalls, security groups, network ACLs, and virtual appliances. Core expectations:

• Documented, reviewed rule sets (at least every six months) with business justification.

• Accurate network and data-flow diagrams showing all account data flows.

• Restricted inbound and outbound traffic to what is necessary for the CDE; default deny.

• Protection between trusted and untrusted networks, including wireless and cloud virtual networks.

Modern relevance: in cloud and container environments, NSCs include cloud security groups, Kubernetes network policies, service mesh policies, and web application firewalls. These must be inventoried, versioned, and reviewed like traditional firewalls.

4.2 Secure configuration (Requirement 2)

• Configuration standards for all system components, based on industry-accepted hardening guidance.

• Vendor default accounts and passwords changed or disabled.

• Only necessary services, protocols, and functions enabled.

• Secure non-console administrative access using strong cryptography.

Modern relevance: infrastructure as code, hardened container images, and policy-as-code checks provide repeatable evidence for configuration compliance.

4.3 Protecting stored account data (Requirement 3)

• Keep storage to a minimum, with a defined retention and secure deletion policy.

• Do not store sensitive authentication data after authorization (full track data, card verification codes, PINs).

• SAD stored before authorization completes must be encrypted (3.3.2).

• Mask PAN when displayed (3.4.1); limit who can see more than the permitted digits.

• Render PAN unreadable wherever stored, using strong cryptography, truncation, tokenization, or keyed cryptographic hashes (3.5.1, 3.5.1.1).

• Technical controls to prevent copying or relocating PAN when using remote-access technologies, unless explicitly authorized (3.4.2).

• Documented key management: generation, distribution, storage, rotation, retirement, and split knowledge with dual control for manual cleartext key operations (3.6, 3.7).

• Service providers must document their cryptographic architecture (3.6.1.1).

Modern relevance: use a managed key management service or hardware security modules, tokenize early, and avoid log files, analytics stores, backups, and data lakes accidentally capturing PAN.

4.4 Protecting data in transit (Requirement 4)

• Strong cryptography and secure protocols for transmitting PAN over open, public networks; trusted keys and certificates.

• Maintain an inventory of trusted keys and certificates (4.2.1.1).

• Encrypt PAN sent through end-user messaging technologies, or prohibit such sending.

Modern relevance: include internal service-to-service traffic where it crosses untrusted segments; automate certificate lifecycle management; use current TLS versions and cipher suites.

4.5 Malware protection (Requirement 5)

• Anti-malware on systems commonly affected by malware, or periodic evaluations for systems that are not.

• Automatic updates, scans, and logging; tamper protection so users cannot disable it.

• Anti-phishing mechanisms (5.4.1) to detect and protect personnel from phishing attacks.

Modern relevance: endpoint detection and response (EDR) tools commonly satisfy anti-malware requirements; container hosts and ephemeral workloads need a documented approach.

4.6 Secure systems and software (Requirement 6)

• Secure software development lifecycle (SDLC), with security training for developers.

• Inventory of bespoke and custom software and third-party components (6.3.2), effectively a software bill of materials.

• Vulnerability identification and risk ranking; critical patches installed within one month.

• Code review before release and protection from common coding vulnerabilities.

• Public-facing web applications must be protected by an automated technical solution that continually detects and prevents web-based attacks (6.4.2).

• Payment page scripts (6.4.3): every script loaded and executed in the consumer’s browser must be authorized, have its integrity assured, and be listed in an inventory with written justification.

• Separation of production from development and test environments, with no live PAN in pre-production unless fully protected.

• Change control with documented impact analysis and rollback.

Modern relevance: CI/CD pipelines are well suited to evidence collection: dependency scanning, static and dynamic testing, signed builds, and approvals recorded automatically.

4.7 Access control (Requirements 7 and 8)

Requirement 7: need-to-know access

• Least privilege, role-based access, documented approvals.

• Review all user accounts and privileges at least every six months (7.2.4).

• Review application and system account privileges (7.2.5).

Requirement 8: identification and authentication

• Unique IDs for every user; no shared or generic accounts except as tightly managed.

• Passwords of at least 12 characters (8.3.6) (or 8 where the system does not support 12), with complexity, history, and change rules.

• MFA for all access into the CDE (8.4.2), not just administrative or remote access, and MFA for remote network access (8.4.3).

• MFA systems must be implemented so they cannot be bypassed, replayed, or used without all factors (8.5.1).

• Interactive use of system and application accounts is restricted and managed; credentials are not hard-coded in scripts or source (8.6.1 to 8.6.3).

Modern relevance: use an identity provider with phishing-resistant MFA, privileged access management, short-lived credentials, and secrets managers for application and pipeline secrets.

4.8 Physical security (Requirement 9)

• Physical access controls for facilities, media, and sensitive areas; visitor management.

• Protection of point-of-interaction (POI) devices, including inventory and periodic inspection for tampering (9.5.1), with frequency supported by a targeted risk analysis.

Modern relevance: for cloud-hosted CDE components, physical controls are generally inherited from the cloud provider’s validated attestation, but the customer still manages POI devices, offices, and media.

4.9 Logging and monitoring (Requirement 10)

• Audit logs capture user access, privileged actions, authentication events, log changes, and security-control status.

• Logs protected from modification, synchronized to reliable time sources, and retained for at least 12 months, with the most recent three months immediately available.

• Automated mechanisms for log review (10.4.1.1) rather than purely manual review.

• Detection and response to failures of critical security controls (10.7.2, 10.7.3), for all entities (previously only for service providers).

Modern relevance: centralized security information and event management (SIEM) with alerting, retention tiers, and clear ownership is the practical route to compliance.

4.10 Security testing (Requirement 11)

• Wireless access point detection; quarterly internal and external vulnerability scans, with external scans by an Approved Scanning Vendor (ASV).

• Authenticated internal vulnerability scanning (11.3.1.2).

• Penetration testing at least annually and after significant change, including segmentation tests where segmentation is used.

• Intrusion detection and prevention at the perimeter and critical points.

• File integrity monitoring or change-detection on critical files.

• Change- and tamper-detection for payment pages (11.6.1): alert on unauthorized modification of HTTP headers and payment page contents as received by the consumer browser, evaluated at least weekly or at a frequency set by a targeted risk analysis.

• Multi-tenant service providers must support customers’ testing needs (11.4.7).

Modern relevance: include APIs, serverless functions, and infrastructure-as-code repositories in vulnerability and penetration testing scope.

4.11 Policies, risk, and governance (Requirement 12)

• Information security policy reviewed at least annually, with defined roles and responsibilities.

• Targeted risk analyses (12.3.1) documented for every requirement that allows flexibility in frequency.

• Annual review of cryptographic cipher suites and protocols (12.3.3) and of hardware and software technologies in use (12.3.4).

• PCI DSS scope documented and confirmed at least every 12 months (12.5.2); service providers every six months (12.5.2.1).

• Security awareness training on hiring and at least annually, including phishing and social engineering (12.6.3.1) and acceptable use of end-user technologies (12.6.3.2).

• Management of third-party service providers (TPSPs): due diligence, written agreements acknowledging responsibility, monitoring of compliance status, and a responsibility matrix (12.8). TPSPs must support customers’ information requests (12.9.2).

• Incident response plan tested at least annually, including response to alerts from change detection and to unexpected storage of PAN (12.10.5, 12.10.7).

Applying PCI DSS to Modern Architectures

5.1 Cloud and shared responsibility

PCI DSS applies fully to cloud environments, but responsibilities are split between customer and provider. Key practices:

• Obtain the provider’s current Attestation of Compliance (AoC) and a responsibility matrix for each service in use.

• Understand the service model: infrastructure, platform, and software services shift different controls to the provider.

• Treat misconfiguration as the principal risk: public storage buckets, over-permissive roles, and open security groups.

• Use cloud-native logging, key management, and posture-management tools, and retain evidence.

A provider’s compliance does not make a customer’s workload compliant by itself.

5.2 Containers, Kubernetes, and microservices

Assess these as part of the CDE when they store, process, or transmit account data or can affect its security.

• Image security: trusted base images, vulnerability scanning, signed images, and an inventory of components.

• Orchestrator hardening: restrict API server access, enforce RBAC, protect secrets, and apply network policies.

• Segmentation: namespaces alone are not a security boundary; combine with network policies and node isolation where needed.

• Ephemeral workloads: ensure logs and evidence persist after containers terminate, and that vulnerability management covers rapid deployment cycles.

5.3 APIs and service-to-service communication

• Strong authentication and authorization for every API, using short-lived tokens and mutual TLS where appropriate.

• Input validation, rate limiting, and abuse detection.

• Never log full PAN or SAD in request or response payloads, traces, or error messages.

• Include APIs in inventories, vulnerability scans, and penetration tests.

5.4 E-commerce and payment page security

Skimming attacks (such as Magecart-style script injection) target checkout pages. Requirements 6.4.3 and 11.6.1 respond to this threat.

Practical measures include: a documented inventory of every script with business justification and owner; Subresource Integrity (SRI) where feasible; a strict Content Security Policy; browser-side monitoring or change-detection tools; minimizing third-party tags on payment pages; and removal of marketing and analytics scripts from checkout.

5.5 Tokenization, point-to-point encryption, and scope reduction

• Tokenization replaces PAN with a non-sensitive value. Properly implemented, it removes systems that only handle tokens from scope.

• Validated point-to-point encryption (P2PE) encrypts card data at the POI and decrypts only in a secure environment, which can dramatically reduce merchant scope and qualify for a simpler self-assessment.

• Outsourcing to compliant providers moves responsibility but not accountability; the merchant still manages the provider relationship and its own residual controls.

Scope reduction is often the highest-return security investment: every system removed from the CDE is one less to harden, monitor, scan, and audit.

5.6 Network segmentation

Segmentation is not mandated, but it is the main way to limit scope. If used, it must be effective, documented, and validated through penetration testing (at least annually, and every six months for service providers). Flat networks bring everything into scope.

5.7 Mobile and contactless acceptance

Software-based card acceptance on commercial off-the-shelf devices, such as tap-to-pay on mobile phones, is addressed by separate PCI SSC standards for mobile payments on COTS (MPoC) and earlier programs. Merchants using such solutions should rely on listed, validated solutions and confirm which PCI DSS requirements remain their responsibility.

5.8 Remote work and administration

Remote access to the CDE needs MFA, hardened endpoints, encrypted connections, and controls preventing local copying of PAN (3.4.2). Manage jump hosts or virtual desktops as in-scope systems, and monitor privileged sessions.

Validation and Reporting

6.1 Ways to validate

6.2 SAQ types in brief

SAQ A (fully outsourced card-not-present), SAQ A-EP (partially outsourced e-commerce with a merchant-controlled page), SAQ B and B-IP (imprint or standalone terminals), SAQ C and C-VT (payment application systems and virtual terminals), SAQ P2PE (validated P2PE), SAQ SPoC (validated mobile solutions), SAQ D (all other merchants and service providers). Eligibility criteria are strict; selecting a questionnaire that is too light is a common error.

6.3 Defined versus customized approach

The defined approach follows the stated requirement and testing procedures. The customized approach lets mature organizations meet the stated objective with alternative controls, supported by a controls matrix, a targeted risk analysis, and evidence that the assessor validates. It is more work to document, so most organizations use it selectively.

6.4 Compensating controls

Where a requirement cannot be met as stated because of a legitimate technical or business constraint, a documented compensating control that meets the intent and rigor of the requirement may be accepted, subject to assessor review. This differs from the customized approach and is generally intended for exceptional cases.

Implementation Roadmap

Phase 1: Scope and discover (weeks 1-6)

• Identify all places account data is stored, processed, or transmitted, including logs, backups, tickets, and spreadsheets.

• Produce data-flow and network diagrams; document scope with formal sign-off.

• Inventory third-party providers and obtain their compliance evidence.

Phase 2: Reduce scope (weeks 6-16)

• Adopt tokenization, hosted payment fields, or P2PE where possible.

• Segment networks and validate segmentation.

• Purge unneeded data and enforce retention limits.

Phase 3: Close gaps (months 3-9)

• Run a gap assessment against v4.0.1, focusing on the 51 formerly future-dated requirements.

• Implement MFA across the CDE, password policy updates, automated log review, authenticated scanning, and payment page script controls.

• Write the required targeted risk analyses and assign owners.

Phase 4: Operationalize (months 6-12)

• Build recurring tasks into calendars and ticketing: six-month access reviews, quarterly scans, annual penetration tests, policy reviews.

• Automate evidence collection from cloud, CI/CD, identity, and SIEM tools.

• Train staff, including phishing and social engineering scenarios.

Phase 5: Assess and sustain

• Perform an internal readiness review, then the formal assessment or SAQ.

• Treat the assessment as a checkpoint, not a finish line: monitor controls continuously and review scope after every significant change.

Timelines vary by size and complexity and are illustrative.

Common Pitfalls

1. Wrong or outdated scope: Unrecognized PAN in logs, email, or analytics databases pulls systems into scope and creates breach risk.

2. Assuming a compliant provider means a compliant merchant: Responsibility matrices must be reviewed and gaps owned.

3. Ignoring payment page scripts: Third-party tags are a leading skimming vector.

4. MFA gaps: Requirement 8.4.2 covers all access into the CDE, including internal users.

5. Missing targeted risk analyses: Choosing a frequency without documented analysis fails the requirement.

6. Manual-only log review: v4.0.1 expects automation.

7. Treating compliance as an annual project: Controls decay between assessments.

8. Weak segmentation validation: Segmentation that was never tested cannot be relied on to reduce scope.

9. Poor key and certificate hygiene: Missing inventories and expired certificates cause both findings and outages.

10. Hard-coded secrets: Credentials in code, images, or scripts undermine requirement 8.6.

Measuring Program Health

Governance: requirements with named owners; current targeted risk analyses; scope reviews completed on schedule.

Technical controls: MFA coverage of CDE access; systems meeting hardening baselines; critical vulnerabilities patched on time; payment page change alerts triaged within target time.

Operations: log sources reporting versus expected; time to detect and respond to failed security controls; access-review completion rate; penetration test findings closed on time.

Third parties: service providers with current AoC and responsibility matrix; contract coverage for PCI responsibilities.

Frequently Asked Questions (FAQs)

1. What is PCI DSS 4.0.1 and how does it differ from 4.0?

PCI DSS 4.0.1 is a limited revision of version 4.0, published in June 2024. It adds no new requirements and removes none; it clarifies wording, fixes errors, and improves alignment with supporting documents. Version 4.0 was retired at the end of 2024, so v4.0.1 is the version used for assessments.

2. Who needs to comply with PCI DSS?

Any organization that stores, processes, or transmits payment card account data, or that can affect the security of that data, including merchants, processors, gateways, acquirers, issuers, and many service providers. Your acquiring bank or card brand determines how you must validate.

3. What happened to the future-dated requirements?

The 51 future-dated requirements introduced in v4.0 were best practices until 31 March 2025. Since that date they are mandatory and fully included in assessments.

4. What are Requirements 6.4.3 and 11.6.1?

Requirement 6.4.3 requires that scripts on payment pages be authorized, integrity-checked, and inventoried with justification. Requirement 11.6.1 requires a mechanism to detect and alert on unauthorized changes to payment pages and HTTP headers as received by the consumer browser. Both target e-skimming attacks.

5. Do SAQ A merchants still need to meet 6.4.3 and 11.6.1?

The updated SAQ A template removed those requirements and replaced them with an eligibility criterion that the merchant’s site is not susceptible to attacks from scripts. The requirements remain in the standard and still apply to other validation types such as SAQ A-EP and SAQ D. Check the current SAQ A eligibility text and PCI SSC FAQs, and ask your acquirer if unsure.

6. What are the new authentication requirements?

Passwords generally must be at least 12 characters (8 where a system cannot support 12), and multi-factor authentication is required for all access into the cardholder data environment, not only remote or administrative access. MFA systems must also be configured to resist bypass and replay.

7. Does using a cloud provider make me PCI compliant?

No. A compliant provider covers the controls it operates, but you remain responsible for your configuration, access, data, and applications. Obtain the provider’s Attestation of Compliance and a responsibility matrix, and map each requirement to the party that owns it.

8. What is the customized approach, and should we use it?

The customized approach lets an entity meet a requirement’s objective using different controls, backed by a controls matrix, a targeted risk analysis, and assessor validation. It suits mature organizations with strong documentation and unusual architectures; most use the defined approach for the majority of requirements.

9. How can we reduce PCI DSS scope?

Minimize and eliminate stored data, tokenize PAN, use hosted payment pages or fields from validated providers, deploy validated P2PE for card-present acceptance, and use well-designed, penetration-tested network segmentation. Document scope formally and review it at least annually.

10. What are the consequences of non-compliance?

The PCI SSC does not fine merchants directly. Consequences come through acquirers and card brands and can include fees, mandatory remediation, increased monitoring, liability for fraud and breach costs, and in serious cases loss of ability to accept cards. A breach also brings legal, regulatory, and reputational impact beyond PCI.

Further Reading (Official Sources)

• PCI Security Standards Council: PCI DSS v4.0.1 and the Document Library

• PCI SSC information supplements on payment page security and e-skimming, cloud computing, and container orchestration

• PCI SSC FAQs on SAQ A eligibility and future-dated requirements

• Your acquiring bank and card brand compliance programs

• Your cloud and payment service providers’ Attestations of Compliance and responsibility matrices

Disclaimer

This article is an independent, original summary for general informational purposes. It is not legal, compliance, or assessment advice and does not reproduce the PCI DSS standard. The official documents published by the PCI Security Standards Council are authoritative, validation requirements vary by acquirer and card brand, and guidance may change. Consult a Qualified Security Assessor or your acquirer for decisions affecting your compliance status.

This work is original and released for free use. You may copy, modify, and distribute it for any purpose without attribution.