The Master Guide to PCI Compliance

PCI compliance is the baseline security standard for any business that stores, processes, or transmits card data, and it's mandatory if you want to keep accepting Visa, Mastercard, or American Express. The standard also changed meaningfully over the last two years, so a setup that passed review in 2023 may not pass today. This guide breaks down what PCI compliance actually requires, what it costs, and which path applies to your business.

What is PCI compliance? 

PCI compliance is a set of security standards for any business that handles credit card transactions. The PCI Security Standards Council sets and updates these standards, and businesses must document and prove compliance annually.

PCI compliance isn't required by law. It's required by contract. Visa, Mastercard, American Express, Discover, and JCB all mandate it as a condition of accepting their cards, and your acquiring bank enforces it through your merchant agreement. Skip it and you risk fines passed down from the card brands and, eventually, losing the ability to process card payments at all.

Any business that transmits, stores, handles, or accepts card data must comply, regardless of size or transaction volume. The specific level of compliance required depends on your transaction volume, covered below.

Some gateways and payment processors claim their drop-in card widgets exempt you from PCI compliance entirely. What tools like Spreedly's checkout SDKs and iFrame actually do is reduce your compliance burden. You still have to certify, but with far less effort than if you handled raw card data yourself.

Merchants, networks, and service providers each carry a piece of the standard

A handful of parties make the card payment ecosystem work, and each one has a defined role under PCI DSS.

• Merchants sell goods or services and accept card payments to do it.
• Card networks, known by brand names like Visa and Mastercard, connect issuing banks (which issue cards to cardholders) and acquiring banks (which let merchants accept those cards).
• Cardholders are the customers paying with a card. Cardholder data includes the primary account number, cardholder name, expiration date, and service code. Add sensitive authentication data (like the CVV or chip data) and there's a lot to protect, which is the entire point of PCI DSS.
• Service providers store or process cards on behalf of merchants or cardholders. Spreedly is a service provider, along with companies like Stripe, plus any payment gateway or point-of-sale vendor.
• Payment software vendors build the hardware and software merchants use to process transactions. They're governed by the PCI Software Security Framework, made up of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. The framework replaced the now-retired Payment Application Data Security Standard (PA-DSS).
• The PCI Security Standards Council, founded by the major card networks, writes the Data Security Standards that every other party in this list has to follow.
• Qualified Security Assessors (QSAs) are certified by the Council to audit and validate PCI DSS implementations.

Spreedly is a service provider and holds Level 1 (L1) certification, the highest level available, validated annually by a QSA. Spreedly isn't classified as a payment software vendor, since the platform isn't installed in an environment outside Spreedly's control.

PCI scope determines both your cost and your risk

Scope is every system component involved in processing, storing, or transmitting card data, collectively called the cardholder data environment (CDE). Getting scope right early is cheaper than fixing it later. A single server hosting one page that redirects to an offsite payment processor has minimal scope. A system with databases, log aggregators, application servers, and load balancers all touching card data has much larger scope, and there's often little room to shrink it once that architecture exists.

Scope creep happens in a few predictable ways: granting CDE access to people who don't need it, connecting unrelated systems to the CDE, or running unrelated software on in-scope components. Every one of those choices expands what an assessor has to review and what you have to secure.

Both merchants and service providers reduce scope by outsourcing card handling to a PCI DSS-compliant provider. Using Spreedly to store and process cards, for example, can limit a merchant's scope to the page that collects the card number. The PCI SSC's scoping guidance is the standard reference for working through scope decisions in detail.

Assessment path depends on transaction volume and merchant level

PCI certification happens one of two ways: a self-assessment questionnaire (SAQ) you complete yourself, or a Report on Compliance (ROC) produced by a QSA. Which path you're eligible for depends on your merchant level, and only your acquiring bank can officially assign that level.

Each card network sets its own merchant level thresholds, and they don't all match. The table below uses Visa's thresholds, which are the most commonly cited. Mastercard, American Express, and Discover each publish their own criteria, so check with your acquiring bank for the network mix you actually process.

SA. Level 2 and 3 merchants may need to do the same if their acquiring bank requires it, but most can self-assess with the appropriate SAQ. Level 4 merchants typically self-assess as well. Ask your acquiring bank which level applies to you before committing time to a compliance path, since they're the ones who assign it.

SAQ A and SAQ A-EP require different levels of scrutiny

How your payment page is built determines which SAQ applies. SAQ A is the lighter path, reserved for e-commerce merchants who fully outsource cardholder data handling to a compliant third party and never touch card data on their own systems. SAQ A-EP applies when a merchant's own website has more influence over the security of the transaction, even without directly touching the card number.

SAQ A has shifted twice under v4.x. The version released alongside PCI DSS v4.0.1 in October 2024 included the new payment-page script controls (Requirements 6.4.3 and 11.6.1). In January 2025, the Council revised SAQ A to remove those two requirements and replace them with a new eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. That revised SAQ A has been the only valid version since March 31, 2025.

In practice, this means SAQ A eligibility now depends on protecting the page that hosts or redirects to the payment form, not just on outsourcing the form itself. Merchants who can't make that confirmation should expect to meet the script controls another way or move to SAQ A-EP.

Hosted iFrames keep most merchants inside SAQ A

A properly implemented iFrame, where all payment page content loads from the payment service provider rather than the merchant's own domain, remains one of the most common ways merchants qualify for SAQ A instead of the more demanding SAQ A-EP.

Spreedly supports four ways to collect payment methods: iFrame, Express, Javascript API, and Direct API. The iFrame was built specifically to give merchants design flexibility while keeping SAQ A eligibility intact. The Javascript API and Direct API give merchants more control over the payment page, which also brings more of that page into scope. See Spreedly's developer documentation for implementation details, or read more about Spreedly's iFrame approach.

