PCI DSS Compliant Software: What an Assessment Actually Tests

PCI DSS compliant software is not what most teams think it is. Teams with genuinely strong engineering fail assessments, teams with mediocre engineering pass them, and that is not a flaw in the standard. It is what the standard is for.

Requirement numbers and dates verified against PCI Security Standards Council primary sources, September 2026.

Nobody fails a PCI assessment because their code was insecure

PCI DSS compliant software is not a property of a codebase. It is a property of an evidence trail. That single distinction explains what most engineering teams find inexplicable about their first assessment: a team with genuinely strong security posture struggles, and a team with a mediocre one sails through.

The standard is not asking whether your software is secure. It is asking whether you can demonstrate, to a stranger, on a schedule, that specific named controls were operating throughout a defined period. That is the whole test PCI DSS compliant software has to pass. Those are different questions, and only one of them can be answered after the fact.

A control that worked perfectly and left no record is, for assessment purposes, a control that did not operate. That is not a technicality. It is the operating principle of the entire regime, and every practical consequence in this article follows from it.

The standard itself is free to read, which is why this article does not enumerate the twelve requirements. Everything below is checkable against PCI Security Standards Council primary sources, and where the exact wording of a requirement matters we point at the Document Library rather than paraphrasing it.

Why do secure teams fail PCI assessments?

Because the assessment tests demonstrability rather than security. A team can run a tight environment and still be unable to show who approved a change in April, or produce twelve months of logs for a control that was never logging. Security is a property of the system now. Compliance is a property of the record covering a period that has already passed.

Level 1 is not a stricter standard, it is a different way of proving the same one

The level you are assessed at does not change what PCI DSS compliant software has to do: every level is measured against the same twelve requirements. This is the single most common misunderstanding about PCI DSS compliant software, and it is worth stating before anything else, because most people believe the opposite.

What the level determines is the validation route. At the top of the scale, an organization is assessed on site by a Qualified Security Assessor, an auditor licensed by the PCI Security Standards Council, who produces a Report on Compliance. Lower down, an organization may complete a Self-Assessment Questionnaire and attest to its own compliance.

The gap between those two routes is the gap between "we believe we comply" and "somebody whose licence depends on being right examined us and wrote it down". Both are legitimate. They are not the same claim, and they are routinely reported as though they were.

Both routes produce an Attestation of Compliance, a short signed document naming the entity, the assessor where one was involved, the date, the scope, and the version of the standard. The AOC is the artefact that actually travels between companies. The Report on Compliance behind it is long and rarely leaves the organization that paid for it.

So when a supplier says "we are PCI compliant", the useful follow-up is three words long: validated how, by whom, and when does it expire? An attestation covers a defined period. A two-year-old AOC describing a different service is a common answer to that question and it is not a good one.

What is the difference between PCI DSS Level 1 and the other levels?

The requirements are identical. The level determines how compliance is validated: an on-site assessment by a Qualified Security Assessor producing a Report on Compliance, or a Self-Assessment Questionnaire completed by the entity itself. Level is a statement about scrutiny, not about which rules apply.

What v4.0.1 actually changed for people who write code

Anyone maintaining PCI DSS compliant software should know that v4.0 was retired on 31 December 2024, and v4.0.1 is the only active version. If your internal documentation still references v4.0, that is the first evidence problem to fix, and it takes an afternoon.

v4.0.1 is a limited revision. The Council was explicit that there are no new or deleted requirements in it. Most of the changes are clarifications, and a changelog is not worth your time. One of them is worth your time, and it is the most informative sentence in the document.

Under Requirement 6, the Council reverted to v3.2.1 language so that installing patches and updates within 30 days applies only to critical vulnerabilities. The v4.0 text had extended that window to a broader set, and it was walked back.

Read that revert for what it tells you rather than for what it changes. A 30-day window across all vulnerabilities is unimplementable for anyone with a real dependency tree, entities and assessors said so, and the standards body conceded. Where the standard has been softened, it was softened because operational reality was argued back at it. Most teams do not know that route exists.

