What is PCI compliance?
PCI compliance means meeting the Payment Card Industry Data Security Standard (PCI DSS). This is the security standard for any business that stores, processes or transmits payment card data. It also covers any business that can affect the security of that data. Do you accept Visa, Mastercard, American Express, Discover or JCB cards? Then your contract with your bank requires you to comply. It usually requires you to prove compliance every year too.
In plain terms, the PCI compliance meaning is this: you protect cardholder data with a defined set of controls, and you can prove it. You prove it with a self-assessment, or with an assessment by a Qualified Security Assessor (QSA). A QSA is an outside assessor approved by the PCI Security Standards Council.
The PCI Data Security Standard and the current version
PCI DSS is maintained by the PCI Security Standards Council (PCI SSC). The major card brands founded it: American Express, Discover, JCB, Mastercard and Visa. The council writes the standard. The card brands and acquiring banks decide who must prove compliance and how, and they enforce it. An acquiring bank (acquirer) is the bank that processes card payments for a merchant.
- PCI DSS v4.0.1 is the current version. It was published in June 2024 as a limited revision of v4.0. It adds clarifications rather than new requirements.
- v4.0 was retired at the end of 2024, so assessments now use v4.0.1.
- The future-dated requirements introduced in v4.0 were best practice until March 31, 2025. Since that date they are required and checked like any other requirement.
PCI DSS is not a law in most places. It is a duty under your contract with your bank, called the merchant agreement. If you do not comply, your acquirer may pass on fines and charge higher processing fees. You may also be liable for breach costs. In serious cases you can lose the ability to accept cards.
Who needs to be PCI compliant?
Two groups:
- Merchants: any business that accepts card payments, online, in person or over the phone, of any size.
- Service providers: companies that store, process or transmit card data for others, or could affect its security. Examples include payment gateways, hosts for cardholder systems, managed security providers and call centers taking card payments.
Using a payment provider such as Stripe, Adyen or PayPal does not remove your PCI duties. But it can shrink them a lot. How you connect to the provider decides how much of the standard applies to you.
The 12 PCI DSS requirements
PCI DSS v4.0.1 groups its controls into six goals and 12 main requirements. Each one breaks down into many smaller rules:
| Goal | # | Requirement |
|---|---|---|
| Build and maintain a secure network and systems | 1 | Install and maintain network security controls |
| 2 | Apply secure configurations to all system components | |
| Protect account data | 3 | Protect stored account data |
| 4 | Protect cardholder data with strong cryptography during transmission over open, public networks | |
| Maintain a vulnerability management program | 5 | Protect all systems and networks from malicious software |
| 6 | Develop and maintain secure systems and software | |
| Implement strong access control measures | 7 | Restrict access to system components and cardholder data by business need to know |
| 8 | Identify users and authenticate access to system components | |
| 9 | Restrict physical access to cardholder data | |
| Regularly monitor and test networks | 10 | Log and monitor all access to system components and cardholder data |
| 11 | Test security of systems and networks regularly | |
| Maintain an information security policy | 12 | Support information security with organizational policies and programs |
Requirement 11 includes quarterly external vulnerability scans by an Approved Scanning Vendor (ASV), plus quarterly internal scans. A vulnerability scan is an automated check for known weaknesses. It also requires penetration testing at least once a year and after significant changes. A penetration test is a hired, legal attempt to break in. You may rely on network segmentation, walling off card systems from the rest, to reduce scope. If so, it must be tested too.
Merchant levels, SAQ and ROC
How you prove compliance depends on your merchant level. Each card brand sets the levels, mainly by yearly transaction volume. The levels below follow Visa's commonly cited definitions. Other brands are similar but not identical, and your acquirer has the final say.
| Level | Typical threshold (Visa) | Usual validation |
|---|---|---|
| Level 1 | Over 6 million transactions a year, or any merchant the brand designates, for example after a breach | Annual Report on Compliance (ROC) by a QSA, plus quarterly ASV scans |
| Level 2 | 1 to 6 million transactions a year | Usually an annual SAQ. Some card brands (for example Mastercard) require it to be completed by a certified Internal Security Assessor (ISA) or a QSA. Check with your acquirer. |
| Level 3 | 20,000 to 1 million e-commerce transactions a year | Annual SAQ, plus ASV scans where applicable |
| Level 4 | Fewer than 20,000 e-commerce transactions, or up to about 1 million total transactions a year | Annual SAQ as required by the acquirer |
A Self-Assessment Questionnaire (SAQ) is a form the merchant fills in. Which SAQ applies depends on how you take payments. SAQ A covers online shops that fully outsource the payment page. SAQ A-EP covers sites that affect the payment page without receiving card data. SAQ B-IP and SAQ C-VT cover certain card terminal and virtual terminal setups. SAQ P2PE covers validated point-to-point encryption solutions, which encrypt card data inside the terminal. SAQ D covers everyone else, including service providers eligible to self-assess.
A Report on Compliance (ROC) is a detailed assessment performed by a QSA. Here, QSA means an assessor company and its staff, qualified by the PCI SSC. The ROC comes with an Attestation of Compliance (AOC), a signed summary of the result. Service providers with large volumes need a ROC. Under Visa and Mastercard rules, that commonly means over 300,000 transactions a year.
Reduce your PCI scope first
The cheapest PCI control is the one you do not need. Every system that stores, processes or transmits card data is in scope. So is every system connected to those. Shrinking that footprint shrinks the work.
- Hosted payment pages or iframes: let your payment provider collect card data so it never touches your servers. An iframe is a window on your page that loads the provider's form. This is often what makes SAQ A possible.
- Tokenization: store a token (a stand-in code) from your provider instead of the card number. Your databases then hold nothing a thief could use.
- Validated P2PE terminals: encrypt card data at the point of interaction, so your in-store network stays out of scope.
- Network segmentation: wall off any systems that must handle card data from the rest of your network, and test that separation.
- Data discovery: find and remove card numbers that ended up in logs, support tickets, call recordings and spreadsheets.
Common PCI compliance gaps under v4.0.1
These are the PCI compliance requirements companies most often struggle with. Many are the future-dated items that became required in March 2025. The numbers in parentheses are the PCI DSS requirement IDs:
- Multi-factor authentication (a second login step, such as a phone code) for all access into the cardholder data environment, not only remote access (8.4.2)
- Inventory and authorization of scripts on payment pages (6.4.3), and change and tamper detection for payment pages (11.6.1). Both target e-skimming, where attackers plant code that copies card details
- Targeted risk analyses to justify how often certain controls are run (12.3.1)
- Authenticated internal vulnerability scanning, where the scanner logs in (11.3.1.2)
- Passwords of at least 12 characters where systems support it (8.3.6)
- Automated tools for reviewing audit logs (10.4.1.1)
- Anti-phishing tools, to block fake emails that trick staff (5.4.1)
- Scope that is not documented and confirmed at least every 12 months (12.5.2)
- Outside service providers without a current Attestation of Compliance, or without a clear split of duties (12.8)
How NextGarrison helps
NextGarrison is not a QSA and does not issue ROCs or sign Attestations of Compliance. We help merchants and service providers prepare. That includes scoping and scope reduction, and gap assessments against PCI DSS v4.0.1. It also includes help fixing gaps, policy templates, and the penetration and segmentation testing required by Requirement 11. When you are ready, your QSA or acquirer handles formal validation. See our compliance readiness services. Or read vulnerability assessment vs penetration testing to understand the testing side.
Need a hand with this?
Talk to a senior consultant. We reply within one business day with clear next steps and a scoped quote.
Written by
NextGarrison Security TeamPenetration testers, SOC analysts and compliance consultants
Our consultants test applications and networks, run 24/7 security monitoring and prepare companies for SOC 2, ISO 27001 and PCI DSS assessments. We write about what we see in real engagements, in plain English.