Compliance costs scale with scope and assessment path

What PCI compliance costs depends on scope (how much of your environment is in scope) and assessment path (self-assessment versus a QSA-led ROC), and those two factors interact with nearly every other cost driver. A narrow-scope Level 4 merchant using a hosted payment page faces a fundamentally different cost profile than a Level 1 service provider running its own infrastructure.

The biggest line items tend to be the same across businesses: QSA fees if you need a ROC, quarterly vulnerability scans, remediation work to close gaps, and the internal staff time to document and maintain controls. Scope drives every one of them, which is why reducing scope is usually the fastest way to reduce cost.

Whatever the assessment path, compliance isn't a one-time cost. PCI DSS requires ongoing maintenance, including quarterly scans and annual re-assessment, so budget for it as a recurring line item rather than a project expense.

Proving compliance means an SAQ or a ROC, plus a signed AOC

Validating compliance takes one of two forms. Smaller organizations complete a Self-Assessment Questionnaire, ideally led by someone who understands the system's full scope. Larger organizations engage a QSA, who determines scope, reviews configurations and access controls, interviews staff, and produces a detailed Report on Compliance documenting every finding.

Either path ends the same way: signing an Attestation of Compliance (AOC), a formal declaration that your business meets the applicable PCI DSS requirements. The merchant level determines which path you're required to take, not how compliant you actually are. A Level 4 merchant and a Level 1 merchant can both be fully compliant. They just prove it differently.

The 12 PCI DSS requirements map to six core objectives

PCI DSS v4.0.1 has 12 requirements organized under six goals for protecting card data. Each requirement breaks down into dozens of sub-requirements and testing procedures that an assessor checks. That's why a full Report on Compliance (ROC) runs long even for a moderately complex environment.

Build and maintain a secure network and systems

• 1. Install and maintain network security controls. Firewalls, cloud security groups and other controls that filter traffic into and out of the CDE.
• 2. Apply secure configurations to all system components. Changing vendor defaults, removing unneeded services and hardening system configurations.

Protect account data

• 3. Protect stored account data. Storing as little data as possible, never keeping sensitive authentication data after authorization, making stored PAN unreadable and managing encryption keys.
• 4. Protect cardholder data with strong cryptography during transmission over open, public networks. Strong TLS and trusted certificates wherever card data crosses a public network.

Maintain a vulnerability management program

• 5. Protect all systems and networks from malicious software. Anti-malware and anti-phishing controls.
• 6. Develop and maintain secure systems and software. Secure development, patching, protecting public-facing web apps and managing payment page scripts.

Implement strong access control measures

• 7. Restrict access to system components and cardholder data by business need to know. Least privilege, role-based access and regular access reviews.
• 8. Identify users and authenticate access to system components. Unique user IDs, password rules and multi-factor authentication.
• 9. Restrict physical access to cardholder data. Facility access, media handling and protecting point-of-interaction devices.

Regularly monitor and test networks

• 10. Log and monitor all access to system components and cardholder data. Audit logs, log review, time sync and log retention.
• 11. Test security of systems and networks regularly. Quarterly internal and external (ASV) scans, penetration testing, and intrusion and change detection.

Maintain an information security policy

• 12. Support information security with organizational policies and programs. Security policy, risk assessments, awareness training, third-party provider oversight and incident response.

What changed from v3.2.1

• Requirement 1 used to be about firewalls. It now covers network security controls of any kind, including cloud-native and other non-traditional setups.
• Requirement 2 is about secure configuration, not password policy. Password and authentication rules are in Requirement 8.
• Requirement 8.4.2 requires MFA for all non-console access into the CDE, not only admin and remote access. It became mandatory on March 31, 2025, so expect it to come up in your next assessment.
• Requirements 6.4.3 and 11.6.1 are new. They require you to inventory and authorize every script on your payment pages and to detect unauthorized changes to them. These also became mandatory in March 2025 and matter most for e-commerce merchants.

PCI DSS v4.0.1 is the current standard

The Council released PCI DSS v4.0 in March 2022, and v3.2.1 was retired on March 31, 2024. The Council then issued PCI DSS v4.0.1 in June 2024 as a limited revision that clarified language without adding or removing requirements. v4.0.1 is the version in effect today, and v4.0 has been superseded.

At launch, a subset of v4.0's new requirements were future-dated, meaning they counted as best practice rather than mandatory. That grace period ended on March 31, 2025.

Every one of those future-dated requirements, covering areas like multi-factor authentication for all CDE access and payment-page script protection, is now mandatory. A tokenization flow, access control policy, or logging setup that passed review under the older, lighter enforcement can fail an assessment today if it doesn't meet these controls.

A practical PCI compliance checklist to start with

Spreedly reduces PCI compliance scope and complexity

Any business accepting card payments online needs to be PCI compliant, and using a PCI Level 1 vault is one of the most effective ways to shrink that burden. Routing card collection through a compliant service provider keeps the bulk of the CDE off your own infrastructure, which means less to scope, less to assess, and less to maintain.

Staying current with a standard that changes as often as PCI DSS is a real operational cost on its own. Payment orchestration platforms like Spreedly absorb a lot of that burden by building support for new requirements directly into the platform, so customers spend less time chasing the standard and more time on their core business.

Every merchant's environment is different, and there may be steps beyond what's covered here based on your specific setup. Reach out to our team if you want help figuring out where payment orchestration fits into your compliance strategy, or read more about Spreedly's Vault to see how token portability reduces scope in practice.