PCI DSS: what it requires and who it applies to

PCI DSS, the Payment Card Industry Data Security Standard, is the set of security requirements that any organisation handling cardholder data must follow, and it is the most important compliance obligation in the card business. It was created by Visa, Mastercard, American Express, Discover and JCB through the PCI Security Standards Council, and it applies to every merchant, acquirer, issuer, processor and service provider that stores, processes or transmits cardholder data. The standard has twelve requirements, from building a secure network to maintaining an information security policy, and compliance is validated annually by an assessment. A failure to comply can result in fines from the schemes, higher transaction fees, and liability for fraud losses. Why PCI DSS exists is that cardholder data is valuable to criminals and the card industry needed a single, enforceable standard to protect it. Before PCI DSS, each scheme had its own security programme, and merchants faced conflicting requirements. The unified standard created a common baseline, and the schemes made compliance a contractual obligation: a merchant that does not comply can be fined, can have its ability to accept cards withdrawn, and can be held liable for the cost of a breach. The standard is not a law, but it is enforced through the scheme rules and the acquiring contracts, which makes it effectively mandatory for anyone in the card business. The parties are the merchant that accepts the card, the acquirer that processes the merchant transactions, the payment service provider that handles the data, the card schemes that enforce the standard, and the Qualified Security Assessor, known as a QSA, that validates compliance. Merchants are classified into four levels by transaction volume: Level 1 merchants process over six million transactions a year and must undergo an on-site assessment by a QSA, while Level 4 merchants process under twenty thousand e-commerce transactions and may self-assess with a questionnaire. Service providers have their own levels, and a Level 1 service provider must also undergo an on-site assessment. In practice the twelve requirements fall into six groups. Build and maintain a secure network, which means firewalls and no vendor default passwords. Protect cardholder data, which means encryption in transit and at rest, and never storing the full magnetic stripe data, the card verification value, or the PIN block after authorisation. Maintain a vulnerability management programme, which means patching and anti-malware. Implement strong access control, which means unique IDs, restricted access, and multi-factor authentication for remote access. Regularly test security systems, which means vulnerability scans and penetration tests. Maintain an information security policy, which means training and incident response. Each requirement has testing procedures, and the assessor checks evidence for every one. Protect stored cardholder data, which means encryption and tokenisation, and restrict access to it on a need-to-know basis. A worked example shows the scope decision. A small online merchant uses a hosted payment page, so the cardholder never enters card data on the merchant website: the customer is redirected to the payment service provider page, which collects the data. That merchant is eligible for the simplest self-assessment questionnaire, SAQ A, because it does not store, process or transmit cardholder data on its own systems. A larger merchant that takes card data on its own website and sends it to its acquirer must complete SAQ D, the full questionnaire, and must meet all twelve requirements. The difference in effort is enormous, which is why many merchants choose a hosted page or a tokenisation service to reduce their PCI DSS scope. What happens when an organisation fails PCI DSS is a breach, and the consequences are severe. If cardholder data is stolen, the schemes will fine the acquirer, the acquirer will pass the fine to the merchant, and the merchant may also have to pay for forensic investigation, card reissuance, and fraud losses. A single breach can cost millions of pounds, and the reputational damage can be worse. The incident response plan, which is a PCI DSS requirement, must be tested annually, and the organisation must be able to show that it detected the breach, contained it, notified the schemes and the acquirer, and remediated the cause. A merchant that cannot show its compliance evidence will be treated as non-compliant, even if its systems were secure. The operational and accounting implications are that PCI DSS compliance is a continuous programme, not a one-off project. The security team must run quarterly vulnerability scans, the infrastructure team must patch systems within the required timeframes, and the compliance team must maintain the evidence. On the ledger, the cost of compliance, including the QSA assessment, the scans, and the remediation, is a real operating cost that must be budgeted, and the cost of non-compliance, including fines and breach liability, must be modelled as a risk. The finance team must also understand that a PCI DSS fine is not a tax deduction in every jurisdiction, and the legal team must review the acquiring contract for the liability clauses. For a business analyst, PCI DSS is a scope and evidence subject. When you specify a payment product, you must define the cardholder data flow, identify every system that stores, processes or transmits cardholder data, and determine the applicable SAQ or the need for a QSA assessment. You must also specify the tokenisation approach, because replacing the card number with a token is the most effective way to reduce PCI DSS scope, and you must specify the evidence that the compliance team will need to collect. A common gap is failing to document the data flow, which means the assessor cannot determine the scope and the project is delayed. Takeaway: PCI DSS is not a security checklist, it is a contractual obligation with fines, and the cheapest way to comply is to avoid holding cardholder data at all. Further reading: the PCI Security Standards Council PCI DSS v4.0 for the twelve requirements; the Visa rules for compliance validation; the Mastercard rules for the site data protection programme. Last reviewed 7 November 2026. A merchant that outsources card handling to a compliant provider still owns the obligation, so the contract must say so.