Assessing and Reporting Against PCI DSS v3.1: The Impact of New Migration Dates for SSL and Early TLS

 

On 18 December 2015 the Council extended the PCI Data Security Standard (PCI DSS) deadline for migrating away from Secure Sockets Layer (SSL)/ early Transport Layer Security (TLS) from 30 June 2016 to 30 June 2018. The extension recognizes that complex relationships and interdependencies exist in the payments industry that could impact an organization’s ability to meet the original deadline. The extension is not intended to delay or postpone migration efforts. It’s critical that organizations work to complete their migration as soon as possible. All organizations using SSL/early TLS should have a Risk Migration and Mitigation Plan, outlining their plans for transitioning to a more secure protocol and how they will manage risk in the interim.

 

While the deadline extension is good news for many organizations in the process of transitioning, we recognize it does create some challenges from a PCI DSS compliance reporting standpoint. A new version of PCI DSS is scheduled for release in 2016 that will include the updated deadlines as well as corresponding reporting forms and templates. In the meantime, there are many organizations assessing against the current version of PCI DSS (v3.1) that will need to report using PCI DSS v3.1 documentation. Below we outline some key considerations for organizations to report compliance against PCI DSS v3.1.

At a high level, the following guidance can be applied when assessing and reporting PCI DSS Requirements 2.2.3, 2.3 and 4.1 for PCI DSS v3.1:

• As is currently the case, entities with a Risk Mitigation and Migration Plan that includes a completion date no later than 30 June 2016 (and that meets all other Risk Mitigation and Migration Plan content requirements) are considered to be “in place” for that particular requirement.*
• Entities with a target migration date that falls between 30 June 2016 and 30 June 2018 are considered as being “in place with a compensating control,” with the PCI SSC announcement providing justification for the migration timeframe.
• Entities with a target migration date that is later than 30 June 2018 are considered to be “not in place” for these requirements.

* Note: All applicable elements of a requirement or sub-requirement must be met in order for it to be considered “In Place.” This guidance addresses only the target migration dates within an entity’s Risk Mitigation and Migration Plan, and does not preclude the need to meet other requirements and sub-requirements.

Since the Self-Assessment Questionnaires (SAQs) and Report on Compliance (ROC) Reporting Template for PCI DSS v3.1 still include the previous deadline of 30 June 2016, it would be technically inaccurate to mark a requirement as “In Place” if it does not meet the requirement as stated. For this reason, an organization that meets requirements for the extended migration dates should report with the “In Place with Compensating Control Worksheet (CCW)” option, and not the “In Place” option.

The following Frequently Asked Questions available in our FAQ resource on the PCI SSC website provide further details:

1. FAQ 1372: How should entities apply the new SSL/TLS migration dates to Requirements 2.2.3, 2.3 and 4.1 for PCI DSS v3.1?
2. FAQ 1373: How should entities complete their ROC or SAQ for PCI DSS v3.1 using the new SSL/TLS migration dates? 

The first FAQ provides a high-level overview for completing a PCI DSS v3.1 validation using the new migration dates. The second FAQ provides detailed information on how to complete a ROC or SAQ for PCI DSS v3.1 using these new dates. Both of these FAQs are recommended for any organization migrating from SSL/early TLS.

For more details on the new migration dates, requirements and available resources, download the Bulletin on Migrating from SSL and Early TLS.  We urge all organizations to complete their migration as soon as possible - don’t look at the extended migration period as a reason to delay taking action.