PCI DSS 4.0 Requirements –Test Security Regularly and Support Information Security with Organizational Policies and Programs

The Payment Card Industry Data Security Standard (PCI DSS) has always been a massive security undertaking for any organization that has worked to fully implement its recommendations. One interesting aspect that seems to be overlooked is the focus on the Requirements, and while minimizing the testing necessities. Not only is testing part of the full title of the Standard, but it is formally memorialized in Requirement 11 of the Standard, “Test Security of Systems and Networks Regularly.”

The most noteworthy upgrades in PCI DSS version 4.0 to Requirement 11 which are applicable to all organizations are that vulnerability scans must be conducted via authenticated scanning, and that all applicable vulnerabilities must be managed. This eliminates organizations from overlooking vulnerabilities, and selective remediation. It would seem that the Security Standards Council (SSC) is sensitive to the impact of these directives, and allows for them to remain as best practices until 31 March 2025.

The importance of testing makes sense, as what good is a security control if it hasn’t been tested to make sure that it is performing both as described in the Standard, as well as the way it is intended? While the methodology for Requirement 11 is specific, its implementation has to apply comprehensively to the entire Standard. 

The same thoroughness is true of Requirement 12, which states: “Support Information Security with Organizational Policies and Programs.” The policies and programs must flow through every requirement in the Standard. While these general approaches have existed in earlier versions of the PCI DSS, the latest version, 4.0, has included some new requirements to increase security. Some of the new requirements work towards future-proofing the Standard.

Perhaps more impactful are the new additions to Requirement 12including the largest number of new subheadings within the revised Standard. Most notable are declarations that two of the requirements are effective immediately: “for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach,” and, “document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment.” This is a bold position by the SSC and shows how the entire Standard needs to be viewed in its entirety, rather than just a collection of individual Requirements. They all have to work together.

Angus Macrae, the Head of Cybersecurity Services in the UK, offers the following advice for organizations that chose the Customized Approach where it is offered in the new Standard. “For entities who seek to innovate and may not always strictly follow the defined or previously prescribed way of meeting certain sub-requirements, the new “Customized Approach” allowance introduced with version 4.0 may well provide a new way to address certain challenges. This is a major change, and indeed, a rather enlightened degree of pragmatic flexibility for such a serious security compliance standard. The Customized Approach should not however be misconstrued as a way of avoiding the requirement altogether, nor should it be seen as any soft or easy option. It will still need to satisfy a strict set of criteria between the entity and its assessor to prove that the strategic objectives behind the requirement are still being met, albeit differently. If adopted correctly, it can provide a way for you to meet or retain overall compliance, without having to make significant and possibly costly changes to your existing practices or stifle innovative new approaches.”

Angus also takes a full view of the entire Standard: “A continual theme across all of the new Requirements is to have roles and responsibilities clearly defined and to promote security as a continuous process. Rather than trying to invent entirely separate SILO processes or technology solutions, simply to try ticking a compliance box, the Standard gives guidance in Section 5 of the introductory information that discusses Best Practices for Implementing PCI DSS into Business-as-Usual Processes:

An entity that implements business-as-usual processes, otherwise known as BAU, as part of their overall security strategy is taking measures to ensure that security controls that have been implemented to secure data and an environment continue to be implemented correctly and functioning properly as normal course of business. 

As well as clearly articulating the benefits of how PCI requirements may be better incorporated into or aligned with existing BAU processes and activities, this section of the standard helpfully provides some tangible examples. These include, the importance of having processes to review changes that could introduce security risks to the environment, processes to identify and respond to security control failures, and processes for performing regular risk assessments when, and as required. Any organization looking to work toward the new Standard should start by reading it all, and paying close attention to this helpful section.”

With a similar integrative approach to the entire Standard, Dimitris Georgiou, who is the Chief Security Officer at Alphabit, a cybersecurity consulting firm in Athens, Greece, offered the following general observations about how an organization can meet the compliance Requirements of PCI DSS version 4.0:

“Foster risk management procedures designed to minimize exposure while being tailored to your operational and regulatory requirements. Train your policy auditors not only to uphold policy, but to routinely challenge and revise it as best fit to your evolving organizational needs. Train the decision makers to accept policy as a business enabler. Train all personnel to appreciate their role as the strongest link in the security chain.”

As many of the contributors to this series have shared, achieving success with the new PCI DSS is not a solitary undertaking. In the same fashion, none of the Requirements should be treated as individual entities. They all have to work together to achieve the goal of protecting the data in the best possible way. To learn even more about the new Standard, as told by other experts in the field, download our eBook.

Learn more about PCI DSS 4.0 Requirements:

PCI DSS 4.0 Requirements – Network Security Controls and Secure Configuration
PCI DSS 4.0 Requirements – Protect Stored Account Data and Protect Cardholder Data During Transmission
PCI DSS 4.0 Requirements – Protect from Malicious Software and Maintain Secure Systems and Software
PCI DSS 4.0 Requirements – Restrict Access, Identify Users and Authenticate Access

PCI DSS 4.0 Requirements – Restrict Physical Access and Log and Monitor All Access