PaymentsGlobal

PCI DSS 4.0.1

Keep payment-security work connected to assessment evidence

Coordinate owners, safeguards and evidence across your scoped payment environment.

Full title
Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1
Issued by
PCI Security Standards Council (PCI SSC)
Current version
v4.0.1, published June 2024. It is the only active version since v4.0 was retired on 31 December 2024.
Applies to
Entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment
Nature
An industry security standard. Who must comply and how they validate is set by the payment brands and acquirers, not by PCI SSC.
Structure
12 principal requirements under six goals, with appendices for multi-tenant providers, compensating controls and the customised approach

Overview

What PCI DSS 4.0.1 is

PCI DSS sets the baseline technical and operational requirements for protecting payment account data. It applies wherever cardholder data or sensitive authentication data is stored, processed or transmitted, and to every system that is connected to that environment or could affect its security. The standard is maintained by the PCI Security Standards Council, while the payment brands and acquirers decide who must comply and how compliance is validated.

Version 4.0 was published in March 2022 and was the first major rewrite since version 3. Version 4.0.1, published in June 2024, is a limited revision: it corrects formatting and typographical errors and clarifies the intent of some requirements and guidance, with no requirements added or removed. Version 4.0 was retired on 31 December 2024, so all assessments now use v4.0.1. Of the 64 requirements that were new in v4.x, 51 were future-dated and became mandatory on 31 March 2025, so a v4.0.1 assessment today covers all of them.

Version 4 introduced two ideas that change how a programme is run. Each requirement can now be met through the defined approach, following the requirement and its testing procedures as written, or through the customised approach, where the entity designs its own control to meet the stated objective, supported by a targeted risk analysis and tested by an assessor. Several requirements also let the entity set how often an activity is performed, provided the frequency is backed by a documented targeted risk analysis under Requirement 12.3.1.

In June 2026 PCI SSC opened a request for comments on v4.0.1 as the start of the next iteration of the standard. No newer version had been published as of October 2026, and v4.0.1 remains the version against which entities are assessed. For the history of the standard and moving from earlier versions, see the PCI-DSS overview.

Who it applies to

PCI DSS applies to any entity that stores, processes or transmits account data, or can affect its security, including:

  • Merchants that accept card payments in person, online or by phone
  • Acquirers, issuers and payment processors
  • Payment aggregators, gateways and other payment service providers
  • Service providers that host, manage or support systems in a cardholder data environment, such as cloud, data centre and managed security providers
  • Banks issuing or acquiring cards, including Indian banks working with the card networks
  • Software and call centre providers whose people or systems can reach account data

Outsourcing payment handling can reduce scope but does not remove it. Responsibilities shared with each third-party service provider must be agreed and documented.

Structure

How PCI DSS 4.0.1 is organised

Twelve principal requirements grouped under six goals, followed by appendices. Each requirement contains detailed sub-requirements with testing procedures and guidance.

Goal 1

Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls
Firewalls and equivalent controls between trusted and untrusted networks, documented configurations, network diagrams and data-flow diagrams, and controls between the cardholder data environment and other networks.
Requirement 2: Apply Secure Configurations to All System Components
Configuration standards based on industry hardening guidance, removal of vendor default accounts and passwords, and only necessary services, protocols and functions enabled.
Goal 2

Protect Account Data

Requirement 3: Protect Stored Account Data
Keeping storage to a minimum, never storing sensitive authentication data after authorisation, masking the primary account number when displayed, rendering it unreadable when stored, and managing cryptographic keys.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Strong cryptography and trusted certificates whenever account data crosses open or public networks, and an inventory of trusted keys and certificates.
Goal 3

Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software
Anti-malware on systems at risk, kept current and active, evaluation of systems considered not at risk, and mechanisms to protect personnel against phishing.
Requirement 6: Develop and Maintain Secure Systems and Software
Secure development of bespoke and custom software, identification and ranking of vulnerabilities, timely patching, protection of public-facing web applications, management of payment page scripts, and change control.
Goal 4

Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Access defined by role and least privilege, approved by authorised personnel, with user accounts and application and system accounts reviewed periodically.
Requirement 8: Identify Users and Authenticate Access to System Components
Unique IDs, strong authentication, multi-factor authentication for all access into the cardholder data environment and for remote access, and management of system and application accounts.
Requirement 9: Restrict Physical Access to Cardholder Data
Physical entry controls, visitor management, protection and secure destruction of media, and protection of point-of-interaction devices from tampering and substitution.
Goal 5

Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Audit logs for defined events, protection and retention of logs, regular log review, time synchronisation, and prompt detection of and response to failures of critical security control systems.
Requirement 11: Test Security of Systems and Networks Regularly
Wireless access point detection, internal and external vulnerability scanning, penetration testing, intrusion detection, and detection of unauthorised changes to payment pages and critical files.
Goal 6

Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs
Information security policy, targeted risk analyses, documented and confirmed PCI DSS scope, security awareness, personnel screening, management of third-party service providers, and an incident response plan.
Appendices

