The Payment Card Industry Data Security Standard (PCI DSS) is an industry-mandated framework created by major card brands to protect cardholder data and sensitive authentication data (for example CVVs and PINs). If your organization stores, processes, transmits, or impacts the security of payment account data, PCI compliance is required.

Becoming PCI compliant can feel complex: merchants and service providers follow different levels, validation paths (SAQ vs ROC), and control sets. This guide simplifies the path into three steps under PCI DSS 4.0—the active standard since PCI DSS 3.2.1 was retired (March 31, 2024).

This guide covers:

Who must comply and why it matters for SaaS and commerce
Step 1: Merchant vs service provider
Step 2: Compliance levels and validation type
Step 3: Meeting the 12 requirements for your level
How SecureSlate supports evidence, monitoring, and audit readiness

When the SAQ asked about controls you forgot existed

GIF via GIPHY

Related guides:

Key takeaways

PCI DSS 4.0 is the current standard, with updates such as stronger authentication/password expectations, automated log review for critical systems, and authenticated vulnerability scanning.
Any organization that stores, processes, or transmits payment card data—or impacts another entity’s cardholder data environment—must comply.
Step 1: Classify as merchant (accepts payments) or service provider (handles or affects payment data for others).
Step 2: Determine level (primarily by transaction volume) and whether you validate via SAQ or ROC.
Step 3: Implement the 12 PCI DSS requirements and complete AOC (Attestation of Compliance).
SecureSlate helps automate evidence, continuous monitoring, and multi-framework alignment alongside PCI.

Who has to be PCI compliant?

According to the PCI Security Standards Council (PCI SSC), organizations that process, store, or transmit payment card data must meet PCI DSS. The goal is to protect consumers from unsafe handling of payment information.

Is PCI compliance necessary?

Yes, if you fall in scope. PCI DSS is not a general law—but it is a contractual and industry requirement enforced by card brands and acquirers. Non-compliance can trigger recurring fines, lost processing relationships, and breach liability.

For SaaS and technology vendors, stakes are high: payment processors, platform partners, and enterprise buyers often require demonstrated PCI compliance before contracts close.

Compliance has a cost—but it is typically far less than penalties, breach response, lawsuits, and lost revenue after a card-data incident.

Step 1: Merchant or service provider?

Entities in scope fall into one of two categories:

Type	Definition	Examples
Merchant	Directly accepts customer payments for goods or services	eCommerce retailers, restaurants, subscription billing
Service provider	Does not necessarily accept payments but touches payment data or could impact another entity’s cardholder data environment (CDE)	Hosting, MSSPs, payment facilitators, some fintech platforms

Both must be PCI compliant and validate annually through a Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)—each culminating in an Attestation of Compliance (AOC).

SAQ vs ROC (high level)

Validation	Who typically performs	Evidence depth
SAQ	Qualified internal team (often with consultant support)	Self-attested questionnaire aligned to environment
ROC	External QSA or internal ISA	Independent assessment with documentation, technical testing, interviews, sampling

Card brands or acquirers may require a higher validation level than volume alone would suggest—based on risk, prior breaches, or contractual terms.

Step 2: Determine your PCI level

Levels dictate how you validate. Transaction volume is the primary driver; your acquirer or brand has final say.

PCI compliance levels for merchants

Level	Typical threshold (annual transactions)	Validation
Level 1	Over 6 million	ROC (QSA/ISA)
Levels 2–4	Below Level 1 thresholds	Typically SAQ (confirm with acquirer)

PCI compliance levels for service providers

Level	Typical threshold	Validation
Level 1	Over 300,000 transactions/year	ROC
Level 2	Fewer than 300,000	Typically SAQ

Voluntary ROC

Many entities eligible for SAQ still pursue a ROC for:

Enterprise customer requirements
Internal security standards
Sales differentiation and trust centers

Step 3: Complete requirements for your level

Once you know merchant vs service provider, level, and SAQ vs ROC, implement controls for your cardholder data environment (CDE) scope and complete validation.

PCI DSS 4.0 introduces meaningful changes—plan for customized approach options where applicable, updated SAQ eligibility, and stronger technical expectations (scanning, logging, authentication).

The 12 PCI DSS requirements

PCI DSS v4.0 organizes 12 requirements across six goals:

Goal	Requirement
Build and maintain a secure network and systems	1. Install and maintain network security controls
	2. Apply secure configurations to all system components
Protect account data	3. Protect stored account data
	4. Protect cardholder data with strong cryptography during transmission over open, public networks
Maintain a vulnerability management program	5. Protect all systems and networks from malicious software
	6. Develop and maintain secure systems and software
Implement strong access control measures	7. Restrict access to system components and cardholder data by business need to know
	8. Identify users and authenticate access to system components
	9. Restrict physical access to cardholder data
Regularly monitor and test networks	10. Log and monitor all access to system components and cardholder data
	11. Test security of systems and networks regularly
Maintain an information security policy	12. Support information security with organizational policies and programs

Use the PCI SSC document library for official requirement text, SAQs, and AOC forms.

Level 1 — ROC and QSA/ISA

Level 1 merchants and service providers must validate through a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA).

The assessor helps:

Validate CDE scope
Review documentation
Perform technical validation (including scanning where required)
Observe processes and conduct interviews and sampling

The output is a Report on Compliance (ROC) and signed Attestation of Compliance (AOC).

Learn more about assessors in 10 things you didn't know about QSAs.

Levels 2–4 — SAQ and AOC

Lower-volume entities (per acquirer rules) may complete a Self-Assessment Questionnaire (SAQ) and AOC.

Key points:

A qualified internal resource (or consultant) can lead the SAQ.
Many SAQs require quarterly ASV scans by an Approved Scanning Vendor.
Nine SAQ types exist—selection depends on how you handle card data (e-commerce only, card-present, outsourced processing, etc.). PCI DSS 4.0 updated eligibility and supports customized approach options where allowed.
Use PCI SSC SAQ guidance to pick the correct form for your environment.

Most organizations under the Level 1 merchant transaction threshold use an SAQ—unless a brand or customer mandates ROC.

Get started with PCI DSS compliance

PCI DSS can look daunting at first—but the path is structured: classify your role, determine level and validation, then operate the 12 requirements with evidence assessors trust.

SecureSlate helps teams:

Map PCI DSS controls alongside SOC 2, ISO 27001, and other frameworks to reduce duplicate work
Automate evidence collection from cloud, identity, endpoint, and security tools (200+ integrations)
Monitor controls continuously and alert when configuration drifts
Centralize policies, risk items, and remediation owners
Prepare for SAQ or ROC with audit-ready documentation and export workflows
Support customer diligence when buyers ask how you protect payment data

Whether you are a merchant launching payments or a service provider in the card data supply chain, SecureSlate helps you move from checklist anxiety to continuous PCI readiness.

Get started for free

FAQ

Is PCI DSS 4.0 mandatory now?

Yes. PCI DSS 3.2.1 was retired; 4.0 is the active standard. Confirm transition timelines and customized approach eligibility with your QSA or acquirer.

What is the difference between SAQ and ROC?

SAQ is self-assessment for eligible entities. ROC is an independent assessment by a QSA/ISA—required for Level 1 and often requested by enterprise customers.

Do SaaS companies need PCI compliance?

If you store, process, transmit, or impact cardholder data—or customers expect it contractually—yes. Many SaaS vendors scope PCI even when payments are outsourced, depending on architecture.

What is an ASV scan?

An Approved Scanning Vendor performs external vulnerability scans required for many SAQs quarterly.

Can I use one platform for PCI and SOC 2?

Yes. Overlapping controls (access, logging, vulnerability management, policies) benefit from cross-framework mapping—SecureSlate is built for that model.

How long does PCI compliance take?

Depends on baseline maturity. Automation compresses evidence and monitoring; scope definition and first ROC/SAQ still require focused project time.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice. PCI DSS requirements, SAQ eligibility, and validation levels are determined by the PCI SSC, your acquirer, and card brands—confirm obligations with qualified assessors and counsel. Transaction thresholds and level tables summarize common guidance; your contractual requirements may differ.

How to become PCI compliant in three steps (PCI DSS 4.0 guide)