PCI DSS 4.0: How to Become PCI Compliant
Originally published by TokenEx.
So the results from your latest audit are in, and it turns out your organization no longer meets the full requirements of the Payment Card Industry Data Security Standard—or even worse, you’ve just learned your previously out-of-scope network now is subject to more than 300 security controls, and you have no idea where to begin. Either one of those revelations is enough to ruin a day, but let’s focus on finding a PCI compliance solution.
To help, we’ve created a step-by-step guide for PCI compliance based on the Payment Card Industry Security Standards Council’s “Prioritized Approach to Pursue PCI DSS Compliance,” a useful document that recommends working toward six goals to help achieve PCI compliance. It’s designed to help organize a cohesive, incremental strategy that outlines a logical progression of milestones for addressing risks to cardholder data and your cardholder environment. These goals are as follows:
- Remove sensitive authentication data and limit data retention
- Protect network systems and be prepared to respond to a system breach
- Secure payment card applications
- Monitor and control access to your systems
- Protect stored cardholder data
- Finalize compliance efforts and ensure all controls are in place
In addition to the six goals for achieving PCI compliance, businesses should also know about the latest version 4.0 of the PCI Data Security Standard (PCI DSS), which we will discuss at the end of this article.
1. Remove sensitive authentication data and limit data retention
This initial step is designed to reduce the impact of a breach. By removing sensitive data from your internal systems, a breach of your environment would reveal no sensitive information. A good rule of thumb here is never to store anything you don’t absolutely need. The less data you’re responsible for protecting, the better.
Applicable controls: 1.1.2, 1.1.3, 3.1, 3.2, 3.2.1, 3.2.2, 3.2.3, 9.8.1, 9.8.2, 12.2
2. Protect network systems and be prepared to respond to a system breach
The second step involves restricting access to and hardening the security of access points commonly exploited during breaches. Additionally, in the event that a breach does occur, you’ll want to have a detailed process in place for responding.
Applicable controls: 1.1.4, 1.1.6, 1.2.1, 1.2.2, 1.2.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.5, 2.1, 2.1.1, 2.2.3, 2.3, 2.4, 2.5, 4.1, 4.1.1, 4.2, 4.3, 5.1, 5.1.1, 5.1.2, 5.2, 5.3, 5.4, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.2, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.3.1, 8.3.2., 8.5.1, 9.1, 9.1.1, 9.1.2, 9.1.3, 9.3, 9.9.1, 9.9.2, 9.9.3, 11.1.2, 11.2, 11.2.1, 11.2.2, 11.2.3, 11.3, 11.3.1, 11.3.2, 11.3.3, 11.3.4, 126.96.36.199, 11.4, 12.5.3, 12.8, 12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5, 12.9, 12.10.1, 12.10.2, 12.10.3, 12.10.4, 12.10.5, 12.10.6, A2.1, A2.2, A2.3
3. Secure payment card applications
Step 3 addresses controls for elements related to payment applications and the security of those applications themselves. Like Step 2, the idea here is to defend against a potential breach by strengthening commonly targeted areas to prevent them from becoming compromised.
Applicable controls: 2.2, 2.2.1, 2.2.2, 2.2.4, 2.2.5, 2.6, 6.1, 6.2, 6.3, 6.3.1, 6.3.2, 6.4, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.5, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6, 6.7, A1.1, A1.2, A1.3, A1.4
4. Monitor and control access to your systems
This step is about controlling and tracking who has access to your network and monitoring what they’re doing while connected to your environment. The concept here is simple. You can’t respond to threats if you aren’t aware of their existence.
Applicable controls: 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.2.1, 7.2.2, 7.2.3, 7.3, 8.4, 8.5, 8.6, 8.7, 8.8, 10.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6, 10.4, 10.4.1, 10.4.2, 10.4.3, 10.5.1, 10.5.2, 10.5.3, 10.5.4, 10.5.5, 10.6.1, 10.6.2, 10.6.3, 10.7, 10.8, 10.8.1, 10.9, 11.1, 11.1.1, 11.5, 11.5.1
5. Protect stored cardholder data
If your organization must store primary account numbers (PANs), step 5 details the requirements for protecting that data in storage. This step can be simplified by storing PANs in only one segment of your network and isolating that area from the rest.
Applicable controls: 3.3, 3.4, 3.4.1, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.6.6, 3.6.7, 3.6.8, 3.7, 9.2, 9.4.1, 9.4.2, 9.4.3, 9.4.4, 9.5, 9.5.1, 9.6.1, 9.6.2, 9.6.3, 9.7.1, 9.10
6. Finalize compliance efforts and ensure all controls are in place
The final step mostly entails housekeeping and paperwork items to document your organization’s adherence to its relevant regulatory compliance obligations. Examples of this include maintaining internal IT security policies and issuing regular employee training.
Applicable controls: 1.1.1, 1.1.5, 1.1.7, 6.4.5, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 6.4.6, 12.1, 12.1.1, 12.3, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.3.5, 12.3.6, 12.3.7, 12.3.8, 12.3.9, 12.3.10, 12.4, 12.4.1, 12.5, 12.5.1, 12.5.2, 12.5.4, 12.5.5, 12.6, 12.6.1, 12.7, 12.11, 12.11.1
The Latest PCI DSS 4.0
The PCI Security Standards Council (PCI SSC) rolled out version 4.0 of the PCI DSS on March 31, 2022, which will replace version 3.2.1 published in 2018. Version 4.0 will address emerging threats and provide innovative solutions to combat new payment threats.
This latest version combines feedback from more than 200 businesses that provided over 6,000 pieces of feedback over the past 3 years towards this new PCI DSS standard. By receiving feedback from a variety of industries, this will help ensure that this global standard remains useful and relevant in today’s ever-changing payment security environment, where there’s an increase in online payments, point-of-sale (POS) devices, and payment data being stored via the cloud.
Even though the 12 DSS requirements will continue to be the main foundation for securing cardholder data, version 4.0 requirements provide guidance regarding how security controls should be used. These new changes for 4.0 include:
- Add flexibility and alternative solutions to maintain payment security.
- Encourage security as an ongoing process.
- Improve payment validation methods and procedures.
- Ensure the latest standard meets the payment industry’s security needs.
In addition to the existing compliance approach, PCI DSS 4.0 offers an alternative approach to achieve compliance – customized implementation. Customized implementation focuses on the objective’s purpose and allows businesses to create security controls to meet their unique needs and thus achieve compliance.
PCI DSS 4.0 Release Date
PCI DSS 4.0 had a formal release in March 2022, which included the final versions of this standard, validation documents, and the first phase of the standard’s translations. Version 3.2.1 will remain active for the next two years through March 2024. PCI 4.0 is set to go into full effect in March 2025.
PCI DSS 4.0 Transition Timeline
During the transition period from March 2022 to March 2024, organizations will have sufficient time to adapt to the major changes in 4.0, update their reporting templates and forms, and establish plans to implement changes to achieve the latest standard requirements. Supporting documents include AOC, ROC, and SAQ.
What to Expect from PCI DSS Version 4.0
For the past decade, there haven’t been many major changes made to the PCI security controls, which makes the 4.0 changes pretty significant. There are six main areas that will be impacted regarding the PCI DSS standards, including customized implementation, security, authentication, encryption, monitoring, and control testing.
1. Customized Implementation
Version 4.0 will shift the 12 requirements to focus on the following security goals:
- Ensure the global standard meets the payment industry’s security needs.
- Provide flexibility and support of alternative solutions to achieve security.
- Promote security on an ongoing basis.
- Improve validation methods for organizations.
With this latest PCI DSS version, businesses can choose to either perform the control as prescribed or choose the customized implementation. The customized option enables organizations to achieve compliance by showing that the intent of the standard is met without needing to provide an operational or technical reason. In turn, this change can help businesses have more flexibility in adjusting implementation solutions and achieving requirement intent. External assessors will need to review the documentation and test every control used for a custom implementation.
2. Increased Security
At its core, PCI DSS is designed to ensure that merchants securely store, process, or transmit cardholder data and protect customers. PCI 4.0 has higher security requirements, which CISOs and CTOs should make note of to adjust the budgets needed to implement the more stringent security measures.
3. Transaction Authentication
A main focus for the new standard is using stronger authentication standards for payment and control process access log-ins. NIST/Password Guidance will play a key role in 4.0. The PCI SSC has partnered with EMVco to use the 3DS Core Security Standard during the transaction authorization process. This stronger focus on authentication security will allow businesses to develop a unique pluggable authentication standard to achieve these data security requirements and still be able to scale with the organization’s transaction goals.
Cyberattacks are increasing and have no signs of going away. One of the most pressing threats within the payments industry is malicious code. Malicious code works by secretly embedding itself into a network, which allows hackers to obtain cardholder data. Luckily, PCI 4.0 plans to address this serious issue with best practices and guidelines for how to fully secure network transmissions.
5. Monitoring Technology Advancements
As technology advancements continue to grow and businesses are searching for pluggable solutions for their information systems, it’s important for the new standard to use a risk-based approach. Specifically, 4.0 allows companies to comply with the new standards while gaining quicker process deployments without needing their technology located in a specific control.
6. Critical Control Testing Frequency
The new standard uses a higher level of critical control testing, including a major increase in testing. It’s important to note that the Designated Entities Supplemental Validation (DESV) requirements previously used to only be required for compromised companies.
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.