Additional requirements and supporting material

Appendix A1
Additional requirements for multi-tenant service providers.
Appendix A2
Additional requirements for entities using SSL or early TLS for card-present POS POI terminal connections.
Appendix A3
Designated Entities Supplemental Validation, applied only when a payment brand or acquirer requires it.
Appendices B and C
Compensating controls and the compensating controls worksheet.
Appendices D and E
The customised approach, with sample templates for the controls matrix and targeted risk analysis.
Appendices F and G
Leveraging the PCI Software Security Framework, and the glossary of terms.
v4 concepts

Ideas that shape a v4.0.1 programme

Defined approach
Meeting each requirement as written, with the assessor following the defined testing procedures.
Customised approach
Designing a control that meets the requirement’s stated objective, supported by a controls matrix and targeted risk analysis, with the assessor deriving tests. Some requirements are not eligible.
Targeted risk analysis
A documented analysis used to set the frequency of certain activities under Requirement 12.3.1, and required for each requirement met through the customised approach.
Scope confirmation
The entity confirms its PCI DSS scope at least once every 12 months and on significant change. Service providers do so at least once every six months.
Roles and responsibilities
Each requirement now begins with documented, assigned and understood roles for the activities it covers.

Implementation roadmap

How to implement it, step by step

A typical route to a first v4.0.1 assessment. Effort depends heavily on how small the cardholder data environment can be made.

  1. 1

    Confirm your obligations and validation route

    Ask your acquirer or the payment brands which merchant or service provider level applies, and whether you validate through a Report on Compliance or a Self-Assessment Questionnaire.

    OutputsValidation levelROC or SAQ type
  2. 2

    Map account data and define scope

    Trace where account data enters, flows, is stored and leaves. Identify every system in, connected to or able to affect the cardholder data environment.

    OutputsData-flow diagramsScoped asset inventory
  3. 3

    Reduce scope

    Remove data that is not needed, and consider tokenisation, point-to-point encryption, outsourcing and network segmentation to shrink the environment that must be protected.

    OutputsSegmentation designScope decisions
  4. 4

    Agree shared responsibilities

    List every third-party service provider that touches account data or can affect it, and record which requirements each one manages.

    OutputsService provider listResponsibility matrix
  5. 5

    Run a gap assessment

    Test current controls against all 12 requirements, including the requirements that became mandatory on 31 March 2025. Decide where the customised approach is justified.

    OutputsGap registerApproach decisions
  6. 6

    Remediate and complete risk analyses

    Close gaps, write the targeted risk analyses for flexible frequencies, and document roles and responsibilities for each requirement.

    OutputsTargeted risk analysesRemediation evidence
  7. 7

    Operate the periodic controls

    Run the quarterly scans, reviews, tests and training on schedule, so evidence exists for the whole assessment period and not only on the day.

    OutputsASV scan reportsReview records
  8. 8

    Assess, attest and repeat

    Complete the assessment with a QSA, or the applicable SAQ, sign the Attestation of Compliance, submit it as your acquirer or the brands require, and plan the next annual cycle.

    OutputsROC or SAQAttestation of Compliance

Audit and evidence guide

What auditors look for, and the evidence to keep

Validation is annual and its form is set by the payment brands and acquirers. Larger merchants and service providers usually need an on-site assessment by a Qualified Security Assessor, while others may self-assess.

