PaymentsGlobal

PCI-DSS

Keep your payment security programme organised

Bring payment security responsibilities, evidence and review work together with Netra.

Version note. This is a general PCI DSS overview. The Netra catalogue entry under this label relates to an earlier edition. For the current edition, see PCI DSS 4.0.1. See PCI DSS 4.0.1

Full name
Payment Card Industry Data Security Standard (PCI DSS)
Issued by
PCI Security Standards Council, founded in 2006 by American Express, Discover, JCB, Mastercard and Visa
Current version
v4.0.1, published June 2024. See the PCI DSS 4.0.1 page for the full detail.
Retired versions
v3.2.1 retired 31 March 2024. v4.0 retired 31 December 2024.
Nature
An industry standard, not a law. Payment brands and acquirers decide who must comply and how they validate.
This entry in Netra
Relates to an earlier edition, kept for historical programmes and records

Overview

What PCI DSS is

The Payment Card Industry Data Security Standard is the security baseline for any organisation that stores, processes or transmits payment card account data, or whose systems could affect that data’s security. It is maintained by the PCI Security Standards Council, which the major card brands formed in 2006 to manage a common standard in place of their separate security programmes. The standard itself is not a law. It applies through the rules of the payment brands and the contracts between merchants, service providers and their acquiring banks.

The standard has been revised several times. Version 3.2.1, published in May 2018, was the long-running version that many programmes were built on, and it was retired on 31 March 2024. Version 4.0, published in March 2022, was the most significant rewrite since version 3: it restated the requirements around outcomes, added the customised approach and targeted risk analysis, and introduced 64 new requirements, 51 of them future-dated to 31 March 2025. Version 4.0.1, published in June 2024, is a limited revision with no added or removed requirements. Version 4.0 was retired on 31 December 2024, which leaves v4.0.1 as the only active version.

This page describes the standard as a whole and how organisations move between versions. In Netra’s catalogue, the entry under this label relates to an earlier edition and is useful for organisations keeping historical scope, assessment records and gap analyses. New assessments are against the current version, covered on the PCI DSS 4.0.1 page.

In June 2026 PCI SSC opened a request for comments on v4.0.1 to begin the next iteration of the standard. As of October 2026 no newer version had been published.

Who it applies to

PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or can affect the security of the cardholder data environment, including:

  • Merchants of every size and channel: card-present, e-commerce and mail or telephone order
  • Acquirers, issuers and payment processors
  • Payment aggregators, gateways and other payment service providers
  • Service providers whose systems or staff can affect the security of a customer’s cardholder data environment
  • Indian banks, fintechs and processors that issue, acquire or process cards on the international and domestic card networks

Whether an entity must validate, and at what level, is decided by the payment brands and its acquirer. Merchant and service provider levels and their thresholds are set by each brand.

Structure

The standard, its versions and its ecosystem

The six goals and 12 principal requirements have been stable for many years, but their titles and content changed in version 4. Validation relies on a set of roles and documents defined by PCI SSC.

History

Versions that matter today

v3.2.1 (May 2018)
A minor revision of v3.2. It was the basis of most programmes until v4 and was retired on 31 March 2024.
v4.0 (March 2022)
A major revision, written around security objectives, with the customised approach, targeted risk analysis and 64 new requirements. Retired on 31 December 2024.
v4.0.1 (June 2024)
A limited revision of v4.0 that corrects errors and clarifies intent, with no added or removed requirements. The only active version.
Future-dated requirements
51 of the new v4 requirements were best practice until 31 March 2025 and are mandatory from that date.
Next iteration
PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026. No newer version had been published by October 2026.
Goals 1–2

Secure network and systems, and protecting account data

Each requirement shows its v3.2.1 title and its current v4.x title.

Requirement 1
v3.2.1: Install and maintain a firewall configuration to protect cardholder data. v4.x: Install and Maintain Network Security Controls.
Requirement 2
v3.2.1: Do not use vendor-supplied defaults for system passwords and other security parameters. v4.x: Apply Secure Configurations to All System Components.
Requirement 3
v3.2.1: Protect stored cardholder data. v4.x: Protect Stored Account Data.
Requirement 4
v3.2.1: Encrypt transmission of cardholder data across open, public networks. v4.x: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.
Goals 3–4

