If your business accepts, processes, stores, or transmits credit or debit card data, PCI-DSS is the security standard you're required to follow — and "we didn't know about it" isn't a defense the card brands accept.
This one's part of the NerdSquad IT Dictionary — plain-English explanations of the compliance frameworks, acronyms, and IT concepts that show up in your business whether you invited them or not.
PCI-DSS has been around since 2004, and it touches more businesses than most people realize. If you take a Visa, Mastercard, Amex, or Discover payment — in person, online, or over the phone — you're in scope. That includes retailers, restaurants, medical practices, law firms, and virtually anyone running a point-of-sale system or e-commerce checkout.
Payment Card Industry Data Security Standard.
It was created by the major card brands — Visa, Mastercard, American Express, Discover, and JCB — who formed the PCI Security Standards Council (PCI SSC) in 2006 to manage the standard collectively. The standard itself is maintained and updated by the Council; the current version is PCI DSS v4.0.1, which became the mandatory baseline on March 31, 2024.
Unlike HIPAA (a federal law) or CMMC (a government contract requirement), PCI-DSS isn't a law. It's a contractual requirement — enforced through your merchant agreement with your payment processor and acquiring bank. Violate it, and you don't go to jail. But you can lose the ability to accept card payments, face significant fines, and be held liable for fraud losses if a breach occurs.
Imagine the card brands as a landlord who lets you use their payment rails — but only if you agree to keep the building up to code. PCI-DSS is the building code. You agreed to it the moment you signed up to accept cards, even if nobody handed you a copy of the rulebook.
The "standard" part matters: unlike a law that applies uniformly, PCI-DSS compliance is validated differently depending on how many card transactions you process per year and how your payment environment is set up.
PCI-DSS organizes merchants into four levels based on annual transaction volume. The higher your volume, the more rigorous the validation requirements:
Level 1: More than 6 million transactions per year (or any merchant that's experienced a breach). Requires an annual on-site audit by a Qualified Security Assessor (QSA) and quarterly network scans.
Level 2: 1 to 6 million transactions per year. Requires an annual Self-Assessment Questionnaire (SAQ) and quarterly scans.
Level 3: 20,000 to 1 million e-commerce transactions per year. Annual SAQ and quarterly scans.
Level 4: Fewer than 20,000 e-commerce transactions, or up to 1 million total transactions. Annual SAQ; scans may be required depending on the processor.
Most small and mid-size businesses fall into Level 3 or Level 4 — which means their primary compliance tool is the Self-Assessment Questionnaire (SAQ). There are several SAQ types (SAQ A, SAQ B, SAQ C, SAQ D, and others), and which one applies depends on how you accept and handle card data. Picking the wrong SAQ type is a surprisingly common mistake.
The standard is organized around 12 core requirements, grouped into six goals:
Build and maintain a secure network: Install and maintain firewalls. Don't use vendor-supplied defaults for passwords and security settings.
Protect cardholder data: Protect stored data. Encrypt transmission of cardholder data across open, public networks.
Maintain a vulnerability management program: Use and regularly update antivirus software. Develop and maintain secure systems and applications.
Implement strong access control measures: Restrict access to cardholder data on a need-to-know basis. Assign a unique ID to each person with computer access. Restrict physical access to cardholder data.
Regularly monitor and test networks: Track and monitor all access to network resources and cardholder data. Regularly test security systems and processes.
Maintain an information security policy: Maintain a policy that addresses information security for all personnel.
PCI DSS v4.0.1 added significant emphasis on customized implementation — giving organizations more flexibility in how they meet requirements, as long as they can demonstrate the security outcome is achieved. This is a meaningful shift from the more prescriptive earlier versions.
This is the one that catches businesses off guard.
Using a third-party payment processor like Square, Stripe, or Toast doesn't remove you from PCI-DSS scope — it reduces it. If your processor handles the card data entirely (and you never see or store raw card numbers), your scope shrinks considerably. But you still have to complete an SAQ and confirm your environment meets the applicable requirements.
The moment card data touches your own systems — even briefly — your scope expands. A payment terminal plugged into a computer on your business network, a phone order written down before being entered into a system, a card number stored in a spreadsheet "just in case" — all of these expand scope and increase your compliance obligations.
Scope reduction is one of the highest-value things an MSP can do for a business that accepts card payments: segment the payment environment from the rest of the network, route card processing through compliant hosted payment pages, and eliminate any unnecessary cardholder data storage.
Non-compliance and breach consequences run through your acquiring bank, not a government regulator. That said, they can be severe:
Importantly, being PCI-compliant at the time of a breach significantly limits your liability exposure. Compliance doesn't prevent breaches — but it does establish that you took reasonable steps, which matters when fines and fraud reimbursements are being assigned.
For businesses that handle card payments, PCI-DSS requirements overlap heavily with standard IT security practices — which is why a good MSP can help you get and stay compliant without hiring a dedicated compliance officer.
Specifically, an MSP can help with:
PCI-DSS doesn't exist in isolation. For businesses in regulated industries, multiple frameworks often apply simultaneously:
The good news: the security controls that satisfy PCI-DSS — strong access controls, encryption, logging, patching, endpoint protection — are largely the same controls that satisfy other frameworks. Build a solid IT security foundation and compliance becomes a byproduct rather than a separate project.
PCI-DSS scope questions alone can take hours to untangle, and the right SAQ type isn't always obvious without knowing how your payment environment is actually set up. If you're not sure where you stand, a conversation is a good place to start.