The same revision added applicability notes clarifying how the payment page script requirements apply, which matters for the next section, and clarified that multi-factor authentication into the cardholder data environment does not apply to accounts authenticated only with phishing-resistant factors.

The date that matters more than the version number is 31 March 2025. The requirements introduced in v4.0 as best practice became mandatory then, and the Council confirmed that v4.0.1 did not move it. If your last assessment predates that transition, your next one is against a materially longer list.

Your tag manager is inside the cardholder data environment now

Requirement 6.4.3 pushed the boundary of PCI DSS compliant software into a system that engineering usually does not own. It is the most common way PCI DSS compliant software stops being compliant without a line of application code changing.

The mechanism is straightforward. Every script executing on a payment page has to be inventoried, authorized, justified, and integrity-assured. Requirement 11.6.1 is its pair: change-and-tamper detection on the payment page itself. One asks what should be there. The other asks whether it changed.

The organizational consequence is the actual story. On most sites the script surface of the payment page is controlled through a tag manager, and the tag manager is operated by marketing on a change process that has nothing to do with engineering change control.

So the control that fails is not technical. Somebody adds an analytics tag on a Tuesday afternoon, the inventory goes stale, and nobody in that approval chain knew the page was inside the cardholder data environment. The script is not malicious. The record is simply wrong, and the record is what gets assessed.

Client-side monitoring products genuinely help here, and it is worth saying so plainly even though every vendor page on this topic is selling one. Automated script inventory and integrity checking is real work that a tool does well. What no tool solves is the approval process, which is where the failure actually originates. Buying the monitor and leaving marketing's change process untouched buys you faster detection of a problem you are still creating every week.

The durable fix is unglamorous: the payment page's script surface belongs to whoever owns compliance for that page, and adding a tag to it is a change that goes through the same gate as a code deploy.

What is the cardholder data environment?

Per the PCI SSC glossary, the people, processes and technology that store, process or transmit cardholder data, plus any system component connected to or able to affect the security of those. The second half is the part that surprises people: a system does not have to touch card data to be in scope, it only has to be able to affect the security of something that does. A payment page's script surface qualifies.

Requirement 6.3.2 is a software bill of materials wearing a different name

Anyone shipping PCI DSS compliant software has owed somebody a component inventory since before SBOM became a policy word. Requirement 6.3.2 asks for an inventory of bespoke and custom software, including third-party components, maintained to support vulnerability management.

Read that description next to any software bill of materials specification and the overlap is obvious. Different vocabulary, largely the same artefact, and the same underlying purpose: knowing what is in the thing you shipped so you can tell whether a published vulnerability affects you.

Most organizations that touch card data and sell into Europe are now on course to maintain two of these. The PCI inventory exists because of 6.3.2. The SBOM exists because of product regulation. Nobody decided to build two, it just happened, because the two obligations arrived from different directions and landed on different teams.

The recommendation has money attached to it: generate one machine-readable inventory from the build and let both regimes read from it. Two hand-maintained inventories are guaranteed to diverge, and a divergent inventory is worse than no inventory, because it produces confident wrong answers to the question of whether you are exposed.

The Cyber Resilience Act's main obligations arrive in the second half of 2026 with an SBOM expectation attached. If you are scoping that work now and you already have a PCI scope, check what 6.3.2 already obliges you to hold before you commission a second pipeline to produce it.

v4.0 moved the cost from building controls to justifying them

The expensive part of v4.0 for anyone maintaining PCI DSS compliant software was not implementing anything. It was writing down why what you implemented is adequate. Two mechanisms did this, and almost nobody frames either of them as a cost.

The first is the choice of approach. The defined approach follows the requirement as stated. The customized approach meets the requirement's stated Customized Approach Objective by some other means, and the entity carries the burden of showing that its design gets there.

