Formal, documented testing and approval procedures for network connections.

Formal documented testing and approval procedures for changes to firewall and router configurations.

Example documentation supporting a network connection was tested and approved.

Example documentation supporting a recent firewall or router change was tested and approved. .

Formal Cardholder Data Environment Network Diagram including date the diagram was finalized/updated.

Formal review or signoff of the CDE Network Diagram, including name of approving reviewer and date.

Formal Data Flow Diagram for the Cardholder Data Environment including the date the diagram was finalized.

Formal review or signoff of the Data Flow Diagram, including name of the approving reviewer and date.

Formal, documented firewall and router configuration standards.

Screenshots of firewall configurations showing that firewalls are configured in a manner consistent with the Firewall and Router configuration standards.

Screenshots of the firewall ruleset showing that traffic is restricted in a manner consistent with the Network Diagram and Data Flow Diagram.

Formal job description including roles and responsibilities for the Network Administrator or similar position.

(Alternative) Skills matrix for the personnel responsible for managing the CDE network.

Documented firewall and router configuration standards showing that roles and responsibilities for firewall/router management are identified.

Firewall and router configuration standards which document a list of approved Services, Protocols, and Ports authorized for use within the Cardholder Data Environment including approval and justification for each item listed.

Firewall and router configuration standard which documents a list of any insecure Services, Protocols, and Ports used within the Cardholder Data Environment and controls/security features implemented to mitigate these weaknesses.

If Insecure Services, Protocols, or Ports must be used, screenshots showing that documented security features/compensating controls have been implemented for each insecure Service, Protocol, and Port.

Documented Firewall and Router \configuration standards, specifying the frequency of rule review (PCI requirement is 6 months)

Documented Firewall and Router rule set review from the last 6 months.

Firewall and Router configuration standards which document the required inbound and outbound traffic which must be allowed into the Cardholder Data Environment.

Screenshots of Firewall and Router rule set showing traffic that is explicitly allowed for both inbound and outbound connections.

Screenshots showing the presence of deny any any rule as the final rule within Firewall or Router rule sets.

(Alternate) If Firewall or Router brands do not display this, documentation from the Firewall/Router vendor documenting that this is implicit.

Screenshots or exports of the router configuration files.

Screenshots showing who can access router configuration files.

Screenshots showing that active/running router configurations match configuration standards for routers.

Screenshots from the firewalls and routers installed between wireless networks and Cardholder Data Environment.

Configuration files from these firewalls and routers to verify that traffic has been restricted.

Network Diagram

Firewall and Router configuration showing how public access is restricted.

Screenshot showing that direct public access to the Cardholder Data Environment is limited to authorized publicly accessible services, protocols, and ports.

Network diagram showing that a DMZ has been implemented.

Firewall and Router configurations showing how the DMZ has been established and that it only allows approved Services, Functions, Ports, and Protocols through.

Firewall and Router configurations showing that inbound Internet traffic is restricted to appropriate, authorized IP Addresses within the DMZ.

Screenshots showing that anti-spoofing methods have been implemented, such as blocking traffic coming into the DMZ which have an IP Address that matches the IP Address of devices within the Cardholder Data Environment.

Screenshots from firewall and router rulesets showing that outbound traffic must be explicitly allowed.

Screenshots from an example inbound connection showing that connection attempts not part of an established connection will be dropped (usually accomplished through the use of Stateful Packet filtering).

Internal firewall and router configurations showing that the internal network zone is separate from the DMZ and untrusted networks.

Network diagram.

Screenshots of firewall and router configurations showing that private IP information will not be disclosed. Commonly accomplished through the implementation of:

Screenshots of firewall and router configurations showing that private IP information will not be disclosed. Commonly accomplished through the implementation of:

If any private IP’s are disclosed, documented authorizations showing who is authorized to receive this information.

Policies or standard configurations showing that personal firewalls are required on laptops or any other portable devices which connect to the internal CDE.

Configuration standards for personal firewalls.

Screenshots showing personal firewalls are configured according to the standard.

Screenshots showing personal firewalls installed/active on laptops or other portable devices.

Screenshots showing that personal firewalls cannot be disabled and that settings cannot be changed by non-administrative personnel.

Documented firewall security policies and procedures.

Any policy or procedures documenting a requirement stating that ALL vendor supplied default account information must be changed.

Screenshots showing that vendor default accounts have been removed, had their default configurations changed, or are disabled.

Any policy or procedures documenting a requirement stating that ALL vendor supplied default account information must be changed.

Screenshots showing that vendor default accounts have been removed, had their default configurations changed, or are disabled.

Any policy or procedures documenting a requirement that all default encryption keys must be changed when deploying wireless infrastructure or when someone with knowledge of the encryption keys leave the company.

Screenshots showing that vendor supplied encryption keys for wireless networks have been replaced.

Any policy or procedures documenting a requirement that All vendor supplied default SNMP community strings must be changed.

Screenshots showing that vendor supplied SNMP community strings for wireless networks have been replaced.

Any policy or procedures documenting a requirement that All vendor supplied default account information must be changed.

