What PCI DSS 6.4 asks for and why e-skimming makes it hard
If you must show PCI DSS 6.4 coverage for a public web application, the requirement has two halves that fail for different reasons. The first is an automated technical solution that continually detects and prevents web-based attacks (6.4.2), typically a web application firewall (WAF) placed in front of the application. The second is management of every script that runs on the payment page in the consumer's browser (6.4.3). Requirement 6.4.2 replaced 6.4.1 on 31 March 2025, so an assessment that still reports 6.4.1 as the control is working from a superseded position. The script requirements became mandatory on the same date, and they are the part most teams underestimate.
The script half exists because of e-skimming. An attacker who alters JavaScript on a checkout page can capture card details as the customer types them, and the merchant's server never sees a suspicious request. A WAF does not address this, because the malicious code is delivered inside a page the business is already serving. The assessor will therefore expect a complete inventory of payment page scripts, a method to confirm each script is authorized, a method to check each script's integrity, and a written justification for every entry. Start by listing every tag, widget, analytics and marketing script that loads on checkout pages, including those added by tag managers. Then ask who approved each one and why it must run there.
The difficulty is that the script set is never still. Third-party vendors update their files, tag managers let marketing staff add scripts without an engineering release, and a single new script can arrive through a container you did not write. The WAF is also hard to set up correctly for the application. A rule set left at defaults will produce false positives that break checkout, while a set tuned to avoid breakage can leave gaps. Confirm with your WAF vendor and your QSA which rule sets, paranoia or sensitivity levels and logging settings you intend to rely on, and keep the tuning record as evidence. Note that scripts used only for 3-D Secure may be treated differently under PCI SSC FAQ 1581, so confirm that boundary before you scope the inventory.
Which web applications and scripts PCI DSS 6.4 covers
Requirement 6.4 only applies to the web applications and payment page scripts inside your scope, so the first job is deciding what is in scope. The cards below cover the decisions that most change the workload: which applications and pages count, how hosted payment pages and iframes shift responsibility, and the narrow exceptions that apply to 3DS scripts and SAQ A.
Public-facing applications in the CDE
Start with every web application reachable from the internet that sits in the cardholder data environment (CDE) or can affect its security. This includes checkout, account and payment-initiation pages, plus the APIs and back-end services those pages call. Check whether an application stores, processes or transmits account data, shares a network or authentication path with systems that do, or manages the payment flow. Any application that meets one of these tests needs the 6.4.2 technical solution in front of it. Document the decision so an assessor can trace it to your network and data-flow diagrams.
Pages that render payment forms
Identify every page that displays a field for card number, expiry date, security code or cardholder name, whether or not the data is ever stored. These pages are the points where card data is captured, so they carry the strongest 6.4.3 exposure. Map each page to its template, its component and the scripts it loads. A form that looks like a simple login or donation page can still be a payment page if it collects account data. Confirm the list with the team that owns front-end code, since content management plugins often add forms without a formal change.
Hosted payment pages and iframes
A hosted payment page or iframe supplied by a payment service provider moves card capture out of your own page, which can reduce which scripts you must manage under 6.4.3. The reduction depends on the design. If your page loads the iframe while your own scripts can read or alter the surrounding form, those scripts still matter. Ask your provider for a written description of which pages and scripts it controls, and check whether your site still loads any script that touches the payment step. Keep that responsibility split in your responsibility matrix.
3DS scripts under FAQ 1581
PCI SSC FAQ 1581 says merchants that use a 3D Secure solution do not need to validate 6.4.3 for the 3DS scripts. The exception is narrow. It covers only the scripts that belong to the 3DS process. Any other script on the same page, including analytics, tag managers, chat widgets or advertising pixels, remains subject to 6.4.3 if it runs for another purpose. Build an inventory that separates 3DS scripts from everything else so the exception is not applied to the whole page by default.
SAQ A and script attack susceptibility
In January 2025 the SSC removed Requirements 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion that the merchant's website is not susceptible to script attacks. This means a merchant that relies on a fully outsourced payment page must still confirm that its site cannot be altered to skim card data. Check what scripts the site loads, who controls them and whether any third-party code can change the page. If the answer is uncertain, a merchant may need to validate against a longer SAQ instead of SAQ A.
How an assessor tests 6.4.2 and 6.4.3
This table compares what a QSA or SAQ reviewer checks for the web attack solution (6.4.2) and the payment page script controls (6.4.3), what evidence is expected, and where organizations usually fail. Read each row as a test question you should be able to answer with evidence before the assessment starts.
| Area tested | What the assessor examines | Common finding |
|---|---|---|
| WAF configuration (6.4.2) | Deployment path showing the solution sits in front of every public-facing payment web application, with configuration exports and change history | Some hostnames, APIs or legacy paths bypass the WAF entirely |
| Rule set coverage (6.4.2) | Enabled rule sets covering injection, cross-site scripting and code injection, with documented tuning exceptions | Rules were installed but most categories disabled to reduce false positives, with no written rationale |
| Blocking mode (6.4.2) | Evidence the solution actively blocks or challenges attacks, not only logs them, tested with sample attack requests | WAF running in detection-only mode since go-live, with no decision to stay in that mode |
| Continuous operation (6.4.2) | Monitoring or uptime records, alerts on engine failure, and logs showing the solution ran across the review period | Gaps in logging during maintenance windows or after upgrades, with no alert on the gap |
| Rule updates (6.4.2) | Record of how rule sets are updated, who approves changes, and dated update history | No evidence that rule sets were refreshed after vendor or community updates |
| Script inventory (6.4.3) | A complete list of every script on payment pages, including those loaded by tag managers, analytics, chat and A/B testing tools, each with a written business justification | Inventory covers the checkout page's own scripts but misses scripts injected at runtime through a tag manager |
| Authorization and integrity methods (6.4.3) | Documented method confirming each script is authorized, and a method assuring integrity such as subresource integrity or a content security policy, with test records | Integrity controls described in policy but not applied to third-party scripts |
| Page sample review (6.4.3) | Assessor loads a sample of payment pages and compares live scripts against the inventory and justifications | Live page loads a script that is absent from the inventory, or a justification that no longer matches the script's purpose |
How to implement 6.4 in order, with the output of each step
This sequence takes a public-facing payment environment from unclear scope to a tested, documented 6.4 control set, with a named output at every stage so the assessor can trace each claim back to evidence.
Confirm scope and the applicable sub-requirements
Start by listing every public-facing web application that is in the cardholder data environment or could affect it, including checkout pages, embedded payment forms and any site that loads scripts into the consumer's browser. Confirm with your QSA or acquirer which validation type applies, because the sub-requirements that apply depend on the SAQ or ROC in use. Record that 6.4.2 superseded 6.4.1, so 6.4.1 is reported as not applicable, and that 6.4.3 applies to payment page scripts unless a script is solely a 3DS function. The output is a signed scope statement listing each application, its hostname and the sub-requirements that apply to it.
Deploy the automated web attack defense in blocking mode
Place an automated technical solution in front of each in-scope application to detect and prevent web-based attacks continually. Open-source options such as Coraza, which works with ModSecurity SecLang rulesets and the OWASP Core Rule Set and integrates with Caddy, HAProxy, Traefik and Nginx, are one route, but your team must confirm that the chosen product covers the attack classes in your threat model and your hosting design. Run the rules in detection mode first, review false positives, then move to blocking. The output is a deployment record showing the solution's position in the traffic path, its rule set version and the date it entered blocking mode.
Crawl and inventory every payment page script
Crawl each in-scope page as a consumer would, including after login, after form interaction and across browsers you support, so that scripts loaded conditionally are captured. Record every script source, whether it is first-party or third-party, the page it runs on and the party that supplies it. Compare the crawl against tag manager configurations and developer notes, because a script that loads only in some conditions is a common gap. The output is a script inventory that lists each script's source, location, owner and load condition.
Define the authorization and integrity methods
For each script in the inventory, define how the organization confirms it is authorized to run and how it assures the script has not been altered. Authorization is typically an approved-owner list tied to change control, and integrity may use subresource integrity hashes, content security policy controls or a monitoring method that detects changes in the browser. Confirm the chosen methods are operated by named roles and that they cover third-party scripts that change without notice. The output is a written method for each control, with an owner and the systems that enforce it.
Document a written justification for each script
Write a justification for every script that states its business purpose, why it must run on the payment page and who approved it. Remove any script that cannot be justified, and check whether scripts for a 3DS function are handled separately under the guidance on 3DS scripts. Keep the justification tied to the inventory entry so that a change to the script triggers a review. The output is an approved script register with a justification, approver and review date for each entry.
Set up alerting and periodic review
Configure alerts that fire when an unauthorized script appears, when an authorized script's integrity check fails or when the web defense solution records a spike in blocked events. Route alerts to a named response owner and define how each alert is triaged and closed. Schedule reviews of the inventory and justifications, and record who performed each review and what changed. The output is an alert configuration export, a triage procedure and a review log showing completed reviews with their findings.
Test the controls before the assessment
Test each control end to end before the assessor arrives. Attempt to load an unapproved script on a test payment page, alter an approved script and confirm the integrity check fails, and send attack traffic that the web defense solution should block. Record the expected result, the actual result and any remediation. Use the results to correct gaps, then retest. The output is a test report that your assessor can reproduce, along with the evidence of each control's operation.
Hand the evidence package to the assessor
Assemble the scope statement, deployment records, script inventory, approved script register, alert configuration, review log and test report into one package. Confirm with your QSA or assessor which formats they accept and how they want samples selected. DeployOpen can prepare systems, controls and evidence, but the assessor independently tests them and issues the report. The output is a versioned evidence index that maps each 6.4 sub-requirement to the artifacts that support it.
Evidence that passes 6.4.2 and 6.4.3 and how to keep it current
An assessor testing 6.4.2 and 6.4.3 looks for records that show the controls work today and kept working between audits. Each artifact below proves one part of the requirement, and each needs a routine owner so it does not drift out of date.
WAF configuration and rule set versions
Export the running WAF configuration and record the exact rule set version, including any OWASP Core Rule Set release and local exclusions. An assessor compares the configuration against what the team says it protects, so every exclusion needs a named reason. Store each export in version control with a date. Re-export after every rule change and at least once per quarter, then confirm the export matches the live engine rather than a copy kept on a laptop. If the team uses Coraza, record the engine version alongside the rules.
Blocking-mode proof
Assessors need evidence that the WAF blocks attacks rather than only logging them. Capture a dated configuration showing the engine in blocking mode for every public-facing application in scope, plus a test request that returns a block response. Repeat the test after upgrades, DNS or load balancer changes, and rule set updates, because a redeployed instance can silently fall back to detection mode. Keep the test scripts so the same check can be rerun on demand.
Samples of blocked attack logs
Keep a representative set of blocked requests covering SQL injection, cross-site scripting and code injection, with timestamps, source addresses, matched rule IDs and the affected URL. Raw logs are rarely enough on their own, so pair each sample with a short analyst note explaining the decision. Set a retention period that covers the full assessment window and the period between assessments, and confirm that log forwarding to the central store has not failed quietly. Review a sample each month so the file reflects current traffic.
Payment page script inventory with justifications
Requirement 6.4.3 expects a complete inventory of every script loaded in the consumer's browser on payment pages, with a written justification for each. The inventory should record the script's source, owner, purpose, and the page where it loads. Scripts used for 3DS may be treated differently under PCI SSC FAQ 1581, but any script run for another purpose stays in scope. Crawl the payment pages on a schedule and reconcile findings against the inventory, because new tags often arrive through marketing or analytics changes.
Authorization and integrity records
6.4.3 requires a method to confirm each script is authorized and a method to assure its integrity. Records can include an approved script list enforced through a content security policy, subresource integrity hashes for scripts that support them, and logs of blocked or altered script loads. Each hash or policy entry should trace back to an approval. Recheck the records whenever a vendor releases a new file, since a changed script with an old hash either fails loudly or, worse, gets an unreviewed exception.
Script change records and periodic review records
Every addition, removal or update to a payment page script needs a ticket or merge request showing who requested it, who approved it and when it went live. Pair those change records with the periodic review record the standard expects, showing the team re-examined the inventory and justifications on a set cadence. Use GitLab protected branches or an equivalent so that changes to the script list and tag manager configuration cannot be pushed without review. A review that is skipped leaves a visible gap, so assign it to a named role with a calendar reminder.
What meeting 6.4 costs in money and effort
This table breaks down the cost and effort components of meeting Requirement 6.4, separating one-time work from recurring work and naming who is paid for each. Use it to see which items a quote should itemize and which factors move the total up or down. No figures are given because none are supplied for this topic, so ask each provider to price these lines in writing.
| Cost component | One-time or recurring | What drives it and what to ask for in a quote |
|---|---|---|
| WAF tooling or licenses | Recurring if commercial, one-time setup if open source | Open-source options such as Coraza carry no license fee, but hosting, log storage and staff time still apply. Ask whether the quote includes the WAF software, its hosting and the rule set updates. |
| Engineering time to deploy and tune rules | One-time, with periodic tuning | Driven by the number of public-facing applications, their traffic and how many false positives the team must clear. Ask for the number of applications in scope and the tuning window included. |
| Script discovery and inventory | One-time, then recurring as scripts change | Driven by the number of payment page scripts and whether a tag manager loads them. Ask how the provider will find scripts loaded through tags, iframes and third-party code, and who signs off the inventory. |
| Written justification and authorization for each script | Recurring | Each script needs a stated business reason and an authorization record. Driven by script count and how often marketing or vendors change tags. Ask who writes and approves justifications. |
| Integrity assurance for scripts | One-time setup, recurring checks | Methods to confirm scripts have not changed depend on whether they are hosted by you or a third party. Ask which method is proposed for each script source. |
| Ongoing script review and change control | Recurring | Each third-party change, such as a new analytics tag, triggers review. Driven by how often vendors update code and how many teams can add tags. Ask for the review workflow and who is accountable. |
| Evidence upkeep | Recurring | Inventories, justifications, WAF logs and change records must stay current for assessor sampling. Ask what evidence is delivered and in what format. |
| External testing or independent review | Recurring, usually annual or after major change | Scope depends on how far the web application is tested beyond the WAF. Ask whether the provider's testing is independent of the team that configured the controls. |
| Assessor sampling | Recurring, at each validation | The assessor selects applications and scripts to test. Effort rises with the number of sampled items and gaps in the records. Confirm the validation level and sampling approach with your assessor before budgeting. |
Which open-source tools support the web defense evidence
Requirement 6.4 asks for two different kinds of evidence: an automated layer that watches web traffic, and a controlled list of every script that runs on a payment page. The tools below cover different parts of that job, and none of them covers the whole requirement on its own.
Coraza web application firewall
Coraza is an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP requests for attacks such as SQL injection, cross-site scripting and code injection, and it has integrations for Caddy, HAProxy, Traefik and Nginx. For 6.4.2, it can produce rule configuration and blocking logs that show an automated technical solution is in place. Confirm rule coverage, paranoia settings and blocking mode in your own environment, because a WAF in detection-only mode will not prevent attacks.
Ruleset tuning and false positive review
A WAF that blocks too little leaves 6.4.2 unmet, and one that blocks too much breaks checkout. Keep the OWASP Core Rule Set version pinned, record each exclusion with its reason and owner, and retest payment flows after every rule change. Assessors typically ask to see the configuration in force and the change history behind it, so store both under version control. Confirm with your assessor which evidence format they accept for rule changes.
Payment page script inventory
Requirement 6.4.3 needs an inventory of every script loaded in the consumer's browser on payment pages, with a written justification for each. A WAF does not produce this list because it inspects server traffic, not what a browser runs after the page loads. Build the inventory from a crawl of each payment page, reconcile it with your tag manager and approvals, and review it on a schedule. Confirm with your QSA whether 3DS scripts fall under 6.4.3 for your setup, since PCI SSC FAQ 1581 addresses that case.
Script integrity and authorization process
Requirement 6.4.3 also requires a method to confirm each script is authorized and a method to assure its integrity. Subresource Integrity hashes, a content security policy that limits script sources, and change approval for tag manager containers are common ways to meet these needs. None of these items is a single open-source product that satisfies the requirement, so the process must tie the inventory, the approvals and the browser controls together. Document who may add a script and how an unexpected change is detected and escalated.
OPNsense network-layer filtering
OPNsense is a BSD-2-Clause stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match to the live log view. It controls which network paths reach your web servers, which supports network security controls, but it does not inspect HTTP request content for application attacks. Treat it as a complement to an application-layer WAF, not a replacement, and confirm the exact rule logging retention your assessor expects.
Pipeline checks for web code changes
Requirement 6.4 protects the application in production, but the code that reaches production passes through a pipeline. GitLab Community Edition protected branches can block direct pushes and disable force pushes, and Semgrep Community Edition can scan repositories in CI/CD for insecure patterns in JavaScript, TypeScript, Python, Java and other languages. These checks support the secure development work in Requirement 6.2 more than the 6.4 runtime controls, so present them as supporting evidence. Confirm that your scan rules cover the injection and cross-site scripting patterns your application uses.
Who does what: your team, an implementation partner and the assessor
Your organization owns requirement 6.4 in full. The controls belong to you, and so do the decisions about how much risk you accept and which scripts may run on your payment pages. No partner or assessor can take those decisions on your behalf, and the assessor will ask who approved each one. Your team also keeps the controls working after the project ends, which is where most of the recurring effort sits.
- Control ownership: Name an accountable owner for the web application protection and for the payment page script process, and record that owner in your policies.
- Script authorization: Decide which scripts are authorized, document a written justification for each one, and approve changes before they reach the browser.
- Risk decisions: Choose the automated solution's rule set, its blocking mode and the exceptions you allow, and record who signed off on each.
- Operation: Review alerts, tune false positives, and confirm that the inventory matches what actually loads in the consumer's browser.
- Evidence retention: Keep logs, change records and review notes ready for the assessor throughout the year, not only at validation time.
Before engaging anyone, confirm that your team can name each owner and produce the inventory without outside help.
An implementation partner such as DeployOpen prepares and runs the technical side inside your environment. Work is typically scoped and agreed in writing before it starts. The partner deploys and tunes the self-hosted defense, builds tooling that helps you inventory payment page scripts, and assembles the evidence your assessor will request. The partner does not own the control, does not decide which scripts are authorized, and does not issue any report or attestation.
- Self-hosted defense: Deploy a web application firewall such as Coraza in front of the public-facing application, integrated with your existing reverse proxy or load balancer, and tune its rule set to the application.
- Inventory tooling: Build a process or tooling that lists the scripts loaded on each payment page and flags any change for review.
- Integrity and change controls: Configure the repository and pipeline controls that gate script and rule changes, such as protected branches in GitLab Community Edition.
- Evidence preparation: Collect configuration exports, logs, test results and change records into a form your assessor can sample.
- Handover: Document the configuration, runbooks and ownership so your team can operate the controls without the partner.
Ask the partner to state in writing which deliverables it produces and which decisions remain with your team.
A Qualified Security Assessor (QSA) or other assessor tests whether requirement 6.4 is in place and reports the result. For a Report on Compliance, the QSA examines your environment and issues the ROC. For a Self-Assessment Questionnaire, the attestation is completed on the official PCI SSC templates. Only the assessor can issue these documents. A certificate from any other party is not recognized as validation.
- Independent testing: The assessor samples scripts, rule configurations and logs, and checks that your evidence matches what runs in production.
- Reporting: The assessor issues the ROC or AOC and states whether each requirement is met.
- Independence limits: An assessor that designed or configured the controls it later tests has a conflict, so consulting work and assessment should be performed by different firms or separated within the assessor's rules.
- Scope confirmation: The assessor confirms which pages and scripts are in scope, so ask for that confirmation in writing before the work starts.
- Payment brand role: The PCI SSC sets the standard, while the payment brands decide which entities must validate.
Confirm with your acquirer or payment brand which validation type applies to you before you select an assessor.
Where organizations fall short on 6.4 and how to close each gap
Most requirement 6.4 findings are not missing tools. They are tools that run in the wrong mode, inventories that drift from the live page, and records that show a control existed on paper but was never checked. The cards below pair each gap with the fix an assessor will expect to see evidenced.
WAF running in detection mode only
A web application firewall that logs suspicious requests without blocking them does not continually prevent web-based attacks, which is what 6.4.2 asks for. Many teams deploy a WAF in monitoring mode during tuning and never move it to blocking. Check the enforcement setting on every rule set protecting payment pages, then keep dated evidence of the change to blocking mode and of the alerts it produces. Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can run in front of Nginx, HAProxy, Traefik or Caddy, so confirm which enforcement mode each deployed instance uses.
Scripts added outside the inventory
Tag managers, marketing pixels and chat widgets are often added by people outside engineering, so the script list never reflects what actually loads in the consumer's browser. Requirement 6.4.3 expects an inventory of every payment page script, so a single unlisted tag is a finding. Compare the inventory against a live capture of the checkout pages, and run that comparison on a schedule and after every tag manager change. Ask who is authorized to publish a tag and whether that approval is recorded.
Justifications that restate the script name
A justification such as "analytics script" or "Vendor X tag" describes what the script is, not why the business needs it on a payment page. Assessors look for a reason tied to a function of the payment page, and for an owner who accepted that reason. Rewrite each entry to name the business purpose, the data the script can access, and the team that approved it. Entries that cannot name a purpose are candidates for removal, not for a longer description.
No integrity method for third-party scripts
Authorizing a script confirms it should be there, but 6.4.3 also expects a method that assures its integrity, so a vendor file that changes silently remains a risk. Many teams have no subresource integrity values, no content security policy restricting sources, and no alert when a hosted file changes. Decide per script which integrity method applies, record the method in the inventory, and test it by altering a copy in a staging environment to confirm the page refuses or flags the change. Confirm with the vendor whether it publishes stable file hashes or versioned URLs before relying on either.
3DS scripts treated inconsistently
PCI SSC FAQ 1581 says merchants using a 3DS solution do not need to validate 6.4.3 for 3DS scripts, but a script added to the same page for another purpose remains in scope. Teams often exempt every script near the checkout flow or, in the opposite error, bring the 3DS provider's scripts into the full review. Document which scripts belong to the 3DS function, confirm that boundary with the assessor, and keep every other script under the standard controls.
No evidence of periodic review
An inventory that was accurate at audit time proves little if nobody reviewed it afterward. Assessors ask for dated reviews, the person who performed each one, and the changes they made or the reasons they made none. Set a recurring review with a named owner, tie it to change tickets for any tag or script update, and keep the review records alongside the inventory. Use the access and change logs from the WAF, tag manager and web server to show that the review matched what actually changed.
What buyers ask about PCI DSS 6.4 cost, time and effort
Does PCI DSS 6.4.1 still apply to my web applications?
No, not as the primary control. Requirement 6.4.2 became effective on 31 March 2025 and superseded 6.4.1, which is now reported as not applicable (PCI SSC FAQ 1593). Assessors will expect the automated technical solution described in 6.4.2 to be in place and operating. Confirm the current reporting treatment with your acquirer or the assessor who will validate your environment, because the answer depends on which SAQ or ROC template you complete. Effort for 6.4.2 is driven mainly by how many public-facing applications sit behind the solution and how much tuning they need to avoid blocking legitimate traffic.
How much extra effort does 6.4.3 add for a site with many third-party scripts?
The effort scales with the number of scripts, not with the number of pages. Requirement 6.4.3 requires a way to confirm each payment page script is authorized, a way to assure each script's integrity, and an inventory of all scripts with a written justification for each. It became mandatory on 31 March 2025. The recurring work is keeping that inventory current as tag managers, marketing teams and vendors add or change scripts. Ask whether your team has a documented approval step for new scripts, which is often the largest gap. Scripts used only for 3DS are handled differently under PCI SSC FAQ 1581, so separate them in your inventory before estimating.
Does a WAF alone satisfy PCI DSS requirement 6.4?
No. A web application firewall addresses 6.4.2, which asks for an automated technical solution that continually detects and prevents web-based attacks. Requirement 6.4.3 covers payment page scripts in the consumer's browser, which a server-side WAF cannot see or control. You need both: the WAF or equivalent for attacks on the application, and a script inventory, authorization method and integrity method for the payment page. Open-source options such as Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can cover the first part, but they need tuning and monitoring to be credible evidence.
Can our team meet 6.4 without an outside partner?
Often yes, if you have engineers who can run and tune a WAF and a governance owner who can maintain the script inventory. Your organization owns its controls, and it can do the work internally. Where teams usually need help is in building the evidence pack, testing rule sets against your own applications, and setting up script integrity monitoring in a way an assessor will accept. A partner can prepare systems and evidence, but only an independent QSA or assessor can validate compliance. Ask any provider to state in writing which tasks they perform and which remain yours.
What do engineering and marketing teams need to contribute to 6.4?
Engineering owns the WAF, its rules, logging, and the change process for applications. Marketing, digital and e-commerce teams own most of the scripts that end up on the payment page, from analytics and personalization tags to chat widgets. Both groups need a shared approval path: marketing requests a script, a named owner justifies it in writing, engineering confirms how its integrity is assured, and the inventory is updated before release. Without that path, the 6.4.3 inventory drifts within weeks of the first review. Agree on these roles before estimating effort.
What should we ask for in a fixed-scope quote for PCI DSS 6.4 work?
Ask for a written scope that lists each in-scope application and payment page, the systems and scripts covered, and the deliverables. A useful quote names the WAF or equivalent to be implemented, the rule set and tuning approach, the script inventory and its justification template, the integrity method, and the evidence pack handed to your assessor. It should also state what is one-time, such as deployment and inventory creation, and what recurs, such as rule updates, script reviews and log review. DeployOpen works from fixed-scope agreements with scope, deliverables and timelines agreed in writing before work starts, and does not publish a price list, so the quote follows from that scope.
What drives the total cost of PCI DSS 6.4 compliance work?
The main drivers are the number of public-facing applications, the number of payment page scripts and their owners, the complexity of your existing delivery pipeline, and whether you are on a hosted payment page or a more integrated checkout. Recurring costs include staff time for script reviews, rule maintenance and log review, plus any assessor fees, which your organization pays directly. Fees for the assessor and any licensed tooling depend on your own selections and quotes. Ask each provider to separate one-time setup from ongoing operations so you can compare options on the same basis.
How DeployOpen scopes, implements and prepares 6.4 evidence
DeployOpen plans and implements the public-facing web application protections that Requirement 6.4 expects, inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence; an independent QSA or the payment brands' validation process decides the outcome.
How we scope
- Engagements are fixed-scope, with the covered web applications, payment pages and scripts named in writing before work starts.
- We inventory internet-facing applications, their hosting paths and every script that loads in the consumer's browser on payment pages.
- The written scope states which 6.4.3 scripts fall under 3DS treatment and which must be justified individually.
How we build
- We deploy a self-hosted web application firewall such as Coraza, tuned with a ModSecurity-compatible ruleset and integrated with your existing reverse proxy.
- We configure payment page script controls, including an authorization method, an integrity check for each script and a maintained inventory.
- We test the protections against injection and cross-site scripting attacks and record the results before go-live.
How we hand over
- You receive configuration records, rule change logs, the script inventory with written justifications and test results mapped to 6.4.1 through 6.4.3.
- Runbooks explain how your team reviews blocked requests, approves new scripts and responds to integrity alerts.
- Deliverables are documented so your QSA or internal assessor can sample the evidence without relying on our staff.
How we support
- Ongoing support, rule and script maintenance and periodic re-testing are available as a retainer under a separate written agreement.
- Changes to payment pages or third-party scripts can be reviewed and added to the inventory as part of that support.
- Before any assessment, ask us to confirm which evidence your assessor needs, and check the final requirements with your acquirer or the PCI SSC documents.
