The PCI Compliance Process: Step-by-Step Under PCI DSS v4.0

If your business accepts card payments — even entirely through Stripe — you have PCI DSS obligations. The good news is that the compliance process is well-defined and, for most companies, far lighter than the standard's 300+ requirements suggest, because scope determines everything. A SaaS company that never touches card numbers can validate with a short self-assessment questionnaire; a payment processor faces a full on-site assessment.

This guide walks the entire PCI compliance process: what v4.0 changed, how to determine your level and validation type, how to shrink scope with segmentation and tokenization, and how to keep compliance running year-round. For framework fundamentals, see our PCI DSS learning hub and the PCI DSS framework overview.

PCI DSS v4.0: Where the Standard Stands in 2026

PCI DSS is maintained by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB). It is not government law; it is a contractual requirement flowing from the card brands through acquiring banks to every merchant and service provider that stores, processes, or transmits cardholder data — or that could affect its security.

The version timeline that matters:

• v3.2.1 retired March 31, 2024 — v4.x has been the only assessable standard since.
• March 31, 2025: the ~50 "future-dated" v4.0 requirements became mandatory. These are no longer best practices — assessors test them. Highlights: MFA for all access to the cardholder data environment (not just admins), stronger password rules (12+ characters), automated log review, authenticated internal vulnerability scans, payment-page script integrity and management (Req 6.4.3), tamper/change detection on payment pages (Req 11.6.1), and documented, periodically confirmed scope.
• v4.0.1 is the current maintenance revision — clarifications, no new requirements.

Two philosophical changes in v4.x worth knowing: the customized approach, which lets mature organizations meet a requirement's objective with alternative controls (documented and tested — realistic mainly for large enterprises), and the targeted risk analysis, which lets you set your own frequencies for certain periodic activities based on documented risk.

The Process at a Glance: Assess → Remediate → Report

The PCI Council frames compliance as a continuous three-phase loop:

1. Assess — Identify where cardholder data lives, define the cardholder data environment (CDE), and evaluate the applicable requirements against your environment.
2. Remediate — Fix gaps: eliminate stored data you don't need, patch vulnerabilities, implement missing controls.
3. Report — Validate formally (SAQ or ROC), submit the Attestation of Compliance (AOC) and scan evidence to your acquirer or partners, and repeat annually.

Everything below is the practical detail of running that loop.

Step 1: Determine Your Merchant Level

Your acquiring bank assigns your level based on annual transaction volume per card brand. Levels determine how you validate, not what you must comply with — PCI DSS applies to everyone.

Service providers (anyone processing/storing/transmitting card data on behalf of others, or able to affect its security — including many SaaS platforms) have their own two-level scheme: Level 1 (over 300,000 transactions, or brand listing requirements) needs a QSA ROC; Level 2 can use SAQ D for Service Providers. Enterprise customers routinely demand a Level 1 service-provider AOC regardless.

Step 2: Scope the Cardholder Data Environment (CDE)

Scoping is the highest-leverage activity in all of PCI. The CDE is every system component that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data — plus anything on the same network segment and anything that can affect the CDE's security (connected-to systems, security tooling, admin workstations).

The scoping process:

1. Find the data. Map every payment flow end to end. Run data-discovery scans — card numbers hide in logs, databases, support tickets, call recordings, and spreadsheets. If you find stored PANs you don't need, delete them; the cheapest control is not having the data.
2. Diagram flows. v4.0 explicitly requires current network and data-flow diagrams, and an annually confirmed documented scope (every 6 months for service providers).
3. Segment aggressively. Isolate the CDE behind firewalls/security groups so the rest of your network is out of scope. Without segmentation, your entire flat network is in scope — every laptop, every server. With good segmentation, PCI applies to a small island. Segmentation controls must be penetration-tested (annually for merchants, every 6 months for service providers).
4. Verify third parties. Every service provider in your card flow (gateway, hosting, tokenization vault) must give you their AOC annually, and responsibilities must be documented in a responsibility matrix.

