Compliance

How much PCI DSS actually applies to you

Most teams assume PCI compliance is a project. If card data never touches your servers, it is mostly a questionnaire. Scope is the whole game. This is the scope and tokenisation material from chapter 17.

This is engineering guidance, not legal advice. Your acquirer decides your validation requirements, and they are the ones to confirm your SAQ type with.

What is PCI DSS?

PCI DSS is basically the credit card industry saying "if you want to handle our cards, you better not screw up the security." It's 12 requirements that sound simple until you try to actually implement them. Think of it as the minimum bar for not being criminally negligent with credit card data.

The 12 Commandments of PCI DSS:

  1. Install and maintain a firewall - Because "we're behind a router" isn't security
  2. Don't use default passwords - Yes, "admin/password" counts as a default
  3. Protect stored cardholder data - Or better yet, don't store it at all
  4. Encrypt data in transit - HTTPS everywhere, no exceptions
  5. Deploy anti-malware controls - Even on servers, on every system commonly affected by malware
  6. Keep systems patched and secure - That WordPress install from 2019 needs updating
  7. Restrict access on a need-to-know basis - Not everyone needs root access
  8. Give everyone unique user IDs - Shared accounts fail this one outright
  9. Restrict physical access - Lock your server room (yes, the cloud counts too)
  10. Monitor and log everything - If it touches card data, it gets logged
  11. Test your security regularly - Pen tests aren't just for show
  12. Have written security policies - "We'll figure it out" isn't a policy

Most of these are good security practices you should be doing anyway. PCI DSS didn't invent any of it; the card industry just made it mandatory for payments.

PCI DSS scope boundaries, showing which systems fall in and out of scope when card data is tokenised

PCI Compliance Levels (AKA How Much Pain You're In For)

[PCI DSS compliance costs] scale dramatically with transaction volume. Level 1 (6M+ transactions annually) means Qualified Security Assessor (QSA) on-site audits at $50,000 to $500,000 per year, 6-12 months to reach initial compliance, a dedicated compliance team, and security consultants at $300+ per hour. Level 2-3 (20K-6M transactions) costs $5,000-$50,000 annually with self-assessment questionnaires (SAQ) and quarterly scans. Level 4 (under 20K e-commerce transactions) costs $0-$5,000 annually, mostly staff time. None of that caps your downside: a single data breach averaged $4.88 million in remediation, legal fees, fines, and reputation damage regardless of compliance level (IBM Cost of a Data Breach Report, 2024).

Level 1 (6M+ transactions/year) - The Big Leagues. A Qualified Security Assessor (QSA) comes to your office, looks at everything, and writes a report that costs more than your car: $50k-$500k annually, 6-12 months for initial compliance, and you need a dedicated team plus a $300/hour security consultant.

Level 2-3 (20k-6M transactions/year) - The Sweet Spot. Self-assessment questionnaires and quarterly scans, $5k-$50k annually, 2-6 months with proper planning. Most growing businesses live here.

Level 4 (<20k transactions/year) - The Starting Point. Simple SAQ, basic scans, $0-$5k annually (mostly your time), 2-8 weeks. The catch: one security incident and you'll wish you'd invested more upfront. Volume determines the level, but a breach at any level can destroy your business.

Reducing PCI Scope (The Secret to Staying Sane)

The single most effective compliance strategy is [scope reduction] through tokenization. Handle raw card data and you face the full PCI DSS requirements (329 controls for SAQ-D), annual costs of $50,000-$500,000, penetration testing, network segmentation, and a lot of documentation. Use hosted payment pages or your processor's tokenization (Stripe Checkout, PayPal Standard, etc.) and you qualify for SAQ-A: 24 questions, annual costs of $0-$5,000, and almost no extra infrastructure. A company processing 100,000 transactions annually saves $45,000+ per year by never handling card data directly. And a system that never holds card data can't leak it, which takes the breach that costs millions in fines, legal fees, and reputation damage off the table.

The best compliance advice anyone can give you: don't touch card data if you can possibly avoid it. Every piece of card data flowing through your systems is radioactive material in your infrastructure - it makes everything more complex, more expensive, and more dangerous.

We had a client who insisted on storing card data "for better user experience." That better experience cost them $200k in compliance and nearly killed the project.

# DON'T: Store card data (increases PCI scope)
def store_payment_bad(card_number, expiry, cvv):
    """
    This is a compliance nightmare waiting to happen.

    By storing raw card data, you're now responsible for:
    - Encrypting data at rest and in transit
    - Securing your entire network infrastructure
    - Regular security audits and penetration testing
    - Strict access controls and monitoring
    - Incident response procedures

    The cost and complexity can easily run into six figures annually.
    """
    payment_data =
    # This single line of code could cost you thousands in compliance
    database.store(payment_data)

# DO: Use tokenization (reduces PCI scope)
from datetime import datetime, timezone

def store_payment_good(payment_token, customer_id, amount):
    """
    This is the smart approach - let your payment processor handle the
    sensitive data and give you a safe token instead.

    Benefits:
    - Minimal PCI compliance requirements (SAQ-A usually)
    - Payment processor handles security for you
    - Tokens are useless if stolen
    - Much lower compliance costs and complexity
    - You can still process future payments with the token
    """
    payment_data =
    # This data can be stored normally - no special PCI requirements
    database.store(payment_data)

    # If you need to charge this customer again, use the token
    # charge_payment(payment_token, new_amount)

What is a Token? (And Why You Should Care)

A token is like a claim ticket at a coat check. You give the attendant your coat (sensitive card data), they give you a ticket (token), and later you can use that ticket to get your coat back. But if someone steals your ticket, they can't figure out what coat it represents without access to the coat check system.

A stolen token is useless without the tokenization system behind it.

# Real card data (sensitive)
card_data =
# After tokenization (safe)
token = 'tok_1234567890abcdef'

# The token is useless without the tokenization system
# Even if someone steals it, they can't reverse it to get the card data

What the book adds

The rest of chapter 17

  • KYC and AML obligations
  • 3D Secure and SCA
  • GDPR duties for payment data
  • The security practices past the questionnaire

30-day money-back · Instant PDF and EPUB

All 42 chapters