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

• Legal, regulatory, and business requirements for data retention including
• Specific requirements for retention of cardholder data for (for example, cardholder data needs to be held for X period for Y business reasons)
• Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.
• Coverage for all storage of cardholder data
• A quarterly process for identifying and securely deleting stored card holder data that exceeds defined retention requirements

3.1b Interview personnel to identify that

• All location of stored cardholder data are included in the data retention and disposal process
• 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.1c 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
• Observer the deletion mechanism to verify data is deleted securely

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:

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.

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

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

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.

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, AV2 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

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

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

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 should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN

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

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

4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

• Only trusted keys and certificates are accepted.

• The protocol in use only supports secure versions or configurations.

• The encryption strength is appropriate for the encryption methodology in use

Examples of open, public networks include but are not limited to:

• The Internet

• Wireless technologies, including 802.11 and Bluetooth

• Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)

• General Packet Radio Service (GPRS).

• Satellite communications

4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

• Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.

• Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.

4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies

4.2.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies

4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

4.3 Examine documentation interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

• Documented,

• In use, and

• Known to all affected parties

6.5.4 Insecure communications

6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access

7.1 Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows:

• Defining access needs and privilege assignments for each role

• Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities

• Assignment of access based on individual personnel’s job classification and function

• Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved

7.1.3 Assign access based on individual personnel’s job classification and function

7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function

7.2 Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

This access control system must include the following

7.2.1 Coverage of all system components

7.2.2 Assignment of privileges to individuals based on job classification and function

7.2.3 Default “deny-all” setting

7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows

7.2.1 Confirm that access control systems are in place on all system components.

7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function

7.2.3 Confirm that the access control systems have a default “deny-all” setting.

8.1.3 Immediately revoke access for any terminated users

8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists—for both local and remote access—to verify that their IDs have been deactivated or removed from the access lists

8.1.3.b Verify all physical authentication methods—such as, smart cards, tokens, etc.—have been returned or deactivated

8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

• All user access to, user queries of, and user actions on databases are through programmatic methods.

• Only database administrators have the ability to directly access or query databases

• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes)

8.7.a Review database and application configuration settings and verify that all users are authenticated prior to access

8.7.b Examine database and application configuration settings to verify that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures)

8.7.c Examine database access control settings and database application configuration settings to verify that user direct access to or queries of databases are restricted to database administrators.

8.7.d Examine database access control settings, database application configuration settings, and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes)

10.1 Implement audit trails to link all access to system components to each individual user.

10.1 Verify, through observation and interviewing the system administrator, that:

• Audit trails are enabled and active for system components

• Access to system components is linked to individual users

10.2 Implement automated audit trails for all system components to reconstruct the following events

10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following

10.2.1 All individual user accesses to cardholder data

10.2.1 Verify all individual access to cardholder data is logged.

10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification

10.3.2 Type of event

10.3.3 Date and time

10.3.4 Success or failure indication

10.3.5 Origination of event

10.3.6 Identity or name of affected data, system component, or resource

10.3 Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:

10.3.1 Verify user identification is included in log entries

10.3.2  Verify type of event is included in log entries

10.3.3 Verify date and time stamp is included in log entries

10.3.4 Verify success or failure indication is included in log entries

10.3.5 Verify origination of event is included in log entries

10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries

10.6.1 Review the following at least daily

10.6.1 Review the following at least daily:

• All security events

• Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

• Logs of all critical system components

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)

10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:

• All security events

• Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD Logs of all critical system components

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)

10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily:

• All security events

• Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

• Logs of all critical system components

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)

10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties

10.8 Examine documentation interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are:

• Documented,

• In use, and

• Known to all affected parties

12.5.5 Monitor and control all access to data

12.5.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.

12.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

12.6.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.