PCI DSS

What Is PCI DSS?

PCI DSS is a set of security standards that apply to any organization handling credit card data. Created in 2004 by the major card brands (Visa, Mastercard, American Express, Discover, JCB), it's maintained by the PCI Security Standards Council. The standard exists because card fraud costs the industry billions annually, and the card brands decided that every company in the payment chain needed minimum security standards.

If your business stores, processes, or transmits cardholder data, PCI DSS applies to you. There's no opt-out. The current version is PCI DSS v4.0.1, which replaced v3.2.1. All organizations were required to comply with v4.0 by March 31, 2024, and the remaining "future-dated" requirements in v4.0.1 became mandatory on March 31, 2025.

Who Needs to Comply?

PCI DSS applies more broadly than most companies realize:

• E-commerce businesses accepting online payments
• Brick-and-mortar retailers with card terminals
• Payment processors and payment gateways
• SaaS platforms that store card numbers for recurring billing
• Fintech companies building payment infrastructure
• Any company that even passes card data through its systems, even momentarily

A common misconception: "We use Stripe, so we don't need PCI compliance." Wrong. Using a third-party processor reduces your scope significantly (you might qualify for the simplest self-assessment questionnaire), but you still need to validate compliance. You're responsible for how your website handles the card entry form, how you secure your account with the processor, and how you manage access to your payment dashboard.

Compliance Levels

PCI DSS groups merchants into four levels based on transaction volume per year:

• Level 1: Over 6 million transactions. Requires an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans.
• Level 2: 1 to 6 million transactions. Annual Self-Assessment Questionnaire (SAQ) and quarterly network scans.
• Level 3: 20,000 to 1 million e-commerce transactions. Annual SAQ and quarterly scans.
• Level 4: Under 20,000 e-commerce transactions or up to 1 million total transactions. Annual SAQ and quarterly scans.

Service providers have a separate two-level system: Level 1 (over 300,000 transactions) requires a QSA assessment; Level 2 can self-assess.

The SAQ comes in several versions (A, A-EP, B, B-IP, C, C-VT, D, P2PE) depending on how you handle card data. Picking the right SAQ is one of the first and most important decisions in the compliance process.

The 12 Core Requirements

PCI DSS v4.0 organizes its requirements into 6 goals and 12 requirements:

Build and Maintain a Secure Network and Systems

1. Install and maintain network security controls (firewalls, security groups)
2. Apply secure configurations to all system components (no vendor defaults, hardening)

Protect Account Data

1. Protect stored account data (encryption, truncation, masking, hashing)
2. Protect cardholder data with strong cryptography during transmission over open networks

Maintain a Vulnerability Management Program

1. Protect all systems and networks from malicious software
2. Develop and maintain secure systems and software (patching, secure development lifecycle)

Implement Strong Access Control Measures

1. Restrict access to system components and cardholder data by business need-to-know
2. Identify users and authenticate access to system components (MFA now required for all access to the cardholder data environment, not just remote access)
3. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

1. Log and monitor all access to system components and cardholder data
2. Test security of systems and networks regularly (vulnerability scans, penetration testing)

Maintain an Information Security Policy

1. Support information security with organizational policies and programs

These 12 requirements expand into over 250 individual sub-requirements. The v4.0 update added significant new mandates, including targeted risk analyses for controls where flexibility is allowed, enhanced authentication requirements, and new e-commerce security controls like script management for payment pages.

Key Changes in v4.0

The jump from v3.2.1 to v4.0 was the biggest PCI DSS update in a decade. Major changes:

• Customized approach option. Organizations can now meet requirements using alternative controls if they can prove equivalent security through a documented risk analysis. This replaces the old "compensating controls" concept with something more flexible.
• MFA everywhere in the CDE. Multi-factor authentication is now required for all access to the cardholder data environment, not just remote access from outside the network.
• Targeted risk analysis. Several requirements now let you define your own frequency (for password rotation, log reviews, etc.) based on a documented risk analysis rather than prescribing fixed intervals.
• Payment page script integrity. New requirements for managing and monitoring scripts on payment pages to prevent web skimming attacks (like Magecart). Merchants must maintain an inventory of all scripts, justify each one, and monitor for unauthorized changes.
• Automated log review. Manual log reviews are no longer sufficient; automated mechanisms are required.
• Internal vulnerability scans. Now require authenticated scanning, not just unauthenticated network scans.

The Compliance Process

1. Determine your merchant level based on annual transaction volume. This dictates whether you need a QSA assessment or can self-assess.

1. Identify the right SAQ (if self-assessing). The SAQ type depends on how your systems interact with card data. A company using a hosted payment page has very different requirements than one processing cards on its own servers.

1. Define your cardholder data environment (CDE). Map every system, network segment, and process that stores, processes, or transmits card data. This scoping exercise is critical. Over-scoping wastes money; under-scoping means you're not actually protecting what needs protection.

1. Gap assessment. Compare your current state against the applicable PCI DSS requirements. This surfaces what needs fixing.

1. Remediation. Implement missing controls: network segmentation, encryption, access controls, logging, vulnerability scanning, policies, training. This is typically the longest phase.

1. Quarterly ASV scans. Hire an Approved Scanning Vendor to perform external vulnerability scans. These must pass (no high-severity vulnerabilities) each quarter.

1. Assessment or SAQ completion. Either your QSA conducts the on-site assessment (Level 1) or you complete the appropriate SAQ (Levels 2-4). Submit the Attestation of Compliance (AoC) to your acquiring bank or payment brand.

What It Costs

Costs vary dramatically by merchant level and environment complexity:

• Level 4 merchant using Stripe/hosted payments (SAQ A): $1,000-$5,000/year (mostly scan fees and time to complete the SAQ)
• Level 2-3 merchant with moderate CDE: $15,000-$50,000/year
• Level 1 merchant requiring QSA assessment: $50,000-$200,000+/year
• Service providers: $70,000-$500,000+ depending on scope

The biggest cost driver is scope. Companies that architect their systems to minimize the cardholder data environment (using tokenization, hosted payment pages, and network segmentation) spend far less on compliance than those processing cards on their own infrastructure.

How Compliance Tools Help

PCI DSS has over 250 sub-requirements, each needing evidence. Compliance automation platforms track your control status against the PCI DSS requirement map, pull evidence from cloud infrastructure and security tools, manage quarterly scan scheduling, and flag gaps before your annual assessment.

For companies also pursuing SOC 2 or ISO 27001, the control overlap is around 40-60%. Tools that map across multiple frameworks let you reuse evidence and avoid duplicating work. All 17 tools in our database support PCI DSS.

Common Mistakes

Thinking a payment processor eliminates PCI obligations. Stripe, Braintree, and Adyen reduce your scope, but they don't remove your compliance responsibility. You still need to complete an SAQ and may need quarterly scans.

Scoping mistakes. Either including too many systems (expensive and time-consuming) or missing systems that touch card data (which means those systems aren't actually protected). Get scoping right before doing anything else.

Ignoring the v4.0 changes. Companies that validated against v3.2.1 for years and assumed v4.0 was just a minor update are finding significant gaps, especially around MFA, script monitoring, and authenticated scanning.

Treating compliance as annual. PCI DSS requires continuous control operation. Quarterly scans, regular log reviews, and ongoing monitoring aren't things you do the week before your assessment. Auditors and acquirers are increasingly looking for evidence of year-round compliance.

Not segmenting the network. Without network segmentation, your entire network is in scope for PCI DSS. Proper segmentation reduces the CDE to just the systems that actually handle cards, which reduces cost, complexity, and risk.