The problem is that many businesses process payments without fully understanding what PCI DSS actually requires. They assume outsourcing payments covers them, or they treat annual compliance as a checkbox exercise. That misunderstanding leaves them exposed to fines, data breaches, and loss of payment processing rights.
This guide covers everything you need to know: what PCI DSS is, who must comply, the 12 requirements, compliance levels, how to achieve and maintain compliance, and what happens if you don't.
TL;DR
- PCI DSS applies to any organization that stores, processes, or transmits payment card data — merchants, SaaS platforms, and service providers alike
- 12 requirements span six control objectives — from network firewalls to physical access controls
- Compliance levels (1–4) are based on annual transaction volume and determine how you validate compliance
- Only 14.3% of organizations maintain full PCI DSS compliance at interim assessments — annual audits aren't enough
- Non-compliance can result in fines of $5,000–$100,000/month and loss of card processing privileges
What Is PCI DSS Compliance?
PCI DSS (Payment Card Industry Data Security Standard) is the global security standard for any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD).
Cardholder data includes:
- Primary Account Number (PAN)
- Cardholder name
- Expiration date
- Service code
Sensitive authentication data includes:
- Card verification codes (CVV2, CVC2, CID)
- Full track data
- PINs and PIN blocks
SAD must never be stored after authorization — even if encrypted.
Origin and Governance
PCI DSS v1.0 launched in December 2004 when Visa, Mastercard, American Express, Discover, and JCB unified their previously separate card security programs into a single standard.
The PCI Security Standards Council (PCI SSC), headquartered in Wakefield, Massachusetts, was formally established on September 7, 2006 to administer and evolve the standard.
PCI DSS v4.0.1 is the currently active version, published June 2024. Key updates include:
- Renamed Requirement 1 to "Install and Maintain Network Security Controls" (broader than just firewalls)
- Expanded MFA requirements under Requirement 8 to cover all access into the CDE, not just remote access
- Introduced a Customized Approach allowing risk-mature organizations to implement alternative controls
- Added targeted risk analysis requirements for password/passphrase change frequency
What Compliance Actually Means
Compliance has three practical components:
- Collect and transmit card data securely
- Store it according to PCI DSS's 12 security requirement domains
- Validate annually that required controls are in place — through self-assessment questionnaires, third-party audits, or both
PCI DSS is not a government law — it's contractually enforced by card brands through acquiring banks. Minnesota (2007), Nevada (2009), and Washington (2010) have incorporated it into state law, giving compliant businesses a liability safe harbor if a breach occurs.
Who Needs to Comply with PCI DSS?
The PCI DSS Quick Reference Guide is unambiguous: PCI DSS "globally applies to all entities that store, process or transmit cardholder data and/or sensitive authentication data." There is no minimum size or transaction volume that exempts a business from the standard.
This includes e-commerce companies, brick-and-mortar retailers, SaaS platforms, payment gateways, healthcare organizations, universities, and municipalities.
Merchants vs. Service Providers
| Type | Definition | Examples |
|---|---|---|
| Merchant | Accepts payment cards directly from customers | Retailers, restaurants, online stores |
| Service Provider | Third party involved in processing, storing, or transmitting card data on behalf of others | Payment gateways, hosting providers, tokenization vendors |
Both categories are subject to PCI DSS, though service providers face additional validation requirements. It's also worth noting that a merchant can qualify as a service provider if it handles card data on behalf of other businesses.
Outsourcing Doesn't Remove Responsibility
PCI DSS v4.0.1 is explicit on this point: "Use of a PCI DSS compliant third-party service provider does not make a customer PCI DSS compliant, nor does it remove the customer's responsibility for its own PCI DSS compliance."
If you use a hosted checkout page or payment iframe, your scope is reduced — but not eliminated. You still need to validate that the integration is correctly configured, that your systems don't inadvertently capture card data, and that your third-party providers maintain their compliance status annually (Requirement 12.8).
The 12 PCI DSS Requirements Explained
The 12 requirements are organized into six control objectives. Here's a concise overview:
| Control Objective | Requirements |
|---|---|
| Build and Maintain a Secure Network | 1–2 |
| Protect Account Data | 3–4 |
| Maintain a Vulnerability Management Program | 5–6 |
| Implement Strong Access Control Measures | 7–9 |
| Regularly Monitor and Test Networks | 10–11 |
| Maintain an Information Security Policy | 12 |
Build and Maintain a Secure Network (Requirements 1–2)
Requirement 1 covers network security controls — what most organizations know as firewalls. Rules must be documented, regularly reviewed, and actively maintained to restrict unauthorized traffic into and out of the Cardholder Data Environment (CDE).
Requirement 2 prohibits vendor-supplied default passwords and insecure default configurations on any system component. These defaults are publicly known and are among the first things attackers try.
Protect Cardholder Data (Requirements 3–4)
Requirement 3 mandates that stored PANs be rendered unreadable using strong cryptography — AES-128 or higher (AES-256 is a common implementation), truncation, tokenization, or hashing. A common failure point: organizations unknowingly store unencrypted PANs in log files or spreadsheets. Running a card data discovery scan is essential before any assessment.
Requirement 4 requires strong cryptography (TLS — not SSL or early TLS, which are explicitly prohibited) for all cardholder data transmitted over open or public networks.
Maintain a Vulnerability Management Program (Requirements 5–6)
- Requirement 5: Deploy up-to-date anti-malware protection on all systems
- Requirement 6: Apply timely patches to operating systems, firewalls, databases, and POS terminals — unpatched systems remain one of the most common attacker entry points
Implement Strong Access Controls (Requirements 7–9)
- Requirement 7: Restrict access to cardholder data based on business need-to-know, using role-based access control (RBAC)
- Requirement 8: Assign unique IDs to every user; require MFA for all access into the CDE (expanded in v4.0.1 beyond just remote access)
- Requirement 9: Restrict physical access to cardholder data — video surveillance, access logs, and secure media handling are all required
Regularly Monitor, Test, and Log (Requirements 10–11)
Requirement 10 mandates logging all access to system components and cardholder data. Key specifics:
- Logs reviewed at least once daily
- Retained for at least one year (minimum three months immediately available)
- Protected from unauthorized modification using file-integrity monitoring
Requirement 11 is where many organizations fall short. The Verizon 2024 Payment Security Report found Requirement 11 had the largest control gap of all requirements — only 47.6% of organizations achieved full compliance at interim assessments, with penetration testing sub-requirements at just 67.7%.
Requirements include:
- Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV)
- Annual penetration testing covering both network and application layers
- Retesting after any significant changes to the environment
Automated scanning alone won't close that gap. The sub-requirements around penetration testing demand manual validation — covering business logic flaws, complex attack chains, and authorization gaps that scanners consistently miss.
Maintain an Information Security Policy (Requirement 12)
Requirement 12 enforces organizational accountability by requiring an organization-wide security policy covering:
- Annual policy review and employee awareness training
- Formal risk assessments
- Background checks for personnel with CDE access
- A documented incident response plan
Auditors routinely flag organizations that have strong technical controls but no documented policy to prove those controls are governed and enforced.
PCI Compliance Levels: What Level Does Your Business Fall Under?
Your compliance level is determined by annual transaction volume and dictates how you validate compliance.
Merchant Levels
| Level | Transaction Volume | Validation Required |
|---|---|---|
| Level 1 | 6M+ transactions/year (or post-breach) | Annual on-site QSA audit (ROC) + quarterly ASV scans |
| Level 2 | 1M–6M transactions/year | Annual SAQ + quarterly ASV scans |
| Level 3 | 20K–1M e-commerce transactions/year | Annual SAQ + quarterly ASV scans |
| Level 4 | <20K e-commerce or up to 1M total | Annual SAQ + quarterly ASV scans (acquirer-determined) |
Card brands can manually reclassify any merchant to a higher level at their discretion — Mastercard, for example, can designate any merchant it considers high-risk as Level 1 regardless of volume.
Service Provider Levels
| Level | Who Qualifies | Validation Required |
|---|---|---|
| Level 1 | Third-Party Processors, Payment Facilitators with 300K+ annual transactions | Annual on-site QSA assessment + quarterly ASV scans |
| Level 2 | Lower-volume data storage entities | Annual self-assessment (SAQ) + quarterly ASV scans |
Reducing Your Scope
Once you know your level, the next question is how to make compliance less painful. Fewer systems in scope means a smaller audit surface, less remediation work, and lower costs. Three approaches that directly shrink your CDE footprint:
- Network segmentation: Properly implemented, this keeps non-payment systems entirely out of PCI scope — so a vulnerability in your internal tools doesn't drag your entire infrastructure into an audit
- Tokenization: Systems that only ever see tokens — not real card numbers — generally fall outside PCI scope entirely, which cuts the number of requirements you need to satisfy
- Hosted payment fields: An iframe that passes card data directly to a PCI-validated server (SAQ A-eligible) means raw card data never reaches your environment — the simplest way to shrink scope for most e-commerce setups
For example, an e-commerce merchant that switches from a direct API integration (SAQ D — all 12 requirements) to a fully hosted iframe solution (SAQ A — ~22 requirements) can cut its compliance burden significantly — often within a single billing cycle.
How to Achieve PCI DSS Compliance
Step 1 — Assess
- Document all systems, processes, and data flows involving cardholder data
- Define your CDE scope — be thorough, including connected systems that could serve as attack vectors
- Run a card data discovery scan to find unencrypted PANs in unexpected locations (logs, spreadsheets, databases)
- Determine your merchant or service provider level and the corresponding validation method
Step 2 — Remediate
Fix vulnerabilities identified during assessment, prioritizing by risk level. Common tasks:
- Patching operating systems, applications, and network devices
- Updating firewall rules and removing unnecessary services
- Replacing default credentials across all systems
- Encrypting stored PANs and implementing MFA
Remediation isn't a one-time event. New vulnerabilities emerge continuously, which is why continuous monitoring matters more than annual reviews.
Step 3 — Test
Conduct required security testing before completing your assessment:
- Internal and external vulnerability scans by an ASV (quarterly requirement)
- Penetration testing covering both network and application layers
- Retesting after any significant infrastructure changes
Penetration testing under Requirement 11 should cover both network and application layers, with findings manually validated to eliminate false positives. Automated scan output alone doesn't meet the intent of the requirement.
Step 4 — Report and Validate
| Merchant Level | Validation Method |
|---|---|
| Level 1 | Report on Compliance (ROC) by QSA + Attestation of Compliance (AOC) |
| Levels 2–4 | Self-Assessment Questionnaire (SAQ) + AOC |
Choose the right SAQ type based on how your organization handles card data:
- SAQ A: Fully outsourced card processing, with no cardholder data touching your systems
- SAQ D: Direct handling of card data, covering all PCI DSS requirements
Submit your completed documentation to your acquiring bank or card brand.
Step 5 — Monitor and Maintain
PCI compliance is not a one-time certification. The data makes this clear: only 14.3% of organizations remained fully compliant at interim assessments in 2023, down from 43.4% in 2020.
Ongoing obligations include:
- Quarterly ASV scans
- Annual penetration tests
- Daily log reviews
- Annual policy reviews and employee training
- Retesting after system changes
Verizon's research found no confirmed payment card breach at any organization validated as fully PCI DSS compliant at the time of the incident. That's the clearest case for sustained, continuous compliance over point-in-time checkboxes.
What Happens If You're Not PCI Compliant?
Financial Penalties
Acquiring banks can impose fines ranging from $5,000 to $100,000 per month for non-compliance — these are contractual penalties enforced through card brand operating rules, not PCI SSC mandates. Beyond fines:
- Post-breach forensic investigations (required and expensive — estimated $20,000–$150,000+)
- Liability for fraudulent charges
- Termination of payment processing rights
- Placement on Mastercard's MATCH list, which can prevent you from processing cards for up to five years
Business Impact
According to ISACA, nearly 1 in 3 consumers stopped doing business with a company known to have compromised cybersecurity. The IBM 2024 Cost of a Data Breach report puts the global average breach cost at $4.88 million — a 10% increase from 2023 — with 70% of breached organizations reporting significant operational disruption.
European organizations face an additional layer of exposure: a payment card breach can trigger GDPR liability on top of PCI penalties, with fines reaching €20 million or 4% of global annual turnover, whichever is higher.
Competitive and Reputational Cost
PCI compliance is increasingly a baseline trust signal — not just for regulators, but for enterprise customers, payment processors, and partners. In practice, this means:
- Enterprise procurement teams now screen for PCI compliance before shortlisting vendors
- SaaS providers and cloud-native businesses without it get eliminated early in the sales cycle
- Payment processors may restrict or revoke processing rights independent of any breach
Frequently Asked Questions
Who needs to comply with PCI DSS?
Any business that stores, processes, or transmits payment card data must comply — merchants, service providers, SaaS platforms, payment gateways, and more. There are no exemptions based on company size or transaction volume, though volume determines your validation level.
What is a PCI DSS assessment?
A formal evaluation of whether your security controls meet all 12 PCI DSS requirements. Depending on your merchant level, this is either a self-assessment (SAQ completed internally) or an on-site audit conducted by a Qualified Security Assessor (QSA).
What is the SAQ for PCI DSS?
The Self-Assessment Questionnaire lets merchants and service providers self-report their compliance status. Multiple SAQ types exist based on your integration method — SAQ A covers fully outsourced card processing, while SAQ D applies to organizations that handle card data directly.
Who can perform a PCI DSS assessment?
Level 1 merchants require a QSA (a company certified by the PCI SSC to conduct formal assessments). Lower-level merchants can use an Internal Security Assessor (ISA) or complete an SAQ directly, depending on their level and acquiring bank requirements.
How frequently does PCI DSS require penetration testing?
Requirement 11 mandates at least annually and after any significant changes to the cardholder data environment. Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are also required year-round.
How much does a PCI DSS audit cost?
SAQ self-assessments for smaller merchants run $50–$300/year. A QSA-conducted on-site audit for Level 1 merchants typically costs $30,000–$50,000, with total compliance costs (remediation, tools, and testing) often exceeding $70,000.
