Free vs Paid PCI DSS Compliance: What Actually Works

TL;DR: free PCI DSS 6.4.3 and 11.6.1 compliance

• Free baseline: You can hit baseline 6.4.3 and 11.6.1 at zero cost on a free-tier script monitoring platform. Inventory, authorization workflow, tamper detection, QSA evidence.
• When paid pays off: Paid tiers add automated blocking, longer retention, richer alerting, RBAC. Above Level 3 that usually pays for itself.
• Deadline: Both mandatory since 31 March 2025. Postponing is a QSA-fail risk at your next assessment.

Short on time? See cside PCI Shield. It covers everything below in one deployment.

Why these requirements were set

Since JavaScript was added to browsers in 2011, client-side execution has opened the door to widespread card skimming attacks. Sophisticated actors now inject malicious scripts via dependencies, plugins, or supply chain compromises, threatening payment card security. Most often, they exfiltrate payment data dynamically, often targeting only a small percentage of users to stay under the radar.

Visa, Mastercard, and Amex have all pointed to client-side script-based attacks as the leading source of credit card data theft. Tokenization helps, but only to a degree. If the client is hijacked, the attack still succeeds.

So PCI DSS v4.0 rightly mandates that businesses implement controls to:

• Prevent unauthorized scripts from executing (6.4.3)
• Assure the integrity of scripts (6.4.3)
• Maintain an up-to-date inventory of scripts with business justifications (6.4.3)
• Detect tampering or unauthorized modifications to payment pages (11.6.1)

How to achieve PCI DSS compliance without buying a solution

If you're resourceful, technically capable, and willing to maintain the tooling yourself, here's how you can do it.

1. Prevent unauthorized scripts (6.4.3)

To meet the requirement to ensure only authorized scripts are allowed to load and execute, you need a strong enforcement layer. A Content Security Policy (CSP) can serve this purpose, but it must be configured tightly and maintained actively.

What you can do:

• Deploy a strict CSP header using script-src to whitelist allowed domains.
• Use nonces or hashes to explicitly allow inline or dynamic scripts.
• Regularly audit your policy and update it with any script changes.

Is it enough for PCI? Yes, BUT only in formal terms. Dynamic scripts can NOT be fully protected against with CSP.

CSP is recognized as a valid control for authorizing scripts. However, CSP alone doesn't track intent. You need supporting documentation that proves why each allowed source was authorized.

BUT, remember the sentence from above:

"For merchants to qualify for SAQ A, they must confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)".

Does CSP solve this with this context? NO. Should a source stay the same, but the contents of the delivered script changes, a CSP would NOT catch it.

The 2024 Polyfill attackwould NOT be stopped by a CSP. This technically means your site IS susceptible to attacks, hence you need a security tool to fully comply. You can sign up or book a demo to chat with us.

Think of the following as part of your PCI compliance checklist:

• Use CSP with script-src restrictions and nonces/hashes.
• CSP must be updated and audited regularly.
• Manage CSP with care; it is brittle and can break apps.

2. Verify script integrity (6.4.3)

You're expected to detect when a script has been tampered with. For static scripts, Subresource Integrity (SRI) is a standard solution. It checks that only scripts with the expected hash load successfully.

What you can do:

• Add integrity and crossorigin attributes to every third-party `` tag.
• Periodically fetch scripts, hash them, and compare to known-good hashes.

Is it enough for PCI? Yes, BUT only for static scripts. Dynamic script can NOT be covered with SRI alone.

Dynamic scripts (e.g. analytics tools, A/B test runners) often change with every request and will break SRI. PCI expects you to acknowledge and mitigate this limitation, either by avoiding dynamic scripts or implementing a way of monitoring.

How to monitor those? That is not possible without tooling. Either a paid solution (like us here at cside 👋) - or your own built solution.

Without going into depth, here is how you could build your own monitoring tool:

1. Create a list of dynamic script URLs
2. Fetch the script contents
3. Normalize the payloadStrip timestamps, cache-busters, or CDN tracking headers (if necessary).
4. Save a cleaned version of the content for comparison.

Hash or diff the result

1. If changed: log and alert.

Alert on unexpected changes

1. Send an email for example

Document your process

1. PCI wants evidence that you're actively monitoring script integrity.
2. Keep logs of these checks and any resulting actions.

However, is this practically possible?

Would you build you own anti-virus software for example? We'd argue the answer for most of us is a clear "no". Building an engine to flag malicious behaviors in JS is a tough thing to do and will require a substantial dataset to be successful. This is more than just a time spent cost issue. It is also a resources issue.

