Who Does PCI DSS Actually Govern?
Let's take the name apart first: PCI DSS: the Payment Card Industry Data Security Standard: was established by the major card brands together and is maintained by the PCI Security Standards Council. It is not a law, and no regulator issues it. Laws come from legislatures and enforcement agencies; this standard's power comes from somewhere else: the contractual relationship between card brands and acquirers. Failing to comply won't bring enforcement, but it can bring penalties, required extra assessments, and: in serious cases: losing the ability to accept card payments at all.
The standard requires that any organization that stores, processes, or transmits card data must satisfy a set of controls. The count and numbering of those controls shift between versions, but the core has long revolved around six things: secure networks, protecting stored data, vulnerability management, access control, monitoring and testing, and security policy.
One more thing has to be clear from the start: each organization defines its own scope, and scope means which systems have touched card data. The narrower the scope, the less an impressive assessment result means: it only speaks to the part that was included. “What's the scope?” is the question to ask before believing any compliance claim. The standard's text and versioning are maintained by the PCI Security Standards Council.
Card Data Isn't One Thing
The standard's most central classification splits card data into two categories, treated very differently:
| Cardholder data (CHD) | Sensitive authentication data (SAD) | |
|---|---|---|
| What it includes | Card number (PAN), cardholder name, expiry date | Full track data, the card security code (CVV2 / CVC2 / CAV2 / CID), and PINs and PIN blocks |
| Can it be stored? | Yes, but it must be made unreadable | Must not be stored after authorization |
| Storage requirement | One of: encryption, hashing, truncation, or tokenization | There is no “compliant way” to store it |
| If leaked | Only usable in transactions when combined with other data | Usable directly for card-not-present transactions |
The right-hand column is the harshest rule in the entire standard: it has essentially no exceptions: there's only “don't store.”
The reason for the different treatment is straightforward: card numbers, names, and expiry dates appear in many places, and banning all storage would break operations: while track data and security codes, after an authorization completes, serve no purpose in legitimate business. Keeping them is pure risk.
So whether “seeing the security code” is acceptable depends on the context. An issuer showing a cardholder their own card's details is necessary and legitimate; a merchant you once bought from being able to display your full card number and security code afterwards is a clear red flag: it probably stored things it shouldn't have.
Masking, Encryption, and Tokenization
The ways to protect a card number are often lumped together, but they differ in reversibility, which makes their use cases completely different:
| Method | What it does | Reversible? | Typical use |
|---|---|---|---|
| Encryption | Uses a key to turn the card number into ciphertext | Yes: reversible with the key | Storage and transmission |
| Truncation / masking | Keeps only part of the characters and replaces the rest | No | Displaying the card number (first six, last four) |
| Hashing | One-way digest, usable only for comparison | No | Checking whether it's the same card |
| Tokenization | Replaces the number with a substitute value; the mapping lives with the issuer | The holder can't reverse it | Allowing the merchant to charge again next period |
Which one to pick depends on what you need to do with the data next.
Choose by purpose: need to reverse it: use encryption; need to display it: use truncation; need to compare it: use hashing; need merchants to keep charging without ever seeing the number: use tokenization. These are four different jobs. Tokenization gets its own page: Tokenization and digital wallets: payment tokens and enrollment.
HSMs and Key Management
Encryption's value rests entirely on the keys, so the strictest part of this standard isn't about algorithms: it's about how keys are managed. That breaks down into four things:
- Keys live in an HSM: a hardware security module is a tamper-resistant dedicated device, and keys never leave its physical and logical boundaries;
- The cryptographic module must be validated: the module inside the HSM needs to pass the FIPS 140 series (a standard from the U.S. National Institute of Standards and Technology; published by that agency);
- Keys must be rotated and separated: replaced periodically, stored separately by purpose, and never fully held by a single person;
- Everything must be logged: generation, backup, access, and destruction all have to be auditable.
This also explains why “we use encryption” carries so little information on its own. The three questions that matter are: where are the keys stored, who can access them, and how often are they rotated. If you can't answer those, no algorithm, however strong, means anything.
Compliance Doesn't Mean Nothing Can Happen
A few claims about this standard need clarifying one by one:
| Common claim | What it actually means |
|---|---|
| “We passed PCI DSS” | Satisfied the controls in force at the time of the assessment. How it's verified depends on level: high-volume organizations need an external assessment; lower-volume ones can use a self-assessment questionnaire |
| “How is the level determined?” | Each card brand assigns levels based on factors like transaction volume: the council doesn't set them directly, so one organization can hold different levels under different brands |
| “Compliant means no breaches” | False. Compliance lowers common risks; it's not a guarantee about the future |
| “Cardholders must be compliant too” | False. Cardholders aren't required parties |
The third row is the most overlooked: and the one most often used to overpromise.
This standard is easier to understand in its proper place: it's a floor. It says “at minimum, do these things”: not “do these things and you're safe.” Real risk usually lives where nothing was checked: outside the scope, after the assessment's point in time, and in slips of people and process.
What Cardholders Can Do
Cardholders can protect their payment data with these four precautions:
Decide whether to give this merchant your card
Don't look for a compliance badge; look at whether it asks for more than it needs: requesting full track data, or expecting the card number and security code stored together, are clear red flags.
Recognize cards by the last four digits
First-six-last-four is the display standard. Any step that asks you for the full card number deserves a “why do you need it?” first.
Don't keep the card number and security code in the same place
Storing them separately can't stop a leak, but it reduces the damage if both leak at once: a card number without the security code often isn't enough to complete card-not-present transactions.
Turn on transaction notifications
You can't touch the storage or transmission links; your only early warning is notifications. If you spot unexplained small transactions, replace the card: don't wait for a real charge.
This platform's boundary should be clear: card numbers and security codes are visible in the cardholder's own account: a legitimate need on the issuing side. But we don't claim to hold any particular certification, and we don't promise which protective measures a merchant will take. The platform's entity registration and identity-information collection scope are documented on the KYC Policy page, and the rules for handling funds and accounts are on the Security & Compliance page.
Security is everyone's responsibility: submit information only through official channels, and see Security & Compliance for how accounts and funds are handled.
FAQ
Is PCI DSS a law?
No. It's an industry standard established by the card brands together; its authority comes from the contractual relationship between card brands and acquirers, and no regulator issues it.
Do individuals need to pass PCI DSS?
No. The standard governs organizations that store, process, or transmit card data: cardholders aren't a required party.
Can merchants store my card number?
Yes, but it must be protected in an unreadable form: one of encryption, hashing, truncation, or tokenization. Storing card numbers in plaintext doesn't meet the standard.
Can merchants store the security code from the back of my card?
Not after authorization completes. The security code is sensitive authentication data, and the standard offers no compliant way to keep it. Issuers storing it for legitimate business needs are the exception, and they must protect it.
If a statement shows only the last four digits, is it encrypted?
No: that's truncation (masking). First-six-last-four is a display standard, not a storage standard; storage still requires the card number to be unreadable.
If an organization can show me my card's full details, is it unsafe?
You can't conclude that. An issuer showing a cardholder their own necessary details is legitimate. The real red flag is a merchant you've bought from being able to display both your full card number and security code afterwards.
What's the difference between encryption and tokenization?
Encryption is reversible: with the key, the card number can be recovered. Tokenization uses a substitute value: the merchant holds the token but can't reverse it into the card number, because the mapping lives with the issuer.
Is an HSM required? Can't keys be stored in software?
The standard requires keys to be protected; an HSM is the most common and strongest implementation: tamper-resistant, keys never leave the module's boundary, and the module itself must pass the FIPS 140 series.
If we pass compliance, nothing will go wrong?
Not true. Compliance is a verification at one point in time and covers only the declared scope. It reduces common risks; it isn't a guarantee about the future.
Got the idea in a few minutes? Go open a card
Cards start at $1, no monthly fee; account top-up is $0 with a $20 minimum per deposit. See the pricing page for full details.