Tokenization: The Great Scope-Shrinker

The dominant strategy for modern merchants is to never possess card data at all:

• Use your payment provider's hosted fields/iframes (Stripe Elements, Braintree Hosted Fields) or full redirects (Stripe Checkout, PayPal) so card numbers go from the customer's browser straight to the processor.
• Store only the returned token for repeat billing. Tokens are useless to attackers and out of PCI scope.
• Result: no CHD storage, minimal CDE, and eligibility for the shortest SAQs. The difference between SAQ A (~30 questions) and SAQ D (200+ questions) is architectural, and tokenization is how you earn it.

Note that v4.0 pulled even outsourced e-commerce closer: SAQ A merchants now face requirements around payment-page script management and change detection, because attackers pivoted to skimming scripts (Magecart) precisely where merchants assumed they had no obligations.

Step 3: Pick Your Validation Path — SAQ Types

Self-Assessment Questionnaires match your payment channel architecture:

The A vs A-EP distinction catches many engineering teams: a redirect/iframe integration keeps you in SAQ A; a direct-post form where your page handles or serves the payment code pushes you into A-EP with roughly five times the requirements. Confirm eligibility with your acquirer before you build.

Step 4: Remediate Gaps

With scope defined and the applicable requirement set known, run a gap assessment against the 12 requirement families (network security controls, secure configurations, stored-data protection, transmission encryption, anti-malware, secure development, access restriction, identification/authentication, physical security, logging/monitoring, security testing, and security governance). Common remediation work in 2026:

• Rolling out MFA for all CDE access (now mandatory for everyone, not just admins).
• 12-character minimum passwords and modern authentication policies.
• Authenticated internal vulnerability scans and closing high-risk findings.
• Payment-page script inventories, integrity controls, and tamper alerting (Reqs 6.4.3 / 11.6.1) — usually a CSP + SRI + monitoring solution.
• Automated log review mechanisms replacing "someone looks at logs."
• Documented targeted risk analyses for requirements with flexible frequencies.
• Cleaning stored PANs out of logs and databases; verifying crypto (strong algorithms, key management).

Step 5: Validate and Report — QSA vs Self-Assessment, ROC and AOC

Self-assessment: an internal responsible party completes the SAQ honestly, gathers evidence, and an officer signs the Attestation of Compliance (AOC) — the summary document you actually send to acquirers and customers. Quarterly external scans by an Approved Scanning Vendor (ASV) with passing results accompany most SAQ types.

QSA assessment: a Qualified Security Assessor — a Council-certified firm — performs interviews, evidence review, sampling, and testing, then writes the Report on Compliance (ROC) plus the AOC. Required for Level 1; often chosen voluntarily by service providers because enterprise buyers demand a QSA-signed AOC. Large organizations can alternatively use a trained internal assessor (ISA) where the brand permits.

How to choose when you have the option:

• Self-assess if you are a small merchant with a heavily outsourced flow (SAQ A/A-EP/C) and no customer pressure for third-party validation.
• Engage a QSA if you are a service provider selling to enterprises, if your SAQ D answers involve judgment calls you don't want to own alone, or if a breach in your space has made your acquirer nervous. QSA engagements for a well-scoped environment typically run $15,000–$60,000; Level 1 ROCs for complex environments go well beyond that.

Whatever the path, the reporting package your acquirer or customers expect is: current AOC, passing ASV scan evidence, and (for ROC-level validation) the ROC executive summary on request.

Step 6: Stay Compliant — The Ongoing Calendar

v4.0's loudest theme is that PCI is continuous, not annual. A workable compliance calendar:

Miss a quarterly scan and your next validation shows a gap — acquirers can levy monthly non-compliance fees ($5,000–$100,000/month at the extreme) and raise your processing rates, and a breach while non-compliant brings forensic investigations, card-brand fines, and reissuance costs.

