A QSA's Top Seven PCI DSS v4.0 Critical Takeaways

CampusGuard, a partner of Nelnet Campus Commerce, focuses on cybersecurity and compliance needs of campus-based organization in higher education. Offering a broad array of offensive security services, throughout their 12 years in business, they stay on top if the most recent updates in security needs. This article was originally published on CampusGuard’s website in April 2022, and shared with permission for the benefit of our clients and industry knowledge.

PCI DSS v4.0 is 360 pages long. It contains some new concepts, like “Defined” versus “Customized” assessment approaches, renumbers most of the requirements (there goes several years’ worth of memorization!), and of course adds new and expanded requirements. It’s going to take a while for the industry to fully digest it and determine impacts and best paths forward. But even a first pass over the newly-published standard shows us a few critical points.

So without further ado:

The message here is that there is no reason to panic. There is time for strategic decisions and planning, and your organization can choose when to make the migration to v4.0 within that two-year transition period. These decisions are probably best left until we can collectively review the updated SAQs (see #3, below), as changes to eligibility and/or requirements in reduced SAQs might lead to different strategic decisions than the updated DSS requirements in isolation. Your CampusGuard Customer Advocate Team will work closely with you to clarify changes and customize guidance to fit your environment, customer service goals, and overall compliance and Information Security strategy.

Once again, the message is that there is ample time to determine how to implement any new requirements that will be applicable to your environment. Specifically, you now have three years before most of the new requirements convert from best practice to formal requirement. The exception is the list of new, top-level policy/procedure and communication requirements that head DSS requirements 1-11, but I would characterize those as a repackaging of the v3.2.1 requirements that ended numbers 1-11. E.g., they’re not really new requirements except by number, and of course the wording is slightly different.

The full impact of v4.0 for most campus-based entities will not be fully clear until we review the SAQs. This is another case of “stay tuned to this channel” (and every other CampusGuard communication channel!). As soon as the updated v4.0 SAQs are published we will begin our review and pass along initial impressions, probably initially via a sequel to this blog entry. As hinted above, we at CampusGuard expect that we could potentially see some changes to eligibility requirements and of course to the specific requirements contained within each SAQ, but it’s too early to tell. For an example of what we might expect, see #6 below.

It will require a lot more effort as compared with the traditional, “Defined” approach – both for your team and any assessors (QSAs and/or ISAs) that might be involved. This means that implementing and managing Customized controls will be more costly year over year. Then there’s this little tidbit from the DSS itself: “Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach; however, these entities may elect to have a QSA or ISA perform their assessment and document it in a ROC Template.”

If you’ve ever had any trouble with requirements 12.8.1 through 12.8.5 (hey, those are still the same!), especially with collecting AOCs and understanding who is responsible for which DSS requirements (12.8.5), you will enjoy the new requirement 12.9.2 for service providers. It mandates that service providers “support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5.” This means that they have to provide AOCs (or other acceptable documentation) and…drum roll, please…some form of 12.8.5 responsibility matrix. I’ve been expecting and hoping for this for some time, going all the way back to the 2014 rollout of v3.0, which introduced requirement 12.8.5 and a first step at mandating service provider cooperation through that iteration of requirement 12.9, which sadly stayed silent on the topic of responsibility matrices. Along these lines, the new DSS also includes this statement in the introductory sections, regarding documentation service providers are expected to share with customers upon request: “The Report on Compliance or Self-Assessment Questionnaire (the associated Attestation of Compliance is not considered sensitive and third-party service providers (TPSPs) are expected to share their AOC with customers).”

Let’s begin with this statement in the introductory sections of the DSS: “Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply.” Then we have: “If the entity can impact the security of a CDE because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page) some requirements will be applicable.” This should help convince those recalcitrant companies that host cloud applications/platforms that integrate with validated payment gateways or processors that they do not get a free pass. They still have responsibilities. Those of you operating your own ecommerce redirection servers (think something like Donate Now or Pay Online buttons) should take a look at future-dated requirement 11.6.1, which mandates change/tamper detection to alert on unauthorized modification to HTTP headers and contents of payment pages. Please note that we have to see if the PCI SSC limits this to A-EP and above environments, or if it will also apply to fully-outsourced SAQ A environments as well. See #3 above, since the full impact via SAQs is yet to be seen.