PCI DSS

PCI DSS organises its controls into six goals (control objectives) that break down into 12 core requirements: build and maintain a secure network and systems (Req 1-2), protect account data (Req 3-4), maintain a vulnerability management programme (Req 5-6), implement strong access control measures (Req 7-9), regularly monitor and test networks (Req 10-11), and maintain an information security policy (Req 12). Each requirement contains testing procedures and, in v4.0, a defined and a customised approach. The current version, PCI DSS v4.0.1, was published in June 2024 as a limited revision of v4.0 that corrects minor errors and clarifies language without adding new requirements.

Visa classifies merchants into four levels by annual transaction volume, which sets the validation path. Level 1: more than 6 million Visa transactions per year across all channels (or any merchant Visa designates Level 1, e.g. after a compromise) - annual on-site assessment and Report on Compliance (ROC) plus quarterly network scan. Level 2: 1 to 6 million transactions per year - annual Self-Assessment Questionnaire (SAQ) and quarterly scan. Level 3: 20,000 to 1 million Visa e-commerce transactions per year - SAQ and quarterly scan. Level 4: fewer than 20,000 Visa e-commerce transactions, or up to 1 million total transactions per year - SAQ and scan as required by the acquirer. Other card brands set broadly similar but not identical thresholds; the acquirer confirms a merchant's level.

PCI DSS defines nine SAQ types, each scoped to how a merchant handles cardholder data: SAQ A (fully outsourced e-commerce or mail/telephone order, no data handling); SAQ A-EP (e-commerce that partially controls the payment page); SAQ B (imprint machines or standalone dial-out terminals, no electronic storage); SAQ B-IP (standalone PTS-approved IP-connected terminals); SAQ C-VT (web-based virtual terminal, one transaction at a time); SAQ C (payment application connected to the internet); SAQ P2PE (hardware terminals in a validated PCI P2PE solution); SAQ D for Merchants (all others that store, process or transmit cardholder data - the most comprehensive); and SAQ D for Service Providers. A merchant who cannot meet an SAQ's eligibility criteria, or who is a Level 1 merchant, completes a full Report on Compliance (ROC) instead of an SAQ.

PCI DSS v4.0.1 is the current standard published by the PCI Security Standards Council.

PCI DSS v3.2.1 retired 31 March 2024. v4.0.1 (a limited revision — no requirements added or removed) was published 11 June 2024, and v4.0 retired 31 December 2024, leaving v4.0.1 the only active version. The 51 future-dated v4.x requirements became mandatory in assessments from 31 March 2025.

PCI SSC publishes ten SAQs: A, A-EP, B, B-IP, C, C-VT, D for Merchants, D for Service Providers, P2PE and SPoC. A separate “SAQ Instructions and Guidelines” document accompanies them and sets out eligibility for each.

Enumerated from PCI SSC’s document library. Which SAQ a given entity may use depends on how it handles cardholder data, and validation is ultimately driven by the acquirer or card brand rather than by PCI SSC. The eligibility criteria sit inside the SAQ Instructions document, which is distributed under licence acceptance and cannot be retrieved automatically — so this entry records the set of questionnaires, not the criteria.

“Integrating Artificial Intelligence in PCI Assessments Guidelines v1.0” is published in the PCI SSC document library, establishing that the Council addresses the use of AI within PCI assessments at version 1.0.

This entry records the document’s existence and version, both visible in the document library. Its contents are behind licence acceptance and have not been read, so no substantive requirement is asserted here.

PCI DSS v4.x allows two approaches. The Defined Approach is the traditional method: the entity implements the stated requirement and the assessor follows the defined testing procedures. The Customized Approach, new in v4.x, lets an entity meet a requirement’s Customized Approach Objective by other means, supporting innovation in security practice. Compensating controls are available only under the defined approach, and only where a legitimate, documented technical or business constraint prevents meeting the requirement as stated; they must be documented annually, reviewed and validated by the assessor, and submitted with the ROC.

Section 1.2. The document states plainly: “Compensating Controls are not an option for the Customized Approach.” Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

Each individual PCI DSS requirement is reported as exactly one of: In Place, Not Applicable, Not Tested, or Not in Place. Not Applicable requires the assessor to render an opinion and to report the testing performed to confirm non-applicability. Not Tested means the requirement was excluded from consideration entirely — the assessor follows the entity’s instruction and renders no opinion — and any use of Not Tested makes the engagement a Partial Assessment.

