A Founder's Guide to the PCI DSS Compliance Checklist
Every fintech founder eventually asks: do we really need to worry about PCI DSS, or is that someone else's problem once we're using Stripe? The honest answer sits in between. If your app touches card data anywhere, even through a PCI-validated gateway, PCI DSS applies to you, and ignoring it until a bank partner asks is how startups scramble weeks before launch. This guide walks through a practical PCI DSS compliance checklist: who it applies to, what the 12 requirements mean, how SAQ types work, and what changed in PCI DSS 4.0. None of it replaces a Qualified Security Assessor for formal validation, but it should get you further than a vendor's marketing page.
What PCI DSS Is
PCI DSS stands for Payment Card Industry Data Security Standard: requirements built to protect cardholder data, maintained by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB in 2006). Here's what surprises most founders: PCI DSS is a contractual obligation rather than a law, written into the agreements you sign with your bank, processor, or gateway. Miss it and the consequence is fines from the card brands, higher processing rates, or, worst case, losing the ability to accept cards at all. The standard applies to your cardholder data environment, or CDE: the people, processes, and technology that store, process, or transmit cardholder data, plus anything connected closely enough to affect its security.
Who PCI DSS Applies To
PCI DSS applies to any organization that stores, processes, or transmits cardholder data, or that could affect the security of a cardholder data environment. That's a broad net on purpose: merchants, processors, gateways, and software vendors whose product touches card data at any point all fall under it. Size doesn't exempt you: a two-person startup processing its first hundred transactions through Stripe is in scope the moment a real card number moves through its system. Size and volume change how you prove compliance, covered next. If you're already scoping KYC and AML requirements for a fintech MVP, PCI DSS is the parallel track for card data, and both usually surface in the same conversation with a banking partner or in broader fintech software development planning.
The Compliance Levels and SAQ Types
Card networks sort merchants into four compliance levels, mostly by annual transaction volume (thresholds vary slightly by card brand): Level 1 is over six million transactions a year or any merchant that's had a breach, Level 2 is one to six million, Level 3 is twenty thousand to a million e-commerce transactions, Level 4 is everything smaller. Nearly every startup starts at Level 4. What you do to prove compliance depends on your level. Level 1 merchants generally need an annual on-site assessment from a Qualified Security Assessor (QSA). Everyone else typically self-assesses with a Self-Assessment Questionnaire, or SAQ: yes-or-no questions mapped to whichever requirements match your setup. Which SAQ you fill out depends on how card data reaches you, not your industry or headcount. A few narrower types exist too (B, B-IP, C, P2PE); the table below covers what most startups run into.
| SAQ Type | Who It's For | What It Means for You |
|---|---|---|
| SAQ A | Fully outsourced hosted checkout; card data never touches your servers | Shortest questionnaire; the target for most startups |
| SAQ A-EP | Checkout partially hosted, but your code still touches the payment page | More scrutiny, plus tampering protections |
| SAQ C-VT | Manually entered transactions via a virtual terminal, no storage | Common for phone-based refunds |
| SAQ D (Merchant) | Doesn't fit a narrower category, or stores card data directly | Longest questionnaire; all 12 categories in full |
A quick gut check: if you've never typed a customer's card number into anything but a gateway's hosted field, you're likely SAQ A territory. The moment your own code touches or stores a raw card number, your scope jumps higher. Confirm which SAQ fits, don't assume the easy one does.
The PCI DSS Compliance Checklist (12 Requirements, Simplified)
Strip away the legal language and the PCI DSS compliance checklist comes down to twelve requirements across six goals. You won't personally implement all twelve; plenty sits with your gateway, cloud provider, or BaaS partner. Know what each one asks for anyway. 'Our vendor handles that' is only true until someone asks you to prove it.
| # | Requirement | What It Means in Practice |
|---|---|---|
| 1 | Install and maintain network security controls | Firewalls or equivalent controls between systems and untrusted networks |
| 2 | Apply secure configurations | No default passwords or vendor settings left in place |
| 3 | Protect stored account data | Don't store data you don't need; never store CVV after authorization |
| 4 | Protect cardholder data in transit | Strong encryption for card data crossing public networks |
| 5 | Protect against malware | Anti-malware tooling on systems that could be affected |
| 6 | Develop and maintain secure systems and software | Patching, secure coding, and change control for the CDE |
| 7 | Restrict access by need to know | Access limited to what each role actually requires |
| 8 | Identify users and authenticate access | Unique logins and multi-factor authentication into the CDE |
| 9 | Restrict physical access | Physical controls around hardware that handles card data |
| 10 | Log and monitor access | Audit logs covering access to card data, retained and reviewed |
| 11 | Test security regularly | Vulnerability scans and, where applicable, quarterly ASV scans |
| 12 | Support it with organizational policies | A documented security policy and formal risk assessment |
Reducing PCI Scope (Tokenization, Hosted Fields)
The fastest lever for shrinking PCI scope: never let raw card data touch your own servers. Hosted fields (an iframe or redirect the gateway controls) and tokenization do exactly that. The customer's card number goes straight to the gateway; your backend only sees a token, useless to anyone who steals it. Done right, this drops you from the heaviest questionnaire, SAQ D, to the shortest, SAQ A. We cover how this works, tokenization included, in our payment gateway integration guide. Scope reduction has limits. Network segmentation still matters with a hosted checkout; a poorly segmented network can pull unrelated systems back into scope. Outsourcing checkout doesn't outsource everything: a refund tool or a spreadsheet with a pasted card number can quietly undo the benefit.
Get a fixed-scope quote for your PCI-ready MVP
Tell us your target gateway, compliance requirements, and launch date. We'll return one number, one timeline, and a clear line between what we build and what you plug in.
Get your quoteWhat Changed in PCI DSS 4.0
PCI DSS 3.2.1 retired in March 2024. If a vendor or an old blog post still talks about 3.2.1, that's a sign the advice is stale. Version 4.0.1, a clarification release on 4.0, is current, and every requirement is mandatory now, including the ones that were only 'best practice' at first (that grace period ended March 31, 2025). A few changes matter more to a startup than the rest. Multi-factor authentication now applies to all access into the cardholder data environment, well beyond remote or admin access alone, and password minimums went from seven to twelve characters. Run an e-commerce checkout? New requirements around client-side script management and payment-page tampering, aimed at JavaScript skimming attacks, deserve a look even behind a hosted gateway. The standard also introduced a 'customized approach' for meeting requirements a different way, backed by documented risk analysis. Flexible on paper; most startups still do better with the standard defined approach at MVP stage.
Compliance software won't file your SAQ for you, but tools like Vanta, Drata, and Secureframe cut real time off evidence collection: access reviews and policy documents tracked automatically instead of chased down manually. Some now market AI-assisted evidence review to flag gaps faster, useful for busywork, not a substitute for a QSA's judgment.
Common Startup Mistakes with PCI DSS
A handful of mistakes show up again and again once we scope a fintech MVP's payment stack. Storing the CVV after authorization tops the list, usually inside a support tool built to speed up refunds. CVV storage is never allowed after authorization, encrypted or not, full stop. Card numbers pasted into logs, error trackers, or a shared spreadsheet come a close second, rarely intentional: a stack trace captures a raw request body, or an agent pastes a number into a chat thread to troubleshoot a failed charge. Assuming a PCI-validated gateway makes you compliant by association is another common one. It reduces scope significantly, a real benefit, but you still have to complete the matching SAQ and attest to it. Then there's scope creep: a CDE that starts clean and, months later, shares a network with half the company's tools because nobody drew a boundary. For the wider security practices around all of this, see our MVP security and scalability guide.
A mistake we see often: a team assumes their SAQ only needs revisiting once a year, at renewal. It's really a living document. Add a refund tool, switch gateways, or let a contractor touch the CDE without updating who's responsible, and your environment has already drifted from what you attested to.
MVP-Stage PCI Priorities
Not every requirement deserves equal attention on day one. If you're scoping payments for a fintech MVP, here's roughly where to spend your limited time first:
- Route all card data through hosted fields or a redirect from day one. Retrofitting this after your own code has touched raw numbers costs far more than building it right.
- Confirm which SAQ applies before your bank partner asks.
- Set an org-wide MFA and password baseline now, even at three people. Cheap early, expensive to bolt on later.
- Keep card data out of logs, support tools, and spreadsheets as a hard rule from the first line of payment code.
- Document your CDE boundary, even if it's a single diagram.
- Revisit scope whenever a feature touches payments differently: subscriptions, payouts, or manual refunds all expand it quietly.
- Line up a QSA relationship before you need one, especially if growth might push you toward Level 1.
Get the first three right and the rest gets noticeably easier.
Tags
Every fintech founder eventually asks: do we really need to worry about PCI DSS, or is that someone else's problem once we're using Stripe? The honest answer sits in between. If your app touches card data anywhere, even through a PCI-validated gateway, PCI DSS applies to you, and ignoring it until a bank partner asks is how startups scramble weeks before launch. This guide walks through a practical PCI DSS compliance checklist: who it applies to, what the 12 requirements mean, how SAQ types work, and what changed in PCI DSS 4.0. None of it replaces a Qualified Security Assessor for formal validation, but it should get you further than a vendor's marketing page.
What PCI DSS Is
PCI DSS stands for Payment Card Industry Data Security Standard: requirements built to protect cardholder data, maintained by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB in 2006). Here's what surprises most founders: PCI DSS is a contractual obligation rather than a law, written into the agreements you sign with your bank, processor, or gateway. Miss it and the consequence is fines from the card brands, higher processing rates, or, worst case, losing the ability to accept cards at all. The standard applies to your cardholder data environment, or CDE: the people, processes, and technology that store, process, or transmit cardholder data, plus anything connected closely enough to affect its security.
Who PCI DSS Applies To
PCI DSS applies to any organization that stores, processes, or transmits cardholder data, or that could affect the security of a cardholder data environment. That's a broad net on purpose: merchants, processors, gateways, and software vendors whose product touches card data at any point all fall under it. Size doesn't exempt you: a two-person startup processing its first hundred transactions through Stripe is in scope the moment a real card number moves through its system. Size and volume change how you prove compliance, covered next. If you're already scoping KYC and AML requirements for a fintech MVP, PCI DSS is the parallel track for card data, and both usually surface in the same conversation with a banking partner or in broader fintech software development planning.
The Compliance Levels and SAQ Types
Card networks sort merchants into four compliance levels, mostly by annual transaction volume (thresholds vary slightly by card brand): Level 1 is over six million transactions a year or any merchant that's had a breach, Level 2 is one to six million, Level 3 is twenty thousand to a million e-commerce transactions, Level 4 is everything smaller. Nearly every startup starts at Level 4. What you do to prove compliance depends on your level. Level 1 merchants generally need an annual on-site assessment from a Qualified Security Assessor (QSA). Everyone else typically self-assesses with a Self-Assessment Questionnaire, or SAQ: yes-or-no questions mapped to whichever requirements match your setup. Which SAQ you fill out depends on how card data reaches you, not your industry or headcount. A few narrower types exist too (B, B-IP, C, P2PE); the table below covers what most startups run into.
| SAQ Type | Who It's For | What It Means for You |
|---|---|---|
| SAQ A | Fully outsourced hosted checkout; card data never touches your servers | Shortest questionnaire; the target for most startups |
| SAQ A-EP | Checkout partially hosted, but your code still touches the payment page | More scrutiny, plus tampering protections |
| SAQ C-VT | Manually entered transactions via a virtual terminal, no storage | Common for phone-based refunds |
| SAQ D (Merchant) | Doesn't fit a narrower category, or stores card data directly | Longest questionnaire; all 12 categories in full |
A quick gut check: if you've never typed a customer's card number into anything but a gateway's hosted field, you're likely SAQ A territory. The moment your own code touches or stores a raw card number, your scope jumps higher. Confirm which SAQ fits, don't assume the easy one does.
The PCI DSS Compliance Checklist (12 Requirements, Simplified)
Strip away the legal language and the PCI DSS compliance checklist comes down to twelve requirements across six goals. You won't personally implement all twelve; plenty sits with your gateway, cloud provider, or BaaS partner. Know what each one asks for anyway. 'Our vendor handles that' is only true until someone asks you to prove it.
| # | Requirement | What It Means in Practice |
|---|---|---|
| 1 | Install and maintain network security controls | Firewalls or equivalent controls between systems and untrusted networks |
| 2 | Apply secure configurations | No default passwords or vendor settings left in place |
| 3 | Protect stored account data | Don't store data you don't need; never store CVV after authorization |
| 4 | Protect cardholder data in transit | Strong encryption for card data crossing public networks |
| 5 | Protect against malware | Anti-malware tooling on systems that could be affected |
| 6 | Develop and maintain secure systems and software | Patching, secure coding, and change control for the CDE |
| 7 | Restrict access by need to know | Access limited to what each role actually requires |
| 8 | Identify users and authenticate access | Unique logins and multi-factor authentication into the CDE |
| 9 | Restrict physical access | Physical controls around hardware that handles card data |
| 10 | Log and monitor access | Audit logs covering access to card data, retained and reviewed |
| 11 | Test security regularly | Vulnerability scans and, where applicable, quarterly ASV scans |
| 12 | Support it with organizational policies | A documented security policy and formal risk assessment |
Reducing PCI Scope (Tokenization, Hosted Fields)
The fastest lever for shrinking PCI scope: never let raw card data touch your own servers. Hosted fields (an iframe or redirect the gateway controls) and tokenization do exactly that. The customer's card number goes straight to the gateway; your backend only sees a token, useless to anyone who steals it. Done right, this drops you from the heaviest questionnaire, SAQ D, to the shortest, SAQ A. We cover how this works, tokenization included, in our payment gateway integration guide. Scope reduction has limits. Network segmentation still matters with a hosted checkout; a poorly segmented network can pull unrelated systems back into scope. Outsourcing checkout doesn't outsource everything: a refund tool or a spreadsheet with a pasted card number can quietly undo the benefit.
Get a fixed-scope quote for your PCI-ready MVP
Tell us your target gateway, compliance requirements, and launch date. We'll return one number, one timeline, and a clear line between what we build and what you plug in.
Get your quoteWhat Changed in PCI DSS 4.0
PCI DSS 3.2.1 retired in March 2024. If a vendor or an old blog post still talks about 3.2.1, that's a sign the advice is stale. Version 4.0.1, a clarification release on 4.0, is current, and every requirement is mandatory now, including the ones that were only 'best practice' at first (that grace period ended March 31, 2025). A few changes matter more to a startup than the rest. Multi-factor authentication now applies to all access into the cardholder data environment, well beyond remote or admin access alone, and password minimums went from seven to twelve characters. Run an e-commerce checkout? New requirements around client-side script management and payment-page tampering, aimed at JavaScript skimming attacks, deserve a look even behind a hosted gateway. The standard also introduced a 'customized approach' for meeting requirements a different way, backed by documented risk analysis. Flexible on paper; most startups still do better with the standard defined approach at MVP stage.
Compliance software won't file your SAQ for you, but tools like Vanta, Drata, and Secureframe cut real time off evidence collection: access reviews and policy documents tracked automatically instead of chased down manually. Some now market AI-assisted evidence review to flag gaps faster, useful for busywork, not a substitute for a QSA's judgment.
Common Startup Mistakes with PCI DSS
A handful of mistakes show up again and again once we scope a fintech MVP's payment stack. Storing the CVV after authorization tops the list, usually inside a support tool built to speed up refunds. CVV storage is never allowed after authorization, encrypted or not, full stop. Card numbers pasted into logs, error trackers, or a shared spreadsheet come a close second, rarely intentional: a stack trace captures a raw request body, or an agent pastes a number into a chat thread to troubleshoot a failed charge. Assuming a PCI-validated gateway makes you compliant by association is another common one. It reduces scope significantly, a real benefit, but you still have to complete the matching SAQ and attest to it. Then there's scope creep: a CDE that starts clean and, months later, shares a network with half the company's tools because nobody drew a boundary. For the wider security practices around all of this, see our MVP security and scalability guide.
A mistake we see often: a team assumes their SAQ only needs revisiting once a year, at renewal. It's really a living document. Add a refund tool, switch gateways, or let a contractor touch the CDE without updating who's responsible, and your environment has already drifted from what you attested to.
MVP-Stage PCI Priorities
Not every requirement deserves equal attention on day one. If you're scoping payments for a fintech MVP, here's roughly where to spend your limited time first:
- Route all card data through hosted fields or a redirect from day one. Retrofitting this after your own code has touched raw numbers costs far more than building it right.
- Confirm which SAQ applies before your bank partner asks.
- Set an org-wide MFA and password baseline now, even at three people. Cheap early, expensive to bolt on later.
- Keep card data out of logs, support tools, and spreadsheets as a hard rule from the first line of payment code.
- Document your CDE boundary, even if it's a single diagram.
- Revisit scope whenever a feature touches payments differently: subscriptions, payouts, or manual refunds all expand it quietly.
- Line up a QSA relationship before you need one, especially if growth might push you toward Level 1.
Get the first three right and the rest gets noticeably easier.
Tags