Vulnerability management and access control

Requirement 5
v3.2.1: Protect all systems against malware and regularly update anti-virus software or programs. v4.x: Protect All Systems and Networks from Malicious Software.
Requirement 6
v3.2.1: Develop and maintain secure systems and applications. v4.x: Develop and Maintain Secure Systems and Software.
Requirement 7
v3.2.1: Restrict access to cardholder data by business need to know. v4.x: Restrict Access to System Components and Cardholder Data by Business Need to Know.
Requirement 8
v3.2.1: Identify and authenticate access to system components. v4.x: Identify Users and Authenticate Access to System Components.
Requirement 9
v3.2.1: Restrict physical access to cardholder data. v4.x: Restrict Physical Access to Cardholder Data, the same title.
Goals 5–6

Monitoring and testing, and information security policy

Requirement 10
v3.2.1: Track and monitor all access to network resources and cardholder data. v4.x: Log and Monitor All Access to System Components and Cardholder Data.
Requirement 11
v3.2.1: Regularly test security systems and processes. v4.x: Test Security of Systems and Networks Regularly.
Requirement 12
v3.2.1: Maintain a policy that addresses information security for all personnel. v4.x: Support Information Security with Organizational Policies and Programs.
v3 to v4

What changed in substance

Objectives and flexibility
Requirements are stated around security outcomes, and each can be met through the defined approach or the customised approach.
Targeted risk analysis
Entities set the frequency of certain activities themselves, backed by a documented targeted risk analysis.
Stronger authentication
Multi-factor authentication for all access into the cardholder data environment, and stronger password requirements.
E-commerce and phishing
Management and change detection for scripts on payment pages, and technical protection against phishing.
Programme discipline
Documented roles for every requirement, scope confirmed at least annually, automated log review and authenticated internal scanning.
Validation

Roles and documents in a PCI DSS assessment

Qualified Security Assessor (QSA)
An assessor company and staff qualified by PCI SSC to perform PCI DSS assessments and complete a Report on Compliance.
Internal Security Assessor (ISA)
A trained employee who can assess their own organisation, where the acquirer or brand accepts it.
Approved Scanning Vendor (ASV)
A company approved by PCI SSC to run the quarterly external vulnerability scans.
ROC, SAQ and AOC
The Report on Compliance, the Self-Assessment Questionnaire for eligible entities, and the Attestation of Compliance that declares the result.
Related

Other PCI SSC standards

PCI DSS sits alongside other PCI SSC standards, including PIN Security, Point-to-Point Encryption (P2PE), the Software Security Framework, 3-D Secure and Card Production and Provisioning. The Software Security Framework replaced PA-DSS, which was retired in 2022.

Implementation roadmap

How to implement it, step by step

For an organisation whose programme, records or controls were built on an earlier version, the route to the current version usually looks like this.

  1. 1

    Confirm what applies now

    Confirm with your acquirer or the payment brands your validation level and route, and that your next assessment is against v4.0.1.

    OutputsValidation levelTarget version confirmed
  2. 2

    Keep historical records separate

    Label earlier scope documents, assessments and evidence by version, so they support history and trend but are not mistaken for current evidence.

    OutputsArchived v3.2.1 recordsVersion labels
  3. 3

    Revalidate the scope

    Redraw account data flows and confirm the cardholder data environment and connected systems as they are today, not as they were at the last assessment.

    OutputsCurrent data-flow diagramsScope confirmation
  4. 4

    Map old controls to new requirements

    Use the version 3 to version 4 changes to see which controls carry over, which need rework and which are new, including all the requirements that became mandatory on 31 March 2025.

    OutputsRequirement mappingGap register
  5. 5

    Decide the approach and frequencies

    Choose the defined or customised approach for each requirement, and write the targeted risk analyses for activities whose frequency you set.

    OutputsApproach decisionsTargeted risk analyses
  6. 6

    Close gaps and run the controls

    Implement new controls such as multi-factor authentication into the cardholder data environment and payment page script management, and run periodic activities on schedule.

    OutputsRemediation evidenceOperating records
  7. 7

    Assess and move to an annual rhythm

    Complete the ROC or SAQ against v4.0.1, sign the Attestation of Compliance, and plan the next cycle around the request for comments now under way for the next iteration.

    Outputsv4.0.1 ROC or SAQAttestation of Compliance

