PCI DSS 3.2 – What You Need to Know

We’ve been getting a lot of inquiries from clients on the new payment card industry (PCI) compliance standard issued by the PCI Security Standards Council in April. The new data security standards (DSS) release, dubbed PCI DSS Version 3.2, contains some major changes from the previous version.

The changes are explained pretty clearly in our May 9 Flash Report, but we recently had the opportunity for a more interactive discussion and to answer questions via a webinar we held on August 18. In a future post, we will follow up with some of the questions we did not have a chance to address. Here, we’d like to focus on the upcoming changes.

Some of the upcoming changes may require a significant effort to achieve. This affects all entities transacting business by credit, debit or cash cards and could result in many organizations being out of compliance for an extended period of time.

The biggest changes affecting all organizations (effective Feb. 1, 2018) are as follows:

Multifactor authentication will be required for administrative access to any system within, or connected to, the cardholder data environment (CDE), even when connecting from within the corporate network. That means that, in addition to a password, anyone seeking to access the system must present some other form of identification, such as a fingerprint or optical scan. This requirement already applies to users, administrators and third parties accessing the system remotely. Note: Companies currently using multifactor authentication as a compensating control for technical noncompliance will no longer be able to list this as a compensating control after it becomes a requirement.

File integrity monitoring (FIM), or some kind of change-detection solution, will be required for all in-scope systems, which includes all systems connected to – not just those within – the CDE. Many organizations do not currently have FIM technology on point-of-sale terminals or administrative workstations.

Change management is an area of increasing concern for the Security Standards Council. PCI 3.2 requires organizations to carefully document all changes to in-scope systems, plus any controls that might be affected by each change, and prove that the controls have been tested post-implementation and that corrective action was taken, if needed, to restore an effective control environment.

Service providers face even greater scrutiny under the new standards.

Security controls monitoring needs to be able to detect failures, and the provider must have supporting processes that document how to fix control failures, as well as processes for documentation, determining root causes and getting security systems back into operation.

Executive management responsibility is another hot-button issue. PCI 3.2 requires service providers to assign a member of executive management to be responsible for protecting the CDE. This executive will oversee testing and sign an attestation of compliance.

Penetration testing on segmentation controls will have to be conducted at least every six months under PCI 3.2, versus annually in 3.1. The scope of penetration testing needs to be coordinated to ensure that the CDE remains secure, even in the event of a total administrative takeover of a segmented system.

Service providers are also now required to provide auditors with a documented description of cryptographic architecture used in the CDE. This must include all algorithms, protocols and keys used for the protection of cardholder data, including key strength and expiration date.

PCI version 3.2 is available for use now and becomes the only valid standard when version 3.1 is retired on Oct. 31, 2016. However, many of the new requirements in 3.2 do not become effective until Feb. 1, 2018. As we said in the webinar, we strongly recommend that organizations work with a Qualified Security Assessor now to ensure compliance and avoid unpleasant surprises under deadline pressure.

[…] entities process, hold and transmit cardholder data, comes into effect today, Nov. 1, 2016. In a post last month we discussed the details and implications of the new standard. Here, we want to point out one […]