PCI DSS is the Payment Card Industry Data Security Standard. It applies to any organization that stores, processes or transmits cardholder data, or that can affect the security of the environment holding it. Whether you must prove compliance is set by your acquirer or card brand, not by the standard itself.
What does PCI DSS actually cover?
The PCI Security Standards Council describes the standard as a baseline of technical and operational requirements designed to protect payment account data. It speaks to merchants, processors, acquirers, issuers and service providers. It is written around two things: cardholder data, and the cardholder data environment (the people, processes and systems that touch it).
That second phrase matters for engineering teams. A server that never sees a card number can still be in scope if it can affect the security of one that does. A shared admin network, a CI runner with deploy rights to the payment service, or a logging pipeline that captures full card numbers all pull systems into scope.
Who needs it?
Anyone in the card flow is in the population. But the duty to validate comes from outside. The Council states that whether an entity must comply or validate compliance is at the discretion of the organizations that manage compliance programs, such as payment brands and acquirers. In practice your acquirer tells you which merchant level you are and what evidence to hand over, for example a self-assessment questionnaire or a report from a Qualified Security Assessor.
A SaaS company that never touches cards but sells to people who do can still be asked for evidence. Service providers get that request often, because their customers need it for their own assessments.
What changed in version 4.0 and 4.0.1?
Version 4.0.1 is a revision of 4.0, and the Council publishes a summary of changes between the two in its document library. Version 4.0 introduced a group of future-dated requirements, and the Council has said those had to be adopted by 31 March 2025. If you are scoping a project today, treat all of them as in force.
Examples that affect software teams include requirements on payment page scripts. The Council has issued guidance on e-commerce requirements 6.4.3 and 11.6.1, which deal with controlling and monitoring scripts on payment pages. If your checkout page loads third party JavaScript, you need an inventory of those scripts and a way to notice when one changes.
How should a software team scope the work?
Start from data flow, not from the standard. Draw where a card number enters, where it rests, and where it leaves. Everything on that path is in scope. Everything that connects to it is a candidate.
Then reduce scope on purpose. Handing card entry to a hosted payment field, or tokenizing early, can shrink the environment sharply. Smaller scope means fewer systems to evidence. Confirm the exact effect with your assessor, because the answer depends on how the integration is built.
Finally, collect evidence continuously. Assessors ask for proof that vulnerability scanning, patching, access reviews and change control happen on a schedule. An inventory of third party components and a record of what you fixed and when are the kind of artifacts that make those conversations short.
What to do
- Ask your acquirer or payment provider what validation they require of you and by when.
- Map the cardholder data flow and mark every system on it.
- List the systems that connect to that flow, and decide whether to isolate or include them.
- Inventory scripts on payment pages and third party libraries in the payment code path.
- Set a schedule for vulnerability scans and patching, and keep the records.
- Download the current standard and the summary of changes from the Council library and map your controls to it with your assessor.
Safeguard can help with the software side of this work, such as dependency inventory, vulnerability findings and compliance automation. It does not certify you. Only a Qualified Security Assessor or your acquirer's program can validate PCI DSS compliance.
Quick check
Does PCI DSS apply to a company that only uses a payment provider?
Often yes, in a lighter form. If card data never touches your systems you may fall under a simpler validation path, but your acquirer decides. Ask them and keep the answer in writing.
Is PCI DSS a law?
No. It is an industry standard. Obligations to follow it usually come from contracts with acquirers and card brands.
Sources
- PCI DSS standard page, PCI Security Standards Council
- PCI SSC Document Library
- Coffee with the Council: guidance for e-commerce requirements effective after 31 March 2025
Last reviewed: 18 October 2026.
