Quick Guide | Changes in PCI DSS v3.2.1

Quick Guide Changes in PCI DSS v3.2.1

On the 17th May 2018, the PCI SSC published the latest version of the PCI Data Security Standard: the PCI DSS v3.2.1.  In this article we look at the changes that have been included in the updated Standard.  These are also discussed in the PCI SSC’s summary of changes document.


A new standard?

This new release is a minor update to the PCI DSS v3.2; hence it’s version numbering as v3.2.1 not v3.3. It includes only clarifications, there are no new PCI DSS requirements although Appendix A2 has been updated because of the passing of the 30th June 2018 SSL/early TLS migration deadline date and its requirements now apply differently.


What are the dates we need to work to?

The PCI SSC has allowed a six month transition period from publication of v3.2.1 to allow organisations in the middle of their compliance program or assessment to complete their activities against v3.2 (both ROCs and SAQs).


PCI DSS v3.2.1 Effective from: Now
PCI DSS v3.2 Retired from: January 1, 2019


During the six month transition period from 17th May 2018 to 31st December 2018, PCI DSS versions 3.2 and 3.2.1 are effective, and able to be used for assessments.  When version 3.2 is retired on 31st December 2018, all compliance assessments after this date must be against PCI DSS v3.2.1.


PCI DSS v3.2.1 is valid for assessments from the date of its publication and all key compliance documents will shortly be released to undertake v3.2.1 compliance assessments.  These will include the Self-Assessment Questionnaires (SAQs) and the ROC Reporting Template (the Report on Compliance template used for on-site assessments). A v3.2.1 version of the Prioritized Approach Tool is also available to merchants still progressing towards compliance.


During the transition period and after 1st January 2019, we recommend that you check all received ROCs to confirm that the assessing QSA has used the correct version of ROC Reporting Template (i.e. it matches the version of PCI DSS the QSA states they have assessed your customer against, which is noted in section 1.3 of the ROC).


Quick Guide | PCI DSS v3.2.1 | Analysis of Changes

The ROC will clearly state the PCI DSS Template title, revision and date.


The PCI DSS v3.2 ROC template is titled ‘PCI DSS v3.2 Template for Report on Compliance’, at Revision 1.0 and dated April 2016; this template must not be used for a PCI DSS v3.2.1 assessment.


The PCI DSS version of the ROC or SAQ submitted must also match the version of the associated Attestation of Compliance that you receive.


It should be noted that the PA-DSS will not transition to v3.2.1 and will remain at v3.2.


So what is new?

As the PCI SSC confirmed in their press release, the PCI DSS has been updated to amend some minor errors, to remove notes against PCI DSS requirements where the effective date of those requirements has now passed, as well as to update notes and testing procedures for those requirements where SSL/early TLS may no longer be used as a security control.


Webpage URL

Find out more about our PCI DSS compliance services by clicking the button below


Requirements where the effective date has passed

Reqt # Requirement Applicable to
3.5.1 Maintain a documented description of the cryptographic architecture that includes:


· Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

· Description of the key usage for each key

Inventory of any HSMs and other SCDs used for key management


Service Providers Only
6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.


All entities
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.


All entities
10.8 Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:


· Firewalls


· File Integrity Monitoring

· Anti-virus

· Physical access controls

· Logical access controls

· Audit logging mechanisms


Segmentation controls (if used)


Service Providers Only
10.8.1 Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:


· Restoring security functions

· Identifying and documenting the duration (date and time start to end) of the security failure

· Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause

· Identifying and addressing any security issues that arose during the failure

· Performing a risk assessment to determine whether further actions are required as a result of the security failure

· Implementing controls to prevent cause of failure from reoccurring


Resuming monitoring of security controls


Service Providers Only If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.


Service Providers Only
12.4.1 Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:


· Overall accountability for maintaining PCI DSS compliance


Defining a charter for a PCI DSS compliance program and communication to executive management


Service Providers Only
12.11 Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:


· Daily log reviews

· Firewall rule-set reviews

· Applying configuration standards to new systems

· Responding to security alerts


Change management processes


Service Providers Only
12.11.1 Maintain documentation of quarterly review process to include:


· Documenting results of the reviews


Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program


Service Providers Only



As we noted in an earlier article, organisations for whom these requirements are applicable were expected to have these controls in place by 31st January 2018.


Even if an organisation had completed their compliance assessment just before the requirements’ deadline date (marking those requirements as ‘Not applicable because they are best practice’), to remain compliant they must still have implemented the requirements that are applicable to them, even if they will not be formally assessed for compliance until many months after the deadline passed.


Amendments related to SSL and early TLS

The note referencing the need to complete Appendix A2, where SSL or early TLS is used as a security control, has been removed from the following requirements.  This change is in preparation for the expiry of the 30th June 2018 migration deadline.


Reqt # Requirement Applicable to
2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.


All entities
2.3 Encrypt all non-console administrative access using strong cryptography.


All entities
4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:


· Only trusted keys and certificates are accepted.

· The protocol in use only supports secure versions or configurations.

· The encryption strength is appropriate for the encryption methodology in use.

All entities


A new note has been added to each requirement’s the guidance column to confirm that SSL/early TLS is “not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2”.


