Version 3.2 heavily concentrates on service providers and merchants to ensure that the implementation and maintenance of PCI DSS gets adopted business-as-usual (BAU), which is the normal execution of standard functional operations within an organisation and eventually becomes second nature. Even though technically it is an annual assessment, the PCI SSC guides businesses to adopt a formal risk based approach to security.
Appendix A3 now contains the Designated Entities Supplemental Validation (DESV) requirements, which used to be a separate document. They are designed only to be used when a payment brand or acquirer requires additional validation of a merchant or service provider’s PCI DSS requirements on a BAU basis. There are “high risk” merchants such as online gaming and various service providers where its necessary to make sure they’re PCI compliant on a day-to-day basis, instead of just an annual basis. DESV is in addition of a full PCI DSS validation.
The PCI SSC has said: “Service providers play an important role in securing cardholder data for their customers. An organization could go to great lengths to protect their internal network only to see a third party negate all of their effort as indicated in data breach reports. That is why several new requirements were identified for service providers in PCI DSS 3.2.”
- PCI DSS 3.2 is available for assessments, although ROC’s written under 3.1 are accepted until October 31 2016
- New requirements in PCI DSS 3.2 have an extended grace period:
- SSL and TLS migration must be completed by June 30, 2018
- Service providers must provide secure alternative by June 2016
- Some point-of-sale (POS) or point-of-interaction (POI) terminals may be subject to exemption as described in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS
- The new requirements introduced in PCI DSS 3.2 will be considered best practices until 31 January 2018. Starting 1 February 2018 they are effective as requirements.
One of the more significant changes is multifactor authentication. 8.3 provides clarification from “two-factor authentication” and expands the requirement from personnel with remote access to all personnel with non-console administrator access to card data and systems.
PCI SSC advise that: “By multi-factor authentication we mean that two or more credentials must be used to authorize a person’s access to card data and systems. Examples of factors include something you know, such as a password or passphrase; something you have, such as a token or smart card; or something you are, such as a biometric.”
It’s important to know that there are no changes regarding Secure Sockets Layer (SSL)/early Transport Layer Security (TLS) migration beyond what was announced in December of 2015.