TL;DR Summary
This blog breaks down the 12 core requirements of PCI DSS 4.0, offering expert insights from CISOs and consultants to help organizations secure payment card data. Key themes include:
- Network security controls and secure system configurations
- Data protection during storage and transmission
- Malware defense, secure software development, and access restrictions
- User authentication, physical security, and activity logging
- Regular testing of systems and networks
- Organizational policies that support continuous security
Each requirement is paired with insider tips to make compliance more practical and achievable. Our blog emphasizes treating PCI DSS as an ongoing security program, not a one-time project.
Requirement 1: Install and Maintain Network Security Controls
Network security is only as effective as the controls that are in place to prevent unauthorized access. Requirement 1 focuses on ensuring full visibility of the entire CDE, including information about the physical hardware, as well as robust documentation concerning all aspects of the environment.
Insider tip from Jeff Man, Sr. Information Security Consultant: “The challenge of meeting Requirement 1 is to ensure sure you are knowledgeable about whatever network security controls you are utilizing. Adhering to the requirements and making sure you are properly applying the protections to your CDE from even your own internal network, and not just the internet is of utmost importance. In this way, you can truly declare the rest of your network as ‘untrusted’ from the perspective of PCI.”
Requirement 2: Apply Secure Configurations to All System Components
One of the most dangerous vulnerabilities is a misconfiguration of a component. This is because misconfigurations can go unnoticed and are not fixed with patching or upgrades. Requirement 2 sets out to correct this by ensuring configurations are carefully managed across the CDE.
Insider tip from Anthony Israel-Davis, Fortra Director of Product Security: “When documenting changes, it’s important to note why a particular service or port is required. Not only will you know why the configuration was set that way, you will also be able to future-proof your audits if you ever need to provide a business justification for insecure services, protocols, or daemons.”
Requirement 3: Protect Stored Account Data
One of the greatest challenges for many organizations relates to how much data to save. While data can be seen as a treasure trove to help grow a business, it is also equally attractive to malicious actors. Requirement 3 aims to control not only how data should be protected, but how much data is reasonable to store.
Insider tip from Funso Richard, Information Security Officer: “Treat your PCI compliance requirements as a program, rather than a project. Though a program incorporates elements of a project, it is an ongoing process that must be designed to remain adaptable to changes in the Standard.”
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open Public Networks
Industry-level encryption is a must among payment card data processors with a legal obligation to keep sensitive financial information safe. Requirement 4 includes improved key and certificate management, a step towards cryptographic hashes, and a push to review cipher suites on a regular basis.
Insider tip from Nigel Sampson, Director of Cybersecurity: “This requirement is changing. It will change again. This is why staying ahead of industry best practices is a more efficient way of dealing with change. Rather than just meeting what the Standard is today, ensuring your cyber program is flexible, scalable, and agile is a must.”
Requirement 5: Protect All Systems and Networks from Malicious Software
In today’s environment, malware is one of the greatest threats, unleashing damages that have monetary consequences. Requirement 5 addresses the importance of combatting malware, from halting the software itself, to implementing anti-phishing technology as a method to prevent this most common attack technique.
Insider tip from Ian Thornton-Trump, Chief Information Security Officer: “Seek a third-party audit against this new standard as soon as possible in order to build in the updates of the new Standard.”
Requirement 6: Develop and Maintain Secure Systems and Software
There is a legal doctrine that speaks of the Fruit of the Rotten Tree. When thinking of securing the CDE, if the systems and software are not secure, there is little that can be done to prevent exploitation of the data that grows out of those systems. Requirement 6 stresses this point.
Insider tip from Tyler Reguly, Senior Manager, Security R&D: “It is important to note that only one part of this requirement applies to internal software development. The remainder applies to your systems and how they are used, configured, and managed. It really is a broad collection of mixed requirements that should be carefully delegated to provide the most complete coverage.”
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
In many organizations, the phrase “need to know” generates a lot of confusion. Requirement 7 makes this previously fuzzy concept very clear by offering two definitions: “Need to know” refers to providing access to only the least amount of data needed to perform a job. “Least privileges” refers to providing only the minimum level of privileges needed to perform a job.
Insider tip from Ben Rothke, Senior Information Security Manager: “Companies need to know precisely what their PCI scope is. Only when a firm knows its scope can it ensure that it is PCI compliant, particularly with Requirement 7. The Qualified Security Assessor (QSA) must sign off on their scope. Too many firms significantly underestimate their scope, and that is a surefire method to ensure they fail a PCI audit.”
Requirement 8: Identify Users and Authenticate Access to System Components
One of the heftiest responsibilities of the security team is keeping a firm awareness of all the users on a system and appropriately controlling the authentication mechanisms for each. One oversight can allow an unauthorized person into the system.
Insider tip from Dr. Andrea Simmons, PhD, Managing Consultant: “For anything that you know will appear misaligned during an audit, if Requirement 8 can be shown to be ‘in place with remediation,’ then no further investigation will be required. Remediation includes the proactive use of Plan of Action and Milestones (POAM) documents (templates), as these, in particular, can show who is responsible for what action, by when. Your QSA relies heavily on documentation to ‘show and tell’ the story of your compliance.”
Requirement 9: Restrict Physical Access to Cardholder Data
Few things could be more embarrassing than putting monumental technical efforts into protecting the CDE, only to be undone by something as simple as a physical security oversight. Requirement 9 seeks to ensure that physical access to the CDE is properly maintained.
Insider tip from Shubhra Deo, Head of Data Privacy and Security: “For sensitive areas in the CDE, an organization should have access control for exit gates and should not rely only on a push button for the exit. Whereas, if the organization is using video cameras, it should capture the face of the person exiting the area. Another tricky part to ponder is that sensitive areas should be enclosed with hard walls, and not glass partitions.”
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
One of the most valuable methods of keeping watch over the entire environment is through monitoring the activity that takes place. Requirement 10 directs the careful curation, review, and storage of system logs, as well as the importance of corrective attention if log mechanisms fail.
Insider tip from Ross Moore, Cybersecurity Analyst and Writer: “Tie monitoring and alerting into other aspects of the business, such as DevSecOps, and IT Infrastructure. Any other business units where it can be integrated could help in procuring the right solutions and assistance in implementation and maintenance.”
Requirement 11: Test Security of Systems and Networks Regularly
Setting all the security necessary to give the appearance of PCI DSS compliance only goes so far. Requirement 11 puts all the settings, configurations, and controls to the real-world test. This enables an organization to see if their defenses are as good as the Standard requires.
Insider tip from Angus Macrae, Head of Cyber Security: “Whilst it is directed under Requirement 11 to conduct internal vulnerability scans at least every three months or upon key changes to the environment, it is not prescribed that you have to use an external QSA or ASV. In fact, the standard categorically states that internal vulnerability scans can be performed by qualified, internal staff so long as they are ‘reasonably independent' of the system component being scanned.”
Requirement 12: Support Information Security with Organizational Policies and Programs
The best security plans are those that do not take place in isolation. The more aware and informed everyone is within the organization, the greater the likelihood of the plans becoming part of the normal business operations. Requirement 12 aims to spread the knowledge so that the entire organization can be part of the security program.
Insider tip from Dimitris Georgiou, Chief Security Officer: “Foster risk management procedures designed to minimize exposure while being tailored to your operational and regulatory requirements.”
Pushing Ahead with PCI DSS Compliance
The last PCI DSS 4.0 deadline has passed, and many companies simply cannot afford to be non-compliant. As Mieng Lim, VP of Product Management at Fortra, notes, “PCI DSS is one of those standards where if you are out of compliance, you literally can’t earn the money to operate and potentially pay for those compliance fees.”
As the experts have shown, there are a lot of nuances to PCI DSS compliance and many tricks to tackling compliance the right way. With the final deadline behind us, now is the time to get clear on your PCI DSS 4.0 goals and how you will go about accomplishing them, regardless of where you are starting on your PCI DSS compliance journey.
Ready to dive deeper into PCI DSS compliance?
PCI DSS 4.0 is broken down into six categories and four levels. Learn all about them in this blog from Fortra.
