And why point-in-time scans no longer pass scrutiny
PCI DSS 4.0 did not introduce client-side security by accident.
Requirement 11.6.1 exists because real-world breaches kept happening after organizations “passed” compliance.
This blog breaks down what auditors are really looking for under 11.6.1 — and where most teams get it wrong.
What PCI DSS 4.0 11.6.1 Actually Says (In Plain English)
Requirement 11.6.1 requires organizations to:
Detect and alert on unauthorized modifications to payment page scripts and content.
Key implications:
- This is about runtime behavior, not static configuration
- Detection must be continuous
- Alerts must be actionable
- Controls must work in production
A quarterly scan or manual review does not meet the intent.
Why This Requirement Exists
PCI councils didn’t invent 11.6.1 theoretically — it is a direct response to:
- Magecart-style skimming attacks
- Third-party script compromise
- Silent client-side injection
- Long-dwell browser-based breaches
In many cases:
- Backend systems were never breached
- WAFs never triggered
- Tokens and card data were stolen directly from the browser
11.6.1 exists to close that gap.
What Auditors Are Not Looking For
Many organizations fail audits because they focus on the wrong evidence.
❌ Not sufficient
- “We use a hosted payment page”
- “We have a CSP header”
- “We scan quarterly”
- “We reviewed scripts last month”
- “Our vendor is PCI compliant”
These are supporting controls, not detection mechanisms.
What Auditors Are Looking For
Auditors evaluate 11.6.1 across four dimensions:
1. Continuous Detection (Not Snapshots)
Auditors expect:
- Monitoring that runs continuously
- Detection of changes between scans
- Coverage during real user traffic
If your control only runs periodically, expect follow-up questions.
2. Script Integrity Awareness
Auditors want to know:
- What scripts run on payment pages
- Where they originate
- When they change
- Whether changes are authorized
“Trusted” third-party scripts are still in scope.
3. Alerting and Response
Detection without alerting is not compliance.
Auditors expect:
- Alerts when unauthorized changes occur
- Defined response procedures
- Evidence of investigation or triage
If alerts are noisy or ignored, controls are considered ineffective.
4. Production Coverage
Controls must operate:
- On live payment pages
- In real browsers
- Against real execution paths
Pre-prod, test-only, or CI/CD-only controls do not satisfy intent.
The Most Common Audit Failures Under 11.6.1
Organizations most often fail due to:
- Relying solely on CSP without monitoring
- Using point-in-time scanners
- No visibility into third-party script behavior
- No alerting or response workflow
- Assuming hosted payments eliminate responsibility
Auditors increasingly push back on assumptions.
Why Hosted Payments Do Not Remove 11.6.1 Scope
A critical misunderstanding:
“We redirect users to a hosted payment page, so client-side risk is gone.”
Reality:
- Your page still loads scripts
- Your page still handles redirects
- Your page still executes JavaScript
- Attackers can still manipulate the flow before redirection
Auditors treat the entire user journey as relevant.
How BreachFin Aligns With 11.6.1 Intent
BreachFin was designed around the actual language and real-world intent of PCI DSS 4.0.
BreachFin provides:
- Continuous monitoring of client-side execution
- Detection of unauthorized script and DOM changes
- Visibility into third-party script behavior
- Actionable alerts aligned with audit expectations
This allows organizations to demonstrate:
- Ongoing detection
- Operational response
- Production-grade coverage
Not just documentation.
Evidence Auditors Respond Well To
When auditors ask for proof, strong evidence includes:
- Records of detected script changes
- Alert logs with timestamps
- Investigation workflows
- Change authorization records
- Clear mapping to 11.6.1 language
BreachFin simplifies evidence collection by design.
Final Takeaway
PCI DSS 4.0 11.6.1 is not about checking a box.
It is about detecting reality.
Auditors are no longer satisfied with:
- Periodic scans
- Static controls
- Assumed trust
They expect continuous, production-grade visibility into what executes in the browser.
If you cannot see runtime client-side behavior,
you cannot meet the intent of 11.6.1 — regardless of how many tools you deploy.
That is the gap BreachFin is built to close.