PCI Compliance Process Checklist

• Confirm your merchant/service-provider level with your acquirer or partners
• Map every payment flow; run data discovery for stray PANs; delete what you don't need
• Build and maintain network and data-flow diagrams
• Architect for minimal scope: hosted fields/redirects, tokenization, no CHD storage
• Segment the CDE and plan segmentation testing
• Identify your SAQ type (or ROC obligation) and confirm eligibility with your acquirer
• Gap-assess against the applicable requirements, including the 2025-mandatory v4.0 items
• Remediate: MFA everywhere in the CDE, 12+ char passwords, script integrity on payment pages, automated log review, authenticated scans
• Collect AOCs from all third-party providers; document the responsibility matrix
• Enroll with an ASV and pass quarterly external scans
• Complete annual pen testing (and segmentation testing)
• Complete the SAQ or QSA assessment; sign and submit the AOC
• Stand up the ongoing calendar with named owners for each recurring task
• Re-verify scope after every significant change

For cost-saving strategies, see our cheapest PCI DSS guide.

Frequently Asked Questions

I use Stripe for everything — am I automatically PCI compliant?

No, but you are close. Using Stripe Checkout or Elements typically makes you eligible for SAQ A, the lightest validation, and Stripe's dashboard helps generate it. You still must validate annually, keep your integration within the eligible pattern (no card data touching your servers), and — under v4.0 — pay attention to the scripts on your payment page. Outsourcing processing outsources most controls, not the obligation.

What's the difference between a ROC and an AOC?

The ROC (Report on Compliance) is the full, detailed report a QSA (or ISA) writes after a Level 1 assessment — often hundreds of pages, shared sparingly. The AOC (Attestation of Compliance) is the short signed summary attesting to the result — it accompanies both ROCs and SAQs and is the document acquirers, partners, and customers actually ask for.

How long does PCI compliance take?

For an outsourced-payments merchant (SAQ A): days to a few weeks. SAQ A-EP or C with real remediation: 1–3 months. A first full SAQ D or QSA ROC for a service provider: commonly 3–9 months including remediation, scanning history, and assessment. Scope reduction is the biggest timeline lever — re-architecting to tokenization often pays back in the first year.

What changed most with PCI DSS v4.0?

Beyond structure: MFA for all CDE access, 12-character passwords, e-commerce script management and payment-page tamper detection, automated log review, authenticated internal scans, targeted risk analyses, documented scope confirmation, and the customized approach option. All future-dated items became mandatory on March 31, 2025 — if your last assessment predates that, expect your next one to be noticeably heavier.

Do I need quarterly scans if I'm SAQ A?

ASV scan requirements depend on SAQ type and acquirer: SAQ A traditionally did not require ASV scans, while A-EP, B-IP, C, and D do. Some acquirers require scans regardless. Check your acquirer's program requirements — they are the party you answer to.

What happens if I'm breached while non-compliant?

You will likely be escalated to Level 1 validation (QSA ROC) regardless of volume, undergo a PFI (PCI Forensic Investigator) investigation at your expense, and face card-brand assessments passed down through your acquirer — plus reissuance costs, fines, and contractual damages. The post-breach costs dwarf the compliance program you were deferring.

Is PCI DSS a law?

Not federally in the US — it is a contractual obligation from the card brands via your acquirer. But some jurisdictions reference it in statute, and breach-related state laws and FTC actions can attach to the same failures. Treat it as binding: your ability to accept cards depends on it.

How AuditXYZ Helps

PCI sits alongside SOC 2, ISO 27001, and HIPAA in most companies' compliance stacks — and the right platform automates evidence across all of them, while the right assessor keeps your QSA fees proportional to your actual scope. AuditXYZ lets you compare compliance automation platforms on PCI DSS v4.0 support and multi-framework pricing, and browse vetted auditors and QSA firms with transparent cost data. Scope small, compare hard, and PCI becomes a maintenance task instead of a crisis.