In March 2022, PCI SSC released version 4.0 of their Data Security Standard (DSS). PCI DSS is a global standard designed to protect payments data. The standard is built around twelve principal requirements with detailed security requirements and corresponding testing procedures. The principal requirements address the areas of:
- building and maintaining secure networks and systems;
- protecting account data;
- maintaining a vulnerability management program;
- implementing strong access control measures;
- monitoring and testing networks; and
- maintaining an information security policy.
It is important to note that PCI DSS defines a minimum set of requirements for protecting payments data. Additional measures may be required to adhere to regulatory requirements or meet corporate goals.
With the introduction of version 4.0, PCI made extensive updates to the existing requirements and added 64 new requirements. Of the 64 new requirements, 13 are effective immediately for all v4.0 assessments, and the remainder are best practices until March 31, 2025, when they become effective. Version 3.2.1 remains valid until March 31, 2024. Until that date, either version can be used for assessments. The goals of version 4.0 are coalesced around four themes. Each goal and a few examples of the updates supporting those goals are described in the following paragraphs.
The first goal is to address the evolving security needs of the payments ecosystem in light of the ever-shifting threat landscape. A change supporting this goal that may have the biggest systems impact for merchants is a requirement for multi-factor authentication. Multi-factor authentication will be required for all access to the cardholder data environment (CDE), but this requirement is in the ‘best practice’ category so not required until March 31, 2025 (Req. 8.4.2). Another new requirement supporting this goal that could have systems impact (if support is not already in place) is to deploy mechanisms to detect and protect personnel against phishing attacks. This could include implementing technologies such as link scrubbers and server-side anti-malware to block phishing emails and malware and controls such as Domain-based Message Authentication and Domain Keys Identified Mail (DKIM) to prevent your organization’s domain from being spoofed (Req. 5.4.1). Passwords must also be a minimum of 12 characters (Req. 8.3.6). This requirement is also a best practice until March 2025 and has an exception if the system does not support 12 characters, however.
The second goal of v4.0 is to approach security as a continuous process rather than an annual compliance exercise. Each of the principal requirements now has a supporting requirement to assign and document the roles and responsibilities for performing the activities associated with each principal requirement (Reqs. 2-11). Additional guidance on implementing and maintaining security is available including new requirements for security awareness training (Req. 12.6).
The third goal is to provide flexibility in how the DSS requirements are met. The standard now allows for two approaches to meet the requirements. The “defined approach” is the traditional prescriptive method for achieving and maintaining compliance by implementing the defined requirement and being assessed by following the testing procedures within the standard. The new “customized approach” focuses on the objective of each requirement and not on how the requirement is met. Each requirement now has a “Customized Approach Objective” that allows the implementing entity to determine and design the security controls required to meet the objective (Appendix D). This approach is intended for organizations that have mature risk management practices. Version 4.0 of the standard allows for group, shared, or generic accounts on an exception basis providing they are managed per the requirement (Req. 8.2.2).
Finally, the last goal of version 4.0 is to improve validation processes and reporting options. The information reported in the Self-Assessment Questionnaire (SAQ) and Attestation of Compliance (AOC) documents has been aligned with the contents of the Report of Compliance (ROC) AOC to improve consistency between the documents. Specifically, the contents of sections 1 and 3 in each of the SAQ/AOC documents are now aligned with the ROC AOC (to learn more about PCI, and their passion for creating acronyms, see our MAG Insights article on PCI found here). In addition, PCI has added appendices to each SAQ and AOC document to support new reporting responses.
As technology advances and the threats to payments security evolve, we can expect the standards and specifications that impact payments, including PCI DSS, will continue to progress as well in an attempt to keep pace. This article has presented just a few of the changes coming with version 4.0 of the PCI Data Security Standard, and I encourage you to review all the applicable changes by accessing the standard on the PCI website. Version 4.0 of the standard, a summary of changes document, and other supporting documentation can be found in the PCI Document Library located here.