- 3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
- 3.2 Do not store sensitive authentication data subsequent to authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
- 3.2.1 Do not store the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder.s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER sto
- 3.2.2 Do not store the card-validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions Note: See Glossary for additional information.
- 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
- 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Note: This requirement does not apply to employees and other parties with a specific need to see the full PAN; nor does the requirement supersede stricter requirements in place for displays of cardholder data (for example, for point of sale [POS] receipts).
- 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches: * Strong one-way hash functions (hashed indexes) * Truncation * Index tokens and pads (pads must be securely stored) * Strong cryptography with associated key management processes and procedures The MINIMUM account information that must be rendered unreadable is the PAN. If for some
- 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
- 3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse:
- 3.5.1 Restrict access to keys to the fewest number of custodians necessary
- 3.5.2 Store keys securely in the fewest possible locations and forms
- 3.6 Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following:
- 3.6.1 Generation of strong keys
- 3.6.2 Secure key distribution
- 3.6.3 Secure key storage
- 3.6.4 Periodic key changes * As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically * At least annually
- 3.6.5 Destruction of old keys.
- 3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key
- 3.6.7 Prevention of unauthorized substitution of keys
- 3.6.8 Replacement of known or suspected compromised keys
- 3.6.9 Revocation of old or invalid keys
- 3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities