PCI DSS 4.0.1 for Software Engineers: What Changed, What You Own

PCI DSS v4.0.1 has been the only active version of the card data security standard since January 2025, and every requirement in it has been mandatory since 31 March 2025. Many of the requirements v4 added are code, pipelines and configuration rather than policy documents, so they land on engineering teams. Here is where the standard stands in 2026, how it is organized, and which parts engineers usually own.

PCI DSS (Payment Card Industry Data Security Standard) is a baseline of technical and operational requirements for protecting payment account data, maintained by the PCI Security Standards Council (PCI SSC). The current line started when PCI SSC published v4.0 on 31 March 2022. Since then:

• v3.2.1 retired on 31 March 2024.
• v4.0.1 was published on 11 June 2024 as a limited revision: corrections and clarifications, with no added or deleted requirements.
• v4.0 retired on 31 December 2024, which left v4.0.1 as the only active version.
• The future-dated requirements became mandatory on 31 March 2025.

A future-dated requirement is one that v4.0 introduced as a best practice with a later effective date, so organizations had time to build it. Of the 64 new requirements in v4.0, 51 were future-dated, and v4.0.1 did not move their effective date. If your last assessment finished before April 2025, the next one is the first where all of them count.

Not yet. PCI SSC ran a request for comments (RFC) on v4.0.1 from 3 June to 20 July 2026. The RFC instructions say the goal is to help decide whether v4.0.1 should be revised and what kind of revision it needs, and they ask specifically about the impact of AI and mobile. As of October 2026 no new version or date has been announced, so treat any "PCI DSS v5" checklist as speculation and plan against v4.0.1.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

The standard has 12 principal requirements grouped under six goals, from building a secure network to maintaining an information security policy (overview; the full text is in the PCI SSC Document Library). Each principal requirement breaks into numbered sub-requirements such as 6.4.3 or 8.4.2, and those numbers are how assessors, tools and this series refer to them.

The standard assigns responsibility to the entity being assessed, not to teams inside it. But v4 does ask you to write the split down: requirements such as 6.1.2 and 8.1.2 say that roles and responsibilities for that requirement's activities must be documented, assigned and understood, and most other principal requirements carry the same item. That gives engineering a concrete reason to agree an ownership map with compliance.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

The split below is the one I see most often on product engineering teams in payments. Treat it as a starting point: what matters is that every requirement has a named owner and that the owner knows it.

On a payment orchestration platform I work on, I co-planned a PCI DSS v4.0.1 self-assessment study against SAQ D for service providers with one other engineer. I built the review and estimation template we work from, I own six of the twelve principal requirements, and I write one control note for each defined-approach requirement. A short note per requirement that says what the control is, where it lives and what evidence shows it working is far easier to review than a long policy document.

Several of the new v4.0 requirements are about documentation and roles, but a cluster of the future-dated ones are engineering work. Each requirement below carried a "best practice until 31 March 2025" note in the v4.0 SAQ A-EP, and the larger ones get their own post later in this series.

Requirement 6.4.3 covers every script a payment page loads and runs in the customer's browser: you need a way to confirm each script is authorized, a way to assure its integrity, and an inventory with a written reason for each one (Requirement 6 summary). Requirement 11.6.1 adds detection: a mechanism that alerts on unauthorized changes to the payment page and its security-relevant HTTP headers as the browser receives them, run at least every seven days or at a frequency set by a targeted risk analysis (SAQ A-EP).

In January 2025 PCI SSC took 6.4.3 and 11.6.1 out of SAQ A and replaced them with an eligibility condition that the merchant's site is not susceptible to script attacks; the requirements themselves remain in PCI DSS. In March 2025 it also published an information supplement on e-skimming. The implementation side is in Securing Payment Page Scripts.

The cardholder data environment (CDE) is the set of systems, people and processes that store, process or transmit cardholder data or sensitive authentication data. Requirement 8.4.2 extends multi-factor authentication (MFA) from administrators (8.4.1) to all access into the CDE, and 8.5.1 says the MFA system must resist replay, must not be bypassable outside a documented, time-limited exception, and must use at least two different types of factor (Requirement 8 summary).

Two PCI SSC FAQs from May 2025 matter here. Synced passkeys built to the FIDO2 requirements count as phishing-resistant authentication and can stand in for MFA under 8.4.2. For administrative access (8.4.1) and remote access (8.4.3), phishing-resistant authentication still needs a second factor.

Requirement 8.3.6 sets a minimum password length of 12 characters (8 where a system cannot support 12) with both letters and digits, and 8.3.9 asks for 90-day changes only where a password is the single factor, with dynamic risk analysis of the account as the alternative (Requirement 8 summary). These rules differ in places from the OWASP® ASVS 5.0 password guidance; Implementing ASVS 5.0 Authentication in a Payments API shows how to satisfy both.

