PCI DSS 4.0.1 payment page requirements for midmarket and enterprise teams
PCI DSS 4.0.1 payment page requirements ask your team to manage the scripts that run in your customers’ browsers and detect unauthorized changes to the payment experience. Requirement 6.4.3 covers script authorization, integrity, inventory, and written justification. Requirement 11.6.1 covers change and tamper detection for payment-page content and security-impacting HTTP headers received by the browser.
The practical work is deciding what should run, confirming that the controls operate, and assigning someone to act when something changes. A lean midmarket team and a global enterprise can meet those responsibilities through different operating models.
What do Requirements 6.4.3 and 11.6.1 cover
The requirements address related parts of payment-page security. Script management establishes what is authorized and how integrity is assured. Change detection identifies unauthorized modifications to what the customer’s browser receives.
| Requirement | What your team must address | Useful supporting evidence |
|---|---|---|
| 6.4.3 | Authorize payment-page scripts, assure integrity, and maintain an inventory with written justification for each script. | Script inventory, authorization records, business or technical justifications, and evidence that the integrity method works. |
| 11.6.1 | Detect unauthorized changes to browser-received payment-page content and security-impacting HTTP headers, and alert personnel. | Monitoring scope, run history, sample alerts, and investigation records. |
PCI SSC’s payment-page security guidance explains how these controls relate to eSkimming risk. Your payment environment and validation path determine which requirements and evidence apply.
What your team needs to manage under Requirement 6.4.3
Requirement 6.4.3 applies to all payment-page scripts loaded and executed in the consumer’s browser. Your process needs to cover four elements:
- Authorization: Confirm that each script is approved.
- Integrity: Implement a method to assure each script’s integrity.
- Inventory: Maintain a record of all payment-page scripts.
- Justification: Document the business or technical reason each script is necessary.
Build that inventory around what actually executes in the browser. Include first-party scripts, third-party services, and scripts loaded indirectly through tag managers or other scripts. A repository review or approved-vendor list may miss downstream code.
Connect each script to an accountable owner. Security can operate the control, while ecommerce, marketing, or application teams explain the script’s purpose. GRC or compliance can coordinate the evidence expected for assessment.
An example of a useful script record
Consider a script that displays delivery estimates during checkout. An illustrative record could include:
| Field | Example entry |
|---|---|
| Script and location | Delivery-estimate script on the checkout page |
| Business owner | Ecommerce application owner |
| Written justification | Displays delivery dates before the customer submits an order |
| Authorization | Approval linked to the relevant change request |
| Integrity evidence | Reference to the implemented integrity method and its validation results |
The record gives your team a starting point for review. You still need to verify the script’s actual behavior and demonstrate that the integrity method works in your environment. If the script changes or loads another dependency, review the affected records and controls.
What your team needs to detect under Requirement 11.6.1
Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modifications to payment-page content and security-impacting HTTP headers as received by the consumer’s browser. That includes unauthorized additions or deletions and indicators of compromise.
The mechanism must evaluate the received headers and payment page at least once every seven days, or at the frequency defined by a targeted risk analysis meeting Requirement 12.3.1. The current standard and supporting documents are available in the PCI SSC Document Library.
Make alert handling part of the operating process. Identify who receives notifications, who investigates, and how the team records the outcome. Test that an alert reaches the responsible team and provides enough detail to investigate.
For example, if a script appears after a tag-manager update, your team should be able to determine whether the change was authorized, reconcile it with the inventory, and investigate unexpected behavior. Retain the monitoring and response records alongside the relevant approval evidence.
How midmarket and enterprise teams can organize the work
Company size changes the coordination required to operate the controls. Your payment environment and applicable validation requirements remain the starting point.
For midmarket teams
Start with one payment journey to establish the process, then extend it across all applicable payment pages. Map where payment information is collected and which surrounding pages can affect that journey. Identify the scripts that execute there and assign owners for their authorization and justification.
Keep the handoffs explicit. The application or ecommerce owner can explain the script’s purpose, security can validate the control and investigate alerts, and compliance can coordinate assessment evidence. One person may fill several roles, but the responsibilities should still be clear.
Use automation to keep inventory and monitoring records current as scripts change. Confirm that someone owns exceptions and failed checks so the process continues between assessments.
For enterprise teams
Standardize the process across brands, domains, business units, and regional teams. Define a common method for determining scope, recording approvals, routing alerts, and retaining evidence.
Central security and compliance teams need a consistent view of coverage and unresolved issues. Local application owners need enough context to approve scripts and investigate changes. Include new sites, payment integrations, and release processes in that model so coverage expands with the business.
How hosted payments and iframes affect your responsibilities
A hosted payment form does not automatically protect the merchant-controlled page around it. An iframe embeds the provider’s payment component within your page, where other scripts may still influence what the customer sees or does.
Source Defense research documented an attack that hid a legitimate Stripe iframe and displayed a counterfeit payment form. The attacker targeted the merchant’s browser-side experience rather than Stripe’s payment infrastructure.
The validation distinction matters. The January 2025 SAQ A revision removed 6.4.3 and 11.6.1 from that questionnaire and added a script-attack eligibility criterion. Those requirements remain in PCI DSS.
PCI SSC FAQ 1588 guidance explains that merchants with embedded third-party payment forms can address the criterion using protective techniques such as those described in 6.4.3 and 11.6.1, or confirmation from their compliant payment provider that its solution includes script-attack protection when implemented as instructed.
That specific criterion excludes redirect-only and fully outsourced payment-link flows. Confirm your SAQ eligibility and responsibilities with your acquirer, payment brand, or other compliance-accepting entity.
How runtime protection fits alongside PCI evidence
Your team also needs to consider what happens while a customer is entering information. A compromised script may read form fields, manipulate the page, or transmit data before someone investigates an alert.
Runtime controls govern what scripts can do during execution, including their access to sensitive data and page elements. Evaluate those capabilities separately from the change-detection obligation in 11.6.1. They complement the work of maintaining scope, approvals, integrity controls, and evidence.
Source Defense supports payment-page script inventory, authorization and justification workflows, payment-data access monitoring, tamper and security-header change alerts, and PCI evidence. Runtime enforcement depends on the selected solution, plan, and configuration. The current capabilities and plans describe those distinctions. Your organization remains responsible for operating its controls and validating compliance.
Where your team can start
Use one payment journey to check whether the process works from end to end. Can you identify the scripts that execute, explain why each is necessary, show how integrity is assured, and trace a change alert to an investigation?
Address the first missing answer. It may require an inventory update, a named owner, a control adjustment, or a clearer response process. Then apply the process across the full scope of your payment environment.
Frequently asked questions
What is the difference between Requirements 6.4.3 and 11.6.1
Requirement 6.4.3 covers payment-page script authorization, integrity, inventory, and written justification. Requirement 11.6.1 covers detection and alerting for unauthorized modifications to payment-page content and security-impacting HTTP headers received by the consumer’s browser.
Does using an iframe remove your payment-page security responsibilities
No. The surrounding merchant page can still affect the payment experience. Your responsibilities depend on the implementation and validation path. For SAQ A embedded-form scenarios, PCI SSC describes a specific script-attack eligibility criterion and ways to address it.
Did the SAQ A changes remove 6.4.3 and 11.6.1 from PCI DSS
No. The January 2025 revision removed those requirements from SAQ A, not from PCI DSS. SAQ A also added a script-attack eligibility criterion that applies to embedded payment-form scenarios. Confirm the appropriate validation route with your compliance-accepting entity.
What evidence should your team maintain
Maintain records showing the scripts in scope, their authorization and justification, and how integrity is assured. For change detection, retain coverage and run history, sample alerts, and investigation records. Agree on the evidence and retention expectations with your assessor or compliance authority.
Does meeting the requirements guarantee protection against eSkimming
No. The security outcome depends on scope, implementation, and operation of the controls. Evaluate how your environment handles unauthorized script activity during a live customer session, including what can be restricted before sensitive data is exposed.
Check your payment-page evidence
Choose one payment journey and compare your script records, integrity controls, and tamper alerts with the evidence an assessor may request. Source Defense’s practical validation checklist can help you identify the next step for your team.
