What should PCI DSS script monitoring check?
A useful control must do more than count scripts. It should show where each script came from, whether an external script carries valid integrity metadata, what the page Content Security Policy permits and what changed since the prior review.
- Script source and first- or third-party ownership
- Integrity and crossorigin attributes for eligible external scripts
- Effective script-src policy and broad source allowances
- Added, removed and materially changed scripts
- Timestamped evidence suitable for operational review
How DygDog supports Requirements 6.4.3 and 11.6.1
Requirement 6.4.3 addresses authorisation, justification, inventory and integrity assurance for payment-page scripts. Requirement 11.6.1 addresses detecting unauthorised changes to payment pages and security-impacting HTTP headers. DygDog supplies technical observations and change evidence; your organisation must still approve scripts, document business justification, investigate alerts and agree scope with its assessor.
Who is this monitor for?
It is designed for e-commerce operators, payment-page owners, agencies and security teams that need an external check without installing browser code. The Pro module is especially useful as an independent control alongside deployment records, vendor governance and any browser-side monitoring already in place.
What DygDog checks
Script inventory
Captures bounded, sanitised metadata for up to 500 script elements.
Third-party origins
Separates scripts delivered from the scanned host from external origins.
SRI presence
Flags eligible external scripts with missing or malformed integrity metadata.
CSP coverage
Evaluates the returned Content-Security-Policy for script restrictions and broad allowances.
Payment-page signals
Classifies likely checkout or payment pages from visible HTML and URL signals.
Risk patterns
Reports conservative indicators such as encoded payloads or payment-field access as signals, not proof.
Baseline drift
Compares the current fingerprint and script set with the latest successful tenant-scoped baseline.
Coverage limits to understand
- The scanner analyses fetched HTML and response headers; it does not execute JavaScript.
- A first scan establishes a baseline, so prior drift cannot be reported.
- Technical evidence does not replace business justification, incident response, a targeted risk analysis or QSA judgement.
Frequently asked questions
Does DygDog make a site PCI DSS compliant?
No. DygDog provides external technical observations and evidence that can support Requirements 6.4.3 and 11.6.1. Compliance depends on your full environment, processes and assessor judgement.
How often should payment pages be checked?
PCI DSS Requirement 11.6.1 calls for evaluation at least weekly or at a frequency defined by the entity’s targeted risk analysis. Confirm the applicable cadence with your assessor.
What happens on the first scan?
DygDog stores the first bounded script inventory as the baseline. Change findings become available when a later successful scan can be compared with it.