Reflectiz PCI DSS Module: Independent QSA Assessment by Integrity360

Requirement 11.6.1 requires tamper detection for HTTP headers and payment-page content as received by the consumer’s browser, at least every seven days. The platform monitors response headers each scan cycle, comparing them against an approved baseline and flagging any addition, deletion, or modification, including changes to Content-Security-Policy, Strict-Transport-Security, and X-Frame-Options. Because it observes headers as the browser receives them, it catches changes introduced by intermediate layers like CDNs or load balancers that server-side monitoring would miss. It runs more frequently than the seven-day minimum by default, is configurable per page to align with Requirement 12.3.1 targeted risk analysis, and integrates with Splunk, Jira, and any SIEM or SOAR supporting a JSON REST API.

Requirement 6.4.3 has three obligations: maintain a script inventory with written justification, authorize each script, and assure each script’s integrity. The platform auto-builds a per-page inventory covering first-, third-, and fourth-party scripts, including those loaded dynamically by tag managers. It authorizes scripts through a structured approval workflow that stores a business justification against each script and page, timestamped and attributed to the approver. For integrity, its behavioral engine detects changes to what a script does at runtime, not just its file hash, so it catches a silent vendor-side replacement even when the new file’s hash looks legitimate. Smart Approval and Bulk Approval reduce repetitive review by auto-processing scripts that match approved behavioral baselines.

It runs a continuous four-phase cycle. First, an agentless browser crawls designated payment pages, simulating real checkout and authentication flows, and maps every script, iframe, pixel, cookie, and HTTP header. Second, it performs deep behavioral analysis, recording JavaScript execution, DOM interactions, form-field access, network requests, and data transmission to answer what each component is, what it does, and where it sends data. Third, it cross-references behavior against reputation databases, vulnerability registries, and Reflectiz intelligence to assign an exposure rating. Fourth, it alerts on new scripts, behavioral changes, and header modifications, retains timestamped approvals, and exports QSA-ready evidence in one click.

No. The exercise was a capability review of the Reflectiz PCI DSS Platform, not a PCI DSS compliance determination for any specific customer environment. The assessment confirms the platform can be effective in supporting Requirements 6.4.3 and 11.6.1 when properly deployed, configured, and integrated into a wider governance, risk, and compliance program. Actual compliance, SAQ eligibility, and any assessment outcome always depend on your own environment, payment flow, implementation, and confirmation from the relevant compliance-accepting entity.

Integrity360 Europe, a PCI Qualified Security Assessor Company and member of the PCI SSC Global Executive Assessor Roundtable (GEAR), assessed the platform against PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1. Its finding: the platform provides automated, continuous monitoring of payment-page scripts and HTTP headers that can be effective in supporting compliance with both requirements when correctly deployed and integrated into an organization’s GRC program. Integrity360 Europe also noted that correct use of the platform may help merchants meet the SAQ A eligibility criteria confirming a site is not susceptible to script attacks.

Merchants who outsource payment processing may skip 6.4.3 and 11.6.1 from SAQ A only if they confirm their site is not susceptible to script attacks. The assessment notes that PCI SSC FAQ #1588 states one way to confirm this is by using techniques such as those detailed in Requirements 6.4.3 and 11.6.1. Integrity360 Europe’s opinion is that correct implementation of the Reflectiz PCI DSS Platform may help merchants meet that SAQ A eligibility criterion. This matters for iframe merchants, since a script on the parent page can still target account data before it reaches the secure frame.

Because eSkimming attacks usually arrive through a script you already approved. Attackers compromise a third-party vendor, and the malicious payload loads via a legitimate script you have run for months. The change is in the script’s behavior, not its presence. A hash check confirms a file matches a known value, but it cannot tell you a vendor-side swap is malicious once the new hash becomes the baseline. The platform observes runtime behavior, so a script that begins reading card-data form fields or exfiltrating to an unfamiliar domain triggers an alert regardless of how the change was introduced.