PCI DSS 3.2 was released in April, and it brings a number of new requirements for IT service providers.
You can download it here, from the list of documents on the PCI Security Standards Council’s website. A summary of changes is also available.
Below we review the biggest changes for service providers in PCI DSS 3.2. But first – are you really a service provider under the rules?
If you are an IT service provider, such as an MSP or VAR, then you are almost certainly a “service provider” under PCI DSS version 3.2.
The PCI SSC glossary defines a service provider as follows:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity.”
Chances are that if you’re an MSP or VAR and your clients accept credit cards, then you are a “service provider” under PCI DSS. These new rules apply to you.
Service providers will be held responsible for a few more security measures than in previous versions of PCI DSS.
For example, service providers will need to detect and notify clients about critical security control failures in a timely fashion.
PCI DSS version 3.2 also requires them to maintain documentation of their encryption architecture. Quarterly reviews are also required to ensure personnel are following proper policies and procedures.
Service providers also need to document each person’s role in the security of cardholder data. This should help clarify any issues that could later lead to a data breach.
Penetration testing on segment controls is also a new requirement for service providers in PCI DSS 3.2. Testing should occur at least every six months.
The timing of new PCI DSS releases has gotten a face-lift over the past few updates.
Instead of releasing a new version every three years, the PCI SSC is moving towards a timelier model, updating the requirements as necessary.
PCI DSS version 3.1, which came out last year, is a perfect example. The unscheduled update was released in response to major vulnerability disclosures, such as the POODLE exploit.
Extended grace period
One of the biggest sighs of relief for everyone under the rule of the PCI DSS is the extended grace period granted in this update.
Service providers and merchants alike will now have until Feb. 1, 2018 to fulfill new requirements found in version 3.2.
The newest changes will be considered “best practices” and not technically “requirements” until the Feb. 1 deadline passes.
This grace period does not include phasing out SSL and TLS 1.0, which will still need to be done by June of this year.
When it comes to PCI DSS assessments, keep in mind that version 3.1 will expire in October, 2016.
While any current assessments conducted against v3.1 will still be good for the year following the assessment date, companies should be able to show that they are working towards being compliant with V3.2 by 2018.
Another update in version 3.2 is the change of terms from “two-factor authentication” to “multi-factor authentication.”
This simply means that instead of using two forms of authentication, everyone must use at least two forms of authentication in certain circumstances, such as when remotely accessing the cardholder data environment (CDE).
The first six or the last four numbers of a Personal Account Number, or PAN, are the only numbers that should be visible to a company employee as mandated by PCI DSS unless a pertinent business need crops up.
Those who are not in compliance with the PCI DSS may find themselves neck-deep in fines and various litigations. Protect your company and your clients by incorporating these security standards into your security framework
For a complete list of updates found in Version 3.2, download the PCI DSS Summary of Changes: V3.1 to V3.2 from the list of documents on the PCI SSC’s website.