PCI compliance requirements just lost their grace period

PCI compliance requirements: what actually changed#

A fox does not wait for the wind to turn before it moves. It reads the first shift in the grass and adjusts its trail while the scent is still fresh, and that is roughly the posture every marketing team touching a payment page needs now. For three years, a long list of pci compliance requirements sat inside PCI DSS 4.0 and 4.0.1 as 'best practice': recommended, watched, gently flagged, but not yet scored.

On 31 March 2025 that grace period closed for good. All 51 of those requirements became fully scored, mandatory line items, and every assessment running through 2026 checks them properly for the first time, as Qualys laid out in its August 2026 review of the assessment cycle.

Two of those fifty-one carry the sharpest teeth for anyone running a payment page or a checkout flow. Requirement 6.4.3 says an organisation must identify every script that loads or executes in a customer's browser on that page, keep a written inventory of each one, secure explicit authorisation for it, and check it for integrity. Qualys put the scope bluntly: 'Analytics tags, chat widgets, and tag manager containers all count.'

Requirement 11.6.1 pushes further, mandating a tamper-detection mechanism that watches for unauthorised change to the payment page's content and its HTTP headers, the exact pattern behind a silent script injection that skims a card number before a shopper, or a security team, ever notices. Both requirements are aimed at the same quiet danger: a script nobody remembers approving, running quietly in a customer's browser, doing nothing anyone would call marketing.

Neither requirement is a new arrival. The PCI Security Standards Council first published them as best practice back in March 2022 and gave the industry three years of runway before scoring began. The Council's own guidance confirms both went mandatory on 31 March 2025, alongside a dedicated document titled 'Payment Page Security and Preventing E-Skimming, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1'.

A Qualified Security Assessor, a firm the Council itself qualifies to validate compliance, now checks every one of them line by line, rather than noting them as a recommendation worth revisiting next year.

The other requirements riding alongside 6.4.3 and 11.6.1#

6.4.3 and 11.6.1 do not travel alone. Requirement 6.3.2 asks for a complete inventory of bespoke and custom software, web applications, APIs and third-party components. Requirement 6.4.2 asks for automated, continuous protection of public-facing applications, replacing the old annual manual review.

Requirements 11.3.1.1 and 11.3.1.2 require risk-based decisions on every vulnerability below critical or high severity, and make authenticated scanning mandatory rather than optional. None of these five is exotic. All five assume someone keeps a current, honest list of what actually runs on the site, which is precisely the habit most marketing stacks lack.

Every square in that grid is a requirement a QSA will now check, not skim. The pci compliance requirements that used to be a polite footnote are the assessment itself, and the rest of this piece is where the story stops being a security bulletin and starts being a marketing brief, because most of what trips these five requirements did not arrive through a firewall. It arrived through a tag manager.

Why this is marketing's problem, not just security's#

Here is the vulpine angle most compliance write-ups miss entirely. folkfox does not sell PCI audits, and neither does your marketing department, but a striking share of the clients we work with across fintech, healthcare and cybersecurity run some kind of payment page: a checkout, a donation form, a subscription billing screen, a booking deposit.

The people adding scripts to those pages are rarely the security team. They are marketing: dropping in an analytics tag, a chat widget, a tag manager container, a pixel tracker, an A/B testing snippet, a retargeting pixel, usually on a Tuesday afternoon, usually without a ticket, usually without telling anyone downstream. Under pci compliance requirements 6.4.3, every one of those additions is now a line item an assessor will ask about by name.

None of this is malicious, and most of it is genuinely useful. A tag management system lets a team configure and deploy tags on a website from a web interface, without editing code directly, which is exactly why marketing loves it and exactly why it is the wrong tool to leave unsupervised on a payment page. This is where pci compliance requirements and everyday marketing tooling collide.

A container built for speed becomes, in security terms, a single point that can load almost anything with almost no review. Google's own engineering guidance on the web platform notes that teams routinely lose track of accumulated third-party scripts, often running duplicate functionality from two different vendors because nobody audited what was already there, as web.dev's own guidance on third-party JavaScript puts it. That is not a security failure. It is a governance gap, and governance gaps are marketing's to close as much as anyone's.

The stakes are not theoretical. Recorded Future's 2024 payment fraud research found e-skimmer infections on roughly 11,000 unique e-commerce domains, a threefold jump on the year before, with 269 million card records posted across dark and clear web sources as a direct result, a figure Qualys cites directly in its 2026 assessment guidance.

