PCI DSS 4.0.1 control guide

PCI DSS Requirement 11.6.1 Change Detection

PCI DSS Requirement 11.6.1 addresses detecting unauthorised changes to payment pages and security-impacting HTTP headers as received by the consumer’s browser. The mechanism must operate at least weekly or at a frequency defined by targeted risk analysis.

PCI DSS Requirement 11.6.1: the short answer

DygDog establishes a per-tenant script baseline, compares later scans and records changes alongside CSP and SRI observations. Teams must schedule the required cadence and investigate alerts through their own response process.

What does PCI DSS Requirement 11.6.1 expect?

The control is aimed at changes that could undermine payment-page security, including script and header changes. It also expects alerting and a defined evaluation frequency. Always use the current PCI SSC standard and work with your assessor when defining exact scope.

How does scan-over-scan change detection work?

On the first successful run, DygDog stores a bounded baseline. Later runs compare aggregate and per-script fingerprints to identify added, removed or materially changed entries. The result includes enough context for a reviewer to reconcile the event with a deployment or vendor update.

How do you operationalise Requirement 11.6.1?

Schedule the Pro deep scan at the cadence your control requires, assign an alert owner, define expected-change evidence and document escalation criteria. Retain snapshots and remediation records. DygDog supplies external observations, not a complete policy or risk analysis.

What DygDog checks

01

Establish baseline

The first successful scan records the initial script inventory and control summaries.

02

Run on cadence

Scheduled scans support repeat evaluation; teams choose a compliant frequency.

03

Compare changes

Added, removed and changed entries are derived from sanitised fingerprints.

04

Review alerts

Findings distinguish drift from suspicious-pattern and control-gap signals.

05

Retain evidence

Timestamped tenant-scoped snapshots support later control review.

Coverage limits to understand

  • No historical change can be inferred before the first baseline.
  • The module is periodic, not a real-time browser sensor.
  • Your targeted risk analysis, alert workflow and assessor acceptance remain outside the scanner.

Frequently asked questions

Is weekly scanning required?

Requirement 11.6.1 specifies at least weekly or a frequency defined by targeted risk analysis. Confirm how that applies to your environment with your assessor.

Does every script change indicate an attack?

No. Releases and vendor updates create legitimate drift. Each unexplained change should be reconciled and investigated.

Does DygDog analyse security headers too?

The module records and evaluates Content-Security-Policy details relevant to script execution. Other DygDog modules assess additional HTTP security headers.

See what changed on your payment page

Get an external script inventory now. Pro scans add PCI-mapped evidence and scan-over-scan change detection.

Run your first scan