PCI DSS Compliance Guide: Levels, Requirements, and How to Become Compliant

We see fintech companies and SaaS platforms wrestle with PCI DSS more than almost any other framework — not because the requirements are unclear, but because scoping decisions made early in the process determine whether compliance costs $20,000 or $200,000.

If your organization processes, stores, or transmits credit card data, you need to become PCI compliant. The Payment Card Industry Data Security Standard (PCI DSS) is not optional for businesses handling cardholder data — it is mandated by the major card brands (Visa, Mastercard, American Express, Discover, and JCB) through your acquiring bank or payment processor. Non-compliance can result in fines ranging from $5,000 to $100,000 per month, increased transaction fees, and ultimately losing the ability to accept card payments.

This guide walks through everything you need to become PCI compliant: the standard's governance, the four compliance levels and what each requires, all 12 PCI DSS requirements with practical implementation guidance, the attestation of compliance process, special considerations for PCI DSS service providers, and how PCI DSS overlaps with SOC 2. Whether you are a PCI Level 3 merchant processing e-commerce transactions or a service provider handling card data on behalf of others, you will find the clarity you need.

What Is PCI DSS?

PCI DSS is a global security standard developed and maintained by the PCI Security Standards Council (PCI SSC), an organization founded by the five major card brands. The standard establishes technical and operational requirements for protecting cardholder data throughout the transaction lifecycle — from the point of capture through processing, transmission, and storage.

The current version, PCI DSS 4.0, was released in March 2022 with a transition period from PCI DSS 3.2.1. As of March 2025, all organizations must comply with PCI DSS 4.0, including the future-dated requirements that were previously optional.

Who Must Comply

PCI DSS applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data. This includes:

• Merchants — Any business that accepts card payments, whether online, in-store, or by phone
• Service providers — Organizations that process, store, or transmit cardholder data on behalf of merchants (payment processors, hosting providers, managed service providers)
• Acquiring banks — Financial institutions that process card transactions for merchants

The scope extends to all system components that are included in or connected to the cardholder data environment (CDE). Reducing your CDE scope through tokenization, network segmentation, and outsourcing to PCI-compliant processors is one of the most effective strategies for reducing compliance cost and complexity.

PCI DSS Compliance Levels

PCI DSS defines four merchant levels and two service provider levels, each with different validation requirements. Your level is determined by your annual transaction volume and is assigned by your acquiring bank or the card brands directly.

Merchant Levels

Level	Annual Transactions	Validation Requirements
Level 1	Over 6 million (any channel)	Annual Report on Compliance (ROC) by QSA, quarterly ASV scans
Level 2	1-6 million	Annual Self-Assessment Questionnaire (SAQ), quarterly ASV scans
Level 3	20,000-1 million e-commerce	Annual SAQ, quarterly ASV scans
Level 4	Under 20,000 e-commerce or up to 1 million other	Annual SAQ, quarterly ASV scans (recommended)

PCI Level 3 is the compliance level with the highest search volume because it captures the broad middle ground of e-commerce businesses — large enough to process meaningful transaction volumes but not large enough to require the full QSA assessment of Level 1. If you are a Level 3 merchant, you will typically complete SAQ A (if you fully outsource cardholder data handling) or SAQ A-EP (if your website can impact the security of payment transactions).

Service Provider Levels

Level	Annual Transactions	Validation Requirements
Level 1	Over 300,000	Annual ROC by QSA, quarterly ASV scans
Level 2	Under 300,000	Annual SAQ-D, quarterly ASV scans

PCI DSS Requirements Overview

PCI DSS 4.0 organizes its requirements into six goals and 12 requirements. Each requirement contains detailed sub-requirements with specific technical and operational controls.

Goal	Requirement	Description
Build and Maintain a Secure Network	1. Install and maintain network security controls	Firewalls, network segmentation, traffic filtering
	2. Apply secure configurations to all system components	Change defaults, remove unnecessary services, harden systems
Protect Account Data	3. Protect stored account data	Encryption, masking, retention limits, key management
	4. Protect cardholder data with strong cryptography during transmission	TLS 1.2+, encrypted tunnels, certificate management
Maintain a Vulnerability Management Program	5. Protect all systems and networks from malicious software	Antivirus/anti-malware, application controls, phishing protection
	6. Develop and maintain secure systems and software	Secure SDLC, patch management, code reviews, web application firewalls
Implement Strong Access Control Measures	7. Restrict access to system components and cardholder data by business need-to-know	Role-based access, least privilege, access reviews
	8. Identify users and authenticate access to system components	Unique IDs, MFA, password policies, service account management
	9. Restrict physical access to cardholder data	Facility controls, visitor management, media destruction
Regularly Monitor and Test Networks	10. Log and monitor all access to system components and cardholder data	Centralized logging, log review, audit trail integrity, time synchronization
	11. Test security of systems and networks regularly	Vulnerability scans (internal/external), penetration testing, IDS/IPS, file integrity monitoring
Maintain an Information Security Policy	12. Support information security with organizational policies and programs	Security policy, risk assessment, security awareness training, incident response

For organizations running file integrity monitoring tools as part of Requirement 11, see our detailed guide on file integrity monitoring for PCI DSS.

Attestation of Compliance (AoC)

The PCI DSS Attestation of Compliance is the formal document that confirms your organization meets PCI DSS requirements. It is what your customers, partners, and acquiring bank will request as proof of compliance.

SAQ Types

Self-Assessment Questionnaires come in several variations based on how you handle cardholder data:

SAQ Type	Applies To	Approximate Questions
SAQ A	Card-not-present merchants that fully outsource cardholder data to PCI-compliant third parties	~25
SAQ A-EP	E-commerce merchants whose website can impact payment transaction security	~140
SAQ B	Merchants using imprint machines or standalone dial-out terminals	~40
SAQ B-IP	Merchants using standalone IP-connected PTS terminals	~80
SAQ C	Merchants with payment application systems connected to the internet	~160
SAQ C-VT	Merchants using web-based virtual payment terminals	~80
SAQ D (Merchant)	All other merchants	~330
SAQ D (Service Provider)	PCI DSS service providers	~330

QSA vs. Self-Assessment

Level 1 merchants and Level 1 service providers must engage a Qualified Security Assessor (QSA) to conduct an on-site assessment and produce a Report on Compliance (ROC). A QSA is an individual certified by the PCI SSC who works for a Qualified Security Assessor Company (QSAC).

Levels 2-4 merchants can self-assess using the appropriate SAQ, though many Level 2 merchants voluntarily engage a QSA for added rigor and credibility. When choosing a QSA, look for experience in your industry and technology stack, and verify their certification status on the PCI SSC website.

PCI DSS for Service Providers

If you are a PCI DSS service provider — meaning you process, store, or transmit cardholder data on behalf of merchants — you face additional requirements beyond what merchants must implement.

Additional Service Provider Requirements

• Requirement 3.5.1.2 — Service providers must use different encryption keys for each customer
• Requirement 8.3.10.1 — Service providers must change customer passwords at least every 90 days if passwords are the only authentication factor
• Requirement 11.4.7 — Service providers must support their customers' penetration testing needs
• Requirement 12.4.1 — Executive management must establish responsibility for protection of cardholder data
• Requirement 12.9 — Service providers must acknowledge in writing that they are responsible for the security of cardholder data they possess

Service providers completing SAQ D face approximately 330 questions — the most comprehensive self-assessment. Many PCI DSS service provider organizations find that engaging a QSA streamlines the process despite it not being required for Level 2.

How to Become PCI Compliant

Follow this step-by-step implementation path from gap analysis to attestation:

Step 1: Determine Your Level and SAQ Type

Confirm your annual transaction volume with your acquiring bank to establish your merchant or service provider level. Then identify which SAQ applies based on how you handle cardholder data.

Step 2: Define Your Cardholder Data Environment

Map every system, network, and process that stores, processes, or transmits cardholder data. This includes databases, applications, network segments, and any connected systems. The goal is to minimize your CDE through scope reduction techniques.

Step 3: Conduct a Gap Analysis

Assess your current controls against each applicable PCI DSS requirement. Document what is in place, what is partially implemented, and what is missing entirely. Prioritize high-risk gaps (encryption, access controls, logging) first.

Step 4: Remediate Gaps

Implement the technical controls, policies, and procedures needed to address identified gaps. This might include deploying encryption, implementing MFA, establishing log monitoring, or reconfiguring network segmentation.

Step 5: Document and Test

Complete your SAQ or prepare for your QSA assessment. Run required ASV vulnerability scans and penetration tests. Ensure all policies and procedures are documented and evidence is available.

Step 6: Submit Your Attestation

Complete the Attestation of Compliance and submit it to your acquiring bank. Maintain compliance through ongoing monitoring, quarterly ASV scans, and annual reassessment.

PCI DSS and SOC 2

PCI DSS and SOC 2 are complementary frameworks with significant control overlap, particularly in areas like access control, logging, encryption, and change management. Organizations serving both fintech customers and broader enterprise clients often pursue both certifications.

Key differences: PCI DSS is prescriptive (specifying exact requirements like "TLS 1.2 or higher"), while SOC 2 is principles-based (requiring "encryption of data in transit" without specifying the protocol). PCI DSS is specifically about cardholder data protection, while SOC 2 covers your entire security program.

For a detailed exploration of how these frameworks work together, see our guide on SOC 2 and PCI DSS for fintech. Organizations pursuing multiple frameworks should consider a multi-framework compliance strategy to maximize control reuse.

For cloud-specific PCI considerations including Stripe integration and cloud storage, see our guide on PCI compliance for cloud and SaaS.

Ready to streamline your PCI DSS compliance? Contact Agency for a gap assessment and a clear path to your Attestation of Compliance.