If your business stores, processes, or transmits payment card data in any way — even just redirecting to a payment page — PCI DSS applies to you. It's not optional and it's not just for large enterprises: the Payment Card Industry Data Security Standard applies regardless of transaction volume, though how you demonstrate compliance scales with it.
The 12 requirements, grouped into 6 goals
PCI DSS's 12 core requirements are organised into six broader goals. This structure is worth knowing because it's how auditors, Qualified Security Assessors (QSAs), and the standard itself frame the whole program:
- Build and Maintain a Secure Network — firewalls, and never using vendor-supplied default passwords.
- Protect Cardholder Data — encrypt it in transit, and don't store more of it than you need to.
- Maintain a Vulnerability Management Program — antivirus/anti-malware, and secure system development.
- Implement Strong Access Control Measures — restrict access on a need-to-know basis, unique IDs per user, restrict physical access.
- Regularly Monitor and Test Networks — track and log all access, test security systems and processes regularly.
- Maintain an Information Security Policy — a formal policy that addresses information security for staff and contractors.
Merchant levels and how you validate compliance
Not every business validates PCI DSS compliance the same way — the card brands (Visa, Mastercard, etc.) define merchant levels based primarily on annual transaction volume, and your level determines what's required:
- Level 1 (the highest volume merchants) — requires an annual Report on Compliance (RoC), typically performed by a QSA, plus quarterly network scans by an Approved Scanning Vendor (ASV).
- Levels 2–4 (lower volume) — generally validate via a Self-Assessment Questionnaire (SAQ), a set of yes/no questions you complete yourself, plus quarterly ASV scans where required.
Exact thresholds vary slightly by card brand, so it's worth confirming your specific level directly with your acquiring bank or payment processor rather than assuming.
Which SAQ type actually applies to you
Even within "complete an SAQ," there are several SAQ types, and which one applies depends entirely on how you handle card data — not your industry or size. The most common ones:
- SAQ A — you fully outsource card data handling to a PCI-compliant third party (e.g. a hosted payment page) and never touch cardholder data on your own systems. The smallest, simplest SAQ.
- SAQ A-EP — similar, but your website directly affects the payment page's security (e.g. it's embedded via iframe you control) even though you don't store card data.
- SAQ B / B-IP — you use standalone payment terminals, with no electronic cardholder data storage.
- SAQ D — the most extensive, for merchants who store, process, or transmit cardholder data directly on their own systems.
The single biggest lever: reduce your scope
This is the most important practical takeaway for most small and mid-sized businesses: the fastest, cheapest path to PCI compliance is almost never "build a fully compliant environment for handling raw card data" — it's redesigning your payment flow so you never touch raw card data at all. Using a hosted checkout page or a tokenization-based integration (common with processors like Stripe, Paystack, and PayFast) can move you from the demanding SAQ D down to the much simpler SAQ A, because the cardholder data environment genuinely isn't on your systems anymore.
Common gaps auditors and QSAs actually find
- Cardholder data lingering in places nobody accounted for — support ticket attachments, log files, backups, or spreadsheets from a one-off manual process.
- Network segmentation that's assumed rather than tested — believing a system is "out of scope" without verifying it can't actually reach the cardholder data environment.
- Vendor/service provider compliance not verified — using a third-party payment processor doesn't automatically make you compliant; you still need evidence of their own PCI DSS status.
- Quarterly vulnerability scans skipped or not remediated — a scan that's run but whose findings are never fixed doesn't satisfy the requirement.
This guide is general information, not a substitute for guidance from your acquiring bank, payment processor, or a Qualified Security Assessor — your specific merchant level, applicable SAQ type, and validation requirements should be confirmed directly with them.
Keeping evidence current between assessments
PCI DSS compliance isn't a once-a-year event — quarterly scans, ongoing access reviews, and policy adherence all need to keep happening between formal assessments. ComplianceDesk's PCI DSS framework gives you the full control set pre-built, with an evidence vault to attach proof as it happens and reminders before a recurring requirement like a quarterly scan falls overdue.