Summary bullets:

• SRI works only for static scripts. Use it where possible.
• SRI Does NOT work with scripts that have varying payloads.
• Monitor actual script content is needed via tooling.

3. Maintain a script inventory (6.4.3)

You're expected to maintain an inventory of all scripts that run on the payment page. This means both static and dynamic scripts, as well as inline scripts, third-party sources (like tag managers or analytics), and anything loaded via frameworks (like React or Vue). PCI wants to see that every script has been reviewed, approved, and has a business or technical justification. This every 7 days (weekly basis).

What you can do:

• Create a version-controlled list (spreadsheet or YAML/JSON file).
• Include: script source, expected hash (if static), business/technical justification, owner/team.
• Update it with every deployment or code change (not script code changes). affecting the payment page.

Here's what you need to include:

• The source or URL
• Whether it's static or dynamic
• A hash (if static and SRI is used)
• Business/technical justification
• Owner or responsible team
• Notes on monitoring (especially for dynamic scripts)

Related guides

Dig deeper into the cluster:

• Stripe's PCI DSS shared responsibilities
• Adyen's PCI DSS shared responsibilities
• PayPal Braintree's PCI DSS shared responsibilities
• PCI DSS 6.4.3 and 11.6.1 solution comparison
• vikingcloud-approves-c-sides-security-platform-for-pci-dss-v4-0-1-requirement-6-4-3-and-11-6-1
• how to comply with PCI DSS 6.4.3
• the January 2025 PCI DSS SAQ A updates, demystified

Is it enough for PCI? Yes, PCI doesn't require anything else here. A manual list is acceptable as long as it's accurate and maintained. Dynamic scripts still need to be listed, even though you can't hash them. In those cases, PCI expects you to explain why SRI can't be used and how the script is being monitored instead. NOTE: This does NOT mean you can just make an inventory and not take action on the points above. It is a slightly looser described requirement that some see as the silver bullet. It is not.

4. Tamper and change detection (11.6.1)

PCI wants you to detect unauthorized changes to the payment page as received in the user's browser. This includes changes to content and HTTP headers (like CSP, CORS, etc.).

What you can do:

• Use a headless browser (e.g. Puppeteer) or curl to fetch the live payment page. You will need to spend money on that...
• Capture headers and HTML content.
• Compare with a known-good baseline and alert on changes.
• Normalize output if needed to avoid false positives (especially important for dynamic content).
• Document what changes trigger alerts, who responds, and how.

Is it enough for PCI? Yes, ASSUMING you run it regularly and have documented what changes trigger alerts, who is notified, and what your response plan is. The required cadence is weekly, UNLESS otherwise justified by a risk analysis.

Note on dynamic pages: Client-rendered frameworks (React, Vue, etc.) often load or mutate the DOM after page load. If you don't account for this, your monitoring will flag false positives. For PCI, this is arguably fine. AS LONG AS you clearly define what you do check (e.g., CSP header, external script domains, key DOM selectors) and why. If you still suffer an attack, the requirement stands:"For merchants to qualify for SAQ A, they must confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)".

Summary bullets:

• Use curl or headless browser to capture and diff headers and HTML.
• Normalize dynamic content to reduce false positives.
• Run checks weekly (or more frequently based on risk).
• Set up alerting and a documented response process.

What a PCI DSS 4.0.1 compliance audit checks for 6.4.3 and 11.6.1

A PCI DSS 4.0.1 compliance audit for e-commerce merchants examines whether the payment page inventory is complete, whether every script has an authorised business or technical justification, and whether the merchant can prove a change-detection mechanism is running against the HTTP headers of the payment page at least once every seven days. Requirements 6.4.3 and 11.6.1 are the two clauses a QSA will spend the most time on for card-not-present flows.

The audit-visible artefacts are specific: a script inventory list with owner, purpose, and expected hash for each entry; documented approvals; and log evidence that the change-detection mechanism has run at the required cadence with alerts flowing to a monitored channel. If any of those artefacts are missing or cannot be reproduced on demand, the audit will flag 6.4.3 or 11.6.1 as non-compliant regardless of any other control quality.

cside produces the script inventory automatically from live payment-page data, maintains hashes and approval state, and runs the 6.4.3 change-detection loop continuously with an evidence trail a QSA can pull directly.

The business benefits of PCI DSS compliance beyond avoiding fines

