3.3: 1. SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.
  • If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not stored after authorization.
  • If SAD is received, examine the documented procedures and observe the secure data deletion processes to verify the data is rendered unrecoverable upon completion of the authorization process.

Description

Purpose

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.

Good Practice

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.

Definitions

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.”

3.3: 1.1. The full contents of any track are not stored upon completion of the authorization process.
  • Examine data sources to verify that the full contents of any track are not stored upon completion of the authorization process.

Description

Purpose

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.

Definitions

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.

Examples

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.

3.3: 1.2. The card verification code is not stored upon completion of the authorization process.
  • Examine data sources, to verify that the card verification code is not stored upon completion of the authorization process.

Description

Purpose

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.

Examples

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.

3.3: 1.3. The personal identification number (PIN) and the PIN block are not stored upon completion of the authorization process.
  • Examine data sources, to verify that PINs and PIN blocks are not stored upon completion of the authorization process.

Description

Purpose

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.

Examples

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.

3.3: 2. SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
  • Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

Description

Purpose

SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions.

Good Practice

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.

Definitions

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.”

3.3: 3. Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: (a) Limited to that which is needed for a legitimate issuing business need and is secured, (b) Encrypted using strong cryptography. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
  • and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.
  • Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine data stores and system configurations to verify that the sensitive authentication data is stored securely.

Description

Purpose

SAD can be used by malicious individuals to increase the probability of successfully generating counterfeit payment cards and creating fraudulent transactions .

Good Practice

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.