PCI DSS 4.0: the card data rules and who they bind

PCI DSS protects cardholder data: the card number, the expiry date, the cardholder name and the authentication data behind them. It binds anyone who stores, processes or transmits that data, which covers merchants, acquirers, processors, facilitators and any service provider in between, and it reaches the systems connected to those as well.

It is not a law. No supervisor issues a PCI fine, and the obligation arrives through the acceptance contract instead. The Council itself notes that who has to validate what depends on the compliance enforcing entity, meaning the scheme, the acquirer or the payment facilitator, which is why two merchants of similar size can face different evidence requirements. Finance Loop covers the regulated obligations that sit beside it in DORA in Germany.

Version 4.0 kept the twelve requirement areas and changed how they are met. The largest addition is the customized approach: instead of implementing the control as written, an organization may meet the stated objective its own way, document why its method achieves the objective, and have an assessor validate that reasoning. That route costs more work, not less, and it exists for mature security teams whose existing controls do not match the prescribed wording.

The rest of the change is a shift of emphasis toward evidence over assertion. Authentication requirements tightened, including multi-factor access to the cardholder data environment. Several controls now require a targeted risk analysis that sets the frequency of an activity from the organization's own risk assessment instead of a fixed interval. Version 4.0.1 followed as a maintenance release correcting and clarifying 4.0, and it is the version to cite.

Two of them took effect on 31 March 2025 after a transition period, and both address what happens in the browser. Requirement 6.4.3 covers the scripts loaded on a payment page: each one has to be inventoried, carry a written business justification, be explicitly authorized by a named party, and have its integrity verified on an ongoing basis, including the scripts served by third parties. Requirement 11.6.1 asks for a mechanism that detects unauthorized change to the payment page as received by the consumer browser. Requirement 12.3.1 covers the targeted risk analysis supporting 11.6.1.

The attack behind them is the reason the dates matter. A script injected into a checkout page, usually through a tag manager or an analytics vendor, reads the card number as the customer types it and sends it elsewhere, and nothing on the merchant's server sees anything wrong. Any marketing or analytics tag on a page that collects card details is in scope of 6.4.3 by that logic.

The smallest questionnaire was reworked in the same month. The Council removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added an eligibility criterion in their place: the merchant has to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The January 2025 version took effect on 31 March 2025, when the October 2024 version retired.

Read the exchange carefully before treating it as relief. The three requirements left the questionnaire and stayed in the standard, so they continue to apply to merchants validating through SAQ D or an onsite assessment, and the new eligibility criterion asks a merchant to attest to the same outcome the removed requirements were meant to produce. Adyen's eligibility guide states the other SAQ A condition: every element of the payment page and form delivered to the customer's browser has to come only and directly from a compliant third-party provider or processor.

The answer comes from the integration, not from the business size. A checkout that redirects the customer to the provider, or that embeds the provider's own iframe, keeps the card number out of the merchant's page and points to SAQ A. A merchant page that collects the card in its own fields and posts it onward, even without storing it, lands in the much longer SAQ A-EP. A merchant that stores card numbers anywhere, or that processes them on its own systems, is in SAQ D.

Transaction volume decides the evidence, not the question set. The schemes classify merchants into levels by annual transactions, and the highest level requires an onsite assessment by a qualified security assessor instead of a self-assessment. The question to ask your acquirer is which level it has you in and which questionnaire it expects, in writing, because that pair determines the cost of the whole exercise.

The cheapest way to meet a requirement is to not be subject to it. If the card number is captured by fields the provider serves and controls, and your system only ever receives a token, then your database, your logs, your backups and your support tools hold no cardholder data and fall outside the assessment. That is the whole argument for a hosted field or a redirect.

Two mistakes undo it. A page that serves the provider's fields but also loads its own scripts into the same page brings those scripts back into scope, which is exactly what 6.4.3 addresses. And a token is not automatically out of scope: if the merchant holds anything that can be reversed into a card number, or the key material to do so, the data is still there. Finance Loop covers the vault question in payment orchestration and the acquiring side in merchant acquiring.

A German payment institution now answers to both, and they ask different questions about the same systems. PCI DSS protects one data type across the environment that touches it, and the enforcer is a contractual counterparty. DORA governs the operational resilience of the whole regulated firm, and the enforcer is BaFin.

The overlap is practical, not legal. Asset inventories, vulnerability management, access control, incident response and third-party oversight appear in both, so the evidence can be produced once and presented twice if the documentation is built for that. Two things do not transfer: DORA's incident reporting runs to the supervisor on regulatory deadlines, and the PCI scope is narrower than DORA's, so a DORA program does not demonstrate PCI compliance for the cardholder data environment. Finance Loop covers the resilience regime in DORA in Germany and the wider field in cybersecurity in finance.

Nothing substantive. Version 4.0.1 is a limited revision published to correct errors and clarify wording in 4.0, and it introduced no new requirements and moved no dates. An organization working toward 4.0 is working toward 4.0.1, and 4.0.1 is the version to name in a document or a contract.

No, and the distinction matters less than it sounds. The standard is set by the card schemes and enforced through contracts, so the consequences of failing it are commercial: evidence demands, fines passed through by the acquirer, and in a serious case the loss of card acceptance. A breach involving card data also triggers the obligations that are law, including data protection notification under the GDPR, which is why a card data incident produces two separate processes.