choose sub requirement:

Requirement 3.1

Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:

  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
  • Specific retention requirements for cardholder data
  • Processes for secure deletion of data when no longer needed
  • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

Testing Procedure

3.1.a
Examine the data retention and disposal policies, procedures and processes to verify they include the following for all cardholder data (CHD) storage:

  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.
  • Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).
  • Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.
  • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

3.1.b
Interview personnel to verify that:

  • All locations of stored cardholder data are included in the data retention and disposal processes.
  • Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.
  • The quarterly automatic or manual process is performed for all locations of cardholder data.

3.1.c
For a sample of system components that store cardholder data:

  • Examine files and system records to verify that the data stored does not exceed the requirements defined in the data retention policy
  • Observe the deletion mechanism to verify data is deleted securely.

Guidance

A formal data retention policy identifies what data needs to be retained, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed.

The only cardholder data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code.

Understanding where cardholder data is located is necessary so it can be properly retained or disposed of when no longer needed. In order to define appropriate retention requirements, an entity first needs to understand their own business needs as well as any legal or regulatory obligations that apply to their industry, and/or that apply to the type of data being retained.

Identifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed.

Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed.

Remember, if you don't need it, don't store it!

Requirement 3.2

Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

  • There is a business justification and
  • The data is stored securely.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

Testing Procedure

3.2.a
For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.

3.2.b
For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.

3.2.c
For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization.

3.2.d
For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.

Guidance

3.2.a
Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.

3.2.b and 3.2.c
Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data.

It should be noted that all PCI DSS requirements apply to issuers, and the only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. A legitimate reason is one that is necessary for the performance of the function being provided for the issuer and not one of convenience. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements.

3.2.d
For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted.

Requirement 3.2.1

Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:

  • The cardholder’s name
  • Primary account number (PAN)
  • Expiration date
  • Service code

To minimize risk, store only these data elements as needed for business.

Testing Procedure

3.2.1
For a sample of system components, examine data sources including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization:

  • Incoming transaction data
  • All logs (for example, transaction, history, debugging, error)
  • History files
  • Trace files
  • Several database schemas
  • Database contents

Guidance

If full track data is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions.

Requirement 3.2.2

Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization.

Testing Procedure

3.2.2
For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization:

  • Incoming transaction data
  • All logs (for example, transaction, history, debugging, error)
  • History files
  • Trace files
  • Several database schemas
  • Database contents

Guidance

The purpose of the card validation code is to protect "card-not-present" transactions—Internet or mail order/telephone order (MO/TO) transactions—where the consumer and the card are not present. If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions.

Requirement 3.2.3

Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.

Testing Procedure

3.2.3
For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization:

  • Incoming transaction data
  • All logs (for example, transaction, history, debugging, error)
  • History files
  • Trace files
  • Several database schemas
  • Database contents

Guidance

These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals).

Requirement 3.3

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.

Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS) receipts.

Testing Procedure

3.3.a
Examine written policies and procedures for masking the display of PANs to verify:

  • A list of roles that need access to displays of full PAN is documented, together with a legitimate business need for each role to have such access.
  • PAN must be masked when displayed such that only personnel with a legitimate business need can see the full PAN.
  • All other roles not specifically authorized to see the full PAN must only see masked PANs.

3.3.b
Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests.

3.3.c
Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see full PAN.

Guidance

3.3
The display of full PAN on items such as computer screens, payment card receipts, faxes, or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that full PAN is only displayed for those with a legitimate business need to see the full PAN minimizes the risk of unauthorized persons gaining access to PAN data.

This requirement relates to protection of PAN displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.4 for protection of PAN when stored in files, databases, etc.

Requirement 3.4

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

  • One-way hashes based on strong cryptography, (hash must be of the entire PAN)
  • Truncation (hashing cannot be used to replace the truncated segment of PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key-management processes and procedures.

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Testing Procedure

3.4.a
Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the following methods:

  • One-way hashes based on strong cryptography,
  • Truncation
  • Index tokens and pads, with the pads being securely stored
  • Strong cryptography, with associated key-management processes and procedures.

3.4.b
Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).

3.4.c
Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable.

3.4.d
Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs.

3.4.e
If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Guidance

3.4
PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected.

One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre-computed hash values.

The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored.

An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key.

The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm) with strong cryptographic keys.

By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.

Requirement 3.4.1

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

Testing Procedure

3.4.1.a
If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).

3.4.1.b
Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

3.4.1.c
Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored.

Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.

Guidance

3.4
The intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable. Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. Many disk-encryption solutions intercept operating system read/write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase upon system startup or at the beginning of a session. Based on these characteristics of disk-level encryption, to be compliant with this requirement, the method cannot:

    1 -  Use the same user account authenticator as the operating system, or

    2 -  Use a decryption key that is associated with or derived from the system’s local user account database or general network login credentials.

Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.

Requirement 3.5

Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:

Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys—such key-encrypting keys must be at least as strong as the data-encrypting key.

Testing Procedure

3.5
Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

  • Access to keys is restricted to the fewest number of custodians necessary.
  • Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
  • Key-encrypting keys are stored separately from data-encrypting keys.
  • Keys are stored securely in the fewest possible locations and forms.

Guidance

3.5
Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. Key-encrypting keys, if used, must be at least as strong as the data-encrypting key in order to ensure proper protection of the key that encrypts the data as well as the data encrypted with that key. The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures.

