Skip to main content
All CollectionsCompliance
Example Evidence for Not Monitored PCI DSS Controls
Example Evidence for Not Monitored PCI DSS Controls
Ethan Heller avatar
Written by Ethan Heller
Updated over a week ago

PCI DSS is a very specific control framework which contains explicit instructions regarding how an organization should be protecting the security of cardholder data. SAQ D contains over 300 of these requirements that an organization may have to comply with. For this reason, we have reviewed the PCI DSS Report on Compliance (ROC) reporting template that PCI QSAs use when assessing the security of cardholder data environments and the expected testing requirements from SAQ D to determine which evidence the PCI Security Standards Council suggests providing for each PCI DSS control. We have listed each piece of evidence from the ROC alongside each of the controls listed within Drata to clarify what should be provided when preparing for a PCI SAQ a PCI QSA audit.

NOTE: This article was written for PCI v3.2.1

Code

PCI Requirement

Name

Example Evidence

DCF-21

1.1.2(a), 1.1.2(b)

Architectural Diagram

1. Approved Architectural Diagram

DCF-16

12.2(b)

Annual Risk Assessment

1. Most recently completed risk assessment report.

DCF-26

12.10.2

BCP/DR Tests Conducted Annually

1. Most recently completed BCP/DR test.

DCF-201

1.1.1

Firewall and Router Configuration Standards

  1. Formal, documented testing and approval procedures for network connections.

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

  3. Example documentation supporting a network connection was tested and approved.

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

DCF-202

1.1.2(a)

CDE Network Diagram

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

DCF-203

1.1.2(b)

CDE Network Diagram - Review

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

DCF-204

1.1.3(a)

Dataflow Diagram

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

DCF-205

1.1.3(b)

Dataflow Diagram Review

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

DCF-206

1.1.4(a)

Firewall Configuration

  1. Formal, documented firewall and router configuration standards.

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

DCF-207

1.1.4(b)

Network Diagram is consistent with Firewall Configuration

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

DCF-208

1.1.5

Network Management Roles and Responsibilities

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

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

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

DCF-209

1.1.6(a)

Services, Protocols, and Ports Approval List

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

DCF-210

1.1.6(b)

Insecure Services, Protocols, and Ports List

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

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

DCF-211

1.1.7(a)

Firewall and Router Rule Review Standard

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

DCF-212

1.1.7(b)

Firewall and Router Rule Review

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

DCF-213

1.2.1(a)

Network Traffic Restrictions

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

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

DCF-214

1.2.1(b)

Network Traffic Denial

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

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

DCF-215

1.2.2

Secured Router Configuration Files

  1. Screenshots or exports of the router configuration files.

  2. Screenshots showing who can access router configuration files.

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

DCF-216

1.2.3

Perimeter Firewalls between CDE and Wireless Networks

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

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

  3. Network Diagram

DCF-217

1.3

Prohibited Direct Public Access to Data Environment

  1. Firewall and Router configuration showing how public access is restricted.

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

DCF-218

1.3.1

DMZ Implemented

  1. Network diagram showing that a DMZ has been implemented.

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

DCF-219

1.3.2

DMZ IP Addresses

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

DCF-220

1.3.3

Anti-Spoofing Measures

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

DCF-221

1.3.4

Explicit Authorization for CDE Outbound Traffic

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

DCF-222

1.3.5

Permit Established Connections Only

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

DCF-223

1.3.6

Cardholder Data in Internal Network Zone

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

  2. Network diagram.

DCF-224

1.3.7(a)

Prevention of Private IP Information Disclosure

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

    1. Network Address Translation (NAT).

    2. Placing CDE servers behind proxies.

    3. Removal or filtering of route advertisements for private networks that use registered addressing.

    4. Internal use of RFC1918 address space instead of registered addresses.

DCF-225

1.3.7(b)

External Private IP Information Disclosure Restricted

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

    1. Network Address Translation (NAT).

    2. Placing CDE servers behind proxies.

    3. Removal or filtering of route advertisements for private networks that use registered addressing.

    4. Internal use of RFC1918 address space instead of registered addresses.

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

DCF-226

1.4(a)

Personal Firewall Installed on Portable Devices

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

  2. Configuration standards for personal firewalls.

NOTE - Mark the control out of scope if devices cannot access the CDE outside of the network.

NOTE - This control covers employee-owned and company-owned devices.

DCF-227

1.4(b)

Personal Firewall on Portable Devices Configured Properly

  1. Screenshots showing personal firewalls are configured according to the standard.

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

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

NOTE - Mark the control out of scope if devices cannot access the CDE outside of the network.

NOTE - This control covers employee-owned and company-owned devices.

DCF-228

1.5

Firewall Security Policy

  1. Documented firewall security policies and procedures.

DCF-229

2.1(a)

Default Accounts Changed

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

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

DCF-230

2.1(b)

Unnecessary Default Accounts Removed/Disabled

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

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

DCF-231

2.1.1(a)

Changes in Encryption Keys

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

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

NOTE - Mark this control out of scope if there are no wireless environments connected to the cardholder data environment or transmitting cardholder data

DCF-232

2.1.1(b)

SNMP Community Strings Changed

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

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

NOTE - Mark this control out of scope if there are no wireless environments connected to the cardholder data environment or transmitting cardholder data

DCF-233

2.1.1(c)

Default Passwords on Access Points Changed

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

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

