Daryl Jackson
On January 30th, the PCI SSC announced that merchants completing Self-Assessment Questionnaire (SAQ) A, would be exempt from complying with PCI DSS requirements 6.4.3 and 11.6.1 under certain conditions.
If you have always filed an SAQ A to maintain PCI compliance, recent 11th hour changes may have upended your world, or at least your ability to maintain PCI compliance. Requirements have been added, some have been removed, and eligibility requirements have changed.
As a trusted member of the Global Executive Assessor Roundtable for PCI SSC-qualified payment security assessor companies, we will examine what these updates could mean for you and your business, ahead of the March 31, 2025, deadline.
Let's Break it Down
Two years ago, the PCI SSC released the new PCI Data Security Standard version 4.0. and set the world on fire. There were many new requirements, most of which were “future dated” in order to allow PCI-affected entities time to adjust their security posture and gain PCI compliance. Among the future dated requirements was a pair regarding the security of payment pages, 6.4.3 and 11.6.1, intended to protect against skimming attacks such as Magecart.
The gist of these 2 new requirements is:
1. eCommerce merchants must ensure that the payment page they serve to client browsers contains only business-justified scripts and;
2. Personnel are alerted if those scripts differ from what was authorized to be served.
The Last Minute Shift: New Exemptions and What They Mean for Merchants
The inclusion of these requirements in the v4.0 SAQ A presented a real challenge to many merchants, since their implementation is technically complex and not widely understood. While it is admirable that the SSC is taking an industry lead by requiring technical controls that have only recently been developed, they’ve left many merchants struggling to implement them. There are approximately 2.8 million eCommerce retailers in the US alone, and most of them were going to have to implement some new measures quickly.
In response, several new businesses sprung up to fulfill this newly required need, while other existing products expanded their solutions. Many merchants were adapting their networks, ecosystems, and websites to make it possible to comply by the March 31st, 2025 deadline.
Then, just two months before the deadline (on January 30th, the PCI SSC announced that merchants completing Self-Assessment Questionnaire (SAQ) A would be exempt from complying with PCI DSS requirements 6.4.3 and 11.6.1 under certain conditions.
If you already have a 6.4.3/11.6.1 solution in place, I recommend you stay the course. These are valuable security measures.
Online was fortunate to be one of the first stakeholders to hear about this, through our participation in the SSC’s E-Commerce Guidance Task Force, which developed additional guidance on how to meet requirements 6.4.3 and 11.6.1.
In the new version of SAQ A (revision 1), the Eligibility Criteria for eCommerce channels requires the following conditions:
- All elements of the payment page(s)/forms) delivered to the customer's browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
- The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems.
Note: If your payment page is a full redirect to a TPSP, these conditions apply to the merchant webpage upon which the redirection mechanism is located.
What is “the payment page"?
Another nebulous term that is hotly debated and can be defined in different ways for different situations.
The PCI SSC definition is:
A web-based user interface containing one or more form elements intended to capture account data from a consumer or submit captured account data, for purposes of processing and authorizing payment transactions. The payment page can be rendered as any one of:
- A single document or instance,
- A document or component displayed in an inline frame within a non-payment page,
- Multiple documents or components each containing one or more form elements contained in multiple inline frames within a non-payment page.
Condition 1: All elements of the payment page(s)/forms) delivered to the customer's browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
Given the description above and the general messaging we are getting from the SSC, for SAQ A you simply have to ensure the fields that capture account data (aka the iFrames) originate only and directly from a PCI-compliant vendor (TPSP) that can provide a current AOC. That TPSP would need to be in compliance with requirements 6.4.3/11.6.1 which protects the integrity of the iFrame(s).
Condition 2: The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems.
To meet condition 2, you must be able to provide evidence that your site is not susceptible to attacks from scripts that could affect your e-commerce systems.
6.4.3/11.6.1 only applied to the payment page(s), but the new SAQ A eligibility guidance seems to reference the merchant’s entire website. That would make this an expansion in requirement which does not appear to be their intention. We take it to mean that confirming that your TPSP is protecting the payment fields they are providing in accordance with 6.4.3/11/6.1 is evidence of non-susceptibility, and are looking forward to the SSC publishing an FAQ to clarify this point. Until further guidance is published, we expect to see a wide range of interpretations as to the intent of the updated eligibility criteria.
Security Best Practices dictates that it is important to protect your website regardless of PCI requirements. Standard SDLC best practices following OWASP guidance, regular testing, and Web Application Firewalls (WAF) are just some of the measures that can be taken. Proper implementation of a Content Security Policy (CSP) is a must, which can be further strengthened using Sub Resource Integrity (SRI).
Naturally, there are also products on the market to make this more manageable. The companies whose products facilitate compliance with 6.4.3/11.6.1 are quick to remind us that they can be applied across the website. If you have already implemented one of these tools for the payment page(s), expanding coverage to the rest of the website certainly seems like the easiest path.
What if I don’t meet the eligibility requirements for SAQ A?
If you’ve completed a SAQ A in the past, but no longer appear eligible, your options for reporting PCI compliance before March 31, 2025 are:
- Perform the changes necessary to meet all eligibility requirements for SAQ A outlined above.
- Move to SAQ A-EP, which contains different eligibility standards and more requirements.
- If you are unable to meet the eligibility requirements for SAQ A or A-EP you may be required to complete SAQ D-Merchant. This is a labor-intensive and expensive option, containing 252 requirements.
While we await further guidance from the council, we take this to be more of a course correction from the council, rather than requiring Merchants to take an alternate route.
Online is ready to assist you in developing or refining your PCI program, help unpack what the v4.0.1 changes will mean for your organization and designing a compliance roadmap to get you there.
For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0.1 Resource Center where we have identified and dissected many of the significant changes and new requirements along the road.
About the Author
Daryl Jackson is a Principal Consultant and PCI QSA at Online Business Systems. He has been working in IT Security for over 15 years.
His decades with the DoD combined with his experience advising for projects ranging from small town infrastructure design, to securing some of the world’s largest retailers gives him a unique perspective on security. Daryl’s sharp eye and collaborative manner are pivotal in helping organizations optimize their people, processes, and technologies.
Submit a Comment