You’re processing payment cards, and your acquirer just dropped a compliance requirement on your desk: PCI DSS compliance. If you’re not sure what that means or why your e-commerce business needs to worry about it, you’re in the same position as thousands of other merchants.
Here’s the reality: any business that accepts, processes, stores, or transmits credit card data is in the scope of PCI DSS. That includes e-commerce companies, SaaS businesses that bill customers with cards, marketplaces that accept vendor payments, and fintech platforms. If you touch card data and you’re not compliant, you’re running on borrowed time.
The consequences of non-compliance are severe. Payment processors can suspend your merchant account. Your bank can revoke credit processing privileges. Visa, Mastercard, and other card networks can levy substantial fines. And if a breach occurs while you’re non-compliant, the financial liability can exceed the value of your entire company.
This guide walks you through everything you need to know about PCI DSS. We’ll explain what it is, who’s actually in scope, what’s changed with the new version 4.0, what the different compliance levels mean, and exactly what you need to do to become and stay compliant.
What Is PCI DSS?
PCI DSS stands for Payment Card Industry Data Security Standard. It’s a global security standard established by the Payment Card Industry Security Standards Council—an organization created by the major payment card networks: Visa, Mastercard, American Express, Discover, and JCB.
The standard exists because payment card fraud is a persistent problem. When a merchant processes a payment card insecurely, attackers can steal card data and commit fraud. That fraud hurts cardholders, issuers, and the entire payment ecosystem. PCI DSS creates a baseline security requirement for any organization in the payment card ecosystem.
It’s important to understand what PCI DSS actually is. It’s not a law. It’s a contractual requirement. When you apply for a merchant account (the ability to process credit cards), you enter into agreements with your payment processor and acquiring bank. Those agreements require you to maintain PCI DSS compliance. If you violate the standard, you breach your merchant agreement, and your processor can terminate your account.
That said, PCI DSS is as close to a legal requirement as a private standard gets. If you process payment cards in the United States, you must comply. There’s no realistic alternative.
Who Needs to Be PCI DSS Compliant? (Merchants, Service Providers, Scope Explained)
PCI DSS applies to any organization that stores, processes, or transmits payment card data. This is broader than many people realize.
A merchant is any business that accepts payment cards from customers. This includes online retailers, brick-and-mortar stores, restaurants, SaaS companies that charge customers, nonprofits that accept donations, and any other organization that runs card transactions. Most merchants deal with PCI DSS compliance.
A service provider is any vendor that processes, stores, or has access to payment card data on behalf of merchants. Payment processors are service providers. So are:
– Gateway providers (companies that authorize card transactions)
– Issuing banks (that issue credit cards)
– Acquiring banks (that settle funds to merchant accounts)
– Hosting providers (if they host systems that contain card data)
– Cloud storage providers (if you store card data there)
– Payment terminal vendors
– Point-of-sale system vendors
– Customer support platforms (if you store card data in them)
If you’re a software company providing a platform that touches payment card data, you’re a service provider, and you have to maintain PCI DSS compliance. Your customers will ask about it. If you can’t demonstrate compliance, you’ll lose deals.
The scope question is crucial: exactly what data is covered by PCI DSS?
Primary Account Number (PAN) is the full credit card number. This is always sensitive and always in scope. If any part of your system touches a complete card number, you’re in scope for PCI DSS.
Sensitive authentication data includes the Card Verification Value (CVV), PIN, and magnetic stripe data. These are in scope even if you don’t store other card data.
Other cardholder data includes the cardholder’s name, expiration date, and service code. This data is in scope and must be protected, though the requirements are somewhat less stringent than for PANs.
The key insight here is: if you’re storing full card numbers, you’re in the strictest scope. If you’re tokenizing cards (replacing the card number with a token that your system uses instead), you reduce scope. Many organizations tokenize specifically to reduce their PCI DSS burden.
PCI DSS v4.0: What Changed and Why It Matters
In 2024, the Payment Card Industry Security Standards Council released PCI DSS v4.0. This is a significant update from v3.2.1, which had been the standard for years.
The transition period runs through March 31, 2025, after which v4.0 becomes mandatory. If you’re currently on v3.2.1, you’re in the final window to understand what changes and plan your transition.
What changed?
The requirements are more prescriptive in some areas and more flexible in others. The standard now explicitly requires multi-factor authentication for remote access to systems that touch card data. It requires stronger encryption and clearer documentation of where encryption keys are managed. It requires assessment of third-party risks and vendor management processes. It requires that organizations implement application security testing and vulnerability assessment more rigorously.
One significant change: v4.0 allows “customized implementation” of certain requirements. In other words, not every organization needs to implement controls in identical ways. A startup might implement multi-factor authentication differently than a large bank. This flexibility allows compliance to be more proportional to risk, but it also requires you to document why you implemented a control the way you did.
Another key change involves cloud and virtual environments. V4.0 has enhanced requirements for organizations using containerization, Infrastructure-as-Code, and cloud-native architectures. This reflects the reality that most new payment systems run on cloud infrastructure, not on-premises servers.
Why it matters:
If you’re compliant with v3.2.1, you’re not automatically compliant with v4.0. You’ll need to assess your current implementation against the new standard and remediate gaps. For most organizations, this is a meaningful project but not an overhaul. You probably already have multi-factor authentication in place, encryption implemented, and vendor management processes defined. V4.0 requires you to be more explicit about these controls and to implement them more thoroughly.
The practical takeaway: if you’re currently compliant with v3.2.1, begin your v4.0 transition immediately. If you’re not currently compliant, build compliance to v4.0 standards rather than the older version.
The Four Merchant Levels Explained (Transaction Volume Tiers and What’s Required at Each)
PCI DSS compliance requirements vary based on your transaction volume. The Payment Card Industry defines four merchant levels, each with different compliance obligations.
Level 1: More Than 6 Million Card Transactions Per Year
These are large merchants—major retailers, national e-commerce platforms, large SaaS companies with extensive customer bases. Level 1 merchants have the strictest compliance requirements.
Level 1 merchants must comply with all PCI DSS requirements and undergo a comprehensive annual audit by a Qualified Security Assessor (QSA). They must also conduct quarterly vulnerability scans by an approved scanning vendor and maintain quarterly network segmentation checks. The compliance burden is substantial because the volume and scope of data handled is enormous.
Level 2: 1-6 Million Card Transactions Per Year
These are mid-sized merchants—growing e-commerce platforms, mid-market SaaS companies, established online retailers. Level 2 merchants must comply with all PCI DSS requirements.
For annual assessment, Level 2 merchants have two options: they can be audited by a QSA (like Level 1), or they can complete a Self-Assessment Questionnaire (SAQ) and work with their acquirer. We’ll discuss SAQs in more detail later, but the key point is that Level 2 merchants have more flexibility than Level 1. They still must conduct quarterly vulnerability scans and maintain network security.
Level 3: 20,000-1 Million Card Transactions Per Year
These are small to mid-sized businesses—local e-commerce platforms, small SaaS companies, small service providers. Level 3 merchants must comply with all PCI DSS requirements and complete an annual SAQ, typically an SAQ A-b (for merchants using a payment gateway).
The compliance burden for Level 3 is lower than Level 1 or 2. You don’t necessarily need a QSA audit (though some acquirers require it). You complete a questionnaire that your acquirer reviews. You still need to assess your systems and vulnerability scans, but the formality is reduced.
Level 4: Fewer Than 20,000 Card Transactions Per Year
These are very small merchants—single-owner businesses, nonprofits, occasional online sellers. Level 4 has the lowest compliance requirements. You must comply with PCI DSS, but your annual assessment might be as simple as completing an SAQ and maintaining basic security practices.
However, don’t confuse “lower requirements” with “no requirements.” You still need to protect card data. You still need to use secure payment processing. You still need to monitor for breaches. The difference is the formality and cost of compliance verification.
Important: Your level isn’t static. If your transaction volume grows, your level changes. A startup that starts at Level 4 and grows to Level 2 must increase their compliance rigor accordingly. Conversely, if your volume declines, you might move to a lower level.
The 12 PCI DSS Requirements Explained (Grouped Logically, Explained in Plain English)
PCI DSS has 12 core requirements. They’re grouped into logical themes. Understanding what each requires helps you build a compliant infrastructure.
Requirements 1-4: Network Infrastructure and Data Protection
Requirement 1: Install and Maintain a Firewall Configuration
Firewalls are the perimeter defense for systems that handle card data. This requirement says you must have a firewall, that it must be properly configured, and that you must document and maintain your firewall rules.
In practical terms, this means your payment systems shouldn’t be directly accessible from the internet. They should sit behind a firewall that only permits necessary traffic. You should document what traffic is allowed and why. You should review your firewall rules regularly.
If you’re using a cloud provider, your provider’s infrastructure includes firewall protections, but you’re responsible for configuring them correctly for your environment.
Requirement 2: Do Not Use Vendor-Supplied Defaults
Out-of-the-box configurations are insecure. Systems ship with default usernames and passwords to make installation easier. Default settings often have features enabled that you don’t need. This requirement says you must change defaults before your system processes card data.
Change default passwords on every system. Disable unnecessary services. Remove default user accounts. Configure systems for your specific use case. Document what you changed and why. This requirement sounds basic, but violations are remarkably common. Attackers often start by trying default credentials.
Requirement 3: Protect Stored Cardholder Data
If you store card data, you must protect it. The primary protection mechanism is encryption. You must encrypt PANs wherever they’re stored—in databases, on backups, on servers, everywhere.
The encryption key requirement is critical: you can’t store encryption keys alongside the encrypted data. Keys must be stored separately and protected. If an attacker steals your encrypted data but also has access to your keys, encryption is useless.
Better yet: consider whether you need to store card data at all. Most organizations can avoid storing PANs entirely by tokenizing (replacing the card number with a token, and letting your payment processor store the actual card). Tokenization removes the compliance burden of PAN storage.
Requirement 4: Encrypt Transmission of Cardholder Data Across Networks
When card data crosses the internet or an internal network, it must be encrypted. This typically means using TLS (Transport Layer Security)—the encryption protocol behind HTTPS.
Any time you transmit cardholder data—between your server and the payment gateway, between servers in your infrastructure, between your system and a customer’s browser—use TLS. Modern implementations use TLS 1.2 or higher.
This requirement seems obvious to security practitioners but is still violated regularly. If your system transmits card data over unencrypted HTTP instead of HTTPS, you’re in violation.
Requirements 5-9: Access Control and System Hardening
Requirement 5: Protect Systems Against Malware
You need anti-malware protection on all systems that process card data. This includes antivirus software, anti-spyware, and other malware detection tools.
In practice, this means your servers and workstations should have updated malware definitions. They should be configured to detect and quarantine malicious software. You should update malware definitions regularly—at least once per month, though more frequent updates are preferable.
Requirement 6: Develop and Maintain Secure Systems and Applications
This is a major requirement with multiple components. You must maintain systems with current security patches. You must develop custom software securely (using secure coding practices). You must address known vulnerabilities. You must test security regularly.
Specifically, this means:
– Keep your operating systems and all software updated with the latest security patches.
– When developing custom applications, use secure development practices (code reviews, security testing, input validation).
– Don’t install unnecessary services or software on systems that handle card data.
– Conduct security assessments (penetration tests, vulnerability scans) at least annually.
For SaaS companies, this requirement is continuous. You need a development process that incorporates security testing. You need to patch vulnerabilities promptly. You need to regularly assess your application for security issues.
Requirement 7: Restrict Access to Cardholder Data by Business Need to Know
Employees should only have access to card data they need to do their jobs. A customer service representative doesn’t need access to the entire payment database. An engineer working on the billing system might need access to transaction logs but not the card storage system.
This requires defining what data each role needs, implementing access controls to enforce those restrictions, and monitoring access. It also requires removing access when people leave your organization or change roles.
Requirement 8: Identify and Authenticate Access to System Components
Everyone accessing systems that handle card data must authenticate with a unique identifier (username). You must implement multi-factor authentication for all remote access. You must use strong passwords and change default credentials.
For organizations with more than a few employees, this typically means directory services (like LDAP or Azure AD) that manage user accounts centrally. For payment infrastructure, it means multi-factor authentication by default.
Requirement 9: Restrict Physical Access to Cardholder Data
Card data is usually stored digitally, but if it’s printed (transaction records, reports), physical access must be restricted. Servers that store card data must be protected from unauthorized physical access.
In practice, this means data centers have physical access controls. Your office where backups or reports are stored should be locked. Trash containing card data should be shredded. This might sound obvious, but physical security is easy to overlook in an era of cloud computing.
Requirements 10-12: Monitoring, Testing, and Policies
Requirement 10: Track and Monitor All Access to Network Resources and Cardholder Data
You must maintain detailed logs of who accessed what data, when, and what they did. These logs are your detective control—if something goes wrong, logs help you understand what happened.
Logging requirements include:
– User access to cardholder data (who logged in, when, what data they accessed)
– Administrative access to systems (who changed firewall rules, who created accounts)
– Network activity (connections to your systems)
– Failed access attempts (login attempts with wrong passwords)
These logs must be retained for at least one year, with the most recent three months immediately available for analysis. Many organizations retain logs longer for forensic purposes.
Requirement 11: Test Security Systems and Processes Regularly
Compliance isn’t a one-time achievement. You must continuously test your security. This includes:
– Vulnerability scanning with an approved scanning vendor (quarterly, and after major changes)
– Penetration testing (at least annually)
– Internal vulnerability assessments
– Configuration reviews
– Wireless access point detection (to ensure unauthorized wireless networks aren’t broadcasting card data)
These tests help you identify gaps before attackers do.
Requirement 12: Maintain a Policy That Addresses Information Security
You need a comprehensive information security policy that covers all the requirements above. This policy should outline your commitment to security, define roles and responsibilities, explain how you’ll handle incidents, and document your expectations for employees and vendors.
This policy should be reviewed and updated annually, communicated to all staff, and acknowledged by employees.
PCI DSS Scope: Cardholder Data Environment (CDE) and How to Reduce It
Understanding scope is critical to managing your compliance burden. The Cardholder Data Environment (CDE) is the sum of all systems, networks, and devices that process, store, or transmit cardholder data.
Your CDE includes:
– Servers that store card data
– Databases with PAN records
– Payment gateway connections
– Payment terminals
– Backup systems containing card data
– Any workstations from which staff access card data
Your CDE does not include:
– Systems isolated from cardholder data
– Workstations used only for general office functions
– Your website’s marketing pages (unless they collect card data)
– Internal networks that don’t touch cardholder data
The smaller your CDE, the less you need to secure. This is why many organizations aggressively reduce their CDE through tokenization and outsourcing. Here are the primary strategies:
Tokenization: Replace card numbers with tokens. A token is a meaningless identifier that only your payment processor can map back to the original card. If you tokenize, you never store the card number, and your CDE shrinks.
Payment Gateway Outsourcing: Don’t process cards directly. Instead, collect the card number from the customer in your payment form, send it directly to your payment gateway (using a hosted form or an iFrame), and the gateway handles it. Your servers never see the card number. This dramatically reduces your CDE.
P2PE (Point-to-Point Encryption): For brick-and-mortar merchants, use payment terminals that encrypt card data immediately. Your systems never see unencrypted card data.
Most modern payment systems use a combination of these strategies. Your e-commerce checkout might collect card data with a tokenizing gateway. Your recurring billing system might store tokens, not card numbers. Your backup systems might not contain any card data.
The takeaway: work with your payment processor to design a payment architecture that reduces your CDE as much as possible. Smaller CDE means lower compliance burden and lower risk.
Self-Assessment Questionnaire (SAQ) vs. QSA Audit: Which Do You Need?
Annual compliance verification happens through one of two mechanisms: a Self-Assessment Questionnaire (SAQ) or a Qualified Security Assessor (QSA) audit.
Self-Assessment Questionnaire (SAQ)
An SAQ is a detailed questionnaire that you complete, documenting how you’ve implemented each PCI DSS requirement. There are multiple versions of the SAQ, depending on your architecture.
– SAQ A: For merchants using only a fully hosted payment form (the payment form is entirely on the processor’s server, and you never touch card data). This is the simplest SAQ.
– SAQ A-ep: For e-commerce merchants using an encrypted payment form hosted on the processor’s server.
– SAQ A-b: For merchants using a payment gateway API where your checkout form collects card data and tokenizes it before sending it to your servers.
– SAQ B-IP: For merchants with IP-based payment terminals.
– SAQ D: For all other merchants (those who store, process, or transmit card data in ways that don’t fit the other categories).
The SAQ you complete depends on your payment architecture. A merchant using a hosted payment form (SAQ A) has a much simpler questionnaire than a merchant storing and processing cardholder data themselves (SAQ D).
You complete the SAQ, attest to its accuracy, and submit it to your acquirer for review. There’s no third-party verification—you’re self-certifying your compliance.
Qualified Security Assessor (QSA) Audit
A QSA is an independent firm that conducts a comprehensive audit of your PCI DSS compliance. QSAs are certified by the Payment Card Industry and have expertise in payment security.
A QSA audit involves:
– Interviewing staff
– Reviewing policies and procedures
– Testing systems and configurations
– Reviewing logs and access controls
– Verifying encryption and security controls
– Producing a detailed report on your compliance
QSA audits are expensive (typically $15,000 to $100,000+ depending on complexity) but provide high assurance of compliance. They’re required for Level 1 merchants and recommended for Level 2 merchants processing high volumes. Level 3 and 4 merchants often use SAQ instead.
Which Do You Need?
Your merchant level and payment architecture determine which approach you use. Level 1 merchants must use QSA. Level 2 merchants can choose between QSA and SAQ (though many acquirers recommend QSA). Level 3 and 4 merchants typically use SAQ.
If you’re a small merchant using a hosted payment form from a processor, you probably need SAQ A—minimal effort. If you’re building custom payment processing code, you probably need either SAQ D (which is complex) or a QSA audit (which is more rigorous but provides clearer verification).
PCI DSS Compliance Checklist: Step-by-Step
Here’s a practical, step-by-step approach to achieving PCI DSS compliance.
Step 1: Determine Your Merchant Level and Scope
First, understand where you fall. How many card transactions do you process annually? What payment architecture do you use (hosted payment form, gateway, direct processing)? This determines your compliance path.
Step 2: Map Your Cardholder Data Environment
Create a diagram of every system that touches cardholder data. Where does card data enter your environment? How does it flow through your systems? Where is it stored? Who can access it? This map is your foundation for compliance.
Step 3: Conduct a Risk Assessment
Document your current security posture. Do you have firewalls? Encryption? Access controls? Logging? Patch management? Identify gaps against the 12 requirements. This assessment guides your remediation.
Step 4: Implement Required Controls
Based on your assessment, implement controls. Encrypt PANs. Set up multi-factor authentication. Configure firewalls. Implement logging. Update systems. Document everything. If you’re at Level 1, bring in a QSA early to guide implementation. For smaller merchants, work with your acquirer—they often have guidance specific to their platform.
Step 5: Establish Security Policies
Write a comprehensive information security policy covering all 12 requirements. Define acceptable use. Outline incident response. Document password policies, patch management, access control. Make sure all staff understand these policies.
Step 6: Train Your Organization
Everyone handling card data needs to understand PCI DSS requirements and their responsibilities. Even staff without direct access to card data need basic security training.
Step 7: Implement Logging and Monitoring
Set up systems to log all access to cardholder data and maintain logs for at least one year. Implement monitoring to detect suspicious activity. Review logs regularly.
Step 8: Conduct Vulnerability Scanning
Work with an approved scanning vendor to conduct quarterly vulnerability scans. Address identified vulnerabilities. Document your remediation.
Step 9: Complete Your Annual Assessment
Either complete your SAQ or schedule your QSA audit. Be honest about your current state. If you’re not fully compliant, disclose gaps and your remediation plan.
Step 10: Maintain Compliance Continuously
Compliance isn’t a one-time project. Budget for ongoing patch management, security testing, policy updates, and staff training. Review your controls quarterly. When systems or payment architecture change, reassess scope and compliance.
Common PCI DSS Failures (and How to Avoid Them)
Patterns emerge in PCI DSS violations. Awareness helps you avoid the most common pitfalls.
Failure 1: Storing Full PANs
Many merchants unnecessarily store complete card numbers. They claim they need them for recurring billing or fraud detection. But in almost every case, they can achieve their goal without storing the PAN. Use tokenization. Use your processor’s reference tokens. Avoid this entirely.
Failure 2: Unencrypted Card Data
Card data in motion and at rest must be encrypted. Encrypted card data in databases is obvious. But what about backups? Logs? Testing environments? Many violations involve unencrypted card data in places people forget about. Ensure encryption is comprehensive.
Failure 3: Weak Authentication
Using only passwords for access to systems handling card data is insufficient. Implement multi-factor authentication, especially for remote access. Don’t accept “users prefer passwords only.” PCI DSS v4.0 makes this mandatory.
Failure 4: Default Credentials
Countless systems ship with default usernames and passwords. These aren’t changed, and attackers exploit them. Change every default. Remove every unnecessary account. This is basic but frequently violated.
Failure 5: Missing Patches
Systems with known security vulnerabilities are vulnerable. Maintain a patch management process. Test patches. Deploy them. This isn’t optional. A system with a publicly disclosed vulnerability that you haven’t patched is a violation.
Failure 6: Inadequate Access Controls
Too many people have access to cardholder data. Implement least-privilege access. People should only access what they need. Remove access when people change roles or leave the company.
Failure 7: Insufficient Logging
Logging must be comprehensive and retained for at least one year. Many organizations either don’t log sufficiently or delete logs prematurely. If you can’t produce logs showing what happened with cardholder data, you can’t prove compliance.
Failure 8: No Vulnerability Scanning
Many merchants skip vulnerability scanning, assuming their system is secure. Regular, professional vulnerability scanning catches issues manual reviews miss. This is required, not optional.
Failure 9: Inadequate Incident Response
You need a documented process for responding to security incidents. If a breach occurs and you don’t know what to do or can’t produce logs showing what happened, the situation worsens. Plan for incidents before they happen.
Failure 10: Insufficient Vendor Management
Your service providers handle card data too. If they’re compromised, you’re compromised. Verify that vendors maintain PCI DSS compliance. Have agreements in place. Test their controls.
PCI DSS Penalties for Non-Compliance
Understanding potential penalties clarifies why compliance matters.
Payment card networks (Visa, Mastercard, etc.) levy fines for violations. These fines vary but typically start at $5,000 per month and can reach $100,000+ per month for serious or repeated violations. Additionally, acquiring banks can impose fines. Payment processors can suspend or terminate merchant accounts. The cost of account termination is loss of revenue—you can’t process card payments, and customers go elsewhere.
If a breach occurs while you’re non-compliant, liability multiplies. You face network fines, customer notification costs, forensics costs, potential state attorney general investigations, and private lawsuits from affected cardholders. The financial exposure is severe.
Beyond financial penalties, there are business consequences. Losing payment processing capability is often fatal to a payment-dependent business. Customer trust erodes if a breach occurs. Insurance costs increase. Investors lose confidence.
The business case for compliance is straightforward: compliance costs far less than non-compliance.
How Soter Advisory Can Help
Navigating PCI DSS compliance requires expertise in payment security architecture, regulatory requirements, and implementation practices. It’s not something most organizations can do optimally without guidance.
Soter Advisory specializes in helping merchants and service providers achieve and maintain PCI DSS compliance. We help you understand your scope and merchant level. We conduct risk assessments. We design compliant payment architectures that minimize your CDE. We help you implement required controls. We prepare you for SAQ or QSA audit. And we maintain your compliance as your business evolves.
If you’re uncertain about your compliance obligations, or if you know compliance is required but don’t know where to start, working with experienced advisors streamlines your path. We’ve guided many organizations through this process and know the questions you need answered and the pitfalls to avoid.
Conclusion
PCI DSS compliance is a business requirement for anyone processing payment cards. It’s not optional, and it’s not something to defer until you’re larger.
The good news is that achieving compliance is manageable. You don’t need to become a security expert. You need a clear understanding of your scope and level, a systematic approach to implementing required controls, and commitment to maintaining compliance as your business grows.
Start by understanding your merchant level and payment architecture. Conduct a risk assessment. Implement required controls systematically. Document your policies. Train your team. And establish a process for continuous verification and improvement.
If you’re ready to achieve sustainable PCI DSS compliance, the first step is a conversation with advisors who understand your business and the requirements. Contact Soter Advisory today to discuss your specific situation and how we can help you build compliant payment infrastructure.
Ready to achieve PCI DSS compliance? Contact Soter Advisory today for a consultation tailored to your business.