NOTE - Mark this control out of scope if there are no wireless environments connected to the cardholder data environment or transmitting cardholder data

DCF-234

2.1.1(d)

Updated Firmware on Wireless Devices

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

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

NOTE - Mark this control out of scope if there are no wireless environments connected to the cardholder data environment or transmitting cardholder data

DCF-235

2.1.1(e)

Wireless Vendor Defaults Changed

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

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

NOTE - Mark this control out of scope if there are no wireless environments connected to the cardholder data environment or transmitting cardholder data

DCF-236

2.2(b)

Update Configuration Standards after New Vulnerabilities

  1. System hardening procedures.

DCF-237

2.2(d)

System Configuration Standards

  1. System hardening procedures which cover the following attributes:

  • Changing of all vendor-supplied defaults and elimination of unnecessary default accounts

  • Implementing only one primary function per server to prevent functions that require different security levels from coexisting on the same server

  • Enabling only necessary services, protocols, daemons, etc., as required for the function of the system

  • Implementing additional security features for any required services, protocols or daemons that are considered to be insecure

  • Configuring system security parameters to prevent misuse

  • Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers

DCF-238

2.2.1(a)

One Primary Function per Server

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

NOTE - If all your assets are virtualized, then this will be covered in DCF 239

DCF-239

2.2.1(b)

One Primary Function per Virtual System Components

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

DCF-240

2.2.2(a)

Enable Only Necessary System Function Services

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

DCF-241

2.2.2(b)

Justify Enabled Insecure Services

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

DCF-242

2.2.3

Additional Security Features for Enabled Insecure Services

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

Example: If FTP is being used, screenshots showing that all files stored on the FTP server were encrypted separately being put on the FTP server.

NOTE - If no insecure features are running, then you can mark this control out of scope.

DCF-243

2.2.4(a)

Proficiency in Common Security Parameter System Settings

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

DCF-244

2.2.4(b)

Common System Security Parameters in Configuration Standards

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

DCF-245

2.2.4(c)

Security Parameter Settings Set Appropriately

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

DCF-246

2.2.5(a)

Unnecessary Functions Removed

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

DCF-247

2.2.5(b)

Enabled Functions Documented

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

DCF-248

2.2.5(c)

Documented Functionality on System Components

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

DCF-249

2.3(a)

Encrypted Non-Console Administrative Access

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

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

NOTE: Non-console access refers to logical access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console access includes access from within local/internal networks as well as access from external, or remote, networks.

DCF-250

2.3(b)

Insecure Remote Login Commands Prevented

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

DCF-251

2.5

Vendor Management Security Policies and Operational Procedures Documented and Accessible

  1. Vendor management policy.

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

DCF-252

2.6

Shared Hosting Provider Secure Configurations

For an example customer that can run their own applications provide the following:

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

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

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

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

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

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

    1. Disk space

    2. Bandwidth

    3. Memory

    4. CPU

  7. Screenshots showing that:

  • Logging is enabled for common third-party applications

  • Logs are active by default

  • Logs are available for customers to review

  • Log locations are communicated to customers

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

DCF-253

3.1(b)

Cardholder Data Deleted Securely

  1. Policies and procedures for data disposal of CHD.

DCF-254

3.1(c)

Cardholder Data Retention Requirements

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

DCF-255

3.1(d)

Quarterly Cardholder Data Retention Review

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

DCF-256

3.1(e)

Cardholder Data meets Data Retention Policy Requirements

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

DCF-257

3.2(a)

Sensitive Authentication Data Storage

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

DCF-258

3.2(b)

Sensitive Authentication Data Secured

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

DCF-259

3.2(c)

Sensitive Authentication Data Deleted after Authorization Process

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

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

DCF-260

3.2.1

Full Track Contents Not Stored

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

  • Incoming Transaction Data

  • All Logs

  • History Files

  • Trace Files

  • Database Schema

  • Database Contents

DCF-261

3.2.2

Card Verification Code Not Stored

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

  • Incoming Transaction Data

  • All Logs

  • History Files

  • Trace Files

  • Database Schema

  • Database Contents

DCF-262

3.2.3

PIN Not Stored

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

  • Incoming Transaction Data

  • All Logs

  • History Files

  • Trace Files

  • Database Schema

  • Database Contents

DCF-263

3.3

PAN is Masked when Displayed

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

  • List of roles which need access to display more than the first six/last four digits of the PAN along with business justification.

  • That the PAN must be masked when displayed such that only personnel with the listed roles may view the full PAN.

  • All roles not listed must only be able to view the first six/last four digits of the PAN.

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

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

DCF-264

3.4

PAN is Unreadable Anywhere it is Stored

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

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

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

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

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

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

DCF-265

3.4.1(a)

Separate Encrypted File System Access Management

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

DCF-266

3.4.1(b)

Cryptographic Keys Stored Securely

  1. Screenshots showing how cryptographic keys are stored securely.

DCF-267

3.4.1(c)

Cardholder Data on Removable Media Encrypted

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

  2. Screenshots of encrypted cardholder data on removable media.

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.

DCF-268

3.5.1

Cryptographic Architecture Description (Service Providers Only)

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

Note: Only applies to service providers.

DCF-269

3.5.2

Restricted Key Access

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

DCF-270

3.5.3