Requirement 3.5.1

Restrict access to cryptographic keys to the fewest number of custodians necessary.

Testing Procedure

3.5.1
Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.

Guidance

3.5.1
There should be very few who have access to cryptographic keys (reducing the potential for rending cardholder data visible by unauthorized parties), usually only those who have key custodian responsibilities.

Requirement 3.5.2

Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

  • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
  • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
  • As at least two full-length key components or key shares, in accordance with an industry-accepted method

Note: It is not required that public keys be stored in one of these forms.

Testing Procedure

3.5.2.a
Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times.

  • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
  • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
  • As key components or key shares, in accordance with an industry-accepted method

3.5.2.b
Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times.

  • Encrypted with a key-encrypting key
  • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
  • As key components or key shares, in accordance with an industry-accepted method

3.5.2.c
Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

  • Key-encrypting keys are at least as strong as the data-encrypting keys they protect
  • Key-encrypting keys are stored separately from data-encrypting keys.

Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.

Guidance

3.5.2
Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data. It is not intended that the key-encrypting keys be encrypted, however they are to be protected against disclosure and misuse as defined in Requirement 3.5. If key-encrypting keys are used, storing the key-encrypting keys in physically and/or logically separate locations from the data-encrypting keys reduces the risk of unauthorized access to both keys.

Requirement 3.5.3

Store cryptographic keys in the fewest possible locations.

Testing Procedure

3.5.3
Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations.

Guidance

3.5.3
Storing cryptographic keys in the fewest locations helps an organization to keep track and monitor all key locations, and minimizes the potential for keys to be exposed to unauthorized parties.

Requirement 3.6

Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

Testing Procedure

3.6.a
Additional testing procedure for service provider assessments only:
If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.

3.6.b
Examine the key-management procedures and processes for keys used for encryption of cardholder data and perform the following:

Guidance

3.6
The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key-management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 3.6.1 through 3.6.8.

Providing guidance to customers on how to securely transmit, store and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities.

This requirement applies to keys used to encrypt stored cardholder data, and any respective key-encrypting keys.

Note: Testing Procedure 3.6.a is an additional procedure that only applies if the entity being assessed is a service provider.

Requirement 3.6.1

Generation of strong cryptographic keys

Testing Procedure

3.6.1.a
Verify that key-management procedures specify how to generate strong keys.

3.6.1.b
Observe the method for generating keys to verify that strong keys are generated.

Guidance

3.6.1
The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "strong cryptography." Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data.

Requirement 3.6.2

Secure cryptographic key distribution

Testing Procedure

3.6.2.a
Verify that key-management procedures specify how to securely distribute keys.

3.6.2.b
Observe the method for distributing keys to verify that keys are distributed securely.

Guidance

3.6.2
The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in 3.5.1, and are never distributed in the clear.

Requirement 3.6.3

Secure cryptographic key storage

Testing Procedure

3.6.3.a
Verify that key-management procedures specify how to securely store keys.

3.6.3.b
Observe the method for storing keys to verify that keys are stored securely.

Guidance

3.6.3
The encryption solution must store keys securely, for example, by encrypting them with a key-encrypting key. Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of cardholder data.

Requirement 3.6.4

Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

Testing Procedure

3.6.4.a
Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s).

3.6.4.b
Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s).

Guidance

3.6.4
A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted.

Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone’s obtaining the encryption keys, and using them to decrypt data.

Requirement 3.6.5

Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). Archived cryptographic keys should only be used for decryption/verification purposes.

Testing Procedure

3.6.5.a
Verify that key-management procedures specify processes for the following:

  • The retirement or replacement of keys when the integrity of the key has been weakened
  • The replacement of known or suspected compromised keys.
  • Any keys retained after retiring or replacing are not used for encryption operations

3.6.5.b
Interview personnel to verify the following processes are implemented:

  • Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.
  • Keys are replaced if known or suspected to be compromised.
  • Any keys retained after retiring or replacing are not used for encryption operations.

Guidance

3.6.5
Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be revoked and/or destroyed to ensure that the keys can no longer be used. If such keys need to be kept (for example, to support archived, encrypted data) they should be strongly protected.

The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be, or suspected of being, compromised.

Requirement 3.6.6

If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

Testing Procedure

3.6.6.a
Verify that manual clear-text key-management procedures specify processes for the use of the following:

  • Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND
  • Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.

3.6.6.b
Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:

  • Split knowledge, AND
  • Dual control

Guidance

3.6.6
Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. This control is applicable for manual key-management operations, or where key management is not implemented by the encryption product.

Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key).

Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials of another.

Requirement 3.6.7

Prevention of unauthorized substitution of cryptographic keys.

Testing Procedure

3.6.7.a
Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.

3.6.7.b
Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.

Guidance

3.6.7
The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes.

Requirement 3.6.8

Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

Testing Procedure

3.6.8.a
Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

3.6.8.b
Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their key-custodian responsibilities.

Guidance

3.6.8
This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities.

Requirement 3.7

Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

Testing Procedure

3.7
Examine documentation and interview personnel to verify that security policies and operational procedures for protecting stored cardholder data are:

  • Documented,
  • In use, and
  • Known to all affected parties.

Guidance

3.7
Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis.

Goal: Protect stored cardholder data

Requirement 3.0

Install and maintain a firewall configuration to protect cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.