The benefits of PCI DSS compliance beyond fine avoidance are concrete: acquirer-relationship stability, payment brand trust, and a materially lower incident-response cost if a breach does happen. Continuously compliant merchants keep their acquirer relationship out of the escalation queue, retain access to the lowest interchange bands offered by their processor, and reduce the volume of forensic work an incident triggers.

There is also a downstream benefit for large e-commerce buyers. Enterprise procurement teams increasingly require PCI DSS attestation as a vendor prerequisite. Continuous compliance means the AoC is always current when a procurement request lands, rather than a scramble every annual cycle.

cside's continuous monitoring keeps the 6.4.3 and 11.6.1 evidence chain current in real time, which means the audit-preparation window shortens from weeks of catch-up to a same-day export.

PCI DSS non-compliance and the penalties merchants actually face

PCI DSS non-compliance carries three penalty tiers that hit merchants directly. Card networks levy fines through the acquirer, typically starting at a few thousand dollars per month for a first offence and escalating to five- or six-figure monthly amounts if the merchant remains non-compliant across audit cycles. The acquirer often passes these fines through in full and adds its own service-charge premium.

The second tier is transaction-level cost. A merchant found non-compliant at breach time faces higher interchange rates on subsequent transactions and increased chargeback liability. PCI DSS non-compliance penalties compound with breach-related liability under state and federal law.

The third tier is the strategic penalty. Persistent non-compliance can lead to loss of card-processing rights or MATCH listing, which restricts the merchant's ability to obtain payment processing from other acquirers.

cside reduces both non-compliance risk and audit-preparation cost by keeping the 6.4.3 and 11.6.1 controls in a continuously verifiable state.

A concise PCI DSS 4.0.1 compliance checklist for 6.4.3 and 11.6.1

A PCI DSS 4.0.1 compliance checklist for payment-page requirements 6.4.3 and 11.6.1 is short but strict. Run through it in order before an audit:

1. Complete script inventory. Every script that loads on the payment page is listed with source, purpose, business owner, and expected hash where the script is static.
2. Documented approval per script. Each entry has a recorded approval decision by an accountable person and a review timestamp within the last review cycle.
3. Change-detection mechanism installed. A tool or process detects unauthorised changes to HTTP headers and script content on the payment page and can produce evidence of runs.
4. Weekly cadence proven. Log evidence shows the change-detection mechanism executed at least every seven days for the full audit period.
5. Alert routing verified. Alerts route to a monitored channel with an escalation path to security or engineering.
6. Test-fire evidence. A test change on a non-production payment page was detected and alerted within the required window.
7. Compensating controls documented, if used. Any deviation from the standard approach is documented with the compensating control rationale.

cside produces items 1 to 6 as continuous evidence, so the audit becomes a review of the running system rather than a reconstruction after the fact.

So, can you do it for "free"?

Yes, sort of. But it's practically impossible.

It's technically possible, but practically AND compatibility fragile. Most importantly, you will more than likely spend more money, time and resources than opting for a paid solution.

You'd need to:

• Write your own tools or scripts
• Build your own method to analyse scripts - this is costly and as a non-security company you would likely not have access to the data or competences to do this. Would you build your own anti-virus?
• Monitor script integrity manually
• Maintain a script inventory with discipline
• Normalize and compare dynamic pages without drowning in false positives

And most importantly: You need to prove that your site is not susceptible to client-side attacks, as explicitly required in the January PCI DSS update.

A CSP won't stop supply chain attacks. An SRI is not compatible with dynamic scripts. And a basic curl check won't protect against context-aware, selective exfiltration.

If you're going the DIY route: Document everything, automate where you can, and prepare for overhead. And, build your own tooling, if possible. But most importantly calculate your time and resources (human or otherwise) and run the numbers. The chances are, you'd likely be better suited to go for a paid solution.

If you're looking to be completely compliant and be safe, we built cside for exactly that. You can book a demo here or sign up to be compliant today.

Understanding PCI 11.6.1 specifically

While 6.4.3 focuses on script inventory and justification, PCI DSS 11.6.1 focuses on detecting unauthorized changes to scripts and HTTP security headers on payment pages.

PCI 11.6.1 requires you to:

• Monitor the content and configuration of every script running on payment pages
• Detect tampering, injection, or unauthorized modification in a timely manner
• Alert the appropriate personnel when unauthorized changes are detected

The word "timely" is intentionally left to QSA interpretation but is generally read as detection within minutes to hours of the change. Weekly or monthly scans do not satisfy 11.6.1. cside's continuous monitoring fires alerts in real time as changes occur, giving your security team the response window compliance requires.