Secret and Private Keys Used for Stored Data

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

  • Encryption with a key-encrypting key that is at least as strong as the key used to encrypt data and is stored separately from this data-encrypting key.

  • Within a secure cryptographic device such as an HSM or PTS-approved point-of-interaction device.

  • As key components or key shares, in accordance with an industry-accepted method.

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

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

DCF-271

3.5.4

Key Storage Locations Limited

  1. List of all locations where keys are stored.

DCF-272

3.6(b)

Guidance for Shared Key Management

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

Note: Only applies to service providers.

DCF-273

3.6.1

Strong Key Generation Procedure

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

  2. Screenshots showing the strong cryptographic key generation process.

DCF-274

3.6.2

Secure Key Generation Procedure

  1. Documented procedures for distributing cryptographic keys securely.

DCF-275

3.6.3

Secure Key Storage Procedure

  1. Documented procedures for how cryptographic keys are securely stored.

  2. Screenshots showing how cryptographic keys are securely stored.

DCF-276

3.6.4

Key Changes for Retired Keys

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

DCF-277

3.6.5(a)

Key Retirement Procedures

  1. Key-management procedures specifying 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.

DCF-278

3.6.5(b)

Replacement of Compromised Keys

  1. Documented key management procedures which include guidance for:

  • Replacement of known or suspected compromised keys.

DCF-279

3.6.5(c)

Retained Keys Used for Decryption/Verification

  1. Documented key management procedures which include guidance for:

  • Details on if any keys will be retained after retirement or replacement including statements detailing that these keys will not be used for encryption.

DCF-280

3.6.6

Split Knowledge and Dual Control of Keys

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

  • Split knowledge of keys such that key components are under the control of at least 2 people who only know their key component

  • Dual control of keys, such that 2 people are required to perform any key management operations and no single person has knowledge of the other person’s key management credentials.

DCF-281

3.6.7

Unauthorized Key Substitution

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

DCF-282

3.6.8

Former Acknowledgment of Key Custodial Responsibilities

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

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

DCF-283

4.1(a)

Secure and Encrypted Data Transmission

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

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

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

DCF-284

4.1(b)

Only Trusted Keys or Certificates Accepted

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

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

DCF-285

4.1(c)

Insecure Versions or Configurations Not Supported

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

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

DCF-286

4.1(d)

Proper Encryption Strength

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

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

DCF-287

4.1(e)

TLS Enabled during Data Transmission

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

Example: For browser based cardholder data transmissions, screenshots showing that HTTPS appears in the URL wherever cardholder data is collected.

DCF-288

4.1.1

Strong Encryption for Wireless Network Transmission

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

  2. Documented standards for these wireless networks.

  3. Screenshots from the configurations of these networks showing that:

  • Industry best practices are used to implement strong encryption for authentication and transmission.

  • Weak encryption such as WEP is not used.

DCF-289

4.2(a)

PAN Secured in Transmission via End-User Messaging Technologies

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

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

DCF-290

4.2(b)

Unprotected PANs Not Sent via End-User Messaging Technologies

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

DCF-291

5.1.1

Anti-Virus Capability

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

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

  • Detects all known types of malicious software.

  • Remove all known types of malicious software.

  • Protect against all known types of malicious software.

Examples of types of malicious software include viruses, Trojans, worms, spyware, adware, and rootkits.

DCF-292

5.1.2

Periodic Evaluation of Malware Threats

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

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

DCF-293

5.2(a)

Anti-Virus Kept Current

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

DCF-294

5.2(b)

Anti-Virus Automatic and Periodic Scans

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

DCF-295

5.2(c)

Anti-Virus Audit Logs

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

DCF-296

5.3

Anti-Virus Configuration

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

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

DCF-297

6.2(b)

Critical Patches Installed

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

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

DCF-298

6.3(b)

Information Security in SDLC

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

DCF-299

6.3(c)

Software Development in line with PCI

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

DCF-300

6.3.1

Removal of Account Information before Application Release

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

DCF-301

6.3.2

Code Review prior to Release

  1. Documented SDLC policy or procedures which document the following requirements:

  • Code changes are reviewed by someone other than the original code author.

  • Code reviews ensure that code is developed according to secure coding guidelines.

  • Appropriate corrections are implemented prior to release.

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

DCF-302

6.4.1(b)

Separate Test and Production Environments Access Control

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

  2. Screenshots from the network device configurations which enforce this separation.

DCF-303

6.4.2

Separation of Duties in Test and Production Environments

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

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

DCF-304

6.4.4

Test Data Removed before System Activation

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

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

DCF-305

6.4.5.1

Documentation of Impact

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

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

DCF-306

6.4.5.2

Documentation of Authorized Party Approval

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

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

DCF-307

6.4.5.3(a)

Functionality Testing

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

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

DCF-308

6.4.5.3(b)

Updates for PCI Compliance Testing

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

DCF-309

6.4.5.4

Back-out Procedures

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

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

DCF-310

6.4.6

PCI Requirements Implemented Upon Completion of Significant Change

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

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

DCF-311

6.5(a)

Common Coding Vulnerabilities

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

DCF-312

6.5(b)

Annual Training for Developer Secure Coding Techniques

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

DCF-313

6.5(c)

Application Development based on Secure Coding Guidelines

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

DCF-314

6.5.1

Injection Flaws

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

  • Validating input to verify user data cannot modify the meaning of commands and queries.

  • Utilizing parameterized queries.

DCF-315

6.5.2

Buffer Overflow

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

  • Validating buffer boundaries.

  • Truncating input strings.