Every one of those infections started as a script quietly running somewhere it should not have been, on a page a marketing team almost certainly touched last. So the fix is not 'get security to lock everything down' and it is not 'let marketing keep shipping tags unchecked'. It is coordination, the kind folkfox builds into every content and campaign programme we run for regulated clients, where nothing lands on a public page without a named owner and a written reason.

A tag stack nobody has walked through recently is undergrowth, not infrastructure, and undergrowth is exactly where something can hide. A marketing team that treats its own scripts as a shared, documented asset stops being an audit finding waiting to happen and starts being the department that made the QSA's job easy.

The pci dss compliance checklist hiding inside five requirements#

Six requirement numbers look like a thicket from a distance. Up close they reduce to one plain question: does anyone here know, in writing, everything that runs on this page, and can anyone prove it has not changed since the last check? That is the whole pci dss compliance checklist marketing teams tend to miss, because it reads like an engineering exercise and lands, in practice, on whichever department last touched the page.

The table below sorts each requirement by what it actually covers, and who, realistically, owns it inside a typical folkfox client.

Read that table again and notice which column carries the most weight for a marketing team: the middle one, not the last. Security or engineering can own the mechanism, the scanning tool, the monitoring dashboard, but nobody can own a script marketing never told them existed.

That is the practical, unglamorous heart of pci compliance requirements 6.4.3: it does not ask security to catch every rogue script after the fact, it asks the organisation to never let an unauthorised one load in the first place. Two technical controls do most of the heavy lifting once a script is authorised: a Content Security Policy that restricts which scripts a page is allowed to load, and Subresource Integrity, which checks a fetched script's cryptographic hash before letting it run.

Why the checklist keeps slipping past marketing's desk#

Small merchants used to lean on the simplest self-assessment route, SAQ A, and assume payment-page script rules did not apply to them. That assumption just broke. The Council removed 6.4.3 and 11.6.1 from SAQ A itself, but added an eligibility test asking merchants to confirm their site is not susceptible to script-based attack, pushing anyone who cannot honestly answer that onto a harder assessment path, one that looks a great deal like the table above.

What a marketing team should actually do about it#

None of these pci compliance requirements call for a replatform or a six-month security programme. They call for the same patient prowl a fox brings to a hedgerow it has crossed a hundred times: slow down, check what has changed since the last pass, and do not assume the trail is still clear just because it was clear last month.

The steps below are the ones folkfox walks clients through when a payment page, a donation form or a subscription flow needs to survive its first proper look from a QSA, rather than merely surviving a glance.

Treat the audit trail you build here as more than paperwork for a QSA. A documented, authorised, integrity-checked script list is also the fastest way to answer a curious customer, a nervous board member or a journalist asking why a checkout page behaved strangely for ten minutes last Tuesday.

folkfox builds that kind of quiet, provable trust into brand strategy work across every regulated sector we serve, because the businesses that outfox an e-skimming headline are the ones that already treat pci compliance requirements as a shared habit, not a February scramble, and could already show, in writing, exactly what was running on their page before the headline broke.

PCI DSS compliance levels, and the honest truth about cost#

PCI DSS compliance levels sort merchants by how much card-present or card-not-present volume they process, not by how tidy their website looks. Visa confirms that a merchant's total transaction volume over a twelve-month period sets its compliance level and the validation route that follows from it. Levels decide how strictly pci compliance requirements are validated, not which of them apply.

In broad terms, the highest-volume merchants sit at the top of that ladder and typically face an annual, QSA-led Report on Compliance, the most thorough form of assessment the standard has. Smaller merchants further down the ladder more commonly complete a Self-Assessment Questionnaire instead, though as the SAQ A changes above show, smaller no longer means exempt from the payment-page rules.

On pci dss compliance cost, the honest answer is the unglamorous one: it depends, and folkfox will not invent a figure to make this section feel more complete than it is. Cost moves with compliance level, with whether an organisation completes a Self-Assessment Questionnaire or commissions a full QSA-led Report on Compliance, with how much of the required inventory, authorisation and monitoring work already exists versus needs building from a standing start, and with how many payment pages, donation forms and subscription flows sit inside scope.

Neither the Council nor its assessors publish a single number that fits every business. Treat anyone who quotes one confidently, without first asking about your level and your stack, with a fox's own scepticism.

What does move the number, reliably, is preparation. A business that walks into its assessment with the pci dss compliance checklist from the table above already ticked off spends its budget on validation, not discovery. The one that has not spends it finding out, mid-audit, exactly how many scripts nobody remembers approving are quietly running on its checkout page. That is the whole of pci compliance requirements in one paragraph: know what is running, prove it, and keep proving it.

Frequently asked questions#