Sections 2.2, 2.3, 4.1 and 4.2. “In Place with Remediation” existed in the original v4.0 ROC Template and was removed by Revision 1, so it is not a valid finding. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

The ROC records an Overall Assessment Result of Compliant, Compliant but with Legal Exception, or Non-Compliant. Separately it records whether a Full or Partial Assessment was performed: Full means every requirement was assessed and none marked Not Tested; Partial means one or more were marked Not Tested. “Compliant but with Legal Exception” applies where a statutory law or regulation prohibits meeting a requirement — the assessor must confirm such a law exists, and contractual obligations or legal advice do not qualify.

Sections 2.1, 2.3 and 4.1. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

The PCI DSS ROC Template is mandatory for QSAs reporting a PCI DSS assessment, and every response section must be completed even where requirements are not applicable. QSAs may add company logos and legal wording to the customisable title page, change page headers, add table rows, and delete the ROC Template Instructions before issuing the report. They may not edit footers, change the format, reorder or remove sections or requirements, or remove any content from Parts I and II.

Sections 5.1 and 5.4. The current unlocked Word version is distributed to assessors through the Assessor Portal at programs.pcissc.org. Accepting payment brands or acquirers may reject a report whose template changes they consider unacceptable. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

PCI DSS v4.0 introduced the targeted risk analysis (TRA). Requirement 12.3.1 covers TRAs that set how frequently a periodic activity is performed; Requirement 12.3.2 covers TRAs supporting any requirement met by the customized approach. A TRA is required only where a requirement explicitly says so. Once prepared, the entity reviews each TRA at least once every 12 months and on changes that could affect risk. A TRA cannot be used to perform an activity LESS often than a requirement states — that is a failure of the requirement, not a risk decision.

Introduction and FAQs 1, 2, 5 and 6. Performing an activity MORE often than stated needs no TRA. Where a documented technical or business constraint prevents meeting a stated frequency, the route is a compensating control, not a TRA. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

Nine requirements let the entity set frequency by TRA, and PCI SSC publishes baseline recommendations for each: malware-risk re-evaluation for components deemed not at risk (5.2.3.1) at least every six months; periodic malware scans (5.3.2.1) daily; review of application and system account access (7.2.5.1) every six months; changing application and system account passwords (8.6.3) every three months; POI device inspections (9.5.1.2.1) monthly; log reviews for other system components (10.4.2.1) every seven days; remediation of non-critical vulnerabilities (11.3.1.1) within three months for medium and six months for low; payment-page change- and tamper-detection (11.6.1) every seven days; and incident-response training (12.10.4.1) yearly and at the start of employment.

Table at the end of the supplement. These are recommendations, not requirements — a TRA is still required to document and justify whichever frequency the entity selects. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

Appendix A3, Designated Entities Supplemental Validation (DESV), is assessed only when an acquirer or payment brand instructs an entity to undergo it. It adds five requirement groups: A3.1 a PCI DSS compliance programme, A3.2 documented and validated scope, A3.3 PCI DSS embedded in business-as-usual, A3.4 controlled logical access, and A3.5 identification of and response to suspicious events. Its cadences are tighter than the annual assessment: scope confirmed and data discovery performed at least every three months, BAU reviews every three months, segmentation penetration testing every six months, and user-account review every six months.

Instructions for Submission and Findings sections. Every DESV requirement examined states “This requirement is not eligible for the customized approach,” so DESV must be met as defined, with compensating controls the only flexibility. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.

PCI SSC recommends retaining all collected assessment evidence for a minimum of three years, so an organisation can substantiate historic compliance statements and support forensic analysis after a breach. Contractual obligations or local law may require longer. Evidence includes work papers, audit results, interview notes, screenshots and configuration settings, and the retention process should guard against evidence being altered, tampered with or destroyed.

Section 3.6.7. This supplement is written against PCI DSS v3.2.1 and states so; the retention recommendation is guidance rather than a numbered v4.x requirement. Where an entity forbids its QSA from retaining evidence, PCI SSC expects a formal agreement allocating retention responsibility.

SAQ A covers e-commerce or mail/telephone-order merchants who outsource all processing of account data to PCI DSS compliant third parties, store, process and transmit no account data electronically on their own systems or premises, have confirmed those third parties are compliant for the services used, and retain any account data only on paper not received electronically. E-commerce merchants must additionally confirm that every element of the payment page delivered to the customer’s browser originates only and directly from a compliant third-party processor, and that their site is not susceptible to script-based attacks affecting their e-commerce systems. SAQ A does not apply to face-to-face channels or to service providers.

