At a glance
- PCI DSS v4.0.1 is the active PCI SSC edition; the requirements formerly marked future-dated became effective March 31, 2025.
- Requirements 6.4.3 and 11.6.1 make payment-page script authorization, integrity, and tamper-change detection especially important for e-commerce evidence.
- Defined and customized approaches produce different implementation and validation records even when they pursue the same security objective.
- A Qualified Security Assessor or accepting entity retains the decision about scope, testing, exceptions, and validation outcome.
The transition is over
PCI SSC published v4.0.1 as a limited revision in June 2024, clarifying requirements and guidance without adding or deleting requirements. PCI DSS v4.0 retired at the end of 2024, leaving v4.0.1 as the active supported edition. The requirements previously designated future-dated became effective on March 31, 2025.
For operators, that means version ambiguity is no longer a harmless backlog item. The control inventory, testing procedure, self-assessment or report template, and evidence period should all identify v4.0.1 and the applicable validation path.
One artifact can support several controls without becoming universal proof
An identity-access review, secure-configuration export, vulnerability scan, change record, incident exercise, or supplier assessment may support PCI DSS and several other regimes. Reusing the bytes is sensible; reusing the conclusion without qualification is not.
The artifact should retain its system and cardholder-data-environment scope, owner, source, collection method, period, checksum, version, sensitivity, and prior review. Each proposed control mapping then receives its own applicability, freshness, and sufficiency decision. Candidate mappings receive no compliance credit until an authorized reviewer accepts them.
Modern e-commerce evidence is operational
PCI SSC has issued specific guidance for e-commerce Requirements 6.4.3 and 11.6.1. The practical evidence is not just a policy: it can include a maintained inventory of payment-page scripts, authorization and integrity justification, security-impact records, deployment and change history, detection configuration, alerts, investigations, and periodic review.
Those records should be collected where the payment surface operates and mapped back to the in-scope page, script, component, and requirement. A screenshot detached from its runtime context and date is a weak substitute for that chain.
Customized approaches need a stronger decision record
PCI DSS v4.x supports a customized approach for eligible requirements, but flexibility increases the need to explain the objective, design, targeted risk analysis, testing, and validation. The platform should preserve that reasoning beside the evidence instead of converting it into an informal exception note.
The result is a useful cross-framework operating model: collect once at the source, preserve context, propose mappings, let qualified reviewers decide, refresh when the evidence or scope changes, and release only the package appropriate to the assessment.
Put it into practice
- Pin every PCI assessment and artifact to v4.0.1, the validation path, entity scope, and evidence period.
- Represent cardholder-data-environment scope and connected-to or security-impacting systems explicitly.
- Track targeted risk analyses with their owner, rationale, cadence, approval, and next due date.
- Maintain payment-page script inventory, authorization, integrity, change detection, alerts, and review evidence together.
- Give cross-framework mappings candidate status until the appropriate reviewer confirms applicability and sufficiency.
For the executive team
PCI DSS v4.0.1 is not another document migration. It expects maintained operational proof.
ControlFrame's opportunity is to let payment evidence serve every applicable framework without losing PCI scope, approach, test method, period, or assessor judgment.
That reduces repeated collection while making the next review more defensible.