How compliance is validated

  1. Step 1

    Report on Compliance (ROC)

    An assessment of every applicable requirement, performed by a Qualified Security Assessor or, where the brand or acquirer accepts it, by a trained Internal Security Assessor.

  2. Step 2

    Self-Assessment Questionnaire (SAQ)

    For eligible entities, a questionnaire matched to how payments are accepted, such as SAQ A for fully outsourced e-commerce or SAQ D for the full set of requirements.

  3. Step 3

    Attestation of Compliance (AOC)

    A declaration of compliance status signed by the entity, and by the assessor where a ROC is performed, submitted to the acquirer or payment brand.

  4. Step 4

    ASV scans

    Quarterly external vulnerability scans by a PCI SSC Approved Scanning Vendor, with passing results needed for each quarter.

What reviewers look for

  • A scope that is complete and confirmed, with accurate data-flow and network diagrams
  • Segmentation that is tested and actually isolates the cardholder data environment
  • No storage of sensitive authentication data after authorisation
  • Multi-factor authentication for all access into the cardholder data environment
  • Management and integrity monitoring of scripts on payment pages
  • Targeted risk analyses that support each flexible frequency
  • Quarterly internal and ASV scans with vulnerabilities resolved and rescanned
  • Penetration tests, including segmentation tests, at the required intervals
  • Log review, with automated mechanisms, and response to security control failures
  • Third-party service provider agreements and annual monitoring of their compliance

Key timelines

External scans by an ASVQuarterly
Internal vulnerability scansAt least every 3 months
Internal and external penetration testsAt least every 12 months
Segmentation testing (service providers)At least every 6 months
PCI DSS scope confirmation12 months (SPs: 6 months)
Security awareness trainingOn hire and every 12 months
Audit log retention12 months (3 on hand)
Future-dated requirementsMandatory since 31 Mar 2025

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Scope

  • Account data-flow diagrams
  • Network diagrams
  • Scoped system inventory
  • Scope confirmation record

Network and configuration

  • Network security control rule reviews
  • Configuration standards
  • Segmentation test results

Data protection

  • Data retention and disposal records
  • Encryption and key management procedures
  • Certificate inventory

Vulnerability management

  • ASV scan reports
  • Internal scan reports
  • Patch records
  • Penetration test reports

Access

  • Role definitions
  • Access reviews
  • MFA configuration
  • Account removal records

Monitoring

  • Log review records
  • Change-detection alerts
  • Incident records

Policy and programme

  • Information security policy
  • Targeted risk analyses
  • Training records
  • Incident response test

Third parties

  • Service provider list
  • Responsibility matrix
  • Provider AOCs

Areas that often need attention

  • Scope drawn too narrowly, missing connected or security-impacting systems
  • Segmentation assumed rather than tested
  • Missed quarterly ASV scans or failing scans left unresolved
  • Payment page scripts with no inventory, authorisation or change detection
  • Flexible frequencies set without a documented targeted risk analysis
  • Unclear responsibilities with service providers
  • Sensitive authentication data found in logs or databases
  • Evidence gathered just before the assessment rather than through the year

How Netra helps

Where each part of the work lives in Netra

Netra loads PCI DSS 4.0.1 as requirements, tasks and policies. Work done for it counts towards other frameworks wherever the same control applies.

Requirements owned and periodic controls run on time

Task Engine

Requirements arrive as tasks with owners and due dates. Recurring tasks for scans, reviews, tests and training keep evidence current through the year.

Status for each requirement

Compliance Centre

Status is derived from completed tasks and evidence, never typed in, and one task can satisfy several frameworks.

Scope and system inventory

Asset Management

Assets in or connected to the cardholder data environment are recorded and linked to the tasks that protect them.

Policies and roles (Requirement 12)

Policy Hub

A policy library generated at onboarding, with a policy score that moves as the work behind each policy is completed.

Targeted risk analyses and risk assessment

Risk Manager

A risk register with inherent and residual heatmaps. Risks reduce as the linked tasks are completed.

Service provider management (12.8)

Third-Party Risk

Vendors found from what Accounts and Purchase pay, assessed through a vendor portal, with decisions and ratings recorded.

Assessor requests and findings

Audit Centre

Run the assessment with evidence already held in a tamper-evident vault, and track findings and corrective actions to closure.

Netra organises PCI DSS work and evidence. It does not by itself establish compliance, and it is not a QSA, an Approved Scanning Vendor, a penetration tester or a SIEM. Validation, the ROC and the Attestation of Compliance follow the process set by your acquirer and the payment brands.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Payments

PCI-DSS

Keep your payment security programme organised

Security

SOC 2

Prepare SOC 2 evidence as part of everyday work

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

See PCI DSS 4.0.1 in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.