Resources
PCI DSS 6.4.3 and 11.6.1 payment page checklist
Use this working checklist to connect payment-page scope, script governance, integrity and change monitoring, response, ownership, and retained evidence before an internal or QSA review.
For PCI compliance owners, security and engineering teams, internal audit, and assessors reviewing how payment-page controls operate in practice.
Checklist coverage
Scope and payment-journey ownership.
Script inventory, authorization, justification, and integrity.
Approved baseline, change detection, notification, and response.
Evidence retention, periodic review, RACI, and assessor traceability.
Updated: July 27, 2026
Review basis
Reviewed against PCI DSS v4.0.1, current PCI SSC e-commerce guidance, SAQ A updates, and related FAQs. The worksheet is a planning aid; applicability and sufficiency remain assessment decisions.
Defined scope
List the payment journeys, page variants, providers, tag managers, and responsible teams being reviewed.
Operating control
Connect inventory and monitoring to approvals, release management, triage, and periodic review.
Evidence package
Retain artifacts that show both control design and actual operation over the review period.
1. Confirm scope before selecting controls
Document every payment journey in which the merchant page can affect what a customer sees or how payment data is entered. Include redirect, embedded, hosted-field, and multi-step patterns, along with locales, mobile variants, consent states, tag managers, CDN behavior, and payment-provider dependencies.
Record the scope decision and the evidence supporting it. A checklist cannot decide applicability on its own; the organization and its assessor need to validate the conclusion against the actual architecture and validation method.
- Named owner for each payment journey and production page.
- Architecture diagram showing merchant, provider, third parties, and browser boundaries.
- Documented SAQ/ROC path and assessor-approved scope assumptions.
2. Confirm the validation path and responsibility model
Do not assume that every e-commerce architecture has the same reporting obligation. PCI SSC removed Requirements 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion requiring merchants to confirm that their site is not susceptible to script attacks that could affect the e-commerce system.
For an embedded payment form, obtain and retain the provider confirmation and implementation conditions where that is the chosen approach, or document the merchant or third-party techniques used to protect the page. A server-side redirect may support a different applicability conclusion when scripts cannot influence the redirection, but the assessor must validate and document that conclusion.
- Name the organization that manages the compliance program: assessor, acquirer, or payment brand.
- Record what the merchant controls, what the payment provider controls, and which party supplies each artifact.
- Keep provider instructions, confirmation, implementation settings, and change notifications together with the scope decision.
3. Establish the 6.4.3 script-control record
For every script loaded and executed in scope, record the observed source, business purpose, owner, authorization, justification, and integrity or authenticity method. Reconcile the approved register with the actual page after releases and material third-party changes.
- First-party bundles, third-party SDKs, tag-manager rules, widgets, and dynamic loaders.
- Approval evidence, exception handling, review date, and removal decision for obsolete entries.
- Technical method such as SRI, signatures, CSP support, controlled delivery, or monitored change process.
4. Operate 11.6.1 detection and response
Define an approved baseline for each relevant payment-page state and monitor meaningful changes to page content, scripts, resource origins, and security-relevant headers. Document how expected releases update the baseline and how unexplained deviations enter triage.
Notification alone is not enough. The operating record should show who received the event, what they reviewed, the decision, containment or approval action, and the closure time. Record execution at least once every seven days or at the periodic frequency defined through the applicable targeted risk analysis.
5. Test operation before marking a row complete
A policy, configured dashboard, or completed worksheet does not prove operating effectiveness. Run a controlled expected release, an unexplained script or header change, a dynamic-value normalization case, a failed observation, and a sample retrieval.
For each test, preserve the input, expected result, actual result, owner, decision, remediation, retest, and evidence reference. A failed test remains open until the control or scope is corrected; it should not be converted into a generic accepted state.
6. Retain evidence and review control health
Agree the review period and retention requirements with compliance, security, legal, and the assessor. Keep evidence searchable by page, script, event, owner, requirement, and date so a sample can be reproduced without rebuilding the history shortly before the audit.
Periodically test whether owners still respond, inventory entries remain current, baseline rules do not hide meaningful changes, and exports contain enough context for an independent reviewer.
On this page
Complete one control worksheet per payment journey
The worksheet turns broad requirements into owner, status, evidence, reviewer, due-date, and exception fields. Complete it with the application, security, compliance, and provider teams rather than assigning every row to one PCI owner.
Definition of done
The journey has a documented validation path, accountable owners, verified script and change controls, tested response, retrievable evidence, and explicit open gaps with dates instead of optimistic check marks.
01
Map the real journey
Capture redirect or embedded architecture, merchant and provider boundaries, page variants, browser states, and all parties that can change the client-side result.
02
Record applicability, not assumptions
Link the SAQ or ROC path, provider confirmation, assessor discussion, and the reason each requirement or eligibility condition is handled in the selected way.
03
Attach one source record per status
A status without a ticket, export, configuration, test result, or signed decision is a planning statement rather than evidence.
04
Run negative and positive tests
Exercise expected change, unexpected change, normalization, routing, failure handling, and evidence retrieval before declaring the control operational.
05
Close ownership and timing gaps
Assign unresolved rows, exceptions, retests, and periodic reviews to named roles with due dates and escalation.
Portable PCI DSS 6.4.3 / 11.6.1 checklist
PDF format for review meetings, control workshops, and assessor preparation.
PDF · portable review copy
Control implementation worksheet
Editable CSV with scope, inventory, authorization, integrity, baseline, frequency, response, evidence, and governance rows.
CSV · UTF-8 · ready for an internal control register
Do not treat a completed template as proof of compliance. Keep the authoritative PCI SSC publications and the assessor's environment-specific conclusions with the working file.
Recommended implementation order
The order reduces the risk of tuning monitoring against an unapproved or unauthorised page state.
01
Scope
Map journeys, variants, dependencies, owners, and validation assumptions.
02
Inventory
Observe scripts and reconcile them with the approved register.
03
Authorize
Capture purpose, owner, approval, and integrity approach.
04
Monitor
Approve baselines and compare meaningful browser-side changes.
05
Respond and retain
Route events, document decisions, and preserve reviewable evidence.
Control and evidence checklist
Use the table as a working index. Add the internal owner, system of record, status, reviewer, and due date in your own control register.
| # | Control area | Verify | Example evidence | Primary owner |
|---|---|---|---|---|
| 01 | Scope | Every payment journey and variant is mapped | Architecture, URL list, scope decision | PCI owner / architecture |
| 02 | Inventory | Observed scripts match the governed register | Script export, source, first/last seen | AppSec / application owner |
| 03 | Authorization | Every script has approval and business justification | Ticket, owner, approval date, exception | Business and technical owner |
| 04 | Integrity | Each script has an appropriate control method | SRI/signature record, CSP support, monitoring rule | Engineering / AppSec |
| 05 | Baseline | Expected page states are documented and approved | Snapshot, release, owner, approval | Application owner |
| 06 | Detection | Meaningful changes create reviewable events | Diff, timestamp, affected page and source | Security operations |
| 07 | Frequency and gaps | Runs meet the required or risk-defined frequency | Execution history, failures, retries, gap decisions | Control owner / platform operations |
| 08 | Response | Events are assigned, decided, and closed | Alert, triage notes, action, closure | SOC / incident response |
| 09 | Retention | Evidence is available for the agreed period | Export, retention setting, sample retrieval | Compliance / platform owner |
| 10 | RACI | Control and escalation roles are accepted | RACI, procedure, contact path, test record | Control owner |
| 11 | Control testing | Expected, unexpected, and failure scenarios pass | Test plan, results, remediation, retest | Control owner / internal audit |
This resource is implementation guidance, not a substitute for PCI DSS, an assessor's judgment, or environment-specific legal and security review.
Separate official requirements from implementation guidance
PCI SSC publications are the authoritative source. This Cartelta checklist organizes practical work and example artifacts; it does not add requirements, guarantee compliance, or replace a QSA's assessment.
Checklist questions
The HTML version is the maintained reference and links into related implementation guidance. The PDF is a portable working format for review sessions and internal planning.
No. The checklist supports preparation and evidence organization. Applicability, control effectiveness, sampling, and the final compliance conclusion depend on the environment, validation method, and assessor review.
Requirements 6.4.3 and 11.6.1 were removed from SAQ A, but the current eligibility criteria require confirmation that the site is not susceptible to script attacks that could affect the e-commerce system. The merchant should document the selected protection or provider-confirmation approach and validate it with the compliance-program owner.
Unobserved page states, unknown scripts, missing provider confirmation, untested routing, failed monitoring runs, unresolved exceptions, and evidence that cannot be independently retrieved should remain visible with an owner and due date.
Primary PCI SSC sources
Use the checklist with these guides
Turn the checklist into an operating control
Start with one real payment journey, verify the evidence produced, and close ownership gaps before expanding the scope.
Discuss implementation scope