Screenshots showing that vendor supplied passwords/passphrases for wireless access points have been replaced.

Wireless device (routers, wireless access points, etc.) hardening procedures.

Screenshots showing that firmware on wireless networking devices has been updated.

Any policy or procedures documenting a requirement that All vendor supplied default account information must be changed.

Screenshots showing that vendor defaults have been changed on wireless networking devices if not covered by controls DCF-231 through DCF-234.

System hardening procedures.

System hardening procedures which cover the following attributes:

Screenshots of system configurations for system components in the CDE, showing that each component only serves one primary function (For example, web servers, database servers, and DNS should be implemented on separate servers.).

Screenshots of virtual server system configurations for virtual technologies in the CDE, showing that each component only serves one primary function (For example, web servers, database servers, and DNS should be implemented on separate servers.)

Screenshots showing the enabled services being run system components in the CDE..

If any insecure services are being run such as Telnet, FTP, etc on system components in the CDE. documented justification for these services being enabled.

If any insecure services are being run such as Telnet, FTP, etc. screenshots or documentation showing how these services are secured.

Documentation not required. QSAs will only interview personnel for this requirement.

Documented Server configuration standards showing that security parameter settings are contained within the standard.

Screenshots showing that security parameters have been configured as noted within the configuration standard for system components within the CDE

Screenshots showing unnecessary services and functions (for example, scripts, drivers, features, subsystems, file systems, etc.) are removed from system components in the CDE.

Configuration documentation from system components in the CDE showing that enabled functionality is documented including rationale for why the services are enabled.

Screenshots showing which services and functions are running on system components from the CDE.

Screenshots showing encryption settings for non-console administrative login to system components from the CDE.

Screenshots showing the login process for non-console administrative access for system components in the CDE.

Screenshots from system components in the CDE, showing that insecure remote login commands (such as Telnet) are prevented from connecting to the CDE.

Vendor management policy.

Operational procedures such as vendor system hardening procedures for system components in the CDE. .

Screenshots of system configurations showing that the hosted entity’s application processes are run using the unique ID of that entity.

Screenshots of system configurations showing that user IDs for the hosted entity’s application processes are not privileged users.

Screenshots of system configurations showing that read, write and execute permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

Screenshots of system configuration settings showing that the entity’s users do not have write access to shared system binaries.

Screenshots of system configuration settings showing that viewing of log entries is restricted to the owning entity.

Screenshots of the system configuration settings showing restrictions are in place for the use of:

Screenshots showing that:

Documented policies and procedures which cover forensic evidence collection and preservation as well as investigation of incidents.

Policies and procedures for data disposal of CHD.

For system components that store cardholder data, screenshots of files and system records to verify that the data stored does not exceed the requirements defined in the data-retention policy.

Documented procedures which define a requirement to evaluate adherence to data retention guidelines on at least a quarterly basis.

Screenshots showing that the oldest cardholder data stored within the CDE falls within the defined data retention guidelines.

For issuers and/or companies that support issuing services and store sensitive authentication data, policies describing the documented business justification for the storage of sensitive authentication data.

For issuers and/or companies that support issuing services and store sensitive authentication data, screenshots of data stores and system configurations showing that the sensitive authentication data is secured.

For entities which are not issuers or or don’t support issuing services, documented policies and procedures describing how sensitive authentication data is deleted securely after the authorization process.

Screenshots from in-scope systems showing how this process is configured and that it is carried out as specified in the documented procedures.

Screenshots from example CDE system components showing 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 in any of the following:

Screenshots from example system components of data sources, including but not limited to the following, showing that they do not store 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) after authorization:

For example system components, screenshots from data sources, including but not limited to the following, showing that PINs and encrypted PIN blocks are not stored after authorization:

Documented policies and procedures which document requirements for masking Primary Account Numbers (PANs) including the following:

Screenshots of system configurations showing that the full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests.

Screenshots showing how PANs are displayed (on-screen, receipts, etc.) to verify that full PANs are masked when displayed.

Evidence about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) showing that the PAN is rendered unreadable using any of the following methods:

If PANs are stored in files or database tables, screenshots showing this encrypted data.

If PANs are stored on removable media such as mass storage devices like USBs or backup tapes, screenshots showing the encrypted data on these devices.

If PANs are stored in audit logs, screenshots showing the encrypted data in these logs.

If both a hashed version of a PAN and a truncated version of a PAN exist within the CDE, documentation to show that the full PAN cannot be reconstructed.

If disk encryption is used, screenshots of the configurations showing 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).

Screenshots showing how cryptographic keys are stored securely.

Screenshots of the configuration to encrypt cardholder data stored on removable media.

Screenshots of encrypted cardholder data on removable media.

Architecture diagram or description showing the cryptographic algorithms, protocols, and keys used within the environment including key strength and expiration, description of key usage for each key, and an inventory of HSMs or other SCDs used for key management.

Screenshots of user access lists for the location of where keys are stored for keys used within the environment to verify that key access is restricted to the smallest number of custodians possible.

Documented policies and procedures which list a requirement to store secret/private key used for cardholder data encryption using one of the following methods:

Screenshots of system configurations and storage locations which show that keys are stored in accordance with the cryptographic key management policies and procedures.

If key-encrypting keys are used, screenshots of system configurations showing that key-encrypting keys are at least as strong as the data-encrypting keys and that key-encrypting keys are stored separately from data-encrypting keys.

List of all locations where keys are stored.

If you are a service provider and shares keys with your customers for transmission or storage of cardholder data, documentation you provide to your customers evidencing 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.

Documented key management procedures which specify how to generate strong cryptographic keys.

Screenshots showing the strong cryptographic key generation process.

Documented procedures for distributing cryptographic keys securely.

Documented procedures for how cryptographic keys are securely stored.

Screenshots showing how cryptographic keys are securely stored.

Documented procedures which cover the key management lifecycle including the lifespan of cryptographic keys and the process for changing keys after the lifespan ends.

Key-management procedures specifying processes for the following:

Documented key management procedures which include guidance for:

Documented key management procedures which include guidance for:

If manual, clear-text management of cryptographic key management operations are used, documented procedures for these operations which include:

Documented cryptographic key management procedures which include the specific controls implemented to prevent unauthorized key substitution.

Documented cryptographic key management procedures which require key custodians to formally acknowledge their responsibilities as key custodians.

Example acknowledgement forms or screenshots showing that key custodians have formally acknowledged their responsibilities for managing encryption keys.

List of all locations where cardholder data is transmitted or received over open, public networks.

Documented standards which detail the level of security protocols and cryptographic algorithms used to protect this cardholder data.

Screenshots from the system configurations of the systems receiving this cardholder data showing the implementation of these security protocols and encryption algorithms.

Documented policies and procedures which specify processes for accepting only trusted keys and certificates.

Screenshots showing that keys and certificates used in the environment are trusted.

Documented policies and procedures which specify processes for only using secure versions and configurations and that insecure versions or configurations will not be supported.

Screenshots of system configurations showing that only secure versions and configurations are in use.

Documented policies and procedures which document implementing the proper encryption strength, per encryption methodology in use.

Screenshots showing that encryption methods listed in documented policies and procedures are implemented and other methodologies are not supported.

If TLS has been implemented for encrypting cardholder data during transmission, screenshots showing that TLS has been implemented.

List of all wireless networks transmitting cardholder data or connected to the CDE.

Documented standards for these wireless networks.

Screenshots from the configurations of these networks showing that:

If an end-user messaging platform such as email is used to send PANs, screenshots of configurations showing how these are secured.

Screenshots from an example communication of PANs sent over end-user messaging platforms showing that they are secured.

Written policies and procedures which prohibit the sending of unprotected PANs over end-user messaging platforms.

Vendor documentation for all anti-virus software used within the CDE.

Screenshots from the anti-virus tools in use to verify that the solutions:

For systems not commonly affected by malicious software, job description of the individuals responsible for evaluating new/emerging malware threats.

Screenshots of any tools, group memberships, or mailing lists used to assist in this monitoring.

Screenshots from the anti-virus configurations. including the master installation, showing how the anti-virus and virus definitions are kept current and updated.

Screenshots from the anti-virus configurations. including the master installation, showing that periodic scans are performed.

Screenshots of the anti-virus configurations, including the master installation, showing that anti-virus logs are enabled and retained in accordance with log retention requirements (PCI requires at minimum 1 year of log retention with 3 months of immediate availability).

Screenshots from the anti-virus configurations, including the master installation, showing that anti-virus software is actively running.

Screenshots from the anti-virus configurations, including the master installation, showing that anti-virus software cannot be disabled or altered by users.

Lists of patches provided by the vendor for systems within the CDE.

Screenshots from systems within the CDE showing that critical security patches have been installed.

Documented SDLC policy or procedures which include a requirement for information security throughout the lifecycle of systems.

Documented SDLC policy or procedures which document a requirement to develop and deploy systems in accordance with PCI DSS requirements (such as log generation and retention, etc.)

Documented SDLC policy or procedures which list a requirement to ensure that pre-production (development, test, staging, QA) accounts, user IDs, and/or passwords are removed from the system before being deployed to production.

Documented SDLC policy or procedures which document the following requirements:

Documentation for an example code change to show that the documented review procedures were followed and that code review results are reviewed and approved by management prior to release.

Documented policies and procedures which state that test and production environments must be separated and have access control implemented to enforce this restriction.

Screenshots from the network device configurations which enforce this separation.

Documented policies and procedures which require a separation of duties between personnel assigned to test regions and prod regions.

Screenshots from the access control configurations/lists showing that separate personnel are assigned roles in test and production regions.

Screenshots from non-production regions showing that live PAN data is not used within non-production regions.

Screenshots from non-production systems showing that test accounts are removed.

Documented Change Control procedures which list a requirement to document the impact of proposed changes.

Screenshots or change documentation showing that the impact of the change was documented for a recent change,

Documented Change Control procedures which list a requirement that changes are approved by an authorized party.

