PCI DSS: Who Must Comply and Which SAQ Applies

The question of PCI DSS who must comply has a deceptively simple answer: anyone who stores, processes or transmits cardholder data, plus the service providers who can affect the security of that data. In practice the scope is where most teams get stuck, because a single hosted checkout can pull you into a different validation path than a full in-house payment system. This guide is written for compliance managers, CISOs and founders who need to know whether PCI DSS applies to them, what the standard actually asks for, and which Self-Assessment Questionnaire (SAQ) fits their setup. It reflects PCI DSS v4.0.1, the version currently in force.

What PCI DSS is

The Payment Card Industry Data Security Standard (PCI DSS) is a security standard for organisations that handle branded payment cards. It is maintained by the PCI Security Standards Council (PCI SSC), a body founded by the major card brands. The current release is PCI DSS v4.0.1. Crucially, PCI DSS is not a law. It is a contractual obligation: the card brands and your acquiring bank require it, and it flows down to you through your merchant agreement or your service-provider contracts. Enforcement, fines and validation deadlines come from acquirers and card brands rather than a regulator. The standard is organised into 12 core requirements grouped under 6 goals, covering everything from network security and encryption to access control, monitoring and a written information-security policy.

Who must comply and who is in scope

If your organisation touches cardholder data at any point, you are in scope. That includes merchants who accept cards for goods or services and service providers whose systems can influence the security of that data. The size of your obligation, and how you prove it, depends on your role and your annual card transaction volume.

Merchants and the four levels

Merchants are sorted into four levels based on annual transaction volume, and the level determines how compliance is validated:

• Level 1 is the highest-volume tier and generally requires an annual on-site assessment, producing a Report on Compliance (ROC) signed off by a Qualified Security Assessor (QSA), plus quarterly network scans.
• Levels 2, 3 and 4 cover progressively lower volumes and can often validate through an annual Self-Assessment Questionnaire and an Attestation of Compliance, again with scanning where card data traverses the internet.

The exact volume thresholds and the treatment of each level are set by the individual card brands, so confirm your level with your acquirer rather than assuming it.

Service providers

Any business that stores, processes or transmits cardholder data on behalf of others, or that could affect the security of a customer's card data, is a service provider under PCI DSS. Hosting providers, payment gateways, managed-security firms and similar businesses typically validate against the fullest requirement set, and larger service providers usually face an on-site assessment regardless of a merchant-style level.

What PCI DSS requires

The substance of the standard lives in its 12 requirements, grouped under 6 goals. In short, PCI DSS asks you to build and maintain a secure network (install and manage firewalls and network controls, and remove vendor default passwords), protect stored cardholder data (through encryption and strong cryptography in transit), and maintain a vulnerability-management programme (anti-malware controls and secure software development). It then asks you to implement strong access control (restrict access on a need-to-know basis, use unique IDs, and secure physical access), regularly monitor and test networks (log and track access, and run vulnerability scans and penetration tests), and maintain an information-security policy that governs how staff handle card data.

Version 4.0.1 keeps this structure but places more weight on continuous, risk-based security rather than a once-a-year snapshot. Several newer expectations, such as tighter scripting controls for payment pages, are relevant to e-commerce merchants and shape which SAQ applies to them.

The Self-Assessment Questionnaires and which applies

Eligible merchants validate by completing the SAQ that matches how they accept and handle card data. Picking the wrong one is a common and costly mistake, because each SAQ carries a different subset of the 12 requirements. The main types are:

• SAQ A - for merchants whose card functions are fully outsourced to validated third parties, such as e-commerce sites that redirect the customer entirely to a hosted payment page or use a fully outsourced iframe. You never touch or store card data on your own systems. This is the shortest SAQ.
• SAQ A-EP - for e-commerce merchants who partially outsource. The classic case is a payment page that your site helps deliver, for example where your web server serves scripts alongside a third-party payment form. Here the payment-page scripting and change-detection controls (requirements 6.4.3 and 11.6.1) matter, and the questionnaire is considerably longer than SAQ A.
• SAQ B - for merchants using imprint machines or standalone dial-out terminals, with no electronic cardholder-data storage.
• SAQ C - for merchants with a payment application connected to the internet, where card data is not stored electronically.
• SAQ D - the fullest questionnaire, for all other merchants who do not fit a narrower SAQ, and for service providers eligible to self-assess. It covers the broadest set of requirements.