DCF-316

6.5.3

Insecure Cryptographic Storage

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

  • Preventing cryptographic flaws.

  • Using strong cryptographic algorithms and keys.

DCF-317

6.5.4

Insecure Communications

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

  • Techniques to properly authenticate and encrypt all sensitive communications.

DCF-318

6.5.5

Improper Error Handling

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

  • Techniques which do not leak information through error messages (usually achieved by presenting generic error messages rather than specific error details).

DCF-319

6.5.6

High Risk Vulnerabilities

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

DCF-320

6.5.7

Cross-Site Scripting (XSS)

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

  • Validating all parameters before inclusion.

  • Utilizing context-sensitive escaping.

DCF-321

6.5.8

Improper Access Control

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

  • Proper authentication of users.

  • Sanitizing input.

  • Not exposing internal object references to users.

  • User interfaces that do not permit access to unauthorized functions.

DCF-322

6.5.9

Cross-Site Request Forgery (CSRF)

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

  • Applications do not rely on authorization credentials and tokens automatically submitted by browsers.

DCF-323

6.5.10

Broken Authentication and Session Management

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

  • Flagging session tokens as “secure”.

  • Not exposing session IDs in URLs.

  • Incorporating appropriate time-outs and rotation of session IDs after a successful login.

DCF-324

6.6

Public-Facing Web Application Vulnerability Assessment

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

  • At least annually

  • After any changes

  • By an organization which specializes in application security

  • That, at a minimum, all vulnerabilities contained in DCF-314 through DCF-323 are covered.

  • That all vulnerabilities are corrected.

  • And that the application is reassessed after vulnerabilities have been corrected.

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

  • The solution sits in front of the public-facing web applications.

  • Is actively running and as up-to-date as applicable to your organization.

  • Is generating audit logs.

  • Is configured to either block web-based attacks or generate an alert which is immediately investigated.

DCF-325

6.7

Policy for Secure Systems and Applications Documented and Accessible

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

DCF-326

7.1

System Access Control Policy

  1. Documented System Access Control which documents the following:

  • Defining access needs and privilege assignments for each role.

  • Restricting access to privileged IDs to the least level of privilege necessary to perform job functions.

  • Assigning access based on individual personnel’s job classification and function.

  • Documenting approval by authorized parties for all access, including listing the specific privileges approved.

DCF-327

7.1.1

System Access Roles Defined

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

  • System components and data resources required for the job function.

  • Level of privilege required for accessing resources (user, administrator, etc.)

DCF-328

7.1.4

Documented Approval by Authorized Parties

  1. Screenshots of the privileges assigned to an example user ID.

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

  • Evidence that the documented approval exists.

  • That approval was provided by an authorized party.

  • That the specific privileges assigned to that user match their assigned privileges.

DCF-329

7.2.1

Access Control System in Place

  1. Screenshots from the access control system for all system components.

DCF-330

7.2.2

Role-Based Access Control System

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

DCF-331

7.2.3

Default "Deny All" on Access Control System

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

DCF-332

7.3

Policy for Restricting Access is Documented and Available

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

DCF-333

8.1.1

Unique User ID

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

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

DCF-334

8.1.2

Privileged and General User ID Authorization

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

  2. Documented access authorization for an example administrative/privileged user.

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

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

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

DCF-335

8.1.4

Inactive User Accounts Removed

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

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

DCF-336

8.1.5(a)

Access Management of Accounts Used by Remote 3rd Parties

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

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

DCF-337

8.1.5(b)

Access to Accounts Used by Remote 3rd Parties Monitored

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

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

DCF-338

8.1.6(a)

User ID Lockout After Repeated Access Attempts

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

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

DCF-339

8.1.6(b)

Non-consumer Customer Password Lockout after Invalid Access Attempts (Service Provider Only)

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

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

DCF-340

8.1.7

Lockout Duration

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

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

DCF-341

8.1.8

Reauthentication of Idle Sessions

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

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

DCF-342

8.2

User Authentication Methods

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

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

DCF-343

8.2.1(a)

Strong Encryption of Authentication Credentials During Transmission and Storage

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

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

DCF-344

8.2.1(b)

Strong Encryption of Non-consumer Customer Authentication Credentials During Transmission and Storage (Service Provider Only)

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

DCF-345

8.2.2

User Identity Verification Before Modifying Authentication

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

DCF-346

8.2.3(a)

Minimum Password Requirements

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

  • A minimum length of at least 7 characters.

  • Contain both numeric and alphabetic characters.

  • (If the above cannot be implemented) Complexity and strength equivalent to the above parameters.

DCF-347

8.2.3(b)

Minimum Password Requirements for Non-consumer Customer (Service Providers Only)

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

  • Have a minimum length of at least 7 characters.

  • Contain both numeric and alphabetic characters.

DCF-348

8.2.4(a)

Periodic Password Change

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

DCF-349

8.2.4(b)

Periodic Password Change for Non-consumer Customer (Service Providers Only)

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

  • Non-consumer customer users' passwords must be changed periodically.

  • Non-consumer customer users are given guidance as to when and under which circumstances passwords must change.

DCF-350

8.2.5(a)

Passwords Different from Last Four

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

DCF-351

8.2.5(b)

Non-consumer Customer Passwords Different from Last Four (Service Providers Only)

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

DCF-352

8.2.6

