Summary
- The PCI compliance process consists of three steps: (1) Assess: scope your cardholder data environment and identify gaps, (2) Remediate: implement security controls and fix vulnerabilities, and (3) Report: Document and validate compliance with your acquirer.
- Before starting, answer three classification questions: Are you a merchant or service provider? How do you accept payments (determines SAQ type)? What's your transaction volume (determines level)? These answers set your entire compliance path.
- Your ongoing work follows the assess-remediate-report cycle: scope your CDE and map data flows, reduce scope then implement technical and process controls, complete your SAQ or ROC and submit with quarterly ASV scans.
- Formal validation is what happens during assessment: scoping verification, sampling for large environments, compensating control review, reporting to acquirer, and clarifications as needed.
- Scope reduction before remediation is the highest-leverage move.
PCI DSS: How a single question drives the entire standard
Payment Card Industry Data Security Standard (PCI DSS) often feels like an intimidating wall of 260+ controls designed for giants like JPMorgan Chase, but for most businesses, it boils down to answering just one question
“Are you protecting card data properly?”
Everything else is an implementation detail. To navigate this, you simply follow an ongoing operational rhythm of three steps:
These three steps serve six core goals such as building secure networks and controlling access, which are refined into 12 mandatory requirements.
Focusing on these 12 requirements provides enough depth to steer your team through the process. While the 260+ micro-controls can be complex, Delve handles that heavy lifting for you, providing a bespoke framework for your specific environment.
Let's review the PCI compliance process
Here’s how you become PCI compliant in three simple steps.
Step 1: Know who you are (before you start)
The PCI compliance journey is different for everyone. The process you follow depends on WHO you are in the PCI ecosystem. The better clarity you have of your identity, the better scope you’ll be able to draw, the less friction you’ll feel along the way. In order for that, you must answer three basic questions before doing anything else.
Question 1: Are You a Merchant or a Service Provider?
- A merchant accepts payment cards for their own goods or services.
- A service provider handles cardholder data on behalf of other companies.
Most startups are merchants. If you're selling software and taking payment, you're a merchant. If you're processing payments for other businesses or storing their customers' card data, you're a service provider. Some companies are both, which means separate compliance tracks for each role.
Why it matters
Service providers face stricter requirements and only qualify for SAQ D (the longest form). They also need to validate scope every six months instead of annually. Merchants have more options depending on how they accept payments.
Question 2: How Do You Accept Payments?
This is the big one. Your payment architecture determines which Self-Assessment Questionnaire applies to you, and SAQ types range from 22 controls to 260+. The difference between SAQ A and SAQ D isn't trivial. It's the difference between a two-week project and a six-month odyssey.
Read that table again. A company using Stripe Checkout (full redirect) answers 22 questions. A company that built its own payment form answers 260+. Same business models can have wildly different compliance burdens. This is why payment architecture decisions made early in a company's life have massive downstream consequences.
One caveat: PCI DSS 4.0 added Requirements 6.4.3 and 11.6.1, which require monitoring scripts on any page containing a payment iframe. So even SAQ A merchants have some technical work now. But it's still dramatically less than handling cards directly.
Question 3: How Many Transactions Do You Process?
Transaction volume determines your "PCI compliance level," which affects how you validate compliance.
Most startups are Level 3 or 4. The critical threshold is 6 million transactions, where you must hire a Qualified Security Assessor (QSA) for an on-site audit. Below that, self-assessment works. Your acquirer (the bank behind your payment processor) can also bump you to a higher level based on risk factors, so don't assume volume is the only consideration.
Step 2: Create a System of Ongoing Compliance Work
Once you know your classification, you must build the "operating rhythm" that keeps you compliant. This is not a one-time event, but a continuous cycle of three phases: Assess, Remediate, and Report.
Assessment Phase: Find where the data lives and what’s broken
The purpose of the assessment phase is to understand what you're protecting and where the gaps are. This phase establishes your scope (the systems that touch card data), which determines everything that follows. Rush it, and you'll pay for it later.
Remediation Phase: Shrink your scope, then fix what remains
Remediation addresses the gaps identified during assessment. The order matters here. Most companies jump straight to implementing controls. Smart companies shrink scope first.
Reporting Phase: Prove the work, then keep proving it
The reporting phase validates and documents your compliance status. This is where you prove everything you've done actually meets requirements.
Step 3: Proving it to the auditor
Your ongoing compliance work is what you do. Formal validation is what happens to it. When you submit your SAQ or undergo a QSA audit, assessors step in to verify the system you've created actually works.
This isn't a separate track running parallel to your ongoing work. It's what happens inside the Report phase when an external party steps in to verify your compliance.
Roadmap of PCI compliance process
For a startup with modern cloud infrastructure, no legacy systems, and willingness to move fast, here's what a realistic timeline looks like. SAQ A through SAQ C scenarios typically take 8-10 weeks. SAQ D with a large environment? Double or triple it. Level 1 requiring a QSA audit? Add scheduling delays and more extensive evidence collection. But the sequence stays the same.
Operationalizing the sequence: Classify, shrink, and handle
PCI compliance can feel overwhelming because it's often presented as a wall of requirements. It's not. It's a sequence: classify yourself, shrink your scope, handle what remains. That sequence, executed with discipline, turns a months-long slog into a weeks-long sprint, especially with tools like Delve that were built for this exact process.
If an enterprise deal is waiting on your compliance, or you'd rather get ahead of the inevitable security questionnaire, we can help you move from zero to certified in weeks.
About the authors
Summary
- The PCI compliance process consists of three steps: (1) Assess: scope your cardholder data environment and identify gaps, (2) Remediate: implement security controls and fix vulnerabilities, and (3) Report: Document and validate compliance with your acquirer.
- Before starting, answer three classification questions: Are you a merchant or service provider? How do you accept payments (determines SAQ type)? What's your transaction volume (determines level)? These answers set your entire compliance path.
- Your ongoing work follows the assess-remediate-report cycle: scope your CDE and map data flows, reduce scope then implement technical and process controls, complete your SAQ or ROC and submit with quarterly ASV scans.
- Formal validation is what happens during assessment: scoping verification, sampling for large environments, compensating control review, reporting to acquirer, and clarifications as needed.
- Scope reduction before remediation is the highest-leverage move.
PCI DSS: How a single question drives the entire standard
Payment Card Industry Data Security Standard (PCI DSS) often feels like an intimidating wall of 260+ controls designed for giants like JPMorgan Chase, but for most businesses, it boils down to answering just one question
“Are you protecting card data properly?”
Everything else is an implementation detail. To navigate this, you simply follow an ongoing operational rhythm of three steps:
These three steps serve six core goals such as building secure networks and controlling access, which are refined into 12 mandatory requirements.
Focusing on these 12 requirements provides enough depth to steer your team through the process. While the 260+ micro-controls can be complex, Delve handles that heavy lifting for you, providing a bespoke framework for your specific environment.
Let's review the PCI compliance process
Here’s how you become PCI compliant in three simple steps.
Step 1: Know who you are (before you start)
The PCI compliance journey is different for everyone. The process you follow depends on WHO you are in the PCI ecosystem. The better clarity you have of your identity, the better scope you’ll be able to draw, the less friction you’ll feel along the way. In order for that, you must answer three basic questions before doing anything else.
Question 1: Are You a Merchant or a Service Provider?
- A merchant accepts payment cards for their own goods or services.
- A service provider handles cardholder data on behalf of other companies.
Most startups are merchants. If you're selling software and taking payment, you're a merchant. If you're processing payments for other businesses or storing their customers' card data, you're a service provider. Some companies are both, which means separate compliance tracks for each role.
Why it matters
Service providers face stricter requirements and only qualify for SAQ D (the longest form). They also need to validate scope every six months instead of annually. Merchants have more options depending on how they accept payments.
Question 2: How Do You Accept Payments?
This is the big one. Your payment architecture determines which Self-Assessment Questionnaire applies to you, and SAQ types range from 22 controls to 260+. The difference between SAQ A and SAQ D isn't trivial. It's the difference between a two-week project and a six-month odyssey.
Read that table again. A company using Stripe Checkout (full redirect) answers 22 questions. A company that built its own payment form answers 260+. Same business models can have wildly different compliance burdens. This is why payment architecture decisions made early in a company's life have massive downstream consequences.
One caveat: PCI DSS 4.0 added Requirements 6.4.3 and 11.6.1, which require monitoring scripts on any page containing a payment iframe. So even SAQ A merchants have some technical work now. But it's still dramatically less than handling cards directly.
Question 3: How Many Transactions Do You Process?
Transaction volume determines your "PCI compliance level," which affects how you validate compliance.
Most startups are Level 3 or 4. The critical threshold is 6 million transactions, where you must hire a Qualified Security Assessor (QSA) for an on-site audit. Below that, self-assessment works. Your acquirer (the bank behind your payment processor) can also bump you to a higher level based on risk factors, so don't assume volume is the only consideration.
Step 2: Create a System of Ongoing Compliance Work
Once you know your classification, you must build the "operating rhythm" that keeps you compliant. This is not a one-time event, but a continuous cycle of three phases: Assess, Remediate, and Report.
Assessment Phase: Find where the data lives and what’s broken
The purpose of the assessment phase is to understand what you're protecting and where the gaps are. This phase establishes your scope (the systems that touch card data), which determines everything that follows. Rush it, and you'll pay for it later.
Remediation Phase: Shrink your scope, then fix what remains
Remediation addresses the gaps identified during assessment. The order matters here. Most companies jump straight to implementing controls. Smart companies shrink scope first.
Reporting Phase: Prove the work, then keep proving it
The reporting phase validates and documents your compliance status. This is where you prove everything you've done actually meets requirements.
Step 3: Proving it to the auditor
Your ongoing compliance work is what you do. Formal validation is what happens to it. When you submit your SAQ or undergo a QSA audit, assessors step in to verify the system you've created actually works.
This isn't a separate track running parallel to your ongoing work. It's what happens inside the Report phase when an external party steps in to verify your compliance.
Roadmap of PCI compliance process
For a startup with modern cloud infrastructure, no legacy systems, and willingness to move fast, here's what a realistic timeline looks like. SAQ A through SAQ C scenarios typically take 8-10 weeks. SAQ D with a large environment? Double or triple it. Level 1 requiring a QSA audit? Add scheduling delays and more extensive evidence collection. But the sequence stays the same.
Operationalizing the sequence: Classify, shrink, and handle
PCI compliance can feel overwhelming because it's often presented as a wall of requirements. It's not. It's a sequence: classify yourself, shrink your scope, handle what remains. That sequence, executed with discipline, turns a months-long slog into a weeks-long sprint, especially with tools like Delve that were built for this exact process.
21-year-old MIT dropouts raise $32M at $300M valuation led by Insight
Don't let manual compliance slow you down.
.avif)
.webp)