The two e-commerce criteria were ADDED by revision r1 in April 2025 — the document’s revision history records them as new eligibility criteria, not a clarification. A merchant that qualified for SAQ A before April 2025 may no longer qualify. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ A-EP covers e-commerce merchants whose website does not itself receive account data but does affect the security of the transaction or the integrity of the page accepting the customer’s account data — typically by controlling how customers or their data are redirected to a compliant processor. Each element of the payment page must originate from either the merchant’s website or a compliant third party. Where the site is hosted by a third party, that provider must meet all applicable requirements including PCI DSS Appendix A for multi-tenant hosting. The SAQ applies only to e-commerce and not to service providers.

For SAQ A-EP the requirements that refer to the cardholder data environment apply to the merchant website itself, because the site directly affects how account data is transmitted even though it never receives that data. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ B covers merchants processing account data only through imprint machines or standalone dial-out terminals connected by phone line, not connected to the Internet or to other systems. SAQ B-IP covers merchants using only standalone, PCI-listed approved PTS point-of-interaction devices connected by IP directly to the payment processor, isolated from other systems, where the device does not rely on any other computer, phone or tablet to reach the processor. Neither SAQ permits electronic storage of account data, applies to e-commerce, or applies to service providers.

Secure Card Readers (SCR) and Secure Card Readers for PIN (SCRP) are explicitly excluded from SAQ B-IP — merchants using them are not eligible. A merchant on an expired PTS POI device should check acceptability with its acquirer or the payment brands. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ C covers merchants with a payment application system such as a POS on the same device or LAN as an Internet connection, isolated from all other systems, where the POS location is not connected to other premises and any LAN serves a single store only. SAQ C-VT covers merchants whose only processing is manual, single-transaction keyboard entry into a third-party hosted virtual payment terminal, accessed from an isolated computing device in a single location with no card readers attached and no software that stores account data. Neither stores account data electronically, applies to e-commerce, or applies to service providers.

Isolation in both SAQs may be achieved by network segmentation, and does not prevent the permitted system type from transmitting transaction data onward to an acquirer or processor. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ P2PE covers merchants whose payment processing runs entirely through payment terminals belonging to a validated, PCI-listed point-to-point encryption solution, where those terminals are the only systems that store, process or transmit account data, the merchant has no access to clear-text account data on any computer system, and the merchant has implemented all controls in the P2PE Instruction Manual supplied by the solution provider. It does not apply to e-commerce or to service providers.

Solutions appearing on the PCI list of Point-to-Point Solutions with Expired Validations are no longer “validated”; a merchant on an expired solution should confirm acceptability with its acquirer or the payment brands. A mail/telephone-order merchant keying data from paper or a call directly into such a terminal can qualify. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ SPoC covers merchants processing card-present transactions only through a PCI-listed approved PTS Secure Card Reader-PIN device together with a commercial off-the-shelf mobile device, as part of a validated PCI-listed Software-based PIN Entry on COTS solution, with no access to clear-text account data on any computer system. The COTS device is general purpose — it need not be dedicated to payments.

Merchants using non-PTS-listed magnetic stripe readers are not eligible. The SAQ may be used for PTS-listed SCRPs that include magnetic stripe reader functionality. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

SAQ D for Merchants applies to any SAQ-eligible merchant that does not meet the criteria for another SAQ type — including e-commerce merchants who accept account data on their own website, merchants who store account data electronically, and merchants who would otherwise fit a narrower SAQ but have additional PCI DSS requirements applicable to their environment. SAQ D for Service Providers applies to all service providers a payment brand has deemed eligible to self-assess.

Under PCI DSS v4.x, SAQ D for Service Providers requires additional documentation in Section 2a and requires the service provider to describe results for each requirement rather than simply answer. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.

Each SAQ states that the merchant confirms eligibility “for this payment channel”, so a merchant running several channels may need to validate them separately. Of the nine merchant SAQs, only SAQ A and SAQ A-EP cover e-commerce; B, B-IP, C, C-VT, P2PE and SPoC each state they are not applicable to e-commerce channels. Every SAQ except SAQ D for Service Providers states it is not applicable to service providers. In all cases the entity must also meet whatever validation its acquirer or the payment brands require — PCI SSC does not set that.

This channel-by-channel framing is the most commonly missed point in scoping conversations: qualifying for a narrow SAQ on one channel says nothing about the others. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.