Screenshots or change documentation showing that a proposed change was approved prior to implementation for a recent change.

Documented Change Control procedures which list a requirement for functionality testing to verify that a proposed change does not adversely impact the security of the system.

Screenshots or change documentation showing that a proposed change underwent functionality testing for a recent change.

Screenshots or change documentation showing that code changes are tested for compliance with PCI DSS requirements before being deployed.

Documented Change Control procedures which list a requirement for back-out procedures as part of proposed changes.

Screenshots or change documentation showing that back-out procedures were documented for a recent change.

For an example significant change within the CDE, documentation demonstrating that the affected systems were tested for PCI DSS requirements after the change was made.

For an example significant change within the CDE, screenshots or document history showing that system documentation was updated after the change was made.

Documented software development policies and procedures which document a requirement for developers to receive secure coding training at least annually based on industry best practices and guidance.

Screenshots or exported training records showing that developers have received secure coding training, including how to avoid common software vulnerabilities, within the last 12 months.

Documented software development policies and procedures which include processes to protect custom developed code from the vulnerabilities listed in DCF-314 through DCF-323 (PCI Requirements 6.5.1-6.5.10).

Documented software development policies and procedures which include processes to protect custom code from Injection Flaws which include:

Documented software development policies and procedures which include processes to protect custom code from Buffer Overflows which include:

Documented software development policies and procedures which include processes to protect custom code from Insecure Cryptographic Storage which includes:

Documented software development policies and procedures which include processes to protect custom code from Insecure Communications which includes:

Documented software development policies and procedures which include processes to protect custom code from Improper Error Handling which include:

Documented software development policies and procedures which include processes to protect custom code from all High Risk Vulnerabilities identified during the vulnerability management process.

For web applications or internal/external application interfaces, documented software development policies and procedures to protect custom code from Cross-Site Scripting (XSS) which include:

For web applications or internal/external application interfaces, documented software development policies and procedures to protect custom code from Improper Access Control (insecure direct object references, failure to restrict URL access, and directory traversal) which includes:

For web applications or internal/external application interfaces, documented software development policies and procedures to protect custom code from Cross-Site Request Forgery (CSRF) which includes:

For web applications or internal/external application interfaces, documented software development policies and procedures to protect custom code from Broken Authentication and Session Management which includes:

If public-facing web applications exist within the CDE, documented policies and procedures which document a requirement for web application security scans (vulnerability scans), and screenshots showing records of these assessments. Documented processes must include guidance for performing assessments:

OR, screenshots from an automated solution which detects and prevents web-based attacks (web application firewall) is in place/ Screenshots must show that:

Documented policies and procedures for developing and maintaining secure systems and applications.

Documented System Access Control which documents the following:

Documented access needs for each role within the CDE which includes:

Screenshots of the privileges assigned to an example user ID.

A documented example of an approval for the example user ID provided by an authorized party for access which includes the following:

Screenshots from the access control system for all system components.

Screenshots showing how the access control system(s) are configured to enforce privilege assignments to individuals based on job classification and function.

Screenshots of access control system configurations showing that the default configuration is to deny all access.

Screenshots showing where employees can access the System Access Control Policy.

Documented policies and procedures for Identity Management which include a requirement to assign a unique user ID before allowing access to system components or cardholder data.

System user access listings showing that all users have a unique user ID.

Documented policies and procedures for Identity Management which include processes for controlling the addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Documented access authorization for an example administrative/privileged user.

Screenshots from the example administrative/privileged user showing that the account has only been assigned the approved permissions.

Documented access authorization for an example general/non-privileged user.

Screenshots from the example general/non-privileged user showing that the account has only been assigned the approved privileges.

Documented policies and procedures for Identity Management which include a requirement to remove or disable user accounts over 90 days old.

System user access lists showing that no account inactive for 90 days or more is still active and/or present on the system.

Documented policies and procedures for Identity Management which have a requirement to disable accounts of third parties (vendors) when not in use and enable these accounts on when needed.

Screenshots or system user access lists showing that third party user accounts (vendor accounts) are enabled only when needed and disabled after use.

Documented policies and procedures for Identity Management which state a requirement to monitor access by third party users (vendors) when they are active within the system.

Screenshots showing how these accounts and their associated activities are monitored.

Documented policies and procedures for Identity Management which document a requirement to lock users out of accounts after no more than six unsuccessful attempts.

Screenshots of system configurations which implement the documented account lockout requirements.

For service providers, documented internal processes and customer documentation which state that accounts will be locked out after six unsuccessful authentication attempts.

Screenshots of system configurations showing how the account lockout requirement is enforced.

Documented policies and procedures related to Identity Management which state a requirement that locked out accounts will remain locked out for no less than 30 minutes or until unlocked by an administrator.

Screenshots of system configurations showing how this account lockout duration is enforced.

Documented policies and procedures related to Identity Management which include a requirement to re-authenticate terminals or sessions after 15 minutes of inactivity.

Screenshots from system configurations showing how this session inactivity timeout is enforced.

Documented policies and procedures which contain guidance on the authentication methods for non-consumer (employee, third party, contractor, but not customer) and administrator accounts.

Screenshots showing the authentication methods used for logging into CDE components.

Vendor documentation showing how authentication credentials (passwords) are stored during transmission and storage.

Screenshots of system configurations showing that passwords are protected with strong cryptography during transmission and storage.

For service providers, screenshots of system configurations showing that password files for non-consumer customer passwords are unreadable during transmission and storage.

Documented policies and procedures which state a requirement to verify a user’s identity prior to modifying authentication information (password resets, generating new keys, etc.).

Screenshots from system components showing that the following password requirements have been implemented and will be enforced:

For service providers, internal process documentation and customer documentation that states a requirement that non-consumer customer passwords must:

Screenshots of system configurations showing that password changes are required every 90 days.

Documented internal processes and customer documentation which document the following requirements:

Screenshots of system configurations showing that passwords must be different from the previous 4 passwords.

Documented internal processes and customer documentation which state a requirement that new non-consumer customer passwords must be different from the previous 4 passwords.

Documented password procedures which define the following requirements:

Screenshots documenting this process of setting first time and reset passwords.

Screenshots of system and/or network configurations which enforce multi-factor authentication for all non-administrative remote access into the CDE.

Screenshots of the authentication process for non-administrative remote access to confirm that multi-factor authentication was enforced.

Screenshots of system and/or network configurations which enforce multi-factor authentication for all non-console administrative access into the CDE.

Screenshots of the authentication process for non-console administrative access to confirm that multi-factor authentication was enforced.

Screenshots of the system configurations which enforce multi-factor authentication for all remote access into the CDE network.

Screenshots of the authentication process showing that MFA is required for remote network access for both a non-administrative and administrative user.

Screenshots showing where employees can find policies and procedures related to Authentication.

Documented policies and procedures related to Authentication which include the following:

System user access lists which show that:

Documented policies and procedures related to Authentication which state that shared or group IDs/passwords or other authentication mechanisms are strictly prohibited.

For service providers, if you have remote access to customer systems, documented policies and procedures which state a requirement that each customer environment requires a unique authentication credential (such as a password).

If other authentication mechanisms besides passwords (such as smart cards, physical or digital tokens, etc.) are used, documented policies and procedures related to Authentication which state a requirement:

Screenshots of system configuration settings and/or physical controls as applicable showing that only the intended account can use the authentication mechanism to gain access.

Screenshots of database and application configuration settings showing that all user access to, user queries of, and user actions on (such as move, copy, or delete) the database are through programmatic methods only such as stored procedures.

Screenshots of database access control settings and database application configuration settings showing that user direct access to or queries of databases are restricted to database administrators.

Screenshots from database access control settings, database application configuration settings, and the related application IDs showing that application IDs can only be used by applications and not individual users or other processes.

For each computer room, data center, and other physical area which contains systems in the CDE:

Pictures showing that video camera or access control mechanisms (or both) are used to monitor the entry/exit points to sensitive areas.

Pictures showing how video cameras or access control mechanisms (or both) are protected from tampering and disabling.

Documented procedures around reviewing data from video cameras and/or access control mechanisms.

Screenshots showing that video camera and/or access control mechanism data is stored for at least three months, unless otherwise restricted by law.

Documented procedures which detail how publicly accessible network jacks are restricted (such as disabling access to publicly accessible network jacks unless explicitly authorized).

Pictures or videos showing how these procedures have been implemented.

Pictures or video showing how physical access to the following devices is restricted:

Documented policies and procedures related to Physical Access which include the following elements for identifying and distinguishing between onsite personnel and visitors:

Pictures showing that visitors are clearly identified (such as a picture of a visitor badge).

Pictures showing the difference between identification for onsite personnel and visitors showing that they can be easily distinguished.

User access lists for the identification system showing that access is limited to authorized personnel (such as user access lists for the systems which provision ID badge access).

User access control lists from the physical access control system showing that access is role-based.

Termination/offboarding checklist showing that physical access was revoked.

Documented procedures for authorizing visitor access which require visitors to be authorized prior to being granted physical access and that visitors are escorted at all times.

Pictures showing the visitor badges given to authorized visitors.

Pictures showing that visitor badges have a set expiration.

Pictures showing how visitors are required to surrender their visitor badges upon leaving the facility.

Pictures showing that visitor log is in place and used for access to the facility as well as any computer, server, datacenter, or data storage rooms.

Pictures from the visitor log showing that the following information is captured:

Pictures showing that the visitor’s log is retained for at least 3 months.

Documented policies and procedures related to physically securing all media (including computers, removable media, paper receipts, paper records, and faxes).

Documented review of the security of the backup media storage location from the last 12 months.

Documented policies and procedures related to the distribution of media and covers distribution of all types of media distributed to individuals.

Screenshots and/or pictures showing how media is classified including labels showing data sensitivity.

Documented procedures related to media transfer which include acceptable methods of information transfer including authorized couriers and the ability to track media transfers.