Unique First-time Passwords

  1. Documented password procedures which define the following requirements:

  • First-time passwords must be set to a unique value for each user.

  • First-time passwords must change after first use.

  • Reset passwords must be set to a unique value for each user.

  • Reset passwords must change after each use.

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

DCF-353

8.3

MFA for Non-Admin and Remote CDE Access

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

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

DCF-354

8.3.1

MFA for Non-console Access to CDE

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

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

DCF-355

8.3.2

MFA for Remote Network Access

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

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

DCF-356

8.4(b)

Authentication Policy Inclusions

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

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

  • Guidance on selecting strong authentication credentials.

  • Guidance for how users should protect their authentication credentials.

  • Instructions to not use previously used passwords.

  • Instructions stating to change a password if the password is suspected to be compromised.

DCF-357

8.5

Shared Authentication Methods are Prohibited

  1. System user access lists which show that:

  • Generic user IDs are disabled or removed.

  • Shared user IDs for system administration activities and other critical functions do not exist.

  • Shared and generic user IDs are not used to administer any system component.

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

DCF-358

8.5.1

Unique Authentication Credential for Service Providers with Remote Access (Service Providers Only)

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

DCF-359

8.6

Authentication Mechanism Use

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

  • Authentication mechanisms are assigned to an individual account and not shared.

  • Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access.

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

DCF-360

8.7(a)

Programmatic Methods for Database Access

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

DCF-361

8.7(b)

Direct Access to Database Restrictions

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

DCF-362

8.7(c)

Application IDs Only Used by the Application

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

DCF-363

9.1

Entry Controls in Place

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

  • Pictures showing that access is controlled using badge readers or other devices including authorizing badges and lock and key.

  • Screenshots or video showing an administrator’s attempt to log into consoles for systems within the CDE showing that these systems are “locked” to prevent unauthorized access.

DCF-364

9.1.1(a)

Physical Access Control to Sensitive Areas

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

DCF-365

9.1.1(b)

Secure Physical Access Control Mechanisms

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

DCF-366

9.1.1(c)

Physical Access Control Mechanism Data Review

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

DCF-367

9.1.1(d)

Physical Access Control Mechanism Data Retention

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

DCF-368

9.1.2

Restricted Physical Access to Publicly Accessible Network Jacks

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

  2. Pictures or videos showing how these procedures have been implemented.

DCF-369

9.1.3

Restricted Physical Access to Network Components

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

  • Wireless access points

  • Wireless gateways

  • Wireless handheld devices

  • Network/communications hardware

  • Telecommunications lines

DCF-370

9.2(a)

Onsite Identification Management

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

  • Identifying onsite personnel and visitors (such as assigning ID badges).

  • Handling changes to access requirements.

  • Revoking terminated onsite personnel and expired visitor identification (such as ID badges).

DCF-371

9.2(b)

Onsite Identification Methods

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

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

DCF-372

9.2(c)

Restricted Access to Badge System

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

DCF-373

9.3

Role-Based Physical Access

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

  2. Termination/offboarding checklist showing that physical access was revoked.

DCF-374

9.4.1

Visitors Preauthorized and Escorted

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

DCF-375

9.4.2(a)

Visitor Badges

  1. Pictures showing the visitor badges given to authorized visitors.

DCF-376

9.4.2(b)

Visitor Badge Expiration

  1. Pictures showing that visitor badges have a set expiration.

DCF-377

9.4.3

Visitor Badge Control

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

DCF-378

9.4.4(a)

Visitor Log to Facility and Data Storage Areas

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

DCF-379

9.4.4(b)

Visitor Log Inclusions

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

  • Visitor’s name

  • Firm the visitor represents

  • Onsite personnel authorizing access

DCF-380

9.4.4(c)

Visitor Log Retention

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

DCF-381

9.5

Media Physically Secured

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

DCF-382

9.5.1

Security Review of Media Backup Storage Location

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

DCF-383

9.6(a)

Media Transfer Procedures

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

DCF-384

9.6.1

Media Classification

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

DCF-385

9.6.2

Media Transferred Securely

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

  2. Screenshots or documentation showing how media transfers are logged.

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

DCF-386

9.6.3

Manager Approval for Media Transfer

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

DCF-387

9.7

Media Storage and Accessibility

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

DCF-388

9.7.1(a)

Media Inventory Logs

  1. Documented media inventory logs.

DCF-389

9.7.1(b)

Periodic Inventory of Media Logs

  1. Documented inventory of media from the past 12 months.

DCF-390

9.8(a)

Media Destruction

  1. Documented policies and procedures related to Media Destruction.

DCF-391

9.8(b)

Periodic Media Destruction Policy

  1. Documented policies and procedures related to Media Destruction which includes:

  • Hard-copy materials must be crosscut shredded, incarcerated, or pulped such that they cannot be reconstructed.

  • Storage containers used for storing media awaiting destruction must be secured.

  • Cardholder data stored on electronic media must be disposed of in such a way that it is unrecoverable such as secure deletion or physical destruction of media in accordance with industry standards.

DCF-392

9.8.1(a)

Destruction of Hardcopy Material

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

DCF-393

9.8.1(b)

Storage Containers for Destroyable Material

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

DCF-394

9.8.2

Cardholder Data Unrecoverable on Electronic Media upon Deletion

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

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

DCF-395

9.9