These get less attention but still need code or pipeline work (Requirement 6, Requirement 8, SAQ A-EP):

• 6.3.2: keep an inventory of your bespoke and custom software and the third-party components inside it, to support vulnerability and patch management. In practice, a software bill of materials per service.
• 6.4.2: put an automated solution in front of public-facing web applications that detects and blocks web attacks, generates audit logs and is kept up to date.
• 7.2.5: give application and system accounts only the privileges they need.
• 8.6.2: never hard-code passwords for application and system accounts that can log in interactively, whether in scripts, configuration files or source code.
• 8.6.3: change those passwords at a frequency set by a targeted risk analysis, and whenever compromise is suspected.
• 10.4.1.1: use automated mechanisms for audit log reviews.

A targeted risk analysis (TRA) is a documented risk analysis for one specific requirement, narrower than an organization-wide risk assessment. PCI DSS v4 uses two kinds:

• Requirement 12.3.1 covers requirements that let you choose how often to perform an activity. The TRA identifies the assets protected, the threats, the factors that drive likelihood and impact, and the resulting frequency with its justification, and you review it at least once every 12 months (SAQ A-EP). 11.6.1 and 8.6.3 are typical engineering examples.
• Requirement 12.3.2 asks for one TRA for each requirement you meet with the customized approach, described in the next section.

A 12.3.1 TRA only applies where a requirement offers that flexibility; it is not a way to stretch a fixed interval. Engineering should write the TRAs for its own controls, because the inputs are engineering facts: how often the payment page changes, how fast a deploy reaches production, what breaks when a credential rotates. PCI SSC's TRA guidance and sample template are in the Document Library.

Every requirement can be met in one of two ways. Under the defined approach, you implement the requirement as written and the assessor follows the testing procedures in the standard. Under the customized approach, you design your own control to meet the requirement's stated objective, document it in depth, and the assessor derives tests from your documentation (PCI SSC).

Two more terms help here. A compensating control is an alternative control you document when a legitimate technical or business constraint stops you from meeting a requirement as written. A Report on Compliance (ROC) is the full assessment report, usually produced by a Qualified Security Assessor (QSA), while a Self-Assessment Questionnaire (SAQ) is the self-assessment form for eligible entities.

The sources for the table are PCI SSC's posts on whether the customized approach fits and on compensating controls versus the customized approach, plus the SAQ instructions, which state that SAQs cannot document the customized approach.

The choice is made per requirement, not for the whole assessment. PCI SSC's June 2026 guidance adds that compensating controls and the customized approach can coexist under the same requirement for different system components, as long as each instance is documented separately. PCI SSC also warns that the customized approach is not a workaround for a requirement you did not meet, and that you should check with your acquirer or the payment brands before using it.

My view: stay on the defined approach unless you have a control that is clearly stronger than the written requirement and a risk owner willing to maintain its TRA. If you validate with an SAQ, the question only arises if your acquirer or the brands let you switch to a ROC.

PCI SSC writes the standards and trains assessors, but it does not enforce compliance or define validation reporting requirements. The payment brands run the compliance programs, and your acquirer (the bank that processes card payments for a merchant) or the brands tell you whether you need a ROC from a QSA or can self-assess. For service providers, SAQ D for Service Providers is the only SAQ; the next post covers scoping and SAQ D for service providers.

Only PCI SSC's official forms count as validation: the ROC, the SAQ, the Attestation of Compliance (AOC) and the attestation for approved scanning vendor scans. PCI SSC does not endorse "PCI compliance certificates". Compliance attaches to an entity and its environment, never to a library, framework or container image, so when a vendor calls its product "PCI compliant", ask for the AOC that covers the service you use.

Earlier, I built backend services for a payment facilitator: merchant management and an internet payment gateway used by more than 500 businesses, with transaction, settlement, reconciliation and risk workflows. Those workflows had to meet the national card network's rules, and that work helped the company obtain its payment facilitator license. The habit I took from it applies to PCI DSS too: read the standard, then design for what the party that checks you will ask to see.

• Confirm your validation path (a ROC, or which SAQ) with your acquirer or the payment brands before estimating any work.
• Map the 12 principal requirements to named owners and write it down; that also covers roles items such as 6.1.2 and 8.1.2.
• List every flexible-frequency control engineering owns and write its 12.3.1 TRA, starting with 11.6.1 and 8.6.3.
• Build the two inventories early: payment page scripts for 6.4.3 and third-party components for 6.3.2.
• Stay on the defined approach unless a risk owner is ready to maintain a TRA for each customized requirement, and plan against v4.0.1 until PCI SSC announces what follows the 2026 RFC.