PCI DSS compliance explained: scope, cost, and staying audit-ready

PCI DSS compliance stopped being an annual box-tick in 2025, and 2026 is the first full year payment teams are living with the consequences. PCI DSS v4.0.1⁠ is now the only active version of the standard; the requirements that were optional for 2 years are mandatory, and assessors expect controls to run year-round, rather than a clean snapshot taken the week before the audit.

For payment teams, the practical question has shifted. It’s no longer ‘did we pass?’ but ‘can we prove these controls were operating continuously, across every provider and every payment page we touch?’ This guide covers what PCI DSS compliance demands in 2026: the requirements that now bite, how your scope is set, what a compliant gateway does and does not cover, and how to stay compliant as you add providers.

What is PCI DSS?

Who developed PCI DSS?

The PCI Security Standards Council⁠ was founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa, after the card brands’ separate security programmes proved too inconsistent for merchants to follow. The first version of PCI DSS appeared in December 2004; the Council was created to own and evolve it as a single, shared standard. That origin explains how enforcement works today: the Council writes and maintains the standard but does not police it. Your acquirer and the card brands decide whether and how you must validate, and they levy the penalties.

Why PCI DSS compliance matters?

Three forces make PCI DSS compliance non-negotiable:

• It’s contractual. Compliance is a condition of your merchant agreement. Accepting cards means agreeing to comply with PCI DSS, which is enforced through the contracts that connect you, your acquirer, and the card brands. There is no opting out while still taking card payments.
• Card data is a standing target. Payment details are immediately monetisable, so checkout pages and payment systems are under constant attack. Client-side skimming campaigns inject malicious code into checkout pages to harvest card numbers as customers type them, and they remain one of the most persistent threats to online payments.
• The downside is expensive and asymmetric. A breach that reaches card data still averages⁠ $4.44 million globally, before the acquirer’s monthly non-compliance fees, forensic costs, card-reissuance charges, and the risk of losing card acceptance entirely. Against the cost of the controls, the maths heavily favours compliance. Done well, PCI DSS also reduces real risk rather than only satisfying an auditor, which is the point the contractual framing tends to obscure.

How many PCI DSS requirements are there?

PCI DSS has 12 core requirements grouped into 6 control objectives, spanning network security, data protection, vulnerability management, access control, monitoring, and security policy.

The shift that catches teams out is the timing of enforcement. A block of requirements sat as ‘best practice’ until they became mandatory on 31 March 2025⁠. In 2026, they are hard pass-or-fail items, and they are where most assessments now fail:

• Multi-factor authentication for all access into the cardholder data environment, not only administrators and remote users.
• A minimum password length of 12 characters wherever passwords are used to authenticate.
• A documented Targeted Risk Analysis justifying the frequency of any control you set yourself.
• Client-side payment-page controls: an authorised, integrity-checked inventory of every script on the page (Requirement 6.4.3) and automated tamper detection that alerts on unauthorised change (Requirement 11.6.1).
• Operational hardening: automated log review, stronger anti-malware, including anti-phishing, and tighter management of third-party service providers.

Who PCI DSS apply to and how validation works

Any organisation that touches card data is in scope. No transaction threshold exempts you from the standard; volume only changes how you validate, not whether you must. That covers merchants of every channel, the service providers behind them (gateways, processors, orchestration platforms, hosting and support vendors), and any business whose pages surround or embed a payment form.

How you validate depends on your level, which the card brands set mainly based on annual transaction volume. The largest merchants (Level 1) and large service providers complete a full Report on Compliance (ROC) with a Qualified Security Assessor (QSA); everyone else typically self-validates through a Self-Assessment Questionnaire (SAQ). Both end in a signed Attestation of Compliance (AoC) submitted to your acquirer, and internet-facing systems need quarterly external scans by an Approved Scanning Vendor (ASV) regardless of level.

The SAQ you complete is set by how card data flows through your environment, and the differences are not trivial. SAQ A carries roughly two dozen requirements, while SAQ A-EP carries around 140. Choosing the wrong one is the most expensive mistake in the process: filing the short questionnaire when you actually qualify for the long one means skipping a hundred-plus controls and creating a false compliance record that makes any later incident far costlier.

PCI compliant payment gateways: what they cover, what stays yours

A common shortcut is to assume that a PCI-compliant payment gateway makes your business compliant. It doesn’t. When a gateway states it is PCI compliant, the provider has validated its own environment and can produce a current AoC for it. That covers the provider’s systems. Your obligations stay on your side of a shared-responsibility boundary: how you integrate, what data touches your systems, and the checkout page customers actually see. The integration method decides how much of that boundary is yours, and it maps directly to your SAQ:

Even a fully outsourced setup isn’t exempt. The v4.0.1 SAQ A eligibility criteria require⁠ e-commerce merchants to confirm their site isn’t susceptible to script attacks, with that criterion applying specifically to embedded iframe integrations rather than pure redirects. A compliant gateway is a necessary building block for secure payment processing. On its own, it’s not a compliance strategy.

