Why do some Issuers believe they don’t need to be PCI DSS compliant?
Documents from the PCI Council, MasterCard, and Visa clearly indicate that Issuers are required to be PCI DSS compliant (see Learn More below). Yet...
4 min read
David Gamey
:
Aug 26, 2021 10:07:00 PM
Card Not Present Security Codes/Values are the 3 and 4 digit printed numbers on your payment cards used to verify card-not-present transactions. PCI DSS has been crystal clear for many years that payment Card Verification Codes/Values are Sensitive Authentication Data (SAD) and can't be stored after transaction authorization except by card Issuers. Specifically PCI says:
Despite this, we occasionally encounter entities storing security codes/values that fit neither of these use-cases. Almost universally, these entities believe they have a compelling justification or loop hole that allows them to store these codes/values. We’ve heard many arguments and seen people trying to rationalize this untenable position. Please, read this article before you get yourself tied up in logical knots.
For some reason, people who clearly see why storing track/track equivalent, or PINs/PIN blocks is prohibited get hung up on the issue of storing security codes/values. No matter how many clarifications and debates on this subject can be cited, someone always tries to push the compliance envelope by word-smithing, analogy, or shear force of will. Every time we have been party to one of these debates (and we’ve seen quite a few), you can see the phases of SAD storage denial: real or feigned ignorance, surprise, rationalization, desperation, escalation, coupled with a range of logical fallacies. Even when the debater realizes they are wrong, some will try bizarre arguments to find cover for their position. We’ve seen people tie themselves in logical knots trying to avoid remediating security code/value storage. To help address this, the PCI SSC recently issued FAQ 1533 which is specifically intended to put an end to these debates by answering why this isn't allowed. Here is a recap of the common questions we've encountered about the storage of SAD and security code/values:
I'm a merchant, merchant service provider, processor, or other non-issuer:
People will try a variety of arguments to escape the rules to rationalize storing security codes/values. The debaters arguing this case are usually guilty of multiple logical fallacies. The situation will not end well if they stay their course. Some examples:
There are only two other complications that you need to be aware of:
The bottom line is that, if you process or transmit card security codes/values it’s in scope and must be treated as sensitive authentication data. You cannot store it after transaction authorization unless you are an issuer and storing it for issuing reasons. Not ever, not encrypted, not hashed, not tokenized, not indexed, not separated from PAN, not with any possibility of correlating or reconnecting the PAN and security code.
Documents from the PCI Council, MasterCard, and Visa clearly indicate that Issuers are required to be PCI DSS compliant (see Learn More below). Yet...
Organizations subject to PCI DSS compliance validation spend significant amounts of time, effort, and money to maintain and validate their...
The adoption of 8-digit BINs in 2022 has already created many transitional challenges for organizations needing access to the full BIN numbers (see...