The direction of travel is clear: the more your own systems touch card data, the longer and more demanding your SAQ becomes. Reducing scope, for example by moving from a self-hosted form to a fully redirected checkout, can move you from SAQ A-EP toward SAQ A and cut your obligations substantially.

How to actually comply

1. Confirm your role and level with your acquiring bank. Ask whether you are treated as a merchant or service provider, and which validation level applies to your volume.
2. Map your cardholder data. Document every place card data is captured, transmitted, processed or stored, including third-party payment pages and any scripts your site serves. This defines your scope.
3. Minimise scope. Outsource what you can to validated providers, tokenise or avoid storing card data, and segment the systems that remain in scope. Less scope means a shorter SAQ and lower risk.
4. Identify the correct SAQ (or confirm you need a QSA-led Report on Compliance) based on how you actually accept payments.
5. Close the control gaps. Work through the applicable requirements: firewalls and network controls, encryption, access control, logging, vulnerability management and your written security policy.
6. Arrange the external pieces. Contract an Approved Scanning Vendor (ASV) for quarterly external scans where required, and a QSA if your level demands an on-site assessment. These are separate engagements from any governance tooling.
7. Complete the SAQ and Attestation of Compliance, collect the evidence behind each answer, and submit to your acquirer.
8. Maintain it year-round. Re-scan, re-test, review logs and re-validate annually. PCI DSS v4.0.1 expects continuous, not annual, security hygiene.

For a control-by-control view of the standard and how it maps to evidence you already collect, see how Venvera handles PCI DSS. If you are not sure where you stand, the free compliance check will give you a quick read on your likely scope and gaps.

Frequently Asked Questions

Is PCI DSS a legal requirement?

No. PCI DSS is a contractual standard enforced by the card brands and your acquiring bank, not a law. That said, ignoring it can breach your merchant agreement and expose you to fines, higher fees or loss of the ability to accept cards, so in practice it functions as a hard requirement for anyone taking card payments.

Does PCI DSS apply to small businesses?

Yes. There is no minimum-size exemption. A business processing a handful of transactions a year is still in scope if it touches cardholder data. Smaller merchants usually fall into the lower validation levels and can self-assess with an SAQ rather than undergoing an on-site assessment, but they are still expected to meet the applicable requirements.

How do I know which SAQ to use?

Start with how card data reaches you. Fully outsourced e-commerce points to SAQ A; an e-commerce page you partially host or serve scripts for points to SAQ A-EP; standalone terminals point to SAQ B; an internet-connected payment application with no stored data points to SAQ C; and anything else, including most service providers, points to SAQ D. When two seem plausible, confirm with your acquirer, since choosing too light an SAQ leaves requirements unmet.

Do I still need PCI DSS if I use Stripe or another payment processor?

Usually yes, but your obligations are lighter. Using a validated processor and a hosted or redirected checkout can move you to SAQ A, the shortest questionnaire, because you avoid handling card data directly. You are still responsible for completing the SAQ, protecting your website integrity and confirming your providers are PCI DSS compliant.

Can a GRC platform make me PCI DSS compliant on its own?

No. No governance platform can validate your compliance by itself, and no GRC platform is an Approved Scanning Vendor. ASV scanning and QSA assessment are separate contracts you arrange independently. Venvera helps you organise, track and evidence your PCI DSS controls; it is not an ASV or a QSA and does not replace either.

What is the difference between an SAQ and a Report on Compliance?

An SAQ is a self-assessment that eligible merchants complete themselves, paired with an Attestation of Compliance. A Report on Compliance (ROC) is produced by a Qualified Security Assessor during an on-site assessment, and it is generally required for the highest-volume Level 1 merchants and large service providers.

Primary sources

• PCI Security Standards Council (PCI SSC) - the body that maintains PCI DSS and publishes the standards, SAQs and supporting guidance. pcisecuritystandards.org.
• PCI DSS v4.0.1 standard - the current version of the standard, with the 12 requirements and their testing procedures, available in the PCI SSC Document Library. PCI SSC Document Library.
• PCI SSC Self-Assessment Questionnaires - the SAQ documents and eligibility guidance that determine which questionnaire applies. SAQ instructions and forms.

Scope note. This guide summarises PCI DSS at a high level and does not replace the standard itself. Validation levels, thresholds and SAQ eligibility are set by the card brands and your acquirer, so confirm the specifics against the official PCI SSC documents and your own contracts before acting.

By Alexander Sverdlov, CEO and Founder, Venvera. Published 20 July 2026 - Last reviewed 20 July 2026.