PCI DSS questions, answered by a QSA.

It depends on how you accept payments and whether you store account data electronically. In short:

• SAQ A: card-not-present merchants who have fully outsourced card capture to a compliant third party, for example a redirect or iframe payment page.
• SAQ A-EP: e-commerce merchants whose website affects the payment page, for example Direct Post or a merchant-served JavaScript form.
• SAQ B and B-IP: standalone dial-out terminals, or standalone PTS-approved terminals connected over IP.
• SAQ C-VT: manual entry into a third party's virtual terminal on an isolated computer.
• SAQ C: an internet-connected payment application at a single location.
• SAQ P2PE and SPoC: PCI-listed point-to-point encryption or software-based PIN entry solutions.
• SAQ D: everyone else, including anyone storing electronic account data, and all SAQ-eligible service providers.

The scoping tool walks through the eligibility criteria for you.

Yes. Outsourcing reduces your scope a great deal but does not remove it. You still validate, usually with SAQ A, and you remain responsible for managing your providers under Requirement 12.8, protecting the page that redirects or frames the payment form, and any paper records.

The cardholder data environment (CDE): the people, processes and technology that store, process or transmit account data, or that could affect its security. That includes systems connected to the CDE and security-impacting systems such as directory services, logging, patching and jump servers. Anything that cannot affect the CDE, and is shown to be isolated from it, can be out of scope.

Segmentation is not a requirement, but it is the most effective way to shrink scope. Properly isolating the CDE takes the rest of the network out of scope. If you rely on segmentation, it must be tested by penetration testing at least once every twelve months and after changes for merchants (Requirement 11.4.5), and every six months for service providers (11.4.6).

They can reduce scope significantly. Systems that only handle tokens, with no ability to retrieve the PAN, may be out of scope. A PCI-listed P2PE solution, used exactly as its instruction manual requires, can qualify a merchant for SAQ P2PE. Vendor claims of "encryption" alone do not, unless the solution is validated and listed by PCI SSC.

Levels are set by each payment brand, not by PCI SSC, and your acquirer applies them. Broadly, under the largest brands' programmes:

• Merchant Level 1: more than about six million transactions a year, or a merchant the brand designates (for example after a compromise).
• Merchant Level 2: about one to six million transactions a year.
• Merchant Levels 3 and 4: lower volumes, mostly validated by SAQ.
• Service provider Level 1: more than about 300,000 transactions a year; Level 2 below that.

Thresholds and rules differ by brand and region, so always confirm yours with your acquirer.

When your acquirer or a payment brand requires one, typically for Level 1 merchants and Level 1 service providers, or after a compromise. You also need a ROC if you want to use the customized approach for any requirement, because it must be documented by a QSA (or an ISA, where permitted).

A Qualified Security Assessor works for a QSA company qualified by PCI SSC and can perform independent assessments for any entity. An Internal Security Assessor is an employee qualified to assess their own organisation; whether an ISA can sign off your validation depends on the payment brand.

Annually, through a new SAQ or ROC and AOC. Some activities run more often: external ASV scans every quarter and after significant changes (11.3.2), scope confirmation at least annually for merchants (12.5.2) and every six months for service providers (12.5.2.1).

v4.0.1 is a limited revision of v4.0 that corrects and clarifies wording without adding new requirements. v4.0 was retired at the end of 2024, so v4.0.1 is the version assessed today. The bigger change is that the requirements introduced as future-dated in v4.0 became effective on 31 March 2025.

• 6.4.3 and 11.6.1: managing payment page scripts and detecting tampering with payment pages.
• 12.3.1: targeted risk analyses for requirements with flexible frequencies.
• 8.4.2: multi-factor authentication for all non-console access into the CDE.
• 5.4.1: automated mechanisms to protect personnel against phishing.
• 3.4.2: technical controls preventing copying or relocating PAN over remote access.

PCI SSC removed them from SAQ A and replaced them with an eligibility criterion: the merchant confirms its site is not susceptible to script attacks that could affect its e-commerce systems. Merchants who cannot confirm this should plan for the controls in SAQ A-EP. They still apply in full to SAQ A-EP, SAQ D and ROCs.

An alternative to meeting a requirement exactly as written: you design a control that meets the requirement's stated objective, back it with a targeted risk analysis and controls matrix, and a QSA tests it. It suits mature organisations with strong reasons to differ; it is not available through an SAQ.

A compensating control is for when you cannot meet a requirement as written because of a legitimate technical or business constraint, and must go above and beyond the original requirement. The customized approach is a deliberate choice to meet the objective differently. Compensating controls remain available in SAQs.

It depends on scope and maturity. A focused gap assessment usually takes a few weeks; remediation can take weeks to several months. Getting scope right at the start keeps the timeline under control.

Most of my PCI DSS work has been in the UAE, South Africa, the United States, India and Vietnam, delivered remotely with onsite work where the assessment requires it.