Screenshots or documentation showing how media transfers are logged.

Documentation for a recent media transfer showing that tracking information was logged.

Documentation from a recent media transfer (including media distribution to individuals) showing that the transfer was approved by an authorized member of management.

Documented policy and procedures related to Media Storage and Accessibility which includes a requirement for periodic inventory of media.

Documented media inventory logs.

Documented inventory of media from the past 12 months.

Documented policies and procedures related to Media Destruction.

Documented policies and procedures related to Media Destruction which includes:

Documented procedures for the destruction of hard-copy materials which contain the acceptable methods of material destruction including crosscut shredding, incineration, or pulping.

Pictures showing that storage containers for hard-copy materials awaiting destruction are secured.

Documented procedures related to rendering cardholder data on electronic media unrecoverable when it is no longer required.

If data is rendered unrecoverable through secure deletion or wiping, documentation showing which industry standard for data deletion is being followed.

If card reading devices are used for card-present transactions, documented policies and procedures related to managing these devices which include:

Documented inventory of card reading devices which documents:

Documented procedures for managing card reading devices which include processes for:

Training materials presented to individuals who manage payment card reading devices which includes:

Training records showing that this training material was given to personnel.

Documented inventory of card reading devices which documents:

Picture of a card reading device including the unique serial number to show that the inventory is accurate.

Documented policies or procedures related to Asset Management or Card Reading Device Management which details when and how the inventory of devices will be updated.

Documented procedures for managing card reading devices which include processes for:

Documented procedures for managing card reading devices which include processes for:

Training materials presented to individuals who manage payment card reading devices which includes:

Training records showing that this training material was given to personnel.

Screenshots showing that audit trails are enabled and active for systems within the CDE.

System user access lists from systems in the CDE showing that access is linked to individual users.

Screenshots of audit log settings showing that individual user access to cardholder data is logged.

Screenshots of an example log showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that all actions taken by root/admin users will be logged.

Screenshots of an example log showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that all access to audit trails/logs is logged.

Screenshots of an example log showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that invalid/failed login attempts are logged.

Screenshots of an example log showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that the use of identification and authentication mechanisms are logged, elevation of privileges are logged, and that changes (addition, modification, or deletion) to accounts with administrator or root privileges are logged.

Screenshots of example logs showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that the initialization of logging and stopping or pausing of logging are logged.

Screenshots showing that these log settings are functioning correctly.

Screenshots of audit log settings showing that the creation or deletion of system-level objects are logged.

Screenshots of an example log showing that these log settings are functioning correctly.

Screenshots of an example log showing that user IDs are captured within log entries.

Screenshots of an example log showing that the type of event which occurred is captured within log entries.

Screenshots of an example log showing that a date and time are associated with log entries.

Screenshots of an example log showing that event success and failures are captured within log entries.

Screenshots of an example log showing that the source of the event (IP address or similar source) are captured within log entries.

Screenshots of an example log showing that affected item/resource ID or name is captured within log entries.

Documented procedures for synchronizing time across system components within the CDE which includes the following elements:

Screenshots showing that the documented process has been implemented (for example, that NTP has been configured and is being used by system components to synchronize time). Screenshots should show that:

Screenshots showing that the documented process has been implemented (for example, that NTP has been configured and is being used by system components to synchronize time). Screenshots should show that:

Screenshots showing that the documented process has been implemented (for example, that NTP has been configured and is being used by system components to synchronize time). Screenshots should show that:

System user access lists and time settings showing that time data is restricted to only those users with a business need for access.

Screenshots from time synchronization settings showing that changes to critical settings will be logged.

Screenshots from an example log showing that changes to critical settings related to time synchronization are logged.

Documented processes for monitoring and reviewing these logs.

Screenshots from the central time server or servers showing that they only receive time data from trusted, industry accepted sources.

OR Screenshots showing that time data is encrypted with a symmetric key and access control lists are configured to only provide time data only to client machines with an IP address on this list.

Screenshots from the logging system showing that audit trails are secured so that they cannot be altered.

Screenshots from the logging system or system user access lists showing that audit trails can only be accessed by individuals with a business need to access them.

Screenshots or pictures showing that audit trails are protected from unauthorized access/modification/deletion through access control mechanisms, physical segregation, and/or logical network segregation.

Documented procedures related to backing up logs which contain the following elements:

Screenshots showing that logs for externally facing technologies (such as DNS, Firewalls, mail servers, etc.) are sent to a centralized logging server or media.

Screenshots showing that File Integrity Monitoring Software or other change detection software is configured to generate alerts if logs are altered. Screenshots should show:

Documented policy related to Log Review which states that the following items will be reviewed at least daily:

Screenshots showing the process for reviewing the following logs at least daily:

Documented policies and procedures related to Log Review stating a requirement to review the logs of all other system components not covered in DCF-434 on a periodic basis according to your documented risk assessment/management procedures.

Documented risk assessment which details risks present for non-critical systems.

Documented policies and procedures related to Log Review detailing how to follow up on identified anomalies and exceptions found in logs.