The second is the targeted risk analysis. The Council's TRA guidance describes two types. One sets the frequency of a control where the requirement leaves that frequency to the entity. The other supports the customized approach, and its output has to identify risks and describe how the designed controls meet the Customized Approach Objective and provide, in the Council's words, at least an equivalent level of protection as the defined requirement.

Notice what both of those are. They are documents. Neither of them is a control. Both of them are now assessable artefacts that did not exist under v3.2.1, and both of them are produced by writing rather than by engineering.

The honest assessment of the customized approach: it is genuinely useful and most organizations should not use it. It requires mature risk management, it transfers the burden of proof onto you, and it gives an assessor more to disagree with rather than less. It is the right tool when the defined requirement is a poor fit for a specific architecture, and the wrong tool when it is being reached for to avoid work.

Which produces the uncomfortable implication of this whole section, and it is true whether or not anybody says it out loud: v4.0 rewards documentation capability. An organization that writes clearly now passes more easily than one that engineers well. If that sounds like a criticism of the standard, it is not. It is a description of what an audit regime is.

Scope is the only lever that pays

Every hour spent shrinking the cardholder data environment returns more than any hour spent hardening it, and it is the one decision that changes what PCI DSS compliant software costs you to maintain. The arithmetic is not subtle: requirements apply per system in scope, so removing a system from scope removes every requirement that applied to it, permanently, along with the ongoing evidence burden each one carried.

Hardening a system in scope adds controls and adds evidence. Removing it adds nothing and subtracts both. These are not two strategies of similar value.

The mechanisms are well established:

• Tokenization: replace the primary account number with a token in every downstream system, the pattern behind most digital purse architectures, so those systems hold something that is worthless if exfiltrated.
• Hosted payment fields or an iframe from the provider: the account number is entered into a document your origin does not control, so it never reaches your servers.
• Network segmentation: a tested boundary between the environment that handles card data and everything else.
• Deleting stored data you never needed: the cheapest scope reduction available, and the one most often blocked by somebody's report.

The trade-off is real and should not be sold as free. Hosted fields cost you control over the payment experience: styling constraints, a slower path to a genuinely custom checkout, and a dependency on the provider's roadmap. A product manager who resists that is not being obstructive, they are pricing something you are not.

There is also an incentive worth naming. A monitoring vendor has no commercial reason to tell you to shrink the environment it monitors, and a development firm has some reason to tell you to, because scope reduction is engineering work. Read every recommendation in this category, including this one, with the author's business model in view.

One caveat that matters for the assessment rather than for the security: segmentation has to be tested to count. An asserted boundary is not a boundary. A boundary somebody attempted to cross and could not, with the result written down, is one.

What a QSA actually asks for

The shape of the questions surprises engineers, because they are questions about process history rather than about system state.

An assessor samples. They pick periods, they pick changes, they pick user accounts, and they ask for the record of each. The sample is theirs to choose, which is the property that makes the exercise meaningful and also the property that makes preparation impossible to fake. You cannot tidy up the three changes you know will be examined, because you do not know which three they are.

An engineering team's instinct is to demonstrate that the system is currently correct. Show the configuration, show the scan, show the dashboard. The assessor's question is a different tense: was it correct in April, who approved the change that made it so, and where is that approval recorded?

That is why the Report on Compliance is long. It is not a summary of your security posture, it is a record of what the assessor examined and what they concluded from each item, requirement by requirement, with the evidence identified. The reporting template published by the Council is worth reading before an assessment rather than during one, because it tells you the form the answers have to take.

The difference between teams that find assessments manageable and teams that find them brutal is not security maturity, and it is not the quality of their PCI DSS compliant software either. It is whether evidence collection is a byproduct of normal operation or a project undertaken in the eight weeks beforehand. The first costs almost nothing per day. The second costs a quarter of somebody's year, every year, and produces worse evidence.

What does a QSA look at during a PCI DSS audit?

