Cartelta resources

PCI DSS 4.0.1 guides for e-commerce and payment pages

Scope and SAQ decision guides, implementation workflows, and evidence examples for teams preparing PCI DSS 4.0.1 and governing payment page scripts and changes.

PCI DSS 4.0.1

payment pages

script attacks

QSA

2-3 week pilot

How to read this section

1. Confirm applicability

Separate embedded forms, redirects, SAQ A criteria, and the applicable validation path.

2. Build the controls

Connect script inventory, authorization, baseline comparison, and response.

3. Test the evidence

Use one reproducible sample to validate ownership and audit readiness.

Choose the problem you are solving

Each topic has one primary guide so requirements, product pages, and implementation resources do not compete for the same search intent.

01

PCI DSS 4.0.1 scope and readiness

Start with applicability, all 12 requirement groups, the validation route, and an owned readiness plan.

Read article

02

SAQ A, A-EP, or D

Select the questionnaire from the real payment architecture and every current eligibility criterion.

Read article

03

SAQ A and payment architecture

Decide what changes for embedded forms, redirects, script-attack protection, and ASV scanning.

Read article

04

Script governance for 6.4.3

Build an observed inventory with owners, authorization, justification, and integrity controls.

Read article

05

Change detection for 11.6.1

Define approved baselines, meaningful deviations, triage, response, and event evidence.

Read article

06

Evidence for internal and QSA review

Connect control design, operating records, exceptions, retention, and reproducible samples.

Read article

07

A focused JSIR pilot

Run one checkout through inventory, baseline, controlled changes, triage, and production criteria.

Read article
Start here

PCI DSS 4.0.1: 12 requirements and readiness plan

PCI DSS 4.0.1 is the active limited revision of the payment card data security standard. This guide turns it into a working map: scope and validation method first, then owners, technical controls, evidence, and a prioritized readiness plan.

PCI DSS 4.0.1 added and removed no requirements; it is a limited revision and became the only active version after 31 December 2024.

Readiness starts with data flows and scope, not with filling in a questionnaire.

The SAQ is selected from payment architecture and every eligibility criterion, not transaction volume alone.

Read article

Why start here

It establishes scope, the 12 requirement groups, the validation route, and an evidence-backed readiness sequence before the technical deep dives.

18 min


All articles

02

PCI DSS / SAQ selection

SAQ A, A-EP, or D: choosing a PCI DSS 4.0.1 questionnaire

A practical e-commerce SAQ decision guide covering payment architecture, A and A-EP eligibility, SAQ D triggers, acquirer confirmation, and a decision-record template.

Read article

03

PCI DSS 6.4.3

PCI DSS 6.4.3: controlling client-side scripts on payment pages

A practical guide to PCI DSS 6.4.3: inventory, authorization, business justification, and script integrity on checkout pages.

Read article

04

PCI DSS 11.6.1

PCI DSS 11.6.1: payment page change detection

How PCI DSS 11.6.1 applies to payment page change detection, critical headers, DOM monitoring, and incident response evidence.

Read article

05

Cartelta JSIR

How to implement Cartelta JSIR for PCI DSS 6.4.3 and 11.6.1

A step-by-step Cartelta JSIR pilot: scope, script inventory, baseline, controlled changes, triage, and an evidence package.

Read article

06

Payment page security

Payment page security after PCI DSS 4.0.1: SAQ A, iframe, and evidence

A practical guide to SAQ A after 31 March 2025: embedded forms, redirects, script-attack protection, ASV scanning, and review evidence.

Read article

07

Client-side security

Why an iframe payment form does not remove every client-side risk

An iframe payment form can change PCI DSS scope, but it does not automatically make the merchant page safe.

Read article

08

Audit readiness

How to build a payment page security evidence pack

A useful evidence pack shortens the path from a pilot to a security decision and a QSA conversation.

Read article

09

Implementation

Five common mistakes in checkout script control

Most failures in this area are not caused by the absence of a tool; they come from defining the control incorrectly.

Read article

10

Pilot strategy

How to run a client-side security pilot without a heavy project

A good pilot should quickly show the scope, real changes, and the next operational decision rather than proving a perfect architecture.

Read article

Implementation resources

Use the articles for decisions and the pages below for operating models, checklists, and technical review.

Who this is for

For security leaders, application security teams, e-commerce owners, and teams preparing their first payment page security pilot.

The goal is to support specific conversations with security teams and auditors, not generic content traffic.