I was trying to come up with a sensible title for this blog post, but I feel this one mirrors the thoughts and feelings of many of us about recent events in the PCI DSS compliance space! There have been some significant changes in recent weeks, and with just 18 days until the compliance deadline, I have some updates and further information for you.
First, some background
I won't go into the details of what PCI DSS Compliance is in this post, you'd already need to know about that for this post to have any value or interest to you. For those familiar, or wanting a refresher, my first blog post in 2022, PCI DSS 4.0; It's time to get serious on Magecart, is definitely the place to start. The v4.0 major release was a huge step forwards in web security for e-commerce sites and you can likely detect my optimism and excitement in that original post. With a long runway to the new standard being in effect, the industry had time to push back, and push back the industry did...
A little over 2 years later in 2024, the Security Standards Council caved under the pressure and released a minor update to v4.0.1 with some pretty major changes. I cover those changes in PCI DSS 4.0.1; What's Changed?, and that's the best place to understand those changes, but with less than a year to go until the compliance deadline at that point, you'd think we'd have some stability going forwards.
The SAQ A update
On the last day of January 2025, just two months away from the compliance deadline, a significant change caught most of the industry by surprise. There are varying levels of compliance with PCI DSS, and they depend on how you handle payments on your website, what kind of volume of transactions you do, and so on. The simplest and easiest level of compliance is the SAQ A, the Self-Assessment Questionnaire A, and it's undoubtedly the most widely used SAQ, with even us at Report URI completing the SAQ A - Attestation of Compliance (AoC). We even publish our document on our website if you're interested, just look in the footer for the link.
The SAQ A for PCI DSS v4.0.1 got renamed as SAQ A r1 (revision 1) and the change control on the document provides this simple sentence that many website operators got excited about.
Removed Requirements 6.4.3, 11.6.1, and 12.3.1 and added an Eligibility Criteria for merchants to confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)
Requirements 6.4.3 and 11.6.1 were the two major additions that really changed the level of security that website operators were going to have to implement. Those two requirements are what my previous blog posts above were focused on, and were also the requirements that were going to introduce the most work as we had to start taking control of our JavaScript dependencies, where previously it was like the Wild West. Website operators could ditch the products they would need, ditch the processes they'd have to create, and let marketing teams run wild with Google Tag Manager and unlimited JavaScript injection again. Freedom!
This is when customers started reaching out en masse to understand what this change meant and were they free of the responsibility placed upon them, but many had focused too much on the deletions from the document, and not the additions. This little bullet point was added to the eligibility criteria for website operators to be permitted to use SAQ A.
The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
Huh? The council took away the two requirements, 6.4.3 and 11.6.1, that required controls around JavaScript be implemented to prevent attacks, but then introduced an eligibility criteria that site operators have to confirm that their sites aren't susceptible to attacks from JavaScript... First of all, this doesn't really seem to make sense, and second of all, we went from several pages of nicely defined criteria with guidance, to a single, vague, sentence instead.
Understandably, this raised more questions than it answered, and while I was fielding countless questions from confused customers, we were waiting for some clarification from the council that was promised to us.
FAQ 1588
On the last day of February 2025, just 31 days before the compliance deadline, the council published FAQ 1588 which 'Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants'. Their announcement of the new FAQ contains most of the details, and you can read the entire FAQ 1588 document if you like, but the TLDR; is the following.
FAQ 1588 clarifies that the merchant can confirm that the merchant’s webpage is not susceptible to script attacks by either:
• Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.
Or
• Obtaining confirmation from the merchant’s PCI DSS compliant Third-Party Service Providers (TPSPs)/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.
Unbelievably, the first suggestion to ensure that your site is not susceptible to attacks from JavaScript is to implement the two requirements that were taken out of the document in the first place... The second suggestion is almost equally outlandish, though, and I'm not sure, on multiple fronts, how this would even work out.
When you embed a payment form on your site, like many of us would do from a TPSP like Stripe, there are different ways you can do that. The most likely method is that you include a JS file and/or iframe on your site that is loaded from the TPSP and handles the collection and sending of card data to the TPSP. This iframe approach gives us a nice layer of separation where everything in the iframe is not our responsibility, and we can rely on the TPSP to handle everything going on there, but our page, the 'parent page', is still our responsibility.
The first thing to pick apart here is that the second bullet point says "the merchant's payment page", but in any deployment scenario like this, falling under SAQ A, the merchant doesn't have a payment page... The payment page is inside the iframe, which Stripe are responsible for, and the parent page hosting that iframe is a "non-payment page", that's the page we're responsible for, our page. Skipping over that, though, I have major questions about how likely it is that the TPSP, Stripe in our case, are going to give us assurances that our page is secure when they have, effectively, no visibility of what's going on there. It seems like an acceptance of enormous risk for the TPSP to do that, and I can't see a clear path on how they could even do that from a technical standpoint either...
To me, this all seems like too little, too late, and our position remains that the only viable way of meeting this eligibility criteria is the first bullet point, which is to implement the clearly written 6.4.3 and 11.6.1 requirements that we can be absolutely sure we meet. Despite scouring the documentation of the TPSP's I'm most familiar with, I've not yet found anything that could reasonably be considered a 'confirmation' from the TPSP that their solution satisfies this new SAQ A eligibility criteria.
Guidance for PCI DSS Requirements 6.4.3 and 11.6.1
Another thing that we'd been waiting for from the council was promised to land in January, presumably delayed by the SAQ A update, and then promised again in February, presumably delayed by the FAQ release, but did finally land in March, just 21 days before the compliance deadline. What we were waiting for was some more detailed information to confirm the viability of approaches to meet the 6.4.3 and 11.6.1 requirements, something to finally settle the many questions we'd been receiving with some definitive answers from the council.
We've always taken a common-sense approach to our interpretation of the guidance, and our aim has always been to have effective measures in place with minimal risk to the functionality or operation of the payment process. I provided feedback on the initial drafts of the v4.0 standard, and being so close to the process, I knew what the objectives were and I provided guidance on the viability of Content Security Policy to help meet those objectives. Despite all of this though, we'd often get an overzealous customer (or usually their QSA), that would have a different interpretation of the guidance and insist that we couldn't meet the requirements.
Well, we can finally put those concerns to rest now with the release of this Information Supplement. The document is too large, and the common concerns too many, to detail them all here, but I am now quite happy that I have a document, authored by the council, that I can refer to and ease the concerns of customers or their auditors. Here's a copy of the Information Supplement if you'd like it:
If you did have any outstanding concerns about how our solution, or a solution from any other vendor, could meet these requirements, then you should now be able to find all of the answers you need here. If you are a Report URI customer, or prospective customer, and you do have any outstanding concerns, feel free to reach out to your account contact, who will now be able to answer any remaining questions that you have.
Hopefully, as we're now 18 days away from the compliance deadline, we can consider ourselves to be in a position of confidence with what we need to do and how we need to do it.