6.4.3 / INVENTORY
Identify every observed payment-page script
Maintain a current browser-observed register across configured payment pages, including resources loaded indirectly through third-party providers.
PCI DSS 4.0.1 • REQUIREMENTS 6.4.3 AND 11.6.1
Know which scripts reach checkout—and keep the evidence ready for review.
Maintain an authorization record for payment-page scripts, detect unexpected changes as customers receive them, and keep requirement-linked evidence ready for internal review and assessment preparation.
THE PAYMENT-PAGE CONTROL RECORD
Build the evidence trail behind 6.4.3 and 11.6.1.
The work begins with four specific questions: what executes, who authorized it, what changed, and how the team responded. Each answer should remain attached to the relevant payment-page resource and requirement.
6.4.3 / DECISION
Record authorization and justification
Approve or block a script, document why it is necessary, and keep the current authorization, reviewer, and decision context alongside the resource.
11.6.1 / INTEGRITY
Detect unexpected changes
Monitor configured payment pages and tracked HTTP headers for changes that require investigation, using browser telemetry and integrity context.
11.6.1 / RESPONSE
Investigate and document follow-up
Review a finding through issues, sessions, configured alerts, and scheduled-audit records while keeping its technical context and latest disposition available.
6.4.3 • PAYMENT-PAGE SCRIPT REGISTER
Keep authorization tied to the script customers actually receive.
Checkout code can arrive through tag managers, payment services, fraud tools, analytics, and dependencies loaded several steps downstream. A browser-observed register reveals the execution chain captured during monitored payment-page activity instead of relying only on deployment records.
CHECKOUT-SPECIFIC ENFORCEMENT
Keep unreviewed payment-page code from inheriting broad access.
Authorization answers whether a script may be present. Policy answers what that script may do. Use the approved checkout purpose to define deliberate destinations and browser capabilities for each provider or resource.
Zero-trust for new resources
Require newly discovered resources to be reviewed before they are trusted in an enforcement workflow.
Provider and resource overrides
Inherit a global baseline or narrow policy for a specific provider or individual resource.
Network and browser controls
Define allowed destinations, regions, storage access, DOM access, network APIs, device capabilities, and other supported permissions.
11.6.1 • CHANGE DETECTION AND RESPONSE
Turn observed payment-page changes into accountable decisions.
When a script, security-impacting header, destination, or observed behavior changes, reviewers need to distinguish an approved release from an unauthorized modification. Keep the finding, affected sessions, technical context, and latest disposition available together.
Scheduled audit runs
Run payment-page audits at the cadence available for the selected plan and retain the resulting history.
Context-rich findings
Connect a finding to its resource, provider, observed behavior, affected sessions, and prior review state.
Configurable notification routes
Send enabled event notifications into the channels your security and operations teams already monitor.
PCI DSS EVIDENCE WORKFLOW
Give assessors a requirement-ready record, not a reconstruction project.
Package requirement status, script authorization and justification, integrity findings, investigation actions, and monitoring context into a portable record that explains how the payment-page controls operated.
Requirement-oriented evidence
Keep actions, findings, and technical evidence associated with the browser-side requirement they support.
Traceable review context
Keep timestamps, the current reviewer decision, findings, audit records, and related technical context available for follow-up.
Exportable report package
Generate a PCI DSS browser-security evidence report for review with compliance stakeholders and assessors.
THE ASSESSMENT TRAIL
Follow one payment-page script from discovery to assessor review.
The workflow is deliberately requirement-specific: define the payment-page scope, inventory the delivered scripts, authorize each one, investigate changes, and export the resulting evidence.
| Stage | Operation | Reviewable record | Supports |
|---|---|---|---|
| Scope | Configure the payment-page URLs and HTTP headers that SiteWall should monitor. | Defined monitoring context | 6.4.3 / 11.6.1 |
| Discover | Observe scripts, providers, dependencies, destinations, and capabilities in the delivered browser experience. | Current script register | 6.4.3 |
| Authorize | Review necessity, record business justification, and set the resource approval state. | Current authorization record | 6.4.3 |
| Detect and respond | Review integrity or behavior changes through audits, issues, session context, and configured alerts. | Finding and latest disposition | 11.6.1 |
| Report | Assemble supported requirement status, evidence, actions, and monitoring context for review. | Browser-security evidence report | 6.4.3 / 11.6.1 |
ADDITIONAL SUPPORTING EVIDENCE
Browser evidence can support more of the PCI DSS conversation.
Beyond its focused support for Requirements 6.4.3 and 11.6.1, SiteWall provides browser-side evidence relevant to additional PCI DSS areas for use within the broader program.
01
Requirements 4.2.1 and 6.4.2
Browser-request destinations, available transport context, resource controls, and network policies can provide supporting evidence for secure transmission and public-facing application protection reviews.
02
Requirements 6.2.4 and 12.8
Runtime findings, integrity observations, provider inventory, dependencies, and available provider incident context can support secure-development and third-party review activities.
03
Requirement 12.10
Issues, alerts, affected sessions, current decisions, latest dispositions, and scheduled-audit records can contribute browser-side evidence to incident-response reviews.
Explore the connected workflows.
Go deeper into the controls, evidence, and related use cases behind this workflow.
- Granular browser policy enforcement
Review resource, provider, capability, and network controls for supported browser activity.
- Compliance reporting and evidence
See how browser observations and control records support assessment preparation.
- Payment-page and digital-skimming protection
Connect checkout script behavior and destinations to a focused investigation.
- Explore browser security capabilities
See how browser discovery, investigation, policy control, and supporting evidence work together.
PCI DSS PAYMENT-PAGE FAQ
Specific answers for payment-page control owners.
Answers for security, compliance, and engineering teams evaluating SiteWall for browser-side PCI DSS work.
Which part of PCI DSS does SiteWall support?
SiteWall focuses on browser-side payment-page script governance and change detection relevant to PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1.
How SiteWall helps:It provides discovery, policy, investigation, audit, alerting, and evidence workflows for that client-side scope.
How does SiteWall support PCI DSS Requirement 6.4.3?
Requirement 6.4.3 addresses managing payment-page scripts, including authorization, integrity, and an inventory with written justification.
How SiteWall helps:SiteWall creates a browser-observed script register and keeps resource context, current approval state, business justification, reviewer, and authorization timestamp together.
How does SiteWall support PCI DSS Requirement 11.6.1?
Requirement 11.6.1 addresses detecting unauthorized changes to payment pages and related security-impacting HTTP headers as received by the consumer browser.
How SiteWall helps:SiteWall monitors configured pages and headers, surfaces relevant change findings, and retains investigation and response context.
Can SiteWall find scripts loaded indirectly by another provider?
Yes. A payment service, tag manager, analytics tool, or fraud provider may introduce additional resources at runtime.
How SiteWall helps:The load flow connects initiating providers to the resources, destinations, and browser capabilities observed downstream.
Does SiteWall send PCI DSS alerts?
SiteWall provides configurable notification routes for enabled event types; notifications can be delivered through supported email and collaboration integrations.
How SiteWall helps:Teams can route relevant findings into their existing response channels, while the underlying issue and session context remains available in SiteWall.
Does SiteWall automatically apply permissions based on observed use?
No. Observed behavior provides evidence that reviewers can use when configuring permissions; it does not create or apply a proposed production policy automatically.
How SiteWall helps:Reviewers deliberately configure global, provider, or resource-level network and browser permissions based on the evidence they observe.
How do SiteWall audits work for payment pages?
SiteWall runs configured payment-page checks at the cadence available for the selected plan and records the resulting audit observations and findings.
How SiteWall helps:Audit records help teams compare current observations with expected controls and support documented follow-up in the organization's review process.
Can an assessor use a SiteWall report?
A SiteWall export can provide browser-side technical records for internal review and assessment preparation, but the assessor decides whether evidence is sufficient for the organization's implementation and scope.
How SiteWall helps:The report organizes supported requirement status, script records, findings, actions, and monitoring context into a portable package.
MAKE EVERY CHECKOUT SCRIPT EXPLAINABLE
Build a payment-page record your team can defend.
Inventory what executes, document why it is authorized, detect unexpected changes, and retain evidence tied directly to Requirements 6.4.3 and 11.6.1.