Appendix A2 itself has also been updated in preparation for the passing of the migration date.  This Appendix now only applies to entities using SSL/early TLS as a security control to protect Card Present Point of Sale (POS) Point of Interaction (POI) terminals, including service providers who provide connections into POS POI terminals.


The introductory verbiage of the appendix has been updated to reflect the fact that SSL/early TLS may only be used as a security control after the 30th June 2018 deadline by POS POI terminals and their service provider connection points.


The Appendix outlines a number of provisions:


  • New POS POI terminal implementations must not use SSL or early TLS as a security control;
  • All POS POI terminal service providers must provide a secure service offering (see requirement A2.3 below);
  • Service providers supporting existing POS POI terminal implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place (see requirement A2.2 below);
  • POS POI terminals in card-present environments that can be verified as not being susceptible to any known exploits for SSL and early TLS, and the SSL/TLS termination points to which they connect, may continue using SSL/early TLS as a security control.


Appendix A2 Requirement Applicable to
A2.1 Where POS POI terminals (at the merchant or payment acceptance location) use SSL and/or early TLS, the entity must confirm the devices are not susceptible to any known exploits for those protocols.


The entity with the POS POI terminals using SSL and/or early TLS, such as a merchant
A2.2 Requirement for Service Providers Only: All service providers with existing connection points to POS POI terminals referred to in A2.1 that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.


POS POI service providers that serve as the termination or connection point for POS POI terminals using SSL and/or early TLS.
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering. POS POI service providers that serve as the termination or connection point for POS POI terminals using SSL and/or early TLS.  These service providers must also provide a secure protocol option for their service.


Amendments to Appendix B: Compensating Controls

As PCI DSS requirement 8.3.1 is no longer a best practice requirement (as discussed above), the PCI SSC has updated the compensating control example included in the PCI DSS Appendix B.


Quick Guide | PCI DSS v3.2.1 | Analysis of Changes

In PCI DSS v3.2, Appendix B stated that multi-factor authentication from within the internal network could be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported.


However, as the Appendix B makes clear, “Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review”; therefore, as multi-factor authentication for non-console administrative access is now a PCI DSS requirement, it can no longer be used as a compensating control.


If you review and/or approve your customers’ compensating controls (e.g. compensating controls submitted by your level 1 merchants) we recommend that, when those entities next submit their validation documentation, you check they are not relying on multi-factor authentication for non-console administrative access as part of the compensating control.


Be aware that multi-factor authentication for non-console administrative access is only invalid as a compensating control if it is already required for the item under review.  For example, as 8.3.1 is a password requirement it cannot be used to compensate for an entity’s lack of fulfillment of other PCI DSS password requirements.


Amended SAQs

The changes outlined above are reflected in updated v3.2.1 version of the PCI DSS Self-Assessment Questionnaires (SAQs).  In addition, one new requirement has been added to SAQ A, the SAQ that applies to Card Not Present (ecommerce or mail/telephone order) merchants when all cardholder data functions are outsourced to validated third parties.


This new requirement is the inclusion of requirement 6.2:


Reqt # Requirement Applicable to
6.2 (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches? SAQ A eligible ecommerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.
(b) Are critical security patches installed within one month of release?


The SAQ A already included requirements intended to protect the merchant website and ensure the integrity of the ecommerce redirect (or iFrame) mechanism:


  • Change vendor defaults and remove unnecessary default accounts (requirement 2.1);
  • Uniquely identify and authenticate all users (excluding consumer users) (requirements 8.1.1, 8.2, 8.5);
  • Use strong passwords for user authentication (requirement 8.2.3);
  • Immediately de-activate or remove terminated user accounts (requirement 8.1.3);

Requirement 6.2 requires merchants to make sure the web server OS, ecommerce software and web applications are up to date by applying the latest applicable security patches to address known security vulnerabilities. 


Critical security patches and updates – to address the most serious vulnerabilities (weaknesses) – must be applied within 30 days of their release.  As the webserver could be managed or supported by a third-party, merchants may need to seek assurance and evidence of fulfilment of this requirement from the third-parties involved.


The addition of the patching requirement 6.2 will help to protect the merchant’s website from compromise, ensuring that known vulnerabilities are addressed and not available to attackers seeking to breach the merchant website to tamper with the redirection mechanism, for example to redirect customers to a fraudulent payment page.


Like this Article?

Subscribe to receive more tips & news about Cyber Security, Compliance and a lot more!

  • Sysnet Global Solutions will use the information you provide on this form to be in touch with you regarding non-promotional as well as promotional material by email and phone. If you agree to same, then please select the ‘I consent’ box after reading the terms and conditions listed below in relation to consent. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, update your preferences for communications, content etc. by clicking on the update my preferences button in any email we send you or by contacting us at marketing@sysnetgs.com We will treat your information with respect. For more information about our privacy practices please visit our website. By clicking below, you agree that we may process your information in accordance with these terms. We use Pardot as our marketing automation platform. By clicking below to submit this form, you acknowledge or agree that the information you provide will be transferred to Pardot for processing in accordance with their Privacy Policy and Terms