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:
1. You have the choice to assess under either under v3.2.1 or v4.0 until v3.2.1 is retired on March 31, 2024.
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.
2. Most new requirements in v4.0 are a best practice until March 31, 2025.
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.
3. As of the writing of this post, the v4.0 SAQs have not yet been published.
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.
4. Do not fall in love with the Customized Approach or see it as an ‘easier’ path to PCI DSS compliance.
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.”
5. V4.0 provides a lot more support to you in managing your third-party service providers.
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).”
6. V4.0 now makes it even clearer that even entities that do not store, process, or transmit account data can still have PCI DSS responsibilities.
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.
7. If you take one key message away from these v4.0 documents, it should be that attackers keep evolving and threats keep growing.
In the “At A Glance” document the PCI SSC says that a core goal of v4.0 is to “Promote security as a continuous process” because “Criminals never sleep. Ongoing security is crucial to protect payment data.” At this point any readers from the Information Security community are muttering “duh” to themselves. Yes, it’s obvious. What should flow from that but is perhaps a little less obvious is that the list of PCI DSS security controls does not get shorter or easier as time goes on. Version 1.1 of the PCI DSS was a 17 page PDF. Version 4.0 is 360 pages. They didn’t just add a lot of cool clip art. The standard is far more robust. It requires more of us as a community, to appropriately protect account data, cardholder data, and sensitive authentication data. The data thieves keep adding to their list of tools, so our list of controls, protections, and requirements has to grow as well. Finally, what does this mean for compliance budgets? Well…they’re not going to go down either, unless you can find a path to reducing scope so that fewer PCI DSS controls are applicable to your environment. Otherwise, it will take additional FTE and hard budget resources to implement, maintain, and assess an ever-increasing list of security controls to maintain compliance.
Keep watching this space as well as all other CampusGuard communication channels like Twitter, LinkedIn, and be sure you’re signed up for our Newsletter and Announcements via the Contact Us section below. And as always, your CampusGuard Customer Advocate Team is here to help, please feel free to contact us.
