Free · No sign-up required

PCI DSS guides

QSA-authored, free guides to PCI DSS v4.0.1: which SAQ applies to you, deep dives on all ten SAQ types, a comparison matrix, an FAQ and plain-English requirement explainers.

Find your SAQ Start with the SAQ guide

Choosing your SAQ

Which SAQ applies to me?Walk the official PCI SSC decision flows for merchants and service providers, with every eligibility clause.Read guide SAQ comparison matrixSide-by-side comparison of all ten SAQ types and the pairs most often confused.Read guide SAQ FAQStraight answers to the questions merchants ask most about self-assessment.Read guide

SAQ deep dives

One page per SAQ type — who it is for, every eligibility criterion, and the mistakes that cost merchants their short-form eligibility.

SAQ ASAQ A is for card-not-present merchants (e-commerce or MOTO) where all account data functions are fully outsourced to a PCI DSS compliant third party and the payment page comes only and directly from that provider.Read guide SAQ A-EPSAQ A-EP applies to e-commerce merchants whose own website delivers some payment-page elements or controls how the customer or their account data is redirected to a PCI DSS compliant third party.Read guide SAQ BSAQ B is for card-present and MOTO merchants that use only imprint machines or standalone dial-out terminals connected via phone line, with no electronic storage of account data.Read guide SAQ B-IPSAQ B-IP is for merchants using standalone, PCI-listed approved PTS POI devices connected via IP to the payment processor, with no electronic storage of account data.Read guide SAQ C-VTSAQ C-VT is for merchants that manually enter a single transaction at a time into a third-party virtual payment terminal hosted by a PCI DSS compliant provider.Read guide SAQ CSAQ C is for merchants with a payment application connected to the Internet at a single location, segmented from other systems, with no electronic storage of account data.Read guide SAQ P2PESAQ P2PE applies when all payment processing runs through a solution on the PCI SSC list of validated P2PE Solutions and every control in the P2PE Instruction Manual is implemented.Read guide SAQ SPoCSAQ SPoC applies to attended card-present merchants using a PCI-listed Secure Card Reader-PIN (SCRP) paired with a commercial off-the-shelf phone or tablet as part of a validated PCI-listed SPoC solution.Read guide SAQ D-MerchantSAQ D for Merchants applies to merchants that are eligible to self-assess but do not meet the criteria for any other SAQ type, including those that store account data electronically or mix channels.Read guide SAQ D-SPSAQ D for Service Providers is the only SAQ available to service providers that have been determined eligible to self-assess by their compliance-accepting entity.Read guide

PCI DSS v4.0.1 topics

Plain-English explainers on the requirements that generate the most questions since v4.0.1 became the only active version.

PCI DSS v4.0.1 transitionWhat changed from v3.2.1, which requirements were future-dated, and what is now mandatory.Read guide Requirement 6.4.3Requirement 6.4.3 targets digital skimming (Magecart-style attacks). Every script that loads in the consumer's browser on a payment page must be there deliberately, must be protected against unauthorised modification, and must be recorded in a written inventory with a business justification.Read guide Requirement 11.6.1Requirement 11.6.1 is the detective control that pairs with 6.4.3. A mechanism must alert personnel when the HTTP headers or the content of the payment page as received by the consumer browser are modified without authorisation, and it must be evaluated at least once every seven days.Read guide Requirement 12.8Requirement 12.8 governs how an entity manages third-party service providers (TPSPs) that can affect the security of cardholder data. It covers the inventory, written agreements, due diligence before engagement, annual monitoring of compliance status, and a documented split of PCI DSS responsibilities.Read guide Requirement 8.3.6Requirement 8.3.6 sets the minimum strength for passwords and passphrases used as an authentication factor. Passwords must be at least 12 characters long and contain both numeric and alphabetic characters, with a narrow exception where a system cannot technically support 12.Read guide Requirement 3.2.1Requirement 3.2.1 keeps account data storage to the minimum. Sensitive authentication data (full track data, card verification codes, PINs and PIN blocks) must not be retained after authorisation, even when encrypted, and all storage of account data must be governed by a documented retention and disposal policy.Read guide Requirement 8.4.2Requirement 8.4.2 broadens MFA well beyond the v3.2.1 position. Multi-factor authentication is now required for all access into the cardholder data environment — including access from inside the corporate network — with a narrow exception for user accounts on a POI terminal that only have access to one card number at a time.Read guide