.png)
In May 2018, the PCI Security Standards Council, the authors of the PCI DSS standard, issued a new version of that standard - version 3.2.1. Let's review the changes from 3.2 to 3.2.1
First, it should be noted that nothing significant has changed, so you do not have to panic.
If you have a PCI DSS compliance program in place or under construction, this new version of the document probably does not change anything. The update comprises administrative fixes, retires forward looking statements about dates that have now passed, and makes a few clarifications.
There are zero new requirements.
There were a few items from the introduction of version 3.2 that were meant to take effect on dates after the version’s release. Those dates have passed, so those items are now just normal requirements—no different from any other standards. There were also a few punctuation and formatting tidy-ups.
See also: Summary of new deadlines in PCI DSS 3.2
Some of my more detail-oriented readers may have noticed that requirement 3.6.2 mentioned in the guidance that encryption keys must only be distributed to the key custodians identified in Requirement 3.5.1. However, 3.5.1 was about documentation and interviewing personnel. This error has now been corrected to refer to 3.5.2 which relates to the list of key custodians.
Another development is the use of Multi Factor Authentication (MFA) as a compensating control example for non-console administrative access from the internal network in Appendix B: the compensating control explanation. MFA is now required for non-console administrative access from the internal network anyway (added as requirement 8.3.1 in version 3.2). That means that this has become an invalid example and has been removed.
The most complicated change relates to users of SSL/Early TLS. Due to implementation dates passing, the current position on SSL/Early TLS is as follows.
- The time for mitigation and migration plans has passed for almost everybody. Except for the POS POI case below; SSL/Early TLS is now banned. Come on people! It is insecure and you have known about it for years! There is no more wiggle room, excuses, or exceptions - except for....
- POS POI terminal installations can continue to use SSL/Early TLS if it is present but not used as a security control, or:
- It is an existing installation (as of the retirement date of PCI DSS version 3.1 in October 2016).
- And the card-present terminals and the termination points that they connect to are not susceptible to any known exploits for SSL/Early TLS.
- If you are a service provider, you must also provide a service free of SSL/Early TLS and you must have the mitigation and migration plans in place.
The exact details have been updated in Appendix A2, and an information supplement is available from the council.
If you still need to rely on SSL/Early TLS in your environment, your only option now is to go the compensating control route and add additional controls to mitigate the insecurity of SSL/Early TLS.
For PCI DSS version 3.2.1, so far, the PCI DSS standard has been updated and there is a corresponding summary of changes document. The SAQs will also be updated soon along with the ROC template and so forth.
You can continue to comply with and validate against PCI DSS 3.2 until the end of 2018. Compliance with 3.2.1 is pretty much the same as compliance with 3.2, but annual QSA validation or self assessment will have to keep using 3.2 documents until the ROCs and SAQs have been updated.
If you have more questions ... 
