GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

Cards & Merchant Payments / Learning brief

PCI DSS: what it protects

Your notes

What this means in plain language

What the Payment Card Industry Data Security Standard actually covers: which card data may be stored and which must never be, how the cardholder data environment defines scope, the difference between a self-assessment questionnaire and an on-site assessment, and how tokenisation and outsourcing shrink the problem without deleting it.

PCI DSS (Payment Card Industry Data Security Standard) is the card industry's security rulebook for anyone who stores, processes, or transmits cardholder data. It is not a law: it binds through contracts, flowing from scheme rules to acquirers to merchants, and it is organised as twelve high-level requirements covering networks, data protection, access control, monitoring, and policy. The standard draws one hard line: cardholder data such as the PAN (primary account number) may be stored if strongly protected, but sensitive authentication data — full magnetic-stripe or chip data, card verification codes, PINs — must never be stored after authorisation, even encrypted. Everything else follows from scope: the cardholder data environment is every system that touches card data plus everything connected to it, and the craft is shrinking that footprint with tokenisation, hosted payment pages, and encrypting terminals. Compliance is validated either by a self-assessment questionnaire (SAQ) or, for larger players, an on-site assessment producing a Report on Compliance — which one applies is decided by the schemes and the acquirer.

Three things to remember

  1. 01

    PCI DSS is a contractual standard, enforced through scheme rules and acquirer agreements, for anyone handling cardholder data.

  2. 02

    Stored PANs must be rendered unreadable, and sensitive authentication data may never be stored after authorisation — encryption is not an excuse.

  3. 03

    Scope is defined by where card data flows; tokenisation and outsourcing shrink it dramatically, but an attestation duty always remains.

Where you would use this

USE CASE 01

A small webshop moves to a hosted payment page and tokenised card-on-file so its own servers never see a PAN, qualifying it for a much shorter self-assessment.

USE CASE 02

A merchant's annual scoping review hunts for stray card data — exports, logs, call recordings — before the assessment tests whether the declared boundary is real.

USE CASE 03

An acquirer tells a fast-growing merchant that its transaction volume now requires an on-site assessment by a qualified security assessor instead of a questionnaire.

Put the idea into a real situation

Illustrative example (SYNTHETIC / TRAINING ONLY): Demo Coffee Ltd, a fictional merchant, accepts cards through terminals from its fictional acquirer Meridian Bank and through a webshop that redirects to the processor's hosted payment page. The terminals encrypt card data at the tap, so Demo Coffee's tills and servers never hold a usable PAN, and the merchant expects a short self-assessment questionnaire. Then the scoping review finds a spreadsheet on the office shared drive: an export from a retired loyalty tool containing 1,200 full card numbers. That single file drags the office network into scope. Demo Coffee securely deletes the file, confirms no copies exist in backups, documents the clean-up, and completes its SAQ and attestation of compliance for Meridian Bank with the boundary intact — and adds a quarterly search for stray card data so the next forgotten export never reaches assessment day.

Evidence & review

REVIEWED 2026-07-18

Any entity that stores, processes, or transmits cardholder data — merchants, service providers, and processors — in any market. Validation levels and reporting duties are set by the card schemes and the entity's acquirer, not by the standard itself.

What this brief simplifies: Describes the standard's structure and scoping logic without citing version-specific requirement numbers or SAQ type letters. The compensating-control and customised-approach mechanisms are omitted; a qualified assessor's judgement governs real cases.

Sources for this brief1
  1. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

Card payments: the four-party model

Who does what in a card payment: the cardholder and merchant at the ends, the issuer and acquirer as their banks, and the card network in the middle routing messages and publishing the rules — plus how the three-party model collapses those roles into one operator.

READ BRIEF

Card authorization under the hood

The real-time round trip behind an approved card payment: the ISO 8583 authorization request and response legs, what the issuer checks before answering, the authorisation hold that reserves money without moving it, and stand-in processing when the issuer cannot answer at all.

READ BRIEF

Card clearing and settlement, explained

How an approved card payment becomes money: end-of-day batches, clearing records presented through the network, interchange applied, multilateral net positions, one settlement movement between banks, and the final postings that debit the cardholder and pay the merchant net of fees.

READ BRIEF
COMMUNITY SIGNAL

Discuss this learning page

Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.

NEXT QUESTION REVIEWMonday, 27 Jul, 8:00 amMonday answer runs use source-supported educational material. Some questions may need owner review.
WHAT ARE YOU SHARING?

Public discussion

LOADING

Loading the discussion…