Audit and evidence guide

What auditors look for, and the evidence to keep

PCI DSS compliance is validated each year through a process set by the payment brands and the acquirer. Assessments under retired versions are no longer accepted for new validations.

How validation works

  1. Step 1

    Level and route

    The acquirer or payment brand assigns a merchant or service provider level, which decides between a Report on Compliance and a Self-Assessment Questionnaire.

  2. Step 2

    Assessment

    A QSA or accepted ISA tests each applicable requirement for a ROC. Eligible entities complete the SAQ that matches how they accept payments.

  3. Step 3

    Scanning

    An Approved Scanning Vendor performs external vulnerability scans each quarter, alongside the entity’s own internal scans.

  4. Step 4

    Attestation and submission

    The entity signs the Attestation of Compliance and submits it, with any reports requested, to its acquirer or the payment brands.

What reviewers look for

  • Which version of the standard the assessment is against
  • An accurate, current scope and data-flow diagrams
  • Segmentation that is tested, where it is used to reduce scope
  • Absence of sensitive authentication data after authorisation
  • Requirements that were new in v4 and mandatory since 31 March 2025
  • Quarterly ASV scans with passing results
  • Clear division of responsibilities with service providers
  • Evidence that periodic controls ran throughout the year

Key dates and timelines

v3.2.1 retired31 Mar 2024
v4.0 retired31 Dec 2024
Future-dated v4 requirementsMandatory since 31 Mar 2025
RFC on v4.0.1 for the next iteration3 Jun to 20 Jul 2026
Compliance validationAnnual
External ASV scansQuarterly

Evidence to keep, by area

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

Version history

  • Earlier assessment reports
  • Earlier AOCs
  • Version-labelled evidence archive

Scope

  • Current data-flow diagrams
  • Network diagrams
  • Scope confirmation

Transition

  • v3.2.1 to v4.0.1 requirement mapping
  • Gap analysis
  • Migration action list

New v4 controls

  • Targeted risk analyses
  • MFA into the cardholder data environment
  • Payment page script inventory

Validation

  • ASV scan reports
  • ROC or SAQ
  • Attestation of Compliance

Third parties

  • Service provider list
  • Responsibility matrix
  • Provider AOCs

Areas that often need attention

  • Programmes still mapped to v3.2.1 requirement wording
  • Earlier evidence reused without checking it against v4.0.1
  • Future-dated requirements treated as optional after 31 March 2025
  • Scope documents not updated since the last assessment
  • Frequencies changed without a targeted risk analysis
  • Service provider responsibilities assumed rather than agreed

How Netra helps

Where each part of the work lives in Netra

Netra keeps the edition explicit. Historical work under this entry stays available as a record, while current work is carried out against PCI DSS 4.0.1.

Transition work owned and tracked

Task Engine

Each gap from the version mapping becomes a task with an owner and a due date, and recurring tasks keep periodic controls running.

Status against the version being assessed

Compliance Centre

Status is derived from completed tasks and evidence, so historical and current positions are not mixed.

Scope and connected systems

Asset Management

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

Policies brought up to v4 wording

Policy Hub

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

Earlier and current assessments

Audit Centre

Audits are run end to end with findings and corrective actions, and evidence is held in a tamper-evident vault with its history intact.

Service providers

Third-Party Risk

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

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

Common questions

More questions about Netra

Related frameworks

View all frameworks
Payments

PCI DSS 4.0.1

Keep payment-security work connected to assessment evidence

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

Security

SOC 2

Prepare SOC 2 evidence as part of everyday work

See PCI-DSS in Netra

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