Payment Card Device Management Policy

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

  • A requirement to maintain an inventory of these devices.

  • A requirement to periodically inspect these devices for tampering or substitution.

  • A requirement to train personnel around how to detect suspicious behavior and report suspected tampering or substitution.

DCF-396

9.9(a)

List of Payment Card Capture Devices Maintained

  1. Documented inventory of card reading devices which documents:

  • Make and model of the device.

  • The location of the device.

  • Device serial number of other unique identifiers.

DCF-397

9.9(b)

Payment Card Capture Devices Periodic Inspection

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

  • Periodically inspecting card reading devices.

  • The frequency in which these device inspections will be carried out.

DCF-398

9.9(c)

Payment Card Capture Device Training and Reporting

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

  • Verifying the identity of any third-party personnel who claim to be repair or maintenance personnel prior to granting them access to the card reading devices.

  • Not installing, replacing, or returning devices without verification.

  • Being aware of suspicious activity around these devices.

  • Reporting suspicious behavior to appropriate personnel.

  • Reporting tampering or substitution of these devices.

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

DCF-399

9.9.1(a)

Payment Card Capture Device List Inclusions

  1. Documented inventory of card reading devices which documents:

  • Make and model of the device.

  • The location of the device.

  • Device serial number of other unique identifiers.

DCF-400

9.9.1(b)

Accurate and Updated Payment Card Capture Device List

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

DCF-401

9.9.1(c)

Payment Card Capture Device List Updates

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

DCF-402

9.9.2(a)

Payment Card Capture Device Surface Inspection

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

  • Periodically inspecting card reading devices.

  • The frequency in which these device inspections will be carried out.

DCF-403

9.9.2(b)

Payment Card Capture Device Inspection Procedures

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

  • Periodically inspecting card reading devices.

  • The frequency in which these device inspections will be carried out.

DCF-404

9.9.3(b)

Training Material for Payment Card Capture Device Tampering Awareness

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

  • Verifying the identity of any third-party personnel who claim to be repair or maintenance personnel prior to granting them access to the card reading devices.

  • Not installing, replacing, or returning devices without verification.

  • Being aware of suspicious activity around these devices.

  • Reporting suspicious behavior to appropriate personnel.

DCF-405

9.9.3(c)

Training for Payment Card Capture Device Tampering Awareness and Reporting Received

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

DCF-406

10.1(a)

Audit Trails Enabled and Active

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

DCF-407

10.1(b)

System Access Linked to Users

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

DCF-408

10.2.1

Audit Trail for Individual User Access to Cardholder Data

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

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

DCF-409

10.2.2

Audit Trail for Root Admin Privilege Access

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

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

DCF-410

10.2.3

Audit Trail Access

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

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

DCF-411

10.2.4

Invalid Logical Access Attempts

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

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

DCF-412

10.2.5

Audit Trail for Identification and Authentication Mechanism Changes

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

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

DCF-413

10.2.6

Audit Trail of Changes to Audit Logs

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

  2. Screenshots showing that these log settings are functioning correctly.

DCF-414

10.2.7

Audit Trail of System-Level Object Creation or Deletion

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

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

DCF-415

10.3.1

Audit Trail Entries: User Identification

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

DCF-416

10.3.2

Audit Trail Entries: Event Type

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

DCF-417

10.3.3

Audit Trail Entries: Date and Time

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

DCF-418

10.3.4

Audit Trail Entries: Pass/Fail Indication

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

DCF-419

10.3.5

Audit Trail Entries: Origination

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

DCF-420

10.3.6

Audit Trail Entries: Affected Item Name

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

DCF-421

10.4

Critical Clock Synchronization and Update

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

  • Only the designated central time server may receive time signals from the designated external time source.

  • Time signals are received in UTC or International Atomic Time.

  • When there is more than one central time server, these time servers are configured to peer with one another.

  • Systems may only receive synchronization information from designated central time server(s).

DCF-422

10.4.1(a)

Time-related System Parameters

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

  • Time signals are received in UTC or International Atomic Time.

  • When there is more than one central time server, these time servers are configured to peer with one another.

  • System may only receive synchronization information from designated central time server(s).

DCF-423

10.4.1(b)

Time Server Peering

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

  • When there is more than one central time server, these time servers are configured to peer with one another.

DCF-424

10.4.1(c)

System Time Source

  1. 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 may only receive synchronization information from designated central time server(s).

DCF-425

10.4.2(a)

Need-to-Know Access to Time Data

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

DCF-426

10.4.2(b)

Time Settings Changes Logged, Monitored, Reviewed

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

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

  3. Documented processes for monitoring and reviewing these logs.

DCF-427

10.4.3

Time Settings Source

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

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

DCF-428

10.5

Secured Audit Trails

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

DCF-429

10.5.1

Limited Access to Audit Trails

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

DCF-430

10.5.2

Audit Trail Files Protected

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

DCF-431

10.5.3

Audit Trail Files Backed Up

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

  • Logs are promptly backed up to a centralized logging server or media.

  • The frequency in which audit trails are backed up.

  • Protections on the centralized logging server or media which make these difficult to alter.

DCF-432

10.5.4

Logs for External-Facing Technologies

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

DCF-433

10.5.5

FIM on Logs

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

  • System settings

  • Which files are monitored

  • Logs/Alerts from the FIM or Change Detection Software

DCF-434

10.6.1(a)

