PCI DSS Compliance Guide: Requirements, Costs, and Deadlines

PCI DSS compliance is now governed exclusively by version 4.0, which became the only active version on March 31, 2024, when version 3.2.1 officially retired. All merchants and service providers that handle cardholder data are now required to comply with 4.0. A second deadline passed on March 31, 2025: the 64 "future-dated" requirements that were designated best practices in 4.0 became mandatory. If you missed that date without a documented plan, you are out of compliance.

This guide explains what PCI DSS 4.0 actually requires, how merchant levels work, what SAQs and ROCs mean for your business, and what realistic compliance costs look like.

The 12 Requirements: What They Actually Mean

PCI DSS is organized into 12 high-level requirements, each with sub-requirements that total over 300 individual controls in version 4.0.

Requirement 1: Install and maintain network security controls. Firewalls and network segmentation to isolate your cardholder data environment (CDE) from other networks. In 4.0, the language shifted from "firewalls and routers" to the broader "network security controls" to accommodate cloud and virtual environments.

Requirement 2: Apply secure configurations to all system components. No default passwords, no unnecessary services running, documented configuration standards for every system type in scope.

Requirement 3: Protect stored account data. Card numbers must be rendered unreadable in storage (truncation, tokenization, encryption, or hashing). Sensitive authentication data (full magnetic stripe, CVV, PIN) must never be stored after authorization, period.

Requirement 4: Protect cardholder data with strong cryptography during transmission. TLS 1.2 minimum for all cardholder data in transit. TLS 1.3 is now explicitly recommended. Clear-text transmission of PANs over open networks is prohibited.

Requirement 5: Protect all systems and networks from malicious software. Antivirus/anti-malware on all applicable systems, with regular updates. Version 4.0 expands this to explicitly cover phishing protection.

Requirement 6: Develop and maintain secure systems and software. Secure coding practices, vulnerability management for web applications, software development lifecycle controls. New in 4.0: explicit requirements for protecting scripts on payment pages (addressing Magecart-style attacks).

Requirement 7: Restrict access to system components and cardholder data by business need to know. Role-based access control, documented access approval processes, regular access reviews.

Requirement 8: Identify users and authenticate access to system components. Multi-factor authentication is now required for all access into the CDE, not just remote access. This was a significant expansion in 4.0. Unique user IDs, strong password policies, and phishing-resistant MFA for administrative access.

Requirement 9: Restrict physical access to cardholder data. Physical security controls for data centers, server rooms, and point-of-sale terminals. Includes tamper detection for POS devices.

Requirement 10: Log and monitor all access to system components and cardholder data. Audit logs for all user activity, automated log review, log retention for at least 12 months with 3 months immediately available.

Requirement 11: Test security of systems and networks regularly. Vulnerability scans (ASV-approved quarterly external scans, internal scans), penetration testing at least annually and after significant changes, intrusion detection/prevention systems.

Requirement 12: Support information security with organizational policies and programs. Documented security policy, annual risk assessment, security awareness training, incident response plan, third-party risk management program.

Merchant Levels: What Determines Yours

Your merchant level is determined by your annual transaction volume and dictates your validation requirements. Getting this wrong means either over-investing in compliance or being out of scope without knowing it.

Level 1: More than 6 million Visa or Mastercard transactions per year, OR any merchant that has suffered a breach affecting cardholder data. Level 1 merchants must undergo an annual on-site assessment by a Qualified Security Assessor (QSA) and produce a Report on Compliance (ROC). This is the most rigorous and expensive path.

Level 2: Between 1 million and 6 million transactions per year. Level 2 merchants must complete an annual Self-Assessment Questionnaire (SAQ) and quarterly network scans by an Approved Scanning Vendor (ASV). Some acquiring banks require Level 2 merchants to have their SAQ validated by a QSA.

Level 3: Between 20,000 and 1 million e-commerce transactions per year. SAQ required annually, ASV quarterly scans required.

Level 4: Fewer than 20,000 e-commerce transactions per year, OR up to 1 million total transactions per year for non-e-commerce merchants. SAQ and quarterly scans typically required, though specific requirements vary by acquiring bank.

Most small businesses fall into Level 4. Your acquiring bank (the bank that processes your card payments) enforces compliance requirements. If you are unsure of your level, contact your acquirer directly.

SAQ vs ROC: Which One Applies to You

A Self-Assessment Questionnaire (SAQ) is a self-certification document. A Report on Compliance (ROC) is an audit report produced by a QSA after an on-site assessment. Level 1 merchants need a ROC. Everyone else typically uses an SAQ.

There are eight different SAQ types (A, A-EP, B, B-IP, C, C-VT, D, P2PE), each applying to a different merchant environment. Choosing the wrong SAQ is a common mistake.

SAQ A applies to merchants who have fully outsourced all cardholder data handling to a PCI-compliant third party and have no electronic storage, processing, or transmission of card data on their own systems. E-commerce merchants using an iframe or redirect payment page (Stripe, Square, Braintree) typically qualify. It covers only 22 requirements and is the simplest path.

SAQ A-EP applies to e-commerce merchants who redirect customers to a third-party payment processor but whose website could affect the security of the payment transaction (e.g., JavaScript on the page that contacts the payment page). More controls than SAQ A, covering 191 requirements.

SAQ B applies to merchants using only imprint machines or standalone dial-out terminals. Rare in modern environments.

SAQ D is the most complex and applies to all merchants who do not qualify for other SAQ types, including those who store cardholder data. It covers all 12 requirements and is essentially a scaled-down ROC. If you are running your own payment stack or storing card numbers, you are here.

