What is PCI-DSS Compliance?

Where it came from

Before 2004, every card brand had its own security program for merchants. Visa had Cardholder Information Security Program (CISP); Mastercard had Site Data Protection. They overlapped enough to be annoying and differed enough to be confusing. In 2004 the brands agreed to a unified standard — PCI-DSS — and in 2006 spun up the PCI Security Standards Council to maintain it. Today's version is PCI-DSS 4.0.1, which significantly tightened authentication, key management, and continuous monitoring requirements.

The twelve requirements

Grouped into six goals. Build and maintain a secure network and systems (firewalls, default passwords). Protect cardholder data (encryption at rest and in transit). Maintain a vulnerability management program (anti-malware, secure development). Implement strong access control (need-to-know, unique IDs, physical restrictions). Regularly monitor and test (logging, vulnerability scans, pentests). Maintain an information security policy. The 4.0.1 revision adds continuous obligations rather than annual snapshots.

PCI-DSS 4.0.1 — what changed

The 4.0.1 revision was the biggest standard refresh in over a decade. It tightened password length and complexity requirements, mandated stronger multi-factor authentication, added requirements for automated vulnerability discovery on payment pages, and replaced the old annual-snapshot model with a continuous monitoring expectation. For most merchants the practical effect is that "we did our audit once a year" no longer cuts it — you need controls that demonstrably operate every day.

SAQ vs ROC and merchant levels

Smaller merchants complete a Self-Assessment Questionnaire (SAQ) annually. There are several SAQ variants depending on how cards are processed — SAQ A for fully outsourced e-commerce, SAQ D for merchants who touch cardholder data, and several in between. Larger merchants (Level 1, over six million Visa transactions per year) hire a Qualified Security Assessor (QSA) to produce a Report on Compliance (ROC).

At QUANT LAB

Our standing advice: never touch card data. Our Stripe integration work uses Stripe Elements or Stripe Checkout, so cardholder data goes from the customer's browser straight to Stripe without ever hitting your servers. That keeps you in the smallest SAQ scope and reduces audit cost by an order of magnitude. We also handle subscription billing and payments infrastructure with the same scope-minimization approach. Where PCI also requires periodic penetration testing, our engagements satisfy that requirement directly.

Common founder questions

"Does using Stripe make me automatically compliant?" No. Stripe handles its own compliance, but your business is still responsible for PCI compliance on your side of the integration. The good news: if you use Stripe Elements or Checkout correctly, your scope shrinks dramatically.

"Can I just say I do not store card numbers and be done?" Probably not. Even if cards never hit your servers, your merchant agreement requires you to attest annually. The attestation is simpler when your scope is small, but it is not optional.

"Do I need quarterly ASV scans?" If your environment is externally accessible and processes card data, yes. ASV (Approved Scanning Vendor) scans are external vulnerability scans run by an approved third party against your perimeter every 90 days.