PCi

PCI Assessments Center

Loading your workspace…

PCiPCI Assessments Center
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

Practical PCI questions

The questions people ask before they ever open an SAQ — cost, levels, paperwork, and what happens if you get it wrong.

PCI compliance checklistPCI DSS compliance follows the same order every time: confirm how you accept payments, define scope, establish whether you may self-assess, select the correct SAQ or engage a QSA, implement and evidence each applicable requirement, then validate with your acquirer. Everything else is detail hanging off those six steps.Read guide PCI for small businessMost small merchants never need the full PCI DSS. If you outsource payment acceptance completely and store no card data electronically, you are usually eligible for a short-form SAQ — often SAQ A for e-commerce or SAQ B/B-IP/P2PE for card-present — which is a fraction of the work of SAQ D. The single biggest lever is reducing what your own systems touch.Read guide PCI compliance levelsPCI compliance levels are assigned by the individual payment brands — not by the PCI Security Standards Council — and they determine how you must validate, not which requirements apply. Level 1 merchants and Level 1 service providers validate through a QSA-led Report on Compliance; lower levels may be eligible for a Self-Assessment Questionnaire, subject to their acquirer.Read guide Cost of PCI complianceThere is no list price for PCI DSS compliance, because cost tracks scope rather than company size. The spend falls into four buckets: validation effort (SAQ or ROC), mandatory testing (quarterly ASV scans, annual penetration testing where applicable), remediation of gaps, and ongoing operations. Cutting scope cuts every bucket at once.Read guide PCI DSS vs SOC 2PCI DSS is a prescriptive payment-security standard mandated by the payment brands for anyone handling card data; SOC 2 is an attestation performed by a CPA firm against the AICPA Trust Services Criteria, with controls the organisation itself defines. They overlap in evidence but not in authority — a SOC 2 report does not demonstrate PCI DSS compliance, and vice versa.Read guide Non-compliance consequencesPCI DSS is enforced contractually, not by statute. Non-compliance is handled by your acquirer under its agreement with the payment brands, and consequences escalate from remediation deadlines and monthly non-compliance charges through to higher transaction costs and, in severe or repeated cases, loss of the ability to accept cards. A breach adds forensic investigation and liability for fraud and reissuance costs.Read guide SAQ vs AoC vs ROCThe SAQ is the questionnaire you answer, the AoC is the signed declaration of the result, and the ROC is the detailed report a QSA writes when self-assessment is not available. An SAQ is always accompanied by an AoC. A ROC is required for Level 1 merchants and Level 1 service providers, or whenever a brand or acquirer mandates it.Read guide Choosing a QSAA QSA must be an individual certified by PCI SSC working for a listed QSA Company, so start by verifying the company on the PCI SSC website. After that, the differentiators are scoping accuracy, sector experience, how the assessor handles evidence and disagreement, and whether the quote is based on a real scoping conversation rather than a headcount.Read guide PCI DSS glossaryCanonical definitions of the terms that appear across the standard, the SAQs and your acquirer's paperwork.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 Requirement 1.3.1Requirement 1.3.1 says inbound traffic to the cardholder data environment must be limited to traffic that is necessary, with all other traffic specifically denied. In practice it is the deny-by-default rule that every network security control ruleset protecting the CDE has to end with.Read guide Requirement 2.2.1Requirement 2.2.1 requires configuration standards that cover all system components in scope, address known vulnerabilities, follow industry-accepted hardening standards or vendor recommendations, are updated as new vulnerabilities emerge, and are applied and verified before or immediately after a system joins production.Read guide Requirement 5.3.2Requirement 5.3.2 gives two acceptable ways to run an anti-malware solution: periodic scans combined with active or real-time scanning, or continuous behavioural analysis of systems and processes. Requirement 5.3.1 sits alongside it and requires the solution to be kept current through automatic updates.Read guide Requirement 6.3.3Requirement 6.3.3 protects all system components from known vulnerabilities through patching. Patches for critical vulnerabilities, ranked using the process in Requirement 6.3.1, must be installed within one month of release; everything else within a timeframe the entity justifies from its own risk ranking.Read guide Requirement 7.2.2Requirement 7.2.2 requires that access — including privileged access — is assigned on the basis of job classification and function, and limited to the least privileges necessary to perform those responsibilities. Requirement 7.2.1 sits above it and requires a defined access control model.Read guide Requirement 9.5.1Requirement 9.5.1 protects point-of-interaction devices that capture card data through direct physical interaction. It requires an up-to-date device list, periodic inspection of device surfaces for tampering or substitution, and personnel trained to spot and report suspicious behaviour.Read guide Requirement 10.4.1Requirement 10.4.1 requires daily review of security events and of logs from all systems that store, process or transmit account data, all critical system components, and all servers performing security functions. Requirement 10.4.1.1 adds that automated mechanisms must be used to perform those reviews.Read guide Requirement 11.3.2Requirement 11.3.2 requires external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor, with vulnerabilities resolved and rescans run until the ASV Program Guide criteria for a passing scan are met. Requirement 11.3.1 covers the internal equivalent.Read guide Requirement 11.4.3Requirement 11.4.3 requires external penetration testing at least once every 12 months and after any significant infrastructure or application change, performed per the methodology defined in Requirement 11.4.1 by a qualified tester with organisational independence. The tester does not have to be a QSA or ASV.Read guide Requirement 12.10.1Requirement 12.10.1 requires an incident response plan that exists and is ready to be activated the moment a security incident is suspected or confirmed. It must set out roles and communication paths — including notification of payment brands and acquirers — containment and mitigation procedures, business recovery, data backup, legal reporting analysis and coverage of all critical system components.Read guide