Samples chosen by the assessor rather than offered by the entity: specific changes, specific periods, specific accounts, and the records behind each. The output is a Report on Compliance documenting what was examined and what was concluded per requirement. The questions are about the history of your process, not the current state of your systems.

The evidence you cannot create afterwards

Nothing about PCI DSS compliant software is retroactive, and everything expensive lives on the far side of that line. You can install a missing control the week before an assessment. You cannot produce twelve months of logs for a control that was not logging.

That asymmetry is the reason the costly failures are always discovered too late to fix for the current cycle. The categories where it bites are predictable:

• Log retention shorter than the assessment period: a 30-day retention default and a twelve-month look-back do not meet.
• Change approvals that happened in conversation: somebody agreed it in a call, the change was correct, and there is no artefact.
• Scan evidence not retained: the scans ran on schedule and the reports were never kept.
• Access reviews performed but not documented: the most common of the four, because the review itself feels like the deliverable.

Every one of those is a case where the control worked and the assessment failed anyway. It feels unfair the first time. It is also the rule, and it is the same rule in every audit regime, which is why this section generalizes well beyond payments.

So the question to ask about any control is not whether it is working. It is: what artefact does this leave, where does that artefact live, and how long does it survive? A control whose honest answer is "none, nowhere, not applicable" is a control you will be arguing about in a room with somebody who is paid to be unconvinced.

Buying PCI DSS compliant software rather than building it

Buying PCI DSS compliant software does not outsource the obligation. A supplier's validation covers the supplier's environment and the supplier's responsibilities, which is the same boundary problem that shows up in financial services cloud engagements. The boundary between theirs and yours does not document itself, and most buyers discover they never wrote it down at the moment an assessor asks for it.

The document that matters is a responsibility matrix: which requirements the supplier satisfies, which you satisfy, and which are shared with the split described. It is unglamorous, it takes an afternoon with the right two people, and its absence is a finding.

Ask for the supplier's Attestation of Compliance, then read three things on it before anything else. The date, because an attestation covers a period. The scope, because it may cover a different service than the one you are buying. And the version of the standard, because an AOC against a retired version tells you when they last looked.

A three-year-old AOC covering an adjacent product is a common answer and an effective one, because it is technically a document and most buyers stop at receiving it. The same third-party evidence logic drives obligations in other regimes: if you are a financial entity in the EU, your ICT providers sit inside a register you have to maintain regardless of what their own certificates say.

Four questions for a development partner who claims PCI experience

Experience with PCI DSS compliant software is the easiest credential in this field to imply and one of the hardest to hold. These four have answers that nobody who has only read the standard can produce

• Were you assessed by a QSA, or did you self-assess? Both answers are legitimate. Only one of them is what most buyers assume when they hear "PCI compliant", and a supplier who blurs the two is telling you something.
• Show me a responsibility matrix from a previous engagement: tests whether they have ever actually operated inside somebody else's scope. A supplier who has will produce one from a drawer.
• What did you do to reduce a client's scope? Separates engineers from box-tickers. A supplier who has never proposed scope reduction was optimizing their own billable surface, whether or not they noticed.
• Which requirement have you found hardest to evidence? A supplier with a specific answer has been through an assessment. A supplier who says "none, we are fully compliant" has not, and has just told you so.

The fourth is the one worth asking first, because it is the only one where a confident answer is the bad sign.

Can you produce, today, the change approval for whatever last shipped to your payment page?

If the answer took longer than a minute, that is the work, tell us what your scope looks like ->.

Further reading on the neighboring obligations: security engineering for financial services, anti money laundering software, and the EU AI Act compliance guide for the evidence logic applied to a different regime.

The one line worth keeping

A control that operated correctly and left no record is, for assessment purposes, a control that did not operate.

About the author

This article was written by Michele Cimmino at Lasting Dynamics, an EU-based custom software development company, where his work centers on software quality and continuous process evaluation. That is the same instinct this article applies to compliance: a control nobody re-examines is a control nobody can evidence.

FAQs