SAD is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Therefore, the storage of SAD upon completion of the authorization process is prohibited.
It may be acceptable for an entity to store SAD in non- persistent memory for a short time after authorization is complete, if following conditions are met:
• There is a legitimate business need to access SAD in memory after authorization is complete.
• SAD is only ever stored in non-persistent memory (for example, RAM, volatile memory).
• Controls are in place to ensure that memory maintains a non-persistent state.
• SAD is removed as soon as the business purpose is complete. It is not permissible to store SAD in persistent memory.
The authorization process completes when a merchant receives a transaction response (for example, an approval or decline).
Refer to Appendix G for the definition of “authorization.”
If full contents of any track (from the magnetic stripe on the back of a card if present, equivalent data contained on a chip, or elsewhere) is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions.
Full track data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Each track contains a number of data elements, and this requirement specifies only those that may be retained post-authorization.
Data sources to review to ensure that the full contents of any track are not retained upon completion of the authorization process include, but are not limited to:
• Incoming transaction data.
• All logs (for example, transaction, history, debugging, error).
• History files.
• Trace files.
• Database schemas.
• Contents of databases, and on-premise and cloud data stores.
• Any existing memory/crash dump files.
If card verification code data is stolen, malicious individuals can execute fraudulent Internet and mail- order/telephone-order (MO/TO) transactions. Not storing this data reduces the probability of it being compromised.
If card verification codes are stored on paper media prior to completion of authorization, a method of erasing or covering the codes should prevent them from being read after authorization is complete. Example methods of rendering the codes unreadable include removing the code with scissors and applying a suitably opaque and un-removable marker over the code.
Data sources to review to ensure that the card verification code is not retained upon completion of the authorization process include, but are not limited to:
• Incoming transaction data.
• All logs (for example, transaction, history, debugging, error).
• History files.
• Trace files.
• Database schemas.
• Contents of databases, and on-premise and cloud data stores.
• Any existing memory/crash dump files.
PIN and PIN blocks should be known only to the card owner or entity that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based transactions (for example, in-store purchases and ATM withdrawals). Not storing this data reduces the probability of it being compromised.
Data sources to review to ensure that PIN and PIN blocks are not retained upon completion of the authorization process include, but are not limited to:
• Incoming transaction data.
• All logs (for example, transaction, history, debugging, error).
• History files.
• Trace files.
• Database schemas.
• Contents of databases, and on-premise and cloud data stores.
• Any existing memory/crash dump files.
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions.
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.
The authorization process is completed when a merchant receives a transaction response (for example, an approval or decline) .
Refer to Appendix G for the definition of “authorization.”
SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions .
Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.