PCI-DSS compliance for startups: a practical guide (without the 200-page PDF)

PCI-DSS gets a bad rap. Everyone talks about it like it’s a 200-page PDF you need to memorize before you can take a credit card. The reality is more nuanced, and most of what you need for an MVP is straightforward.

This is the guide I wish existed when we started our first PCI-compliant project.

What PCI-DSS actually is

PCI-DSS (Payment Card Industry Data Security Standard) is a set of security standards created by the major credit card companies (Visa, Mastercard, etc.) to protect cardholder data.

Important: PCI-DSS is a contractual obligation, not a law. If you accept credit cards, your processor (Stripe, Square, etc.) requires you to comply.

Equally important: if you use Stripe Elements / Stripe Checkout / Stripe.js properly, you almost certainly don’t store or process card numbers yourself, which puts you in a much simpler compliance bucket.

The 4 levels

PCI-DSS has 4 levels based on transaction volume:

• Level 1: 6M+ transactions/year. Full audit by QSA (Qualified Security Assessor). On-site assessment.
• Level 2: 1-6M transactions/year. Self-Assessment Questionnaire (SAQ). Annual.
• Level 3: 20k-1M transactions/year. SAQ A or SAQ A-EP. Annual.
• Level 4: under 20k transactions/year. SAQ A. Minimal.

For most early-stage startups: you’re Level 4 (or 3 once you grow). The SAQ is a self-attestation, not a full audit. Much cheaper and faster.

The 12 requirements (in plain English)

PCI-DSS has 12 requirements across 6 categories. Here’s what they actually mean:

1. Install and maintain network security controls

Plain English: Firewall your servers. Don’t expose databases to the internet.

For an MVP: Use AWS/GCP default VPCs and security groups. Don’t poke holes. Use managed databases (RDS, Cloud SQL), not self-hosted.

2. Apply secure configurations to all system components

Plain English: Change default passwords. Disable unused services. Patch your software.

For an MVP: Managed services handle most of this. AWS Lambda, RDS, etc. are PCI-eligible out of the box.

3. Protect stored account data

Plain English: Don’t store credit card numbers. If you must, encrypt them.

For an MVP: Use Stripe.js / Stripe Elements. Card numbers never touch your servers. This single decision saves you 80% of PCI compliance work.

4. Protect cardholder data with strong cryptography during transmission

Plain English: Use HTTPS everywhere. No exceptions.

For an MVP: Let’s Encrypt (free) or Cloudflare ($0-$20/month). All major hosting platforms do this for you.

5. Protect all systems and networks from malicious software

Plain English: Antivirus on servers. Keep software updated.

For an MVP: AWS/GCP infrastructure is managed. You mainly need to patch your application dependencies (use Dependabot or Renovate).

6. Develop and maintain secure systems and software

Plain English: Code securely. Don’t have SQL injection vulnerabilities. Don’t have hardcoded secrets.

For an MVP: This is the one requirement that’s actually your responsibility. Code reviews, dependency scanning, secrets management (use AWS Secrets Manager or HashiCorp Vault).

7. Restrict access to system components and cardholder data by business need to know

Plain English: Only people who need access should have access.

For an MVP: Use role-based access control (RBAC) in your app. Use IAM roles in AWS. Don’t share credentials.

8. Identify users and authenticate access to system components

Plain English: Multi-factor authentication for all admin access. Strong passwords.

For an MVP: MFA for AWS/GCP accounts (built-in). MFA for your app’s admin panel. Use Auth0 or Clerk for user auth.

9. Restrict physical access to cardholder data

Plain English: Don’t let random people walk into your data center.

For an MVP: AWS/GCP data centers are already certified. You use them, you inherit their physical security.

10. Log and monitor all access to system components and cardholder data

Plain English: Track who accessed what, when. Keep logs for at least a year.

For an MVP: AWS CloudTrail + CloudWatch. Application-level logging with structured logs (Datadog, Sentry, etc.).

11. Test security of systems and networks regularly

Plain English: Run vulnerability scans. Penetration testing for higher levels.

For an MVP: Automated dependency scanning (Dependabot, Snyk). Annual penetration test when you reach Level 1.

12. Support information security with organizational policies and programs

Plain English: Have written security policies. Train your team.

For an MVP: Document your security practices. Train new hires on day 1. Update policies as you grow.

SAQ A vs SAQ A-EP: the critical distinction

This is where most startups get confused.

SAQ A (the easy one):

• You use Stripe Checkout, Stripe.js, or Stripe Elements
• Card numbers never touch your servers
• Your servers only receive a “token” representing the card
• 22 questions, mostly checkbox

SAQ A-EP (more work):

• You embed Stripe.js or Elements directly
• Card numbers pass through your page but not your server
• You handle more of the security yourself
• 139 questions, more detail required

SAQ D (the hardest):

• Card numbers touch your server
• You store, process, or transmit card data
• 329 questions, requires full audit

For most startups: SAQ A is the goal. Use Stripe Checkout (redirect) or Stripe Elements (iframe) so card data never touches your server.

Practical steps for an MVP

If you’re building a fintech MVP today:

1. Use Stripe Checkout or Elements (not Stripe.js directly). This puts you in SAQ A.
2. Deploy on AWS or GCP (PCI-eligible out of the box). Use managed services.
3. Enable MFA everywhere (AWS account, GitHub, Stripe, your app’s admin panel).
4. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault). Never commit secrets to git.
5. Set up logging (CloudTrail + CloudWatch). At minimum, log all access to customer data.
6. Enable Dependabot or Renovate for automated dependency updates.
7. Document your security practices in a single page. Update quarterly.

What we charge for PCI-compliant MVPs

For our fintech clients:

• Compliance-aware architecture: included in base MVP cost (no extra)
• PCI documentation generation: +$3k-$5k (one-time)
• Annual penetration test (when you reach Level 1): ~$15k-$30k
• Ongoing security review: $2k-$5k/quarter

The architecture is the same whether you have 100 or 100,000 transactions. Compliance scales with documentation and process, not engineering effort.

Common mistakes

1. Building a custom payment form to avoid Stripe fees. You save 2.9% + 30¢ and lose 6 months of compliance work.
2. Storing card numbers “for analytics”. You don’t need to, and the audit cost is enormous.
3. Skipping the SAQ. “We’re too small” is not a defense. If you accept cards, you owe the SAQ.
4. Treating PCI as a one-time thing. It’s continuous — annual SAQ, continuous logging, continuous patching.
5. Not getting legal review. PCI is contractual. Have a lawyer review your processor agreement.

The bottom line

PCI-DSS sounds scary but is manageable for an MVP if you make the right architectural decisions:

• Use Stripe Elements/Checkout
• Deploy on AWS/GCP
• Use managed services
• Enable MFA everywhere
• Document your practices

Most of the work is documentation, not engineering. The engineering work is the same whether you’re PCI compliant or not — you just need to be intentional about it.

Need help with a PCI-compliant fintech MVP?

We build fintech products that pass audits. Book a free intro call — we’ll tell you honestly if we can help and what it’ll cost.