If your latest PCI DSS audit report flagged gaps against Requirements 6.4.3 and 11.6.1, it’s not time to panic yet. These findings are common and entirely fixable.
Most of the time, the gap is between static guardrails and continuous runtime governance. QSAs assess whether you have active control over what executes in the client browser, not simply whether guardrails are configured.
That is also why traditional controls like CSP or manual reviews can feel complete and still fall short. Because they can limit where scripts can load from, but on their own, they can’t govern drift or prove integrity over time as your tag managers update, vendors push changes, and dependencies shift with time.
In this article, we discuss the remediation steps that close such gaps and how you can produce evidence that stands up in a re-audit.
Understanding your PCI audit findings
A report of compliance needs to be unambiguous by design. So QSAs record the assessment result by requirement, and then capture the supporting detail that explains what they could and couldn’t validate in the environment.
That supporting detail usually lands in two forms. Sometimes it’s a specific gap, which reads as a clear pass or fail point tied to a particular element of the requirement. Other times it’s an observation, which doesn’t necessarily change the assessment result, but gives qualitative context on how the control is operating and where it may struggle as conditions change.
Objective deficiencies for 6.4.3 and 11.6.1
For 6.4.3, it means the existing controls fail to prove that every script on a payment page is authorized, verified for integrity, or documented with a clear business or technical justification.
So the common specific gaps tend to look like this:
- Inventory gaps: They happen when scripts executed in the consumer browser don’t reflect in the inventory, or the inventory exists but lacks justification. In practice, we’ve seen QSAs fail Requirement 6.4.3 even when a script inventory existed, because it reflected what engineering believed was deployed, not what actually executed at runtime. One team had a clean spreadsheet inventory but still failed because a tag manager injected a marketing pixel after page load.
- Authorization gaps: They occur when a script is present on the payment page without a presentable approval trail. The QSA does not need a story. They need evidence.
- Integrity gaps: QSAs expect you to be able to prove that the scripts running on the payment page behave the way you intend them to, and that you have a way to detect if the behaviour drifts.
For 11.6.1, the gaps are usually about whether monitoring is continuous, correctly scoped, and operationally evidenced. PCI DSS explicitly states the need for a detection mechanism that must monitor unauthorized changes in script content or in the security-impacting HTTP headers of payment pages, and alert concerned personnel.
That’s why gaps are often discovered around three specific areas:
- Incomplete scoping: Monitoring often focuses on page content (scripts) but overlooks security-impacting HTTP headers.
- Baseline deviations: While the system may detect changes, there is often no logged history of version comparisons or known good baselines.
- Broken response loops: Gaps frequently appear in the alerting phase when either the system fails to notify personnel of a change or when there is no retained triage history to prove an intervention.
The difference between not implemented and insufficient evidence findings
An insufficient evidence finding is different. It usually means the mechanism exists, but the QSA can’t decisively conclude it operates continuously, covers the full scope, or produces expected results every time it runs.
For example, the inventory may exist, but it may be incomplete at runtime or not outdated. Approval may exist, but be informal, scattered, or difficult to tie back to specific scripts. The environment could be monitored, but without time-stamped logs, baseline comparisons, or alert records. That’s insufficient evidence.
But when QSAs flag issues like missing business justification for a script, authorization workflow, or integrity verification methods that monitor how and what scripts load at runtime, that’s a missed implementation. In that case, remediation is largely about implementation. You need to add or rebuild certain mechanisms.
Common findings and their interpretation for 6.4.3 and 11.6.1
QSAs tend to flag certain findings for 6.4.3 and 11.6.1 with specific phrases. Let’s understand what these correspond to and what would help the assessors validate them next time.
| Requirement | Typical finding | What the QSA actually needs |
| 6.4.3 | Script inventory incomplete | Complete first-party and third-party script discovery for what executes on the payment page, with authorization records tied to each script |
| 6.4.3 | No continuous monitoring evidence | Time-sequenced logs that show ongoing script monitoring, change detection, and retained results you can produce for a defined period |
| 11.6.1 | Change detection not documented | Evidence the detection mechanism is running on in-scope payment pages and generating alerts when scripts or security-impacting headers change |
| 11.6.1 | No response records | Documentation that shows how detected changes were reviewed, remediated, and closed, including who reviewed and what decision was made |
Your 90-Day Remediation Timeline
Once you’ve received a failed PCI DSS audit report, the best move is to understand the findings and fix the underlying issue behind the gaps. But to do that, you have to run the controls long enough to generate defensible evidence, then validate and package everything for reassessment.
Plugging the gaps around continuous monitoring requirements requires operational history, so you can’t just remediate and re-audit immediately. But since your acquiring banks typically allow 90-180 days for remediation, there isn’t a need to rush; your focus has to be on setting up defensible controls and packaging evidence records that hold up under reassessment.
Here’s a timeline to do that:
Days 1 to 30: Address immediate gaps
Identify the gaps mentioned in your audit report and discern if they arise due to insufficient evidence or absent controls. And if a control element is not implemented, you implement it now.
For Requirement 6.4.3, that usually means establishing a method to confirm each payment page script is authorized, a method to ensure script integrity, and a complete inventory that reflects what actually executes in the customer’s browser.
Ensure that for every script you discover, you document authorization workflows and business justification in a way you can present and defend during an audit. This includes the re-authorization workflows once the drift is detected or any updates are pushed.
The gaps mapped to Requirement 11.6.1, if any, in your report are mentioned; they’re generally due to absent or insufficient change detection and alerting mechanisms. So ensure your mechanisms evaluate both script contents and security-impacting HTTP headers as received by the consumer browser, and that they alert personnel about any drifts.
The default expectation is that this runs at least weekly unless you have a targeted risk analysis that defines a different frequency.
Days 31-60: Build evidence package
By day 30, your controls should be in place, and you can start to collect evidence to present to a QSA. Document scripts, the list of monitored pages, and time-stamped outputs such as logs or reports.
For 11.6.1, you validate that your evidence proves any changes to script content and security-impacting headers are actually detected and that personnel are alerted. Once done, start packaging:
- Documentation describing the detection scope.
- Evidence that proves the mechanism evaluates both headers and scripts and compares current versions to prior known versions to detect deviations. This includes a time-stamped monitoring report showing baseline vs current values for key HTTP headers and script content hashes.
- A documented triage trail so the response is evidenced. That means each detection event has a timestamp, an owner, and a recorded disposition showing what action was taken.
You do the same for 6.4.3, so the inventory, justification, and authorization artifacts stay tied to what actually executes in the consumer browser.
Days 61-90: Validation and re-audit prep
Once your evidence is in place, the last step is to triage it and plug any gaps before the real audit.
Start with an internal self-assessment that mirrors the QSA’s original findings language. Here, you’re not trying to re-litigate the assessment, just double-check that each stated gap is now closed with evidence that maps cleanly to the requirement and survives basic scrutiny.
From there, verify completeness across the scope. Make sure every in-scope payment page has the same evidence trail, not just the one you used as an example. Check that inventories reflect scripts that load at runtime, approvals are retrievable, integrity is triaged at set frequency, and that monitoring results include the timestamps, alerts, and reports reflecting continuous operation.
Then package the material the way a QSA consumes it. Organize documentation around each finding and requirement so the assessor can retest efficiently without chasing context across tools, tickets, and shared drives.
Once you’re confident about the evidence package, schedule the reassessment ensure stakeholders understand the updated authorization flow, the monitoring expectations, and the detection responsibilities.
How PaymentGuard AI accelerates remediation
The failed findings compliance for Requirements 6.4.3 and 11.6.1 follow a recurrent pattern where the script inventory drifts away from what actually runs on the payment page, approvals occur but aren’t provable at the script level, and drift gets monitored, but without a clean, time-sequenced record that ties detection to alerting and response.
PaymentGuard AI is designed to close those gaps by keeping runtime discovery, authorization, integrity verification, change detection, and audit reporting bound together as one operating loop. It does that across payment pages and embedded payment iFrames, which is where the scope gets messy in implementation.
Let’s zoom in on how it keeps your payment pages compliant with Requirements 6.4.3 and 11.6.1:
A live inventory from day one
You can have a script inventory, a review process, and a monitoring tool, and still fail Requirement 6.4.3 if those pieces do not stay tied to what actually gets executed on the payment page in the client browser.
PaymentGuard AI automatically discovers scripts on payment pages and embedded iFrames and builds a live inventory so the evidence reflects what was executed, not what someone remembered to documen
Authorization workflows are enforced for every script
Scattered approvals across tickets, emails, and documents are the most common failure points. PaymentGuard AI supports script inventory and authorization reporting, including approval history and justifications, so the approval trail stays retrievable at audit time.
Integrity verification gets proved effortlessly
QSAs look for a demonstrable method to verify integrity. PaymentGuard AI covers integrity verification, drift monitoring, and alerting as part of a unified automated workflow, which helps teams prove how integrity is being assured and how drift would be detected.
Change and tamper detection that matches the control intent
11.6.1 is about detecting unauthorized modifications on payment pages as received by the consumer’s browser. PaymentGuard AI monitors the payment page environment and establishes a baseline of approved scripts and headers, triaging them continuously with what executes to reliably detect change and alert personnel for remediation.
Maintains audit-read alert and ownership trails across the audit window
Audits stall when teams fail to prove alerts work, gets routed to the right people at the right time. PaymentGuard AI emphasizes real-time alerts and integrations into security workflows, which help create a durable record that an alert was generated, routed, and visible to an owner.
A triage trail that makes response provable
Many teams have response mechanisms in place, but fail at documentation. PaymentGuard AI allows you export reports containing change logs and compliance status, demonstrating the entire path from detection to alerts and review. This allows you to walk into your next audits with demonstrable evidence.
That’s why the organizations using PaymentGuard AI for remediation typically achieve re-audit success in 60-90 days because the system begins generating compliant evidence immediately. No manual process development, no evidence compilation scrambles, no questions about whether monitoring is truly continuous.
This is what makes a 60 to 90-day re-assessment window realistic with PaymentGuard AI.
It starts generating the audit-ready evidence on day one, without needing you to invent new manual workflows or scrambling to compile proof at the end. By the end of your 90-day window, you can show a continuous trail of accurate script inventories, approvals, detection logs, alerts, and documented review actions.
The bottom line
PCI is validating what the client’s browser executes and whether you can prove control over that runtime over a period. So, mechanisms that live only in tickets, screenshots, or quarterly reviews don’t easily cut it. Continuous governance and a clear evidence trail does.
So you need demonstrable oversight over what runs on payment pages at runtime, bind every script to a justification and approval, monitor scripts and security-impacting headers continuously, and retain the full trail from detection to response. If done correctly, the next audit would certainly bring fewer surprises.
Schedule a demo to see how PaymentGuard AI can get you re-audit-ready in 60-90 days with continuous compliance evidence.
