Verizon's 2018 Payment Security Report found that 47.5% of organizations fall out of compliance with PCI DSS during interim validation, the checks that happen between annual assessments rather than at the assessment itself. Passing once a year and staying compliant in between are two different things, and that difference is exactly where things go wrong.
It goes wrong because PCI DSS compliance isn't a one-time badge, it's a baseline security standard any business handling payment card data has to meet continuously. It applies the moment you accept your first card, not once you hit some revenue threshold, and it's enforced not by a government agency but contractually, through the card brands and the banks and processors that carry their agreements.
This article covers PCI DSS as its own framework end to end. If you're looking specifically at the healthcare crossover, where protected health information sits alongside card data, ComplyJet's PHI, PCI, and PII compliance guide is the more specific read.
By the end of this, you'll know exactly what PCI DSS compliance requires, who's actually involved in getting there, how validation works, and what it costs to get wrong.
Here's what's ahead:
- What PCI DSS compliance actually means, and who created the standard
- Who needs it, and whether it's legally required
- The 6 goals behind the 12 requirements, and who's involved in enforcing them
- How compliance gets validated: SAQs, Reports on Compliance, and Attestations of Compliance
- What non-compliance costs, and what compliance itself costs
- Common myths, and how to actually get started
What Is PCI DSS Compliance, Really?
What is PCI DSS compliance, in one sentence? A single security standard, not two separate things bolted together, built to protect cardholder data wherever it gets stored, processed, or transmitted. PCI DSS stands for Payment Card Industry Data Security Standard.
The PCI Security Standards Council develops and maintains it. Visa, Mastercard, American Express, Discover, and JCB founded the council in 2006 specifically to give the payments industry one standard instead of five competing ones, and that's still its job today.
The standard is currently on version 4.0.1, which superseded version 3.2.1. The 4.0.1 update focused on clarifying and modernizing existing controls rather than reinventing them: more flexibility in how organizations validate certain cryptographic and authentication controls, plus tighter guidance on managing scripts on payment pages. It's a refinement, not a rewrite.
Why PCI DSS Compliance Actually Matters
The card brands can revoke a merchant's ability to accept their cards at all. That's the ceiling risk, and it sits above the fines, the forensic investigation costs, and the reputational damage that stack on top of it (all covered in the non-compliance section below).
The Real Benefits of PCI DSS Compliance
The benefits of PCI DSS compliance show up long before any breach happens. For an early-stage company specifically:
- Enterprise and payment-processor deals often require it outright. Larger customers and some processors won't onboard a merchant that can't show a completed SAQ or ROC.
- It reduces actual breach risk, not just the appearance of taking security seriously. The 12 requirements map to genuinely common attack paths: weak passwords, unencrypted data in transit, unmonitored access.
- It's a credibility signal during procurement, the same way SOC 2 or ISO 27001 status is. A security reviewer who sees current PCI DSS validation has one less open question.
Who Actually Needs PCI DSS Compliance, and Is It Legally Required?
PCI DSS compliance isn't a federal law in the US, and there's no single global statute requiring it either. It's a contractual obligation: card brands write it into their agreements with acquiring banks, and those banks write it into their agreements with merchants. A handful of US states (Minnesota, Nevada, and Washington) reference PCI DSS directly in their own data security statutes, but that's the exception, not the rule.
Who it actually applies to is simple: any business that stores, processes, or transmits cardholder data, regardless of size. A solo founder taking their first card payment is in scope exactly as much as a retailer processing millions of transactions a year, just at a much lighter validation level (more on that below).
Using a PCI-compliant payment processor, Stripe, Worldpay, or similar, reduces your own PCI DSS scope. It does not eliminate it. Your processor handles the parts of the transaction that pass through their systems, but anything you touch directly, a checkout page you host, card data you store even briefly, still puts you in scope.
For a business based in the UK specifically, PCI DSS compliance UK requirements work through the exact same acquirer-contract chain as anywhere else. There's no separate UK statute creating the obligation; it's the same card-brand agreement, just enforced through UK-based acquiring banks instead of US ones.
Who's Actually Involved in PCI DSS Compliance
Six groups make up the PCI DSS ecosystem, and knowing which one you'll actually deal with during your own process saves a lot of confusion.
| Group | Role |
|---|---|
| PCI Security Standards Council | Writes and maintains the standard itself; doesn't audit individual businesses |
| Merchants | Any business that accepts, stores, processes, or transmits cardholder data |
| Service providers | Hosting companies, payment gateways, and processors that handle cardholder data on a merchant's behalf |
| Card issuers and acquiring banks | Issue the cards and process the payments; enforce compliance through merchant agreements |
| Qualified Security Assessors (QSAs) | Certified assessors who conduct on-site audits and produce Reports on Compliance |
| Approved Scanning Vendors (ASVs) | Certified vendors that run the required external vulnerability scans |
For most early-stage companies, the two you'll actually interact with directly are a QSA (if your validation level requires an audit) or an ASV (for the vulnerability scans most levels require), not the Council itself.
The distinction between those two matters in practice. A QSA looks at your whole environment, people, processes, and systems, and produces a judgment call on whether your controls actually meet the standard. An ASV runs a narrower, automated external scan looking specifically for known vulnerabilities on anything internet-facing. Most businesses above Level 4 need both at some point, not one or the other.
The 6 PCI DSS Compliance Goals Behind the 12 Requirements
The 12 requirements aren't a flat list. They're organized under 6 broader goals, and understanding the goals makes the requirements themselves easier to hold in your head.
| Goal | Requirements |
|---|---|
| Build and maintain a secure network | 1. Install and maintain firewall configuration; 2. Don't use vendor-supplied defaults |
| Protect cardholder data | 3. Protect stored cardholder data; 4. Encrypt data in transit across public networks |
| Maintain a vulnerability management program | 5. Use and update anti-malware software; 6. Develop and maintain secure systems |
| Implement strong access control measures | 7. Restrict access by business need-to-know; 8. Assign unique IDs to each user; 9. Restrict physical access |
| Regularly monitor and test networks | 10. Track and monitor all access; 11. Regularly test security systems |
| Maintain an information security policy | 12. Maintain a policy addressing information security |
Each of these 12 requirements breaks down into its own set of specific, testable controls. Together, these six PCI DSS compliance goals give the requirements their structure, and understanding which goal a given control serves makes it much easier to explain to a team why a specific policy exists. We cover each requirement in full in a dedicated guide; this table is the map, not the whole territory.
The PCI DSS Compliance Audit, SAQs, ROC, and AOC Explained
For most small businesses, a PCI DSS compliance audit doesn't mean a third-party visit at all. It means filling out a Self-Assessment Questionnaire (SAQ), one of several versions depending on how you accept payments. Higher-volume merchants (Level 1, covered below) go through a full on-site assessment by a Qualified Security Assessor instead.
Three documents come out of this process, and they're easy to confuse. The one that trips people up most is the PCI DSS report on compliance, mostly because smaller merchants rarely encounter one directly and assume it's just a longer version of the questionnaire. It isn't; it's a separate, independently produced document.
| Document | What it is | Who produces it |
|---|---|---|
| Self-Assessment Questionnaire (SAQ) | A self-evaluation against the applicable requirements | The merchant or service provider itself |
| Report on Compliance (ROC) | An independent audit report | A Qualified Security Assessor |
| Attestation of Compliance (AOC) | A formal sign-off confirming the SAQ or ROC's findings | Whoever produced the SAQ or ROC |
What Is a PCI DSS Report on Compliance?
A Report on Compliance is the output of a full, independent audit: a Qualified Security Assessor reviews your environment against every applicable requirement and documents the findings. It's required for Level 1 merchants and any organization a card brand specifically designates for it.
What Is a PCI DSS Attestation of Compliance?
A PCI DSS attestation of compliance is the formal document that gets submitted regardless of path. Whether you completed an SAQ or went through a full ROC, the AOC is the signed statement confirming the result, and it's what your acquirer or the card brands actually file.
Being compliant and having documented, validated compliance are two different things. You're expected to meet the requirements continuously, but you only prove it on the cadence your validation level requires, typically annual.
Is PCI DSS Compliance Certification a Real Thing?
Not in the formal sense. PCI DSS compliance certification gets used loosely in marketing the same way "SOC 2 certified" does, but there's no certifying body issuing a credential here either. What you get is a validated SAQ or ROC and an AOC, not a certificate with an expiration date.
ComplyJet's breakdown of whether SOC 2 is a certification walks through the same attestation-versus-certification distinction in more depth. The underlying logic is identical: "certified" is shorthand people reach for because it's familiar, not because it's the technically accurate term.
PCI DSS Compliance Levels
Validation requirements scale by transaction volume, not by revenue or company size, across four merchant levels:
| Level | Annual transaction volume |
|---|---|
| Level 1 | Over 6 million |
| Level 2 | 1 million to 6 million |
| Level 3 | 20,000 to 1 million (e-commerce) |
| Level 4 | Fewer than 20,000 (e-commerce) |
Service providers get their own, separate two-tier scale, based on how many accounts or transactions they handle on behalf of merchants rather than transactions of their own. A payment gateway processing on behalf of thousands of small merchants can land at a higher tier than most of the individual merchants it serves, which surprises a lot of first-time service providers.
The exact validation requirements at each level, which SAQ type applies, whether a QSA is mandatory, vary by card brand and acquirer, and we go into that fully in a dedicated PCI DSS compliance levels guide. The table above is enough to know roughly where you sit, and your acquiring bank will confirm your exact level and validation requirements directly once you start processing.
The Real Cost of PCI DSS Non Compliance
PCI DSS non compliance carries specific, board-level consequences, not vague reputational risk. Card brands and acquiring banks can levy fines ranging from $5,000 to $100,000 or more per month, a range independently corroborated by multiple sources (Fortinet among them). If a business ignores the fines and stays non-compliant, it risks losing its ability to process cards entirely.
Being PCI DSS compliant doesn't make a business breach-proof. But a compliant business that suffers a breach anyway is in a materially different position than a non-compliant one: it can show it met the standard's requirements, which typically reduces the fines and penalties assessed afterward. Compliance is what you point to after an incident, not just a preventive measure.
The fine range gets the headlines, but the real cost of non-compliance is almost always the forensic investigation, the customer notifications, and the deals that quietly stall while a security review is pending. That's the part founders don't budget for. — Upendra Varma, CTO at ComplyJet
Target's 2013 card-data breach is the standard public example of how this compounds: more than 40 million card accounts exposed, followed by an $18.5 million multistate settlement with state attorneys general in 2017, on top of the direct forensic, legal, and card-brand costs the company absorbed at the time.
What PCI DSS Compliance Cost Really Looks Like
PCI DSS compliance cost depends heavily on your validation level and how mature your existing security controls already are. A Level 4 merchant filling out a short SAQ spends very little; a Level 1 merchant going through a full QSA-led assessment is a materially bigger undertaking.
ComplyJet's own flat-rate pricing gives one concrete anchor point: $5,000 a year for a single framework, PCI DSS included, regardless of company size, with the same price whether you're a 5-person team or a 40-person one. That's meaningfully below the higher end of what a from-scratch compliance program, hiring consultants, building documentation, running gap assessments, tends to run for a growing company.
Timeline follows the same logic as cost. A Level 4 merchant with reasonable security hygiene already in place can often complete their SAQ in a matter of days. A Level 1 organization building controls from a low starting point, and coordinating a QSA's schedule for the on-site assessment, should realistically expect a multi-month runway before they're audit-ready, not a multi-week one.
How to Start Becoming PCI DSS Compliant
Getting started follows a consistent shape, regardless of your level:
- Determine your merchant level based on annual transaction volume.
- Scope your cardholder data environment, everything that touches card data, directly or indirectly.
- Choose your validation path, the applicable SAQ, or a QSA-led assessment if your level requires one.
- Remediate any gaps the assessment or self-review surfaces.
- Submit your AOC and keep the underlying controls running, not just documented.
Network segmentation is worth calling out on its own: a well-scoped cardholder data environment shrinks how many systems the 12 requirements actually apply to, which shrinks the audit itself. It's the single highest-leverage move most businesses can make before starting. For the full step-by-step, including how to run the gap analysis and map controls to requirements, see ComplyJet's dedicated PCI DSS compliance checklist.
Ongoing operational continuity, keeping controls running after validation, not just during it, usually gets handled as part of a broader plan rather than a PCI-specific one. See ComplyJet's guide to business continuity and disaster recovery planning for how that intersects with PCI DSS alongside SOC 2, ISO 27001, HIPAA, and GDPR.
If you're evaluating tools to help manage the validation path itself rather than doing it manually, ComplyJet's guide to the best PCI compliance software covers the vendor landscape directly.
Common PCI DSS Compliance Myths
- "PCI DSS only applies to large or e-commerce-only businesses." It applies to any business handling any volume of card transactions, in person or online, at Level 4 if nowhere else.
- "Being mostly compliant is good enough." PCI DSS doesn't have a partial-credit model. A gap in one requirement is a gap in your compliance status, not a rounding error.
- "My payment processor being compliant covers me too." It reduces your scope, not your obligation. Anything you touch directly, a hosted checkout page, locally stored card data, still puts you in scope yourself.
- "PCI DSS compliance is a one-time project." It's validated on a recurring cycle (typically annual) and expected to hold continuously in between, not just on the day of the assessment.
- "Debit card transactions are exempt." Many debit cards run on the same networks as credit cards and carry the same scope obligations. The card type doesn't change whether PCI DSS applies; how the transaction routes does.
How ComplyJet Helps with PCI DSS Compliance
ComplyJet supports PCI DSS alongside SOC 1, SOC 2, ISO 27001, HIPAA, GDPR, and 25+ other frameworks, with flat per-company pricing rather than per-seat, and AI-assisted policy drafting to cut down the documentation load. See ComplyJet's PCI DSS framework page for the specifics of what's covered.
We don't hand over software and leave you to turn it into an audit-ready outcome alone. Evidence collection, control monitoring, and getting ready for an SAQ or a QSA-led assessment happen with guided support, backed by a vetted audit-partner network when a formal audit is what your level requires. If your business already carries another framework, ComplyJet's guide to HITRUST certification cost covers how PCI DSS fits alongside HITRUST specifically.
FAQs
Who Has to Validate PCI DSS Compliance, and Who Checks It?
Merchants and service providers validate their own compliance, either through a self-assessment or a QSA-led audit depending on level. Acquiring banks and card brands are the ones who actually enforce it, since they're the parties whose agreements require it.
What Is Required for PCI DSS Compliance?
You need to meet all 12 requirements under the standard's 6 goals, covering network security, cardholder data protection, vulnerability management, access control, monitoring, and a written security policy, then validate that through an SAQ or ROC and file an AOC.
How Does PCI DSS Compliance Work in Practice, Day to Day?
Most of it is operational, not a one-time event: patching systems, reviewing access logs, keeping firewall rules current, and running the periodic vulnerability scans your level requires. The annual validation is a checkpoint on controls that are supposed to be running continuously.
Is PCI DSS Compliance UK-Specific, or Does It Work the Same Way Everywhere?
It works the same way everywhere. PCI DSS compliance UK expectations mirror the US and every other market: no domestic law requires it directly, but no UK business can process card payments without meeting it through their acquirer's contract.
How Long Does PCI DSS Compliance Take?
Timeline and cost move together (see the cost section above for the specifics by level). The bigger variable isn't the paperwork itself, it's how far your current environment is from meeting the 12 requirements before you start.
Related Reading
- Best PCI Compliance Software, for readers ready to evaluate specific tools and services rather than just understand the framework.
- PHI, PCI, and PII Compliance, for the healthcare-data crossover this guide deliberately doesn't cover.
- Is SOC 2 a Certification? Attestation vs. Certification, Explained, the same attestation-versus-certification logic applied to a different framework.