Documentation showing that the process to follow up on anomalies and exceptions identified through log review have been implemented (such as JIRA tickets showing that an anomaly was investigated, etc.)

Documented policy related to Audit Log Retention.

Documented policy related to Audit Log Retention which states a requirement that logs will be retained for at least 1 year.

Screenshot showing that logs, archives or logs, or compressed log files are stored for at least one year.

Documented policy related to Audit Log Retention which states a requirement that at least 3 months of logs must be available at all times for immediate analysis.

Screenshots showing that 3 months of logs are immediately available for analysis.

Documented policies and procedures related to detecting and reporting failures in security controls which cover:

Screenshots showing how alerts are configured for the following systems:

Documented policies and procedures for responding to the failure of security controls which cover the following items:

Documented records showing that security control failures were documented and that they include the following elements:

Documented policies and procedures related to monitoring all access to network resources and cardholder data.

Screenshots showing where these policies and procedures are stored and available to employees/contractors.

Documented policies and procedures related to detecting and identifying authorized and unauthorized wireless access points on at least a quarterly basis.

Documented policies and procedures related to detecting and identifying any unauthorized wireless access points on at least a quarterly basis which includes at least the following devices will be detected:

If wireless scanning is used to identify unauthorized wireless access points, the results from the most recent scan showing that:

If automated monitoring is utilized to detect unauthorized wireless access points (for example, Wireless IDS/IPS, NAC, etc.) screenshots of the alerting configuration showing that alerts will be generated and sent to personnel.

Documented inventory of authorized wireless devices including business justification for each wireless access point.

Documented Incident Response Plan which includes details on responding to identified unauthorized wireless access points.

Recent wireless access point identification scan from the past 3 months.

Response documentation verifying that any identified unauthorized wireless access points were appropriately responded to according to the Incident Response Plan.

Internal Vulnerability Scans from the past 4 quarters (NOTE: for initial compliance, the past 4 quarters are not required, just the most recent scan).

Any supporting documentation from these internal vulnerability scans.

Documentation showing that any high-risk items in quarterly vulnerability scans have been remediated.

Rescan reports showing that all high-risk items identified in quarterly internal scans have been remediated.

If an internal resource was used to perform internal vulnerability scanning, an organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

Output from the past four quarters of external vulnerability scans performed by an Approved Scanning Vendor (ASV) (NOTE: for initial compliance, the past four quarters are not required, just the most recent quarter.)

Documentation showing that any rescans of external vulnerability scans were completed until the ASV Program Guide for passing a scan have been met (such as no vulnerabilities with a CVSS of 4.0 or higher, etc.).

Evidence to show that the party performing the external vulnerability scans was a PCI SSC Approved Scanning Vendor (ASV).

Documented policies and procedures which define what constitutes the definition of a significant change.

Any documented vulnerability scan results showing that scans are carried out after a significant change within the CDE has occurred.

Initial vulnerability scan reports and any rescans carried out after a significant change in the CDE showing that:

If an internal resource was used to perform internal vulnerability scanning, an organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

Documentation which defines the methodology used for conducting penetration tests which must include:

Scope of Work from the most recent external penetration test which defines:

Documented penetration test report from the most recent external penetration test.

If an internal resource was used to perform internal vulnerability scanning, an organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

Scope of Work from the most recent internal penetration test which defines:

Documented penetration test report from the most recent internal penetration test.

If an internal resource was used to perform internal vulnerability scanning, an organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

Documented penetration test reports, retesting reports, and remediation documentation showing that any identified exploitable vulnerabilities were corrected and that testing was repeated until the vulnerabilities were corrected.

If the CDE is segmented from other networks, documented penetration testing methodology which defines a requirement to test these segmentation controls.

If the CDE is segmented from other networks, results from the most recent penetration test showing that the following elements were addressed:

If the CDE is segmented from other networks, if an internal resource was used to perform internal vulnerability scanning, organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

If you are a service provider and use segmentation controls to segment your CDE from other networks, results from the most recent penetration test from within the past 6 months.

If you are a service provider and use segmentation controls to segment your CDE from other networks, results from the most recent penetration test showing that the test covered all segmentation controls/methods used.

If you are a service provider and use segmentation controls to segment your CDE from other networks, results from the most recent penetration test showing that the test verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

If an internal resource was used to perform internal vulnerability scanning, an organizational chart showing the position of the person performing the internal vulnerability scan.

Resume, Linkedin profile, or other documentation demonstrating the competence of the internal resource who performed the internal vulnerability scans.

If an external resource was used, evidence that the external party is both independent and competent.

Vendor documentation for the IDS/IPS solution implemented.

Screenshots of system configurations showing how the IDS/IPS and signatures are kept up-to-date.

Screenshots from the change detection solution (such as File Integrity Monitoring) and relevant change detection system configurations showing what is monitored.

Documented list of files which are monitored by the change detection solution.

Screenshots of the alerting configuration for the change detection solution, including who is alerted.

Screenshots of the change detection system configuration settings showing that critical file comparisons are carried out at least weekly.

