HomeCustomersPricingDocs
Back
  • April 01, 2025
  • 4 min read

PCI Script Security and 6.4.3 and 11.6.1 Compliance: Webinar Q&A

John Hetherton

Head of Compliance

Categories

Compliance

During our webinar, A Practical Guide to PCI Script Security and 6.4.3 and 11.6.1 Compliance, we received a number of insightful questions throughout the presentation. We thought it would be helpful to share them publicly, so we’ve compiled a list of the top 10 questions along with our answers below.

What are the implications of non-compliance with PCI?

Typically fines—these are determined by the card brands and passed to the acquirer. The acquirer may then decide whether to pass the fines on to merchants. The longer non-compliance goes on, the higher the fines become. 

What is the difference between a third-party iFrame and a Level 1 iFrame? We use JavaScript to embed your iFrame and encrypt sensitive card data. However, do you have a webpage dedicated to card data encryption where we can redirect the user?

There is no difference really, an iFrame for collecting cardholder data should only ever be served by a Level 1 PCI DSS compliant service provider. Evervault does provide an iFrame but not a Full Page Redirect.

Do acquirers conduct spot audits to verify that Merchant SAQs are accurate? How frequently?

Yes, but they typically rely on a Qualified Security Assessor (QSA) to perform the assessment and sign off on either a Self-Assessment Questionnaire (SAQ) or, in some cases, a full Level 1 Report on Compliance (RoC). Acquirers can issue letters requesting the SAQs. The responses in aggregate are summarised, and reported to the card brands. Card brands then determine whether a given acquirers portfolio is sufficiently compliant. They can then decide to push fines or not.

Who enforces PCI DSS compliance for merchants and service providers?

It depends. For merchants, their acquiring bank contractually requires them to be PCI DSS compliant. For service providers, enforcement typically comes from the card brands or directly from their customers requesting proof of compliance.

Is it feasible to implement a Content Security Policy (CSP) for 3D-Secure workflow pages?

For merchants using a 3DS solution, validation to PCI DSS Requirement 6.4.3 for 3DS scripts is not required due to the inherent trust relationship between the 3DS service provider and the merchant, as established in the merchant’s due diligence and onboarding processes, and the business agreement between the entities (PCI FAQ 1581).

Since it proxies Hotjar scripts (or other scripts you may be running), is there a risk of changes in how the original script behaves? Would we still see the same outputs in Hotjar, etc.?

The proxy does not alter the script content. However, it analyzes the content and alerts on potential malicious changes. The Evervault dashboard also provides Git-style diffs to track script modifications.

If you were just starting to work on PCI DSS requirements 6.4.3 and 11.6.1 now, how would you approach implementation before April 1st?

  • Reduce scripts on payment pages where possible.
  • Implement CSP in monitoring mode first, then blocking once sufficiently tuned.
  • Establish an inventory of scripts.
  • Implement secure headers and perform security scans.
  • Monitor for changes to inventoried scripts
  • Compile Audit Evidence

Is CSP good enough on its own?

Based on the latest information supplement, it appears that CSP on its own will not be enough, as CSP primarily uses script source for determining whether scripts are allowed to execute or not.

What alternatives are there to SRI?

In the absence of SRI and hashes, the other option is monitor script content changes. This is mostly being done by means of dynamic assessment of scripts and changes to scripts. Check out Page Protection for more information.

What are the Security Related HTTP Headers I should be monitoring for change?

  • Content-Security-Policy (CSP)
  • Strict-Transport-Security (HSTS)
  • X-Content-Type-Options: *Referrer-Policy
  • Permissions-Policy
  • Set Cookie
  • CORS

Some headers, such as X-Frame-Options, are deprecated in favor of CSP directives. Additionally, privacy-focused browsers may limit referrer information regardless of the Referrer-Policy settings.

Watch a Practical Guide to PCI Script Security and 6.4.3 and 11.6.1 Compliance

If you need to understand how to protect your payment pages and manage browser scripts in compliance with requirements 6.4.3 and 11.6.1 of PCI DSS 4.0, this webinar is for you.

Watch the webinar

John Hetherton

Head of Compliance

Related Posts