Prime Factors Blog

What You Need to Know About PCI DSS 3.2

Posted by Pete Flagella on Oct 11, 2016 10:00:00 AM

Find me on:

38904254_s.jpgUnless you draft regulations or hired someone specifically to study the details of the regulations, it can be hard to keep up with their many changes. Merchants have had a variety of responses when it comes to the requirements of the PCI DSS, from indifference to total acceptance and everything in between. Regardless of how you feel about them though, you will need to be aware of how they're changing and what it means to you. The new version of PCI, 3.2, was developed earlier this year and takes effect on October 31, 2016. The overarching theme is to push more responsibility onto the merchant for keeping their security measures up to date. Some of the updates will require major upheaval for some merchants in order to keep pace with new security standards.

To learn how encryption can lower the cost of regulatory compliance while enhancing security, download our white paper Reducing the Cost of Regulatory Compliance with Encryption 

What's Old

While PCI DSS is not mandated by the federal government, there are severe consequences for having the means to protect customer data and failing to do so. All companies that handle credit cards should become PCI DSS compliant or risk incurring harsh fines and penalties following a security breach. For the most part, the core recommendations are the same from version to version. Companies need to install firewalls and anti-malware, as well as enforce strong password policies. There should be perimeter protections, both inside and outside of a facility, to keep data from being physically stolen. Customer data must be encrypted in public networks, and companies need to have policies for security that can be easily updated. There should only be a small group of verified people with unique credentials accessing the key data to ensure fewer mistakes and cut down on internal fraud. All information needs to be consistently monitored and all activity documented for both auditing and tracking purposes. Version 3.1 is currently in effect, and has been since the first day of 2015. Its major changes involved removing SSL and the early editions of TSL from the guidelines, as these security protections have exhibited flaws that actually make it easier for hackers to infiltrate systems. As of now, these technologies can't be used to protect payment card data, and merchants who still use this technology for other daily tasks should plan to fully transition before July 1, 2018, if they want to remain compliant.  Version 3.1 also worked to clarify certain points and to make exceptions clearer. For example, it spelled out whether or not a rule applied only to service providers. Version 3.1 heavily emphasized encryption as an effective security measure for any and all important data.

What's New

Version 3.2, like 3.1, continues to clarify the terms of PCI DSS and tightens up some of the language for the sake of precision. It emphasizes the specifics of authentication and the monitoring process in a merchant's security policies. Now, merchants and credit card processing companies accessing cardholder or financial data will need to have multi-factor authentication, regardless of what network they happen to be on — internal or external. Previously this was only required if the user was on an unsecured, unknown, or otherwise compromised network. Using passwords alone is not enough to thwart criminals, and it was found that many merchants were still making poor choices when it came to choosing passwords. PCI DSS defines multi-factor authentication in a variety of ways, such as key cards, biometric identification and tokens or keys if tokenization or encryption is being used. It could be as simple as sending a text message to a phone with a unique code to input. The newest version also updates the standards that are used to monitor PCI DSS compliance, meaning that companies will now need to implement quarterly reviews instead of yearly. Because changes can happen in the blink of an eye in terms of how hackers work to successfully steal information, companies can no longer rely on casual audits every 12 months. The good news is that not every burden of responsibility is placed on the merchants. Service providers will be required to have ways to detect failure within their network at the time of the breach, and an effective response method in place to stop the hackers as soon as possible. All ISPs need to perform penetration testing every 6 months and perform checks/testing on employees once every three months to ensure that everyone is keeping up with protocol. All executives of the service provider companies must familiarize themselves with the core policies and procedures of PCI DSS.

Tides Are Changing

It's clear just from the amount of swipe machines still in operation in stores and the amount of hacks from around the world that merchants still struggle with understanding the full ramifications of PCI DSS. Despite the financial protocols set by PCI DSS, there are still a lot of people who do not place top priority on cardholder data security. Part of this lies in the fact that until late 2015, merchants were not typically penalized in the event of a breach, leaving them free to persist in using antiquated measures to protect cardholder data. However, each new version of the guidelines attempts to correct this imbalance when it comes to who is liable during a cyber attack. You can expect the rule updates that follow to continue tightening up the amount of work required from a merchant to properly keep cardholder data safe.

Why You Shouldn't Delay

While the changes for PCI DSS 3.2 go live in October, 2016, companies will not have to comply with said changes until February of 2018. This will be a significant time of transition and ultimately a good deal of work for companies who may have to hire additional staff to ensure that the updates are made. Some companies may consider replacing entire computer systems in order to keep up with the standards. Assessing what needs to be done now is the best way to ensure that all changes are made before the deadline. Those who wait may be forced to scramble to find a solution, which can mean taking shortcuts or purchasing equipment that is not compatible with current systems.

Tips for Owners

A multi-national corporation that needs to change their security audits from once a year to four times a year will obviously need to do more work to comply with version 3.2 than a merchant with one establishment. But even the lone merchant may need more help than they think. Encryption and tokenization are both excellent ways to comply with PCI DSS guidelines, either by directly meeting them or by going above and beyond in strengthening security policies. Both methods work to ensure that if a hacker manages to take the information, there will be no way for the thief to use it to commit crime. When you pick the right encryption tools, you can make it easier to run checks and monitor practically everything happening within a system. Choosing the right software can also make key management, implementation, installation, and training a far simpler task. While at one point the complexities of these programs may have seemed impractical to a general merchant, their improvements have been markedly helpful in keeping up with the precautions defined by PCI DSS necessary to prevent theft.


To learn how encryption can lower the cost of regulatory compliance while enhancing security, download our white paper Reducing the Cost of Regulatory Compliance with Encryption


Topics: Enterprise Data Protection, encryption, PCI Data Security Standards, PCI DSS 3.2