Requirement 3: Protect stored cardholder data

Encryption is a critical component of cardholder data protection. If an intruder circumvents other network 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 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 PAN in unencrypted e-mails.

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 store the card verification code or value or PIN verification value data elements. Note: See "Glossary" for additional information.

All Account information is collected over the phone so we do not deal with the magnetic stripe 

3.2.2 Do not store the card-validation 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 Note: See "Glossary" for additional information.

 

CVV numbers are not asked for during the collection of payment information except when a real time pre authorization is requested by our clients and the authorization company requires the cvv the number.  the only place this is stored is in the recorded audio file.  The recording device is monitoring via trunk side vs station side not enabling the agent to stop the recording durning the collection of the payment information. 

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

PIN numbers are not collected for any reason. 

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

The PAN is encrypted on capture in our CRM application and stored encrypted in the database.  The PAN is only decrypted when batch files are created at night for our clients and their vendors.  Each batch file that does contain the PAN is then PGP encrypted with the appropriate companies public key. The PAN will also be decrypted by the internal IT Department for trouble shooting purposes.

 

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 reason, a company is unable to encrypt cardholder data, refer to Appendix B: "Compensating Controls for Encryption of Stored Data."

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.

Disk encryption is not used to encrypt data.

 

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 changing of keys

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.