What the March 2025 Deadline Actually Means

March 31, 2025 was the date by which all 64 future-dated requirements in PCI DSS 4.0 became mandatory. These requirements were labeled as "best practices" when 4.0 launched in March 2022 to give organizations time to implement them.

The most operationally significant future-dated requirements that became mandatory in 2025 include:

Targeted risk analysis for customized controls. If you use any customized approach (an alternative control that achieves the same security objective by different means), you must document a formal targeted risk analysis for each one.

Phishing-resistant MFA for all CDE access. Standard MFA (push notifications, TOTP apps) must be phishing-resistant (FIDO2/WebAuthn, hardware security keys) for administrative access. This is a meaningful infrastructure change for many organizations.

Payment page script integrity controls. Merchants must have a method to detect unauthorized changes to payment page scripts. This addresses Magecart attacks where attackers inject card-skimming scripts into checkout pages. Acceptable methods include Content Security Policy (CSP) headers, subresource integrity (SRI) attributes, or script monitoring tools.

Automated log reviews. Manual log review is no longer acceptable. Security Information and Event Management (SIEM) systems or equivalent automated tools are now required.

If your organization did not implement these by March 31, 2025, your QSA or SAQ should reflect non-compliance. The practical consequence is that your acquiring bank could place you in a remediation plan, increase transaction fees, or in severe cases, terminate your merchant account.

Realistic Compliance Costs by Merchant Level

PCI compliance costs vary significantly by level, environment complexity, and whether you engage a QSA or handle validation internally.

Level 4 merchants (SAQ A, fully outsourced payments): $1,000 to $5,000 per year. ASV quarterly scans run $100 to $400 per scan. SAQ completion is internal time. The main cost is ensuring your payment provider is actually PCI-compliant and obtaining their Attestation of Compliance.

Level 4 merchants (SAQ D, self-hosted payment stack): $10,000 to $40,000 per year. Penetration testing adds $5,000 to $20,000 annually. Policy documentation, security awareness training, log management tooling, and remediation effort add up quickly. Many merchants at this level underestimate the scope.

Level 3 merchants: $15,000 to $60,000 per year. Higher transaction volumes mean more complex environments. Penetration testing scope increases. MFA infrastructure, SIEM solutions, and DLP tooling become necessary.

Level 2 merchants: $40,000 to $150,000 per year. If your acquiring bank requires a QSA-validated SAQ, add $15,000 to $40,000 for QSA fees.

Level 1 merchants (full ROC): $150,000 to $500,000+ per year. QSA on-site assessment fees alone run $50,000 to $150,000. Add remediation costs, penetration testing, ASV scans, and staff time.

Common hidden costs: Tokenization or encryption implementation ($20,000 to $100,000+ one-time), SIEM deployment ($20,000 to $80,000 per year for mid-market tools like Splunk or Sentinel), network segmentation projects ($10,000 to $50,000 one-time), and legal review of third-party agreements.

The Most Common PCI Compliance Failures

The Payment Security Report, published annually by Verizon, consistently shows that a significant portion of companies are not fully compliant at the time of a breach. The most common gaps are:

Not maintaining compliance between annual assessments. Companies achieve compliance for their assessment, then let controls drift. PCI DSS requires continuous compliance, not annual compliance.

Scope creep. Organizations add systems that touch cardholder data without updating their CDE boundary. A server added to the production environment that communicates with a payment system is in scope by default.

Third-party risk management failures. Merchants assume their payment processor handles all compliance obligations. But if you have any integration, API connection, or data sharing with a payment processor, you have compliance obligations too.

Failure to implement the 2025 mandatory requirements. Many small and mid-size merchants were unaware that the future-dated requirements became mandatory in March 2025. Script integrity controls and phishing-resistant MFA are the most commonly missing.

Frequently Asked Questions

What happens if I fail a PCI DSS assessment?

Your QSA will issue a Report on Compliance noting the failed controls. Your acquiring bank will typically place you in a remediation plan with a deadline to address gaps. Non-compliance fees from acquiring banks range from $5,000 to $100,000 per month depending on the bank and merchant size. If a breach occurs while non-compliant, card brands can impose fines of $5,000 to $100,000 per month and may require a forensic investigation at your expense.

Does using Stripe or Square make me PCI compliant?

Using a third-party payment processor significantly reduces your scope, but it does not eliminate your compliance obligations. You are still responsible for the security of your systems, how you integrate with the processor, and whether your payment pages have been compromised (Magecart attacks). You must still complete the appropriate SAQ and maintain quarterly ASV scans if required.

How often does PCI DSS change?

Major versions have been released approximately every 6 to 9 years (1.0 in 2004, 2.0 in 2010, 3.0 in 2013, 4.0 in 2022). Minor updates and errata are released more frequently. The PCI Security Standards Council maintains a timeline of active requirements and future-dated items on their website (pcisecuritystandards.org).

Is PCI DSS certification the same as SOC 2?

No. PCI DSS is a payment card industry standard specifically for organizations that handle cardholder data. SOC 2 is a reporting framework for service providers, focused on security, availability, processing integrity, confidentiality, and privacy. They serve different purposes and different audiences. Some organizations pursue both, particularly SaaS companies that process payments and sell to enterprise customers who require SOC 2 reports. For a side-by-side view of how PCI DSS fits alongside other frameworks you may need, see our Cybersecurity Compliance Checklist. If you are also pursuing SOC 2, start with The Complete SOC 2 Compliance Checklist for 2026.