Policy for Critical Systems Daily Log Review

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

  • All security events.

  • Logs of all system components that store, process, or transmit Cardholder Data or Sensitive Authentication Data.

  • Logs from all critical system components.

  • Logs of all servers and system components that perform security functions.

DCF-435

10.6.1(b)

Critical System Logs Reviewed Daily

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

  • All security events.

  • Logs of all system components that store, process, or transmit Cardholder Data or Sensitive Authentication Data.

  • Logs from all critical system components.

  • Logs of all servers and system components that perform security functions.

DCF-436

10.6.2(a)

Policy for Non-critical Systems Periodic Log Review

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

DCF-437

10.6.2(b)

Non-critical System Review Aligned with Risk Management

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

DCF-438

10.6.3(a)

Follow-up Procedures on Discovered Anomalies and Exceptions

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

DCF-439

10.6.3(b)

Follow-up on Discovered Anomalies and Exceptions Performed

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

DCF-440

10.7(a)

Policy for Audit Log Retention

  1. Documented policy related to Audit Log Retention.

DCF-441

10.7(b)

Audit Log Retention Period

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

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

DCF-442

10.7(c)

Audit Logs Available for Analysis

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

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

DCF-443

10.8(a)

Critical Security Control System Failure Detection and Reporting

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

  • Firewalls

  • IDS/IPS

  • FIM

  • Anti-virus

  • Physical access controls

  • Logical access controls

  • Audit logging mechanisms

  • Segmentation controls (if used)

DCF-444

10.8(b)

Critical Security Control System Failure Alert

  1. Screenshots showing how alerts are configured for the following systems:

  • Firewalls

  • IDS/IPS

  • FIM

  • Anti-virus

  • Physical access controls

  • Logical access controls

  • Audit logging mechanisms

  • Segmentation controls (if used)

DCF-445

10.8.1(a)

Critical Security Control System Failure Response

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

  • Restoring security functions

  • Identifying and documenting the duration (date and time start to end) of the failure

  • Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause.

  • Identifying and addressing any security issues that arose during the failure.

  • Performing a risk assessment to determine whether further actions are required as a result of the security failure.

  • Implementing controls to prevent cause of failure from reoccurring.

  • Resuming monitoring of security controls.

DCF-446

10.8.1(b)

Critical Security Control System Failure Documentation

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

  • Identification of causes(s) of the failure, including root cause.

  • Duration (date and time start to end) of the security failure.

  • Details of the remediation required to address the root cause.

DCF-447

10.9

Policy for Network Access Monitoring Documented and Accessible

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

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

DCF-448

11.1(a)

Wireless Access Point Detection and Identification

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

DCF-449

11.1(b)

Unauthorized Wireless Access Points Detected and Identified

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

  • WLAN cards inserted into system components

  • Portable or mobile devices attached to system components to create a wireless access point

  • Wireless devices attached to a network port or network device

DCF-450

11.1(c)

Quarterly Wireless Scan of Wireless Access Points

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

  • Authorized and unauthorized wireless access points are identified

  • The scan was performed within the last quarter for all system components and facilities.

DCF-451

11.1(d)

Wireless Access Point Automated Monitoring Alerts

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

DCF-452

11.1.1

Inventory of Authorized Wireless Access Point

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

DCF-453

11.1.2(a)

Incident Response Plan for Unauthorized Wireless Access Points

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

DCF-454

11.1.2(b)

Actions Against Unauthorized Wireless Access Points

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

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

DCF-455

11.2.1(a)

Quarterly Internal Vulnerability Scans

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

  2. Any supporting documentation from these internal vulnerability scans.

DCF-456

11.2.1(b)

High Risk Vulnerabilities Identified and Resolved

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

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

DCF-457

11.2.1(c)

Internal Vulnerability Scans by Competent and Independent Party

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

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

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

DCF-458

11.2.2(a)

Quarterly External Vulnerability Scans

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

DCF-459

11.2.2(b)

External Vulnerability Rescans Until Pass

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

DCF-460

11.2.2(c)

External Vulnerability Scans by PCI-Approved Vendor

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

DCF-461

11.2.3(a)

Vulnerability Scans After Significant Change

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

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

DCF-462

11.2.3(b)

Vulnerability Rescans

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

  • For external scans, no vulnerabilities are still present which are scored as 4.0 or higher by the CVSS.

  • For internal scans, all “high-risk” vulnerabilities as defined by PCI DSS requirement 6.1 have been remediated.

DCF-463

11.2.3(c)

Vulnerability Rescans by Competent and Independent Party

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

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

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

DCF-464

11.3

Penetration Testing Methodology

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

  • Being based on an industry-accepted penetration testing approach (such as the MITRE attack framework, Cyber Kill Chain, etc.)

  • Includes coverage for the entire CDE perimeter and critical systems.

  • Includes testing from both inside and outside the network.

  • Includes testing to validate any segmentation and scope reduction controls.

  • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in PCI DSS Requirement 6.5.

  • Defines network-layer penetration tests to include components that support network functions as well as operating systems.

  • Includes review and consideration of threats and vulnerabilities experienced in the past 12 months.

  • Specifies retention of penetration testing results and remediation activities.

DCF-465

11.3.1(a)

External Penetration Testing Scope

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

  • That the test will be completed using the approved methodology.

  • Will be conducted at least annually.

  • Will be conducted after any significant changes to the environment.

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

DCF-466

11.3.1(b)

External Penetration Tests by Competent and Independent Party

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

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

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

DCF-467

11.3.2(a)