Documented procedures for responding to alerts generated by the change detection system.

Documented policies and procedures related to security monitoring and testing.

Screenshots showing where these policies and procedures are stored and available to employees/contractors.

Documented policies for acceptable use of critical technologies which states that explicit approval from authorized parties is required to use all technologies.

Documented policies for acceptable use of critical technologies which states that technology use requires a user ID and password or other authentication mechanism.

Documented policies for acceptable use of critical technologies which states a requirement to maintain a list of devices used in the environment and a list of personnel authorized to use these devices.

Documented policies for acceptable use of critical technologies which states a requirement to tag devices in a way that displays owner, contact information, and purpose.

Documented policies for acceptable use of critical technologies which states the acceptable network locations for each type of technology.

Documented policies for acceptable use of critical technologies which states a requirement to maintain a list of company approved products.

Documented policies for acceptable use of critical technologies which states that remote access technologies will be disconnected after a specified period of inactivity.

Screenshots of remote access technology configurations showing that remote access sessions will be disconnected after a set period of inactivity.

Documented policies for acceptable use of critical technologies which states that remote access technologies will only be enabled for vendors and business partners when required and deactivated immediately after.

Documented policies for acceptable use of critical technologies which states a requirement that employees are forbidden from copying, moving, or storing cardholder data onto local hard drives and removable media when accessing data remotely.

Documented policies for acceptable use of critical technologies which states a requirement that employees authorized to access cardholder data follow PCI DSS requirements to protect cardholder data.

Documented Information Security policy and any supporting procedures which define the information security responsibilities for all personnel.

If your organization is a service provider, a documented PCI DSS compliance program.

If your organization is a service provider, documented PCI DSS compliance program which assigns overall accountability for maintaining PCI DSS compliance.

If your organization is a service provider, documented PCI DSS Charter which outlines the conditions under which the PCI DSS compliance program is organized and communicated to executive management.

Documented Information Security policies and procedures which formally assign the responsibilities for information security to a CISO, Information Security Officer, or similar official.

Documented Information Security policies and procedures which formally assign a responsibility to establish, document, and distribute information security policies and procedures.

Documented Information Security policies and procedures which formally assign a responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit personnel.

Documented Information Security policies and procedures which formally assign a responsibility for establishing, documenting, and distributing security incident response plans and procedures including escalation procedures.

Documented Information Security policies and procedures which formally assign a responsibility for administering (adding, deleting, and modifying) user accounts and authentication management.

Documented Information Security policies and procedures which formally assign a responsibility for monitoring and controlling all access to data.

Formally documented Cardholder Data Security Awareness Training Program which documents that training is provided to all personnel regarding data security policies and procedures.

Formally documented Cardholder Data Security Awareness Training Program which documents that multiple methods will be used to communicate awareness and educate personnel. Example methods include:

Training records showing that all personnel have received training upon hire and at least annually thereafter on cardholder data security..

Formally documented list of all service providers which lists the specific services being provided.

An example of a formally written agreement with a service provider which contains an acknowledgement by the service provider that they are responsible for the security of cardholder data that they possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Formally documented policies and procedures for engaging with service providers, including proper due diligence which will be performed on potential service providers.

Formally documented Vendor Management program which includes procedures for monitoring service providers’ compliance with PCI DSS on at least an annual basis.

Formally documented list or other information which notes which PCI DSS requirements are managed by your organization and which are managed by service providers.

If your organization is a service provider, formally documented policies and procedures which require that your organization acknowledge within a written agreement your responsibilities with maintaining all applicable PCI DSS requirements to the extent that you possess or otherwise store, process, or transmit cardholder data on behalf of your customers or could otherwise impact the security of your customer’s cardholder data environment.

Documented Incident Response Plan that addresses the roles, responsibilities, and communication/contact strategies used in the event of a security incident. This should also include a notification of payment brands, at a minimum.

Documented Incident Response procedures which include the specific steps to be executed when responding to an incident.

Documented Incident Response Plan or procedures which include an analysis of your organization’s legal requirements for reporting compromises of security.

Documented Incident Response Plan or procedures which include coverage and response steps for all critical system components.

Documented Incident Response Plan or procedures which include references to or inclusion of incident response procedures from the specific Payment Brands applicable to your organization.

Documented policies or procedures related to Incident Response or Training which include a requirement to train staff with Incident Response roles on a periodic basis.

Documented policies or procedures for Incident Response which cover responding to alerts from security monitoring systems including but not limited to intrusion-detection, intrusion-preventions, firewalls, and file-integrity monitoring systems.

Documented Incident Response Plan which includes procedures for incorporating lessons learned and industry developments into the Incident Response Plan.

If your organization is a service provider, documented Incident Response Plan which covers the following items:

If your organization is a service provider, documented evidence that you review records to determine if your personnel are adhering to the Incident Response Plan on a quarterly basis.

If your organization is a service provider, documented evidence that the Incident Response Plan is reviewed on a quarterly basis.

Formally documented review and sign-offs by the personnel responsible for the PCI DSS Compliance Program.