How to get PCI DSS certified

There is no single PCI DSS ‘certificate’ to frame on the wall. You validate compliance for a given year, receive an Attestation of Compliance, and then renew it annually. The route differs by level, but the sequence is the same:

1. Scope it. Map where card data enters, flows, is stored, and which systems can reach it. Everything connected to or affecting that environment is in scope, and accurate scoping eliminates most wasted remediation efforts.
2. Shrink it before you secure it. Tokenisation, point-to-point encryption, hosted or redirect payment pages, and network segmentation all take systems out of scope. The cheapest control is the one you no longer need because the data is not there.
3. Confirm your level and SAQ. Establish both with your acquirer and identify whether you self-assess or need a QSA-led Report on Compliance.
4. Run a gap analysis. Compare current controls against every applicable v4.0.1 requirement and produce a prioritised remediation plan with owners and dates.
5. Remediate the hardest first. Close the high-failure items: client-side script controls, MFA into the whole environment, twelve-character passwords, logging, and your Targeted Risk Analyses.
6. Test on cadence. Internal scans at least every 90 days, quarterly external ASV scans, and penetration testing annually and after significant changes.
7. Validate, then operate continuously. Complete the SAQ or ROC, sign the AoC, then keep controls running and collect rolling evidence: logs, alerts, scan history, and change records.

How much does PCI DSS compliance cost?

PCI DSS cost scales with scope and starting posture rather than with the standard itself. The validation route is the biggest single driver. Self-assessment is the lighter path: the SAQ itself is free, and with tooling and support, a smaller merchant typically budgets $5,000 to $20,000 a year, while a QSA-led Report on Compliance runs from $35,000 to $200,000 depending on the size and complexity of the cardholder data environment.

Recurring testing sits on top regardless of route. Quarterly external ASV scans run $100 to $500 per IP, and penetration testing, required for an ROC and several SAQ types, ranges from roughly $5,000 to $30,000 or more, depending on scope. Then come the variables that dwarf the audit fee for many teams: remediation to close gaps, compliance tooling, employee training, and internal staff time, which often runs from a fraction of a full-time role to two or more.

How to prepare for a PCI DSS audit?

Whether your assessment is a self-completed SAQ or a QSA-led ROC, preparation separates a clean validation from a painful one. Five moves matter most.

1. Start months ahead. The work expands with scope, so begin early enough to fix what a dry run uncovers rather than discovering it on assessment day.
2. Run a readiness assessment. A pre-assessment against every applicable requirement, internally or with a QSA, surfaces gaps while you can still close them cheaply. A third-party readiness review often pays for itself by shortening formal QSA fieldwork.
3. Assemble twelve months of evidence. This is the defining change under v4.0.1: assessors want proof that controls ran all year, not a binder built the week before. Have ready your network and data-flow diagrams and documented scope; current policies and Targeted Risk Analyses; four quarters of ASV scans plus internal scans and the latest penetration test; access-control and MFA evidence; log samples and proof of automated review; change records and the payment-page script inventory with integrity and tamper-detection evidence; and a third-party register with each provider’s AoC and a responsibility matrix.
4. Confirm third-party coverage. Collect AoCs from every service provider and check they cover the exact services you use. A gap in a provider’s scope becomes your gap.
5. Assign ownership and brief your people. Name who is accountable for each requirement area, make sure the staff who will be interviewed know their controls, and ensure the assessor has the access and documents they will request.

Containing scope as you scale

Everything above is manageable for one provider. It strains the moment you run several, which any serious operation does, for routing to the best provider per market, failover, local methods, and fee leverage. Each provider adds an integration, an Attestation to track, a responsibility matrix, and another set of scripts touching your checkout. Stacking individually compliant gateways doesn't contain scope; it multiplies the boundaries you defend. The structural answer is to route card data through one controlled layer before it reaches any provider, so you define and validate that boundary once, which is where payment infrastructure sits above the gateways rather than beside them.

Corefy is certified to PCI DSS Level 1, the most demanding tier the standard defines, and an independent QSA audits the platform every year across our developers, infrastructure, management, support, and operations. Because the layer your card data passes through is kept compliant continuously, most clients carry no certification burden at all: card data is handled on Corefy's side, so they don’t have to pass PCI DSS certification themselves. Only those who choose to host the payment page on their own infrastructure and connect server-to-server need to certify.

That is what lets one of our clients reach a setup that their previous configuration couldn't support. They wanted host-to-host (H2H) MIDs with their payment providers, a more direct processing arrangement that gives greater control over the payment flow but normally pulls card data, and full PCI scope, back onto the merchant's own systems. Corefy's Level 1 certification is what made it workable: customers enter their card details on Corefy's hosted payment page, the data never touches the merchant's infrastructure, and the business gets access to H2H MIDs that would otherwise have been out of reach.