Internal Penetration Testing Scope

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

  • That the test will be completed using the approved methodology.

  • Will be conducted at least annually.

  • Will be conducted after any significant changes to the environment.

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

DCF-468

11.3.2(b)

Internal Penetration Test by Competent and Independent Party

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

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

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

DCF-469

11.3.3

Resolving Vulnerabilities from Pen Testing

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

DCF-470

11.3.4(a)

Penetration Testing on All Segments

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

DCF-471

11.3.4(b)

Penetration Testing Requirements

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

  • Segmentation controls were tested in the past 12 months and after any significant change to the segmentation controls/methods.

  • The tests covered all segmentation controls/methods.

  • The test verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

DCF-472

11.3.4(c)

Penetration Tests for Control Segmentation Verification by Competent and Independent Party

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

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

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

DCF-473

11.3.4.1(a)

Periodic Segmentation Control Penetration Testing (Service Providers Only)

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

DCF-474

11.3.4.1(b)

Penetration Testing Scope (Service Providers Only)

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

DCF-475

11.3.4.1(c)

Penetration Testing Verification of Segmentation Control Effectiveness (Service Providers Only)

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

DCF-476

11.3.4.1(d)

Segmentation Control Penetration Tests by Competent and Independent Party (Service Providers Only)

If you are a service provider and use segmentation controls to segment your CDE from other networks:

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

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

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

DCF-477

11.4(c)

IDS/IPS Up to Date

  1. Vendor documentation for the IDS/IPS solution implemented.

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

DCF-478

11.5(a)

Change Detection Mechanism in Place

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

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

DCF-479

11.5(b)

Change Detection Mechanism Alerts

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

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

DCF-480

11.5.1

Change Detection Mechanism Alert Response

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

DCF-481

11.6

Policy for Security Monitoring and Testing Documented and Accessible

  1. Documented policies and procedures related to security monitoring and testing.

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

DCF-482

12.3.1

Explicit Approval for Technology Use

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

DCF-483

12.3.2

Technology Use Authentication

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

DCF-484

12.3.3

Access List of Devices and Personnel

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

DCF-485

12.3.4

Technology User Tags

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

DCF-486

12.3.6

Acceptable Network Locations

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

DCF-487

12.3.7

Company-Approved Product List

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

DCF-488

12.3.8

Automatic Disconnect of Inactive Remote-Access

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

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

DCF-489

12.3.9

3rd Party Remote-Access Usage

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

DCF-490

12.3.10(a)

Employee Remote-Access Usage

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

DCF-491

12.3.10(b)

Cardholder Data Protection per PCI Requirements

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

DCF-492

12.4

Information Security Responsibilities

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

DCF-493

12.4.1

PCI DSS Compliance Program (Service Providers Only)

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

DCF-494

12.4.1(a)

PCI DSS Compliance Accountability (Service Providers Only)

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

DCF-495

12.4.1(b)

PCI DSS Compliance Program Charter (Service Providers Only)

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

DCF-496

12.5(a)

Designated Information Security Official

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

DCF-497

12.5.1

Designated Entity to Maintain Security Policies and Procedures

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

DCF-498

12.5.2

Designated Entity to Monitor and Analyze Security Alerts

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

DCF-499

12.5.3

Designated Entity to Maintain Incident Response Procedures

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

DCF-500

12.5.4

Designated Entity to Administer User Accounts

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

DCF-501

12.5.5

Designated Entity to Monitor and Control Data Access

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

DCF-502

12.6(a)

Cardholder Data Security Awareness Program

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

DCF-503

12.6.1(a)

Multiple Methods for Security Awareness

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

  • Posters

  • Memos

  • Letters

  • Web-based Training

  • Meetings

  • Other types of promotions

DCF-504

12.6.1(c)

Cardholder Data Security Awareness Training

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

DCF-505

12.8.1

List of Service Providers

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

DCF-506

12.8.2

Service Providers Agreements

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

DCF-507

12.8.3

Pre-Agreement Process for Service Providers

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

DCF-508

12.8.4

Annual PCI DSS Compliance of Service Providers Monitored

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

DCF-509

12.8.5

Specified PCI DSS Responsibilities of Service Providers

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

DCF-510

12.9

Service Providers Acknowledge Security Responsibilities (Service Providers Only)

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

DCF-511

12.10.1(b)(1)

Incident Response Management

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

DCF-512

12.10.1(b)(2)

Specific Incident Response Procedures (SOPs)

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

DCF-513

12.10.1(b)(5)

Reporting Compromise

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

DCF-514

12.10.1(b)(6)

Critical System Coverage and Response

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

DCF-515

12.10.1(b)(7)

Inclusion of Incident Response Procedures from Payment Brands

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

DCF-516

12.10.4

Security Breach Response Training

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

DCF-517

12.10.5

Security Monitoring System Alerts

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

DCF-518

12.10.6

Incident Response Plan Review and Update

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

DCF-519

12.11(a)

Incident Response Review Inclusions (Service Providers Only)

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

  • Daily Log Reviews

  • Firewall ruleset reviews

  • Applying configuration standards to new systems

  • Responding to security alerts

  • Change Management processes

DCF-520

12.11(b)

Incident Response Plan Reviewed Quarterly (Service Providers Only)

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

DCF-521

12.11.1

Quarterly Incident Response Plan Review Report (Service Providers Only)

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

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

Did this answer your question?