PCI DSS Compliance

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements maintained by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover, and JCB. Any organization that stores, processes, or transmits cardholder data must comply, regardless of size or transaction volume.

Non-compliance carries real financial consequences. Card brands can levy fines of $5,000 to $100,000 per month against acquiring banks, who pass them directly to the merchant. Beyond fines, a non-compliant organization risks losing merchant processing privileges entirely, which for most businesses means the inability to accept credit cards at all.

In the event of a data breach, non-compliant organizations face forensic investigation costs, mandatory card reissuance fees ($3 to $10 per card across potentially millions of accounts), regulatory penalties, and civil liability. Companies like Target and Equifax have paid hundreds of millions in breach-related costs. The compliance investment is a fraction of breach exposure.

The card brands classify merchants into four levels based on annual transaction volume, and each level carries different validation requirements. Level 1 applies to merchants processing over 6 million transactions per year across all channels. Level 1 merchants must complete an annual Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA) and submit quarterly network scans by an Approved Scanning Vendor (ASV).

Level 2 covers merchants processing 1 million to 6 million transactions annually. These merchants may complete a Self-Assessment Questionnaire (SAQ) or undergo a QSA audit, depending on acquirer requirements. Level 3 applies to merchants processing 20,000 to 1 million e-commerce transactions per year, validated through the appropriate SAQ.

Level 4 includes all merchants processing fewer than 20,000 e-commerce transactions or up to 1 million non-e-commerce transactions annually. Despite being the smallest tier, Level 4 merchants must still complete an SAQ and may be required to perform quarterly ASV scans. All levels require quarterly ASV scans if the merchant has any internet-facing systems.

Important: any merchant that suffers a data breach can be escalated to Level 1 by the card brands, regardless of transaction volume. Compliance level is a floor, not a ceiling.

Service providers are organizations that store, process, or transmit cardholder data on behalf of other entities, or that could impact the security of cardholder data. This includes payment gateways, hosting providers, managed security services, tokenization vendors, and any third party with access to card data environments.

Level 1 service providers process or have the potential to impact more than 300,000 transactions per year. They must undergo an annual on-site QSA assessment and produce a Report on Compliance (ROC). Level 2 service providers handle 300,000 or fewer transactions and may validate compliance through SAQ D for Service Providers.

The distinction between merchant and service provider classification matters because some organizations qualify as both. A SaaS platform that processes payments for its own services (merchant) while also handling payments on behalf of its customers (service provider) must validate compliance under both classifications. Misclassifying your organization is one of the most common and costly PCI mistakes.

SAQ A is the simplest form, with roughly 30 requirements. It applies to merchants that fully outsource all cardholder data functions to PCI-compliant third parties with no electronic storage, processing, or transmission on the merchant's systems. If your checkout uses a full redirect to Stripe Checkout, PayPal, or a hosted payment page, SAQ A is likely your path. This is the minimal scope scenario.

SAQ A-EP covers e-commerce merchants that partially outsource payment processing but whose website controls how the payment page is delivered (for example, via an embedded iFrame). It includes approximately 140 requirements and demands more rigorous controls because the merchant's web server could be compromised to affect payment data. SAQ B applies to merchants using imprint machines or standalone dial-up terminals with no internet connection, while SAQ B-IP covers IP-connected terminals.

SAQ C applies to merchants with payment application systems connected to the internet but no electronic cardholder data storage. SAQ C-VT covers merchants manually entering single transactions via a virtual terminal on an isolated computer. SAQ P2PE applies to merchants using validated PCI-listed Point-to-Point Encryption (P2PE) solutions, with only about 33 requirements because the encryption hardware removes nearly all scope.

SAQ D is the most comprehensive, covering all 300+ PCI DSS requirements. It applies to merchants that directly process, store, or transmit cardholder data and to service providers that do not meet SAQ D for Service Providers criteria. If your systems touch raw card numbers at any point, you are likely in SAQ D territory.

Card vault providers operate at the highest scope tier. Their entire Cardholder Data Environment (CDE) stores raw PANs and potentially sensitive authentication data. They face full PCI DSS Level 1 service provider requirements with hundreds of controls, regular penetration testing, and annual QSA audits.

Payment gateways and processors also fall under high scope as Level 1 service providers. They transmit and often process cardholder data, requiring comprehensive network segmentation, encryption, and access controls. Payment facilitators (PayFacs) carry a unique burden: they must validate their own compliance and ensure each sub-merchant also meets PCI requirements appropriate to their level.

Companies using Stripe, PayPal, Square, or similar PCI-compliant providers benefit from dramatically reduced scope. If your integration uses a full redirect or hosted payment fields, your scope can be as low as SAQ A, roughly 30 requirements. Moving from a redirect to an embedded iFrame increases scope to SAQ A-EP. Using a direct post or client-side tokenization where your servers see card data, even briefly, can push you into SAQ D.

For e-commerce businesses, scope increases in this order: full redirect (lowest), iFrame or hosted fields (moderate), JavaScript-based tokenization (moderate-high), direct API post (highest). Choosing the right integration architecture before you build is far cheaper than re-architecting after a QSA tells you your scope is larger than expected.

Tokenization replaces actual card numbers with non-sensitive tokens that have no exploitable value if stolen. Implementing tokenization through a PCI-compliant provider can reduce your in-scope systems by 80% to 95%. The token is useless without access to the token vault, which stays within the provider's environment, not yours.

Network segmentation isolates the Cardholder Data Environment from the rest of your corporate network. Proper segmentation means that a breach of your general IT infrastructure does not automatically compromise card data. Without segmentation, your entire network is in PCI scope, which multiplies both compliance cost and audit complexity.

Point-to-Point Encryption (P2PE) encrypts cardholder data at the point of interaction (the terminal) using hardware-based encryption that prevents decryption anywhere in the merchant environment. PCI-validated P2PE solutions reduce scope by over 90% because the merchant never handles readable card data. This is the fastest path to minimal scope for brick-and-mortar businesses.

Other effective strategies include minimizing data retention (do not store what you do not need), outsourcing payment functions to PCI-compliant providers, and consolidating payment systems to reduce the number of in-scope components. Every system you remove from scope is one fewer system to monitor, patch, audit, and defend.

Requirement 1: Install and maintain network security controls (firewalls, access control lists, and segmentation between trusted and untrusted networks). Requirement 2: Apply secure configurations to all system components, removing vendor defaults and unnecessary services. Requirement 3: Protect stored account data using encryption, truncation, masking, and hashing, with strict key management. Requirement 4: Protect cardholder data with strong cryptography during transmission over open or public networks, with TLS 1.2 as the minimum.

Requirement 5: Protect all systems and networks from malicious software using regularly updated anti-malware solutions. Requirement 6: Develop and maintain secure systems and software through patching, secure coding practices, and vulnerability management. Under v4.0, this now explicitly covers custom and bespoke software with required code reviews or WAF protections. Requirement 7: Restrict access to cardholder data to only those personnel with a documented business need.

Requirement 8: Identify users and authenticate access to system components. PCI DSS v4.0 increased the minimum password length to 12 characters and expanded multi-factor authentication (MFA) requirements to all access into the CDE, not just remote access. Requirement 9: Restrict physical access to cardholder data and systems. Requirement 10: Log and monitor all access to network resources and cardholder data with centralized logging and alerting.

Requirement 11: Test security of systems and networks regularly through vulnerability scans, penetration testing, and intrusion detection. Requirement 12: Support information security with organizational policies, procedures, and a formal security awareness program. Under v4.0, service providers must perform a formal PCI scope review at least every six months.

PCI DSS v4.0 replaced v3.2.1 and all v4.0 requirements became mandatory on March 31, 2025. Organizations that have not transitioned are now out of compliance. The update represents the most significant revision to the standard since its creation, with structural changes to how requirements are organized and validated.

Key changes include expanded MFA requirements for all access into the CDE (not just remote), a minimum password length of 12 characters (up from 8), enhanced encryption requirements, and the introduction of the Customized Approach as an alternative to the Defined Approach. The Customized Approach allows organizations to meet the intent of a requirement through alternative controls, validated by the QSA, rather than following prescriptive implementation steps.

Service providers face additional obligations under v4.0. They must reassess their PCI scope at least every six months (not just annually), implement controls to detect and respond to failures of critical security controls in a timely manner, and maintain an up-to-date inventory of all trusted keys and certificates. These changes reflect the reality that service provider compromises have cascading effects across thousands of merchant environments.

For technology teams, the most impactful v4.0 changes include requirements for authenticated internal vulnerability scanning, targeted risk analysis to define the frequency of certain periodic controls, and explicit requirements for managing payment page scripts to prevent e-commerce skimming attacks. If your last assessment was under v3.2.1, a gap analysis against v4.0 should be your first priority.