PCI DSS v3.2 — Payment Card Industry Data Security Standard
- ClassificationCategoryPayment SecurityDomainCybersecurityFramework FamilyPCI Security Standards
- Regulatory ContextTypeStandardLegal InstrumentStandardSectorFinancial SectorIndustryPayment & FinTech
- Region / PublisherRegionGlobalRegion DetailGlobalPublisherPayment Card Industry Security Standards Council (PCI SSC)
- VersioningVersionv3.2 (April 2016; superseded by v3.2.1 in May 2018 and retired January 1, 2019)Effective DateRetired January 1, 2019Issue DateApril 2016
- AdoptionAdoption ModelIndustry RequirementImplementation ComplexityHigh
- Official ReferenceOpen Link in New TabSource
License included / downloadable: Yes
PCI SSC publishes PCI DSS free of charge; the current documents are downloaded from the PCI SSC Document Library after accepting the Council's license agreement. v3.2 is retired, and the text to use is PCI DSS v4.0.1.
Framework text is licensed by its publisher and is included only where stated above.
- PCI DSS v3.2 (April 2016) is a retired version of the standard, superseded by v3.2.1 in May 2018 and retired on December 31, 2018.
- The current version is PCI DSS v4.0.1, published June 2024; no entity can validate to v3.2 today.
- v3.2 made multi-factor authentication for non-console administrative access mandatory from February 1, 2018.
- For service providers it added six-monthly segmentation testing, a documented cryptographic architecture, and a formal compliance program.
- Its Appendix A2 governed the migration from SSL and early TLS, with a deadline of June 30, 2018.
Overview
PCI DSS v3.2 is a superseded version of the Payment Card Industry Data Security Standard: the current version is PCI DSS v4.0.1, published in June 2024. The PCI Security Standards Council (PCI SSC) published v3.2 in April 2016 as an update from v3.1, and the Council's version table records that it was retired on December 31, 2018 (Table 6 of v4.0.1). The Council's December 2018 notice states that v3.2 remained valid through December 31, 2018, that entities could validate to either v3.2 or v3.2.1 before January 1, 2019, and that from that date all validations had to be to v3.2.1.
v3.2 introduced requirements that became mandatory on February 1, 2018: for all organizations, change management confirmation that affected requirements are in place after significant change (Requirement 6.4.6) and multi-factor authentication for all non-console administrative access (8.3.1); for service providers, a documented description of the cryptographic architecture (3.5.1), detection and response to failures of critical security control systems (10.8 and 10.8.1), penetration testing of segmentation controls at least every six months (11.3.4.1), a formal PCI DSS compliance program (12.4.1) and at least quarterly reviews of policy adherence (12.11 and 12.11.1). Its Appendix A2 governed the migration from SSL and early TLS, whose deadline was June 30, 2018.
No entity can validate to v3.2 today. Section 14 of v4.0.1 directs questions about previous versions to the organizations that manage compliance programs, the payment brands and acquirers, and the chain of successors is complete: v3.2.1 (May 2018) retired on March 31, 2024, v4.0 (March 2022) retired on December 31, 2024, and v4.0.1 is the only version in use. This page is kept as the record of the v3.2 lifecycle for teams that hold assessments, contracts or evidence that reference it.
Why does it matter?
A retired version still matters when contracts, assessment histories or control libraries cite it. v3.2 was the version that made multi-factor authentication for non-console administrative access and six-monthly segmentation testing for service providers part of PCI DSS, and the version under which the industry completed its migration away from SSL and early TLS. Knowing what v3.2 required, and when it stopped being valid, lets a team read an older Report on Compliance or Attestation of Compliance correctly and move the evidence behind it into the v4.0.1 requirement set without gaps.
Key benefits include:
- Multi-factor authentication for administrators
Requirement 8.3.1 required MFA for all non-console administrative access, mandatory from February 1, 2018 in every organization's assessment.
- Change control that re-checks PCI DSS
Requirement 6.4.6 required change management processes to confirm that affected PCI DSS requirements are in place after a significant change.
- Service provider accountability
Requirements 3.5.1, 10.8 and 10.8.1, 11.3.4.1, 12.4.1, 12.11 and 12.11.1 added cryptographic architecture documentation, control-failure detection, six-monthly segmentation testing, a formal compliance program and quarterly reviews for service providers.
- An end to SSL and early TLS
After June 30, 2018 SSL and early TLS could not be used as a security control, except by POS POI terminals verified as not susceptible to known exploits and the termination points they connect to, as Appendix A2 defined.
- A clear retirement path
The Council published v3.2.1 in May 2018 and gave six months for the transition, retiring v3.2 on January 1, 2019 so that reporting templates and forms could be updated.
How does it work?
The Document Changes table of the current standard records the lifecycle: April 2016, v3.2, 'Update from PCI DSS v3.1'; May 2018, v3.2.1, 'Update from PCI DSS v3.2'. The SAQ D for Merchants carries the same milestones, with revision 1.0 of April 2016 aligned to v3.2, revision 1.1 of January 2017 renumbered to match the other SAQs, and the June 2018 revision aligned to v3.2.1. The new v3.2 requirements were a best practice until February 1, 2018 and mandatory from that date, when they had to be included in PCI DSS assessments; the Council's March 2018 post listed them by number for all organizations and for service providers.
The Council described v3.2.1 as a minor revision planned to account for dates that had already passed, the February 1, 2018 effective date and the SSL and early TLS migration dates, with no new requirements. Its December 2018 notice explained that the six-month transition allowed organizations to update reporting templates and forms and gave flexibility to entities whose validations in the second half of 2018 included completing the SSL and early TLS migration before June 30, 2018. Entities wanting to validate to v3.2 were told to complete the validation before January 1, 2019; from that date every validation had to be to v3.2.1.
Structurally, v3.2 used the twelve principal requirements, numbered 1 to 12, that PCI DSS has kept through v4.0.1 (Table 1 of the current standard), and the requirement numbers the Council cited for v3.2, from 3.5.1 to 12.11.1, fall within them. Teams reading a v3.2-era report should expect that numbering. The Council's summaries of changes (3.1 to 3.2, 3.2 to 3.2.1, 3.2.1 to 4.0 and 4.0 to 4.0.1), each named in the Document Changes table of the current standard, are the documents that trace a v3.2 requirement forward to its v4.0.1 counterpart.
Key Elements
- Version and dates
Published April 2016 as an update from v3.1; valid through December 31, 2018; retired January 1, 2019 (Table 6 of v4.0.1 and the Council's December 2018 notice).
- New requirements for all entities (effective February 1, 2018)
Change management confirming affected requirements after significant change (6.4.6) and multi-factor authentication for all non-console administrative access (8.3.1).
- New requirements for service providers (effective February 1, 2018)
Cryptographic architecture description (3.5.1); detection and response to failures of critical security controls (10.8, 10.8.1); segmentation penetration testing at least every six months (11.3.4.1); a formal PCI DSS compliance program (12.4.1); quarterly reviews of policies and procedures (12.11, 12.11.1).
- Appendix A2: SSL and early TLS
Migration deadline June 30, 2018; after that date SSL and early TLS could not be used as a security control except for verified POS POI terminals and their termination points.
- v3.2.1 (May 2018)
A minor revision with no new requirements that removed references to dates already passed; it was the only valid version from January 1, 2019 and was itself retired on March 31, 2024.
- Successors
v4.0 published March 2022 and retired December 31, 2024; v4.0.1 published June 2024 and current, with future-dated requirements that became required after March 31, 2025.
What does it cover?
PCI DSS v3.2 applied to the population PCI DSS still addresses: entities that store, process or transmit cardholder data or sensitive authentication data, including merchants and service providers, with validation required at the discretion of the payment brands and acquirers that manage compliance programs (Section 2 of v4.0.1 states this for the current version). Its additional service-provider requirements applied to entities assessed as service providers. Today the version's scope is historical: it bounds the assessments, Attestations of Compliance and compensating-control documentation produced between April 2016 and December 31, 2018, and it is the baseline from which the v3.2.1 reports that followed until March 31, 2024 were written.
What are its objectives?
Read today, the v3.2 edition is understood through what it set out to do:
Strengthen authentication by requiring multi-factor authentication for all non-console administrative access (8.3.1).
Keep PCI DSS controls intact through change by confirming affected requirements after significant change (6.4.6).
Make service providers accountable through a formal compliance program, quarterly reviews and detection of control failures (12.4.1, 12.11, 10.8).
Complete the industry's move away from SSL and early TLS by June 30, 2018 (Appendix A2).
Hand over to v3.2.1 in May 2018 and retire on January 1, 2019.
Framework in Context
v3.2 is one step in the version chain that Table 6 of the current standard records: v3.2 (April 2016, retired December 31, 2018), v3.2.1 (May 2018, retired March 31, 2024), v4.0 (March 2022, retired December 31, 2024) and v4.0.1 (June 2024, current). Section 14 of the current standard states that v4.0.1 is the current version and that questions about earlier versions belong with payment brands and acquirers. The Self-Assessment Questionnaires followed the same path: the October 2024 SAQs for v4.0.1 replaced the v4.0 SAQs when v4.0 retired. Every forward reference from this page leads to PCI DSS v4.0.1, where the twelve requirements, the defined and customized approaches and the current dates are described.
Common Framework Mappings
PCI DSS v3.2 was mapped to the same information security control sets that organizations map PCI DSS v4.0.1 to today; a crosswalk built for v3.2 should be re-based on the v4.0.1 requirement numbers before it is reused.
Mapped frameworks include:
CIS Controls v8.1
COBIT 2019
FedRAMP Rev. 5
HIPAA
ISO 27001:2022
ISO 27002:2022
NIST CSF 2.0
NIST 800-53 Rev.5
SOC 2
How SmartSuite Supports PCI DSS v3.2
SmartSuite provides the system for managing controls, evidence, mappings, assessments, and reporting.
Use Compliance Management to keep the retired v3.2 requirement set beside the current v4.0.1 set, so that older assessments and evidence stay readable while the live program runs on v4.0.1, and Internal Audit Management to confirm that nothing in the current program still points at a v3.2 requirement number.
Version Register
Record which PCI DSS version each past assessment, Report on Compliance and Attestation of Compliance was validated against, with the April 2016 to December 31, 2018 window for v3.2.
Requirement Crosswalk to v4.0.1
Map each v3.2 requirement number a report cites, such as 8.3.1 or 11.3.4.1, to the v4.0.1 requirement that now covers the control, so evidence moves without gaps.
Historical Evidence Archive
Keep v3.2-era policies, scan reports, compensating controls worksheets and attestations with their dates, separate from live evidence.
Service Provider Program Record
Carry forward the formal PCI DSS compliance program, quarterly reviews and control-failure detection that v3.2 introduced for service providers (12.4.1, 12.11, 10.8).
Protocol and Cryptography Inventory
Retain the SSL and early TLS migration record (Appendix A2, June 30, 2018) as the starting point for the cipher suite and protocol inventory v4.0.1 requires.
Migration Tracking to v4.0.1
Track the gaps closed between the v3.2 control set and v4.0.1, including the requirements that became mandatory after March 31, 2025.
Related frameworks
CIS Controls v8.1 is a prioritized set of 18 Controls and 153 Safeguards, in three Implementation Groups, with a new Govern function.
ISO/IEC 27001:2022 specifies requirements for an information security management system: Clauses 4 to 10, risk treatment, the Statement of Applicability and 93 Annex A controls.
ISO/IEC 27002:2022 is the reference set of 93 information security controls in four themes, with attributes and implementation guidance, that supports an ISO/IEC 27001 ISMS.
ISO/IEC 27701:2025 specifies requirements for a stand-alone privacy information management system (PIMS) for PII controllers and processors, replacing the 2019 edition.
NIST SP 800-53 Rev. 5 is the NIST catalog of security and privacy controls in 20 families, mandatory for federal systems under OMB A-130 and FISMA; Release 5.2.0 issued August 27, 2025.
NIST CSF 2.0 (CSWP 29, February 26, 2024) is the voluntary cybersecurity framework with six Functions including Govern, 22 Categories, 106 Subcategories, Profiles and Tiers.
Frequently Asked Questions For PCI DSS v3.2 (Payment Card Industry Data Security Standard)
No. The Council's version table (Table 6 of PCI DSS v4.0.1) lists v3.2 as retired on December 31, 2018, and its December 2018 notice states that from January 1, 2019 all validations had to be to v3.2.1. v3.2.1 and v4.0 have since retired as well, and PCI DSS v4.0.1 is the current version.
The Document Changes table of the current standard dates v3.2 to April 2016, as an update from v3.1. It remained valid through December 31, 2018 and was retired as of January 1, 2019, six months after v3.2.1 was published in May 2018.
They became mandatory on February 1, 2018. For all organizations: change management confirming that affected PCI DSS requirements are in place after significant change (6.4.6) and multi-factor authentication for all non-console administrative access (8.3.1). For service providers: a documented cryptographic architecture (3.5.1), detection and response to failures of critical security control systems (10.8, 10.8.1), segmentation penetration testing at least every six months (11.3.4.1), a formal PCI DSS compliance program (12.4.1) and at least quarterly reviews that security policies and procedures are followed (12.11, 12.11.1).
The Council described v3.2.1, published in May 2018, as a minor revision with no new requirements, made to account for dates that had already passed: the February 1, 2018 effective date for the new v3.2 requirements and the June 30, 2018 SSL and early TLS migration deadline. Entities could validate to either version until December 31, 2018; v3.2.1 then stood alone until it was retired on March 31, 2024.
PCI DSS v4.0.1. Section 14 of that standard names it the current version, v4.0 retired on December 31, 2024, and the requirements that were a best practice until March 31, 2025 are now required. The Section 14 note adds that questions about the use of previous versions should go to the organizations that manage compliance programs, such as payment brands and acquirers.
Put this framework to work in SmartSuite
Manage controls, risks, evidence, and audits in one platform designed for modern governance, risk, and compliance.