PCI DSS – the Payment Card Industry Data Security Standard – is the security framework that governs how organizations handle credit and debit card data. If your website processes, stores, or transmits cardholder information in any way, compliance is not optional: it’s a contractual requirement enforced by card brands like Visa and Mastercard. This article walks through what PCI DSS actually requires, who it applies to, and what practical steps look like for a typical web-based business.
What the Standard Actually Covers
PCI DSS was created by the Payment Card Industry Security Standards Council, a body founded by major card networks in 2006. The standard defines 12 core requirements organized around six control objectives – from maintaining a secure network to monitoring and testing systems on a regular basis.
The scope extends beyond just the payment page. If your application touches cardholder data anywhere in its flow – including in logs, error messages, or session storage – that component falls within scope. Many organizations underestimate this and end up with a compliance surface far larger than they anticipated.
The Four Merchant Compliance Levels
Not every business faces the same obligations. PCI DSS groups merchants into four levels based on annual transaction volume:
Level 1 – Over 6 million card transactions per year. Requires an annual on-site audit by a Qualified Security Assessor (QSA) and quarterly external network scans.
Level 2 – 1 to 6 million transactions. Requires an annual Self-Assessment Questionnaire (SAQ) and quarterly scans.
Level 3 – 20,000 to 1 million e-commerce transactions. SAQ and quarterly scans required.
Level 4 – Fewer than 20,000 e-commerce transactions (or up to 1 million total). SAQ required; quarterly scans may be required at the acquirer’s discretion.
Most small online businesses fall into Level 4, which still carries real obligations. Dismissing compliance because the requirements seem aimed at large enterprises is one of the most common and costly mistakes in this space.
The 12 Requirements at a Glance
The requirements span network security, access controls, encryption, and monitoring. The six control objectives break down into 12 specific requirements:
Install and maintain network security controls. Apply secure configurations to all system components. Protect stored cardholder data. Protect data in transit with strong cryptography. Protect all systems against malware. Develop and maintain secure systems and software. Restrict access to cardholder data by business need to know. Identify users and authenticate access to system components. Restrict physical access to cardholder data. Log and monitor all access to network resources and cardholder data. Test security of systems and networks regularly. Support information security with organizational policies and programs.
Requirements 6 and 11 are where web application security becomes most directly relevant. Requirement 6 specifically calls for protection against OWASP Top 10 vulnerabilities – including SQL injection and XSS. Requirement 11 mandates regular vulnerability scanning using Approved Scanning Vendors (ASVs).
The Most Overlooked Technical Requirements
Encryption in transit is table stakes, but many teams miss how precisely PCI DSS specifies it. The standard requires strong protocols – TLS 1.2 or higher – and deprecates older versions entirely. Validating your SSL/TLS configuration is not just about having a certificate; it means verifying cipher suites, protocol versions, and certificate chain integrity.
Vulnerability scanning is another area where shortcuts cause problems. PCI DSS requires quarterly external scans by an ASV, and any failing result must be remediated and rescanned before the period is considered compliant. A single unresolved medium-severity misconfiguration can invalidate a quarter’s worth of work.
Logging is frequently treated as an afterthought. Requirement 10 demands that logs capture all access to cardholder data, administrative actions, and failed authentication attempts – and that logs are retained for at least 12 months, with the most recent three months immediately accessible.
A Common Misconception Worth Addressing
A widespread belief is that using a third-party payment processor – like Stripe or PayPal – eliminates PCI DSS obligations entirely. This is not accurate. Outsourcing payment processing reduces scope significantly, particularly if customers are redirected to a hosted payment page and your server never sees raw card data. But it does not eliminate compliance requirements altogether.
Your site still needs to be protected against attacks that could redirect users before they reach the payment page, inject malicious scripts into checkout flows, or compromise user sessions. E-commerce security considerations extend well beyond the checkout form itself. Even with a fully hosted payment solution, requirements around network security, access controls, malware protection, and vulnerability management still apply to the rest of your environment.
Where PCI DSS and GDPR Overlap
For businesses operating in Europe, PCI DSS compliance often runs alongside GDPR obligations. There is meaningful overlap: both frameworks require data minimization, strong access controls, encryption, and breach notification processes. GDPR security requirements for websites share technical ground with PCI DSS, but the two frameworks differ in scope – GDPR covers all personal data, while PCI DSS focuses specifically on payment card information.
Building toward one framework often advances the other, but they should be tracked separately. The specific controls, assessment processes, and penalties differ considerably between them.
Practical Steps for Getting Compliant
Start by defining your cardholder data environment (CDE) – every system, network segment, and application that stores, processes, or transmits card data. Reducing the size of this environment through network segmentation is one of the highest-leverage actions available. The smaller the scope, the fewer systems need to meet the full set of controls.
Next, identify which SAQ variant applies to your business. There are multiple types (A, B, C, D) depending on how card data flows through your systems. Choosing the wrong one and completing it incorrectly is a common compliance failure that only surfaces during a breach investigation.
From there, address technical controls in order of risk: patch known vulnerabilities, enforce TLS 1.2 or higher, implement proper logging, restrict privileged access, and establish regular vulnerability scanning. Automated daily scanning helps catch configuration drift and newly disclosed vulnerabilities between formal quarterly ASV assessments.
Frequently Asked Questions
Does PCI DSS apply if payments are handled entirely through a plugin like WooCommerce?
Yes, though scope may be reduced. If the plugin redirects to a hosted payment page and your server never sees raw card data, you likely qualify for SAQ A – the lightest questionnaire. But you still need to ensure your environment is secure, patched, and monitored. Site compromises can expose customers before they ever reach the payment page.
How often do PCI DSS requirements change?
The PCI SSC releases updated versions periodically. Version 4.0 became the mandatory standard in March 2024, replacing version 3.2.1. It introduced more flexibility in how controls are implemented, added new multi-factor authentication requirements, and introduced a customized approach option for mature security programs. Guidance written for version 3.2.1 may no longer reflect current obligations.
What are the consequences of non-compliance after a data breach?
Non-compliance during a breach typically results in fines passed through by acquiring banks, increased transaction fees, and potential loss of the ability to accept card payments. Businesses may also be held responsible for card reissuance costs. The combined financial impact – fines, forensic investigation, remediation, and reputational damage – routinely reaches hundreds of thousands of dollars even for smaller merchants.
Summary
PCI DSS compliance is a layered technical and organizational effort, not a one-time checkbox. Understanding which requirements apply to your transaction volume and how your systems actually handle card data is the necessary starting point. From there, the practical work involves tightening network controls, enforcing current encryption standards, implementing comprehensive logging, and maintaining a regular cadence of vulnerability scanning. For most web-based businesses, automated security monitoring between formal assessments is what bridges the gap between annual SAQ submissions and real-world security posture.