If your institution accepts payments online, you have probably had the same conversation more than once: “Are we PCI compliant?” It’s a fair question. It is also the wrong finish line.
PCI DSS is a baseline standard designed to protect account data. It helps you define controls, assign responsibility, and prove you have a program. What it does not do by itself is stop modern web attacks that happen in the browser, on the pages your users actually interact with.
That gap is where e-skimming and other client-side attacks live.
PCI compliance is necessary, but it is not the same as payment security
Many organizations treat PCI DSS like a certification you earn and then file away until the next assessment. Meanwhile, the web changes daily. Marketing tags get added. Accessibility tools update. Third-party widgets rotate versions. A new landing page goes live for admissions or the giving season. Small changes add up quickly, and attackers take advantage of that speed.
The practical reality is simple: you can pass an assessment and still have blind spots that put cardholder data, and often other sensitive data, at risk.
“Beyond PCI DSS” does not mean ignoring PCI. It means building the operational capabilities that PCI is trying to drive, and applying them in a way that matches how client-side attacks actually happen.
Why client-side attacks slip past traditional controls
In a client-side attack, the attacker targets the user’s browser, not your back-end systems. That matters because many traditional security controls are designed for servers, networks, and endpoints. In an e-skimming scenario, malicious JavaScript can capture form data in the browser before it is transmitted, tokenized, encrypted, or processed by downstream systems.
This is why a site can have strong back-end security, modern payment processing, and a clean vulnerability scan, yet still leak payment data.
Higher education sites are particularly exposed because they are often a patchwork of:
- Multiple departments publishing pages and content
- Lots of third-party scripts for analytics, fundraising, chat, scheduling, and personalization
- Seasonal and campaign-driven changes that add complexity quickly
Attackers like environments where changes are constant, and ownership is distributed. They do not need to “hack the payment processor” if they can quietly modify what runs in the browser.
The PCI DSS 4.0.1 requirements that matter most for client-side risk
PCI DSS 4.0.1 introduced a more direct focus on payment page scripts and tampering detection. Two requirements come up again and again when you talk about client-side threats.
Requirement 6.4.3: Control scripts on payment pages
At a high level, this requirement is about knowing what scripts run on payment pages, why they are there, and whether they have changed. That typically translates into:
- Maintaining an inventory of scripts
- Having a business or technical justification for each script
- Using methods to ensure script integrity and authorization
A common question here is, “What counts as a payment page?” If your page includes a payment form, redirects to a payment experience, or embeds a payment form in an iframe, you should assume it is in scope for the intent of these controls. The browser does not care whether the payment form is “yours” or embedded, and attackers do not either.
Requirement 11.6.1: Detect changes and tampering
This requirement focuses on being able to detect unauthorized changes to payment pages and related security-impacting mechanisms. In practice, this means you need a way to notice when something changes that should not have changed, and to do it fast enough to matter.
If your “detection” process is a quarterly review or an occasional spot check, that is not detection. That is archaeology.
Another frequent question is, “Is monitoring just the HTML enough?” Not really. Client-side risk is driven by what executes in the browser, including scripts and security-impacting settings. You need coverage that aligns with what actually changes and what attackers manipulate.
Where PCI programs commonly stop short
This is the part that causes frustration during assessments and incidents. Teams often think they have addressed the intent, but they are relying on processes that cannot keep up with modern web environments.
Payment-page-only thinking
Organizations sometimes scope controls narrowly to one hosted checkout page. But the user journey often includes pages that collect sensitive information before checkout, or pages that share scripts with the checkout page.
In higher education, that might include:
- Tuition and fee payment portals
- Donation forms and giving campaigns
- Housing deposits
- Event registrations and ticketing
- Continuing education enrollment
Attackers can target adjacent pages, reuse injected scripts across templates, or compromise a tag manager that affects many pages at once. Treating the payment page as a single URL is rarely how your site behaves in real life.
Over-trusting “approved” third parties
A script can be “approved” and still become risky later due to:
- A vendor compromise
- A supply chain issue in the vendor’s dependencies
- A configuration change that enables risky behavior
- A takeover of an unused or expired asset that is still referenced
This is why a one-time approval process is not enough. Approval must be paired with ongoing visibility into what is actually running.
Inventory and review that cannot stay current
A manual script inventory can be accurate on Monday and wrong by Friday. Websites evolve too quickly, especially when multiple teams can publish changes.
Auditors typically want evidence that your inventory is current, changes are controlled, and you can prove what happened if something changes unexpectedly. If your evidence is spread across email threads, screenshots, and best intentions, you are going to have a hard time, even if your team is doing real work.
What “beyond PCI” looks like in practice
The goal is not to create a bigger compliance program. The goal is to reduce the gap between policy and reality.
A practical “beyond PCI” approach includes:
- Defining scope as the payment experience, not a single page
Map the paths that lead to payment, including embedded forms, parent pages, and shared templates. If a page can influence what loads on the payment experience, it deserves attention. - Establishing script governance that reflects how work happens
You need clear ownership and simple rules that teams can follow without becoming a bottleneck. For example, who can add a script, who approves it, and what documentation is required. - Monitoring continuously, not periodically
Client-side attacks are quiet and fast. Continuous monitoring is what turns the problem from “we hope nothing changed” into “we know what changed, when, and where.” - Treating unexpected change as an incident trigger
If a new script appears on a payment page, or an existing script changes outside an approved workflow, that should generate an alert and a defined response path. - Keeping audit evidence in mind from day one
A good client-side program naturally produces artifacts, including inventories, change history, alerts, approvals, and outcomes. That makes assessments easier because you are not recreating history at the last minute.
If you are thinking, “This sounds like a lot,” that is the point. It is a significant amount of work to do manually, which is why many organizations struggle to operationalize these requirements.
How ScriptSafe helps institutions operationalize the intent with less friction
ScriptSafe helps institutions reduce client‑side risk and streamline PCI DSS 4.0.1 alignment, without turning web security into a full‑time administrative burden.
At a practical level, ScriptSafe helps you:
- Maintain visibility into the scripts running on your payment experiences
- Identify changes that could indicate tampering or unauthorized updates
- Support script governance by making it easier to document what is present and why
- Reduce the manual effort of validating changes and maintaining evidence over time
This matters because client-side risk is not only a security issue; it is also a compliance, financial, and reputational issue. When e-skimming hits, the cost is not limited to card brands and remediation. It can also include incident response time, legal exposure, public communication, and loss of trust from students, parents, alumni, and donors.
Key takeaways
PCI DSS is a baseline, not a guarantee against browser-based attacks. Client-side threats like e-skimming exploit the gap between what your back-end controls protect and what executes in the user’s browser. PCI DSS 4.0.1 pushes organizations toward better control of payment page scripts and better tampering detection, but most teams need automation to keep up with real-world web changes. A “beyond PCI” approach focuses on continuous visibility, practical governance, and audit-ready evidence.
If you want to reduce client-side payment risk and make the PCI DSS 4.0.1 intent easier to operationalize, see how ScriptSafe aligns with your web and compliance workflow.
Request a demo or get started.
