Document Diff - PCI Watch

Added p. 2

This document is intended for use with PCI DSS v 3.2.1 r1.

Added p. 5

• Section 1: Contact Information and Report Date

• Section 2: Summary Overview

• Section 3: Description of Scope of Work and Approach Taken

• Section 4: Details about Reviewed Environment

• Section 5: Quarterly Scan Results

• Section 6: Findings and Observations

Added p. 6

• Appendix A: Additional PCI DSS Requirements

• Appendices B and C: Compensating Controls and Compensating Controls Worksheet (as applicable)

Added p. 9

• One word (yes/no) Example Reporting Instruction: Indicate whether the assessed entity is an issuer or supports issuing services. (yes/no)

• Document name or interviewee job title/reference

• Brief description/short answer

Added p. 12

• Lead Assessor name:

• List all other assessors involved in the assessment. If there were none, mark as Not Applicable. (add rows as needed) Assessor name: Assessor PCI credentials: (QSA, PA-QSA, etc.)

• List all Associate QSAs involved in the assessment. If there were none, mark as Not Applicable. (add rows as needed) Associate QSA name: Associate QSA mentor name:

12. Maintain a policy that addresses information security for all personnel ☐ ☐ ☐ ☐ Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers ☐ ☐ ☐ ☐ Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card- Present POS POI Terminal Connections Appendix A3: Designated Entities Supplemental Validation ☐ ☐ ☐ ☐

• Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as applicable

• Other necessary payment components, as applicable

Note

• the response must go beyond listing the activities that the assessor performed …

Added p. 21

• Other details, if applicable (add content or tables here for brand/acquirer use, if needed):

• Indicate whether there are wireless networks or technologies in use (in or out of scope), (yes/no) If “no,” describe how the assessor verified that there are no wireless networks or technologies in use.

• All boundaries of the cardholder data environment

• Any network segmentation points which are used to reduce scope of the assessment

• Boundaries between trusted and untrusted networks

• Wireless and wired networks

Added p. 25

Data Store (database, etc.) File(s) and/or Table(s) Cardholder data elements stored (for example, PAN, expiry, Name, any elements of SAD, etc.) How data is secured (for example, what type of encryption and strength, hashing algorithm and strength, tokenization, access controls, truncation, etc.) How access to data stores is logged (description of logging mechanism used for logging access to data•for example, describe the enterprise log management solution, application-level logging, operating system logging, etc. in place)

Added p. 28

• Provide the name of the assessor who attests that all PA-DSS validated payment applications were reviewed to verify they have been implemented in a PCI DSS compliant manner according to the payment application vendor’s PA-DSS Implementation Guide

• Any additional comments or findings the assessor would like to include, as applicable:

Number (optional) Employee Name Role/Job Title Organization Is this person an ISA? (yes/no)

• Identify whether the entity being assessed is a managed service provider. (yes/no)

• Identify whether there were any responses indicated as “In Place with Compensating Control.” (yes/no)

• If “yes,” complete the table below:

• If “yes,” complete the table below:

• Identify whether there were any responses indicated as “Not Tested”: (yes/no)

Added p. 32

• Is this the assessed entity’s initial PCI DSS compliance validation? (yes/no)

• The most recent scan result was a passing scan,

• The entity has documented policies and procedures requiring quarterly scanning going forward, and

• Any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.

• Network connections, and

• Testing and approval of all network connections. <Report Findings Here>

• Approved <Report Findings Here>

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place

• Approved <Report Findings Here>

• Is current. <Report Findings Here>

• Includes all connections to cardholder data. <Report Findings Here>

• At each Internet connection. <Report Findings Here>

• Inbound traffic <Report Findings Here>

• All other inbound traffic <Report Findings Here>

Added p. 43

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place configured per the organization’s specific configuration settings.

• Personal firewall (or equivalent functionality) is actively running.

• Personal firewall or equivalent functionality is not alterable by users of the portable computing devices.

• Actively running. <Report Findings Here>

• Removed <Report Findings Here>

• From default at installation

• Default SNMP community strings are not used.

• Default passwords/passphrases on access points are not used.

• Authentication over wireless networks

• Authentication over wireless networks

• Authentication over wireless networks. <Report Findings Here>

• Center for Internet Security (CIS)

• International Organization for Standardization (ISO)

• SysAdmin Audit Network Security (SANS) Institute

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place with industry-accepted hardening standards.

• Changing of all vendor-supplied defaults and …

Added p. 58

• Database contents Identify the sample of system components selected for 3.2.1-3.2.3.

Added p. 61

• One-way hashes based on strong cryptography,

• One-way hashes based on strong cryptography,

• Index tokens and pads, with the pads being securely stored

• Index tokens and pads, with the pads being securely stored

Added p. 66

• Encrypted with a key-encrypting key.

<Report Findings Here> 3.5.3.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

<Report Findings Here> 3.6.1.b Observe the procedures for generating keys to verify that strong keys are generated.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 3.6.5.a Verify that key-management procedures specify processes for the following:

• Any keys retained after retiring or replacing are not used for encryption operations.

• Split knowledge of keys, such that key components are under the control of at Indicate whether manual clear-text cryptographic key-management operations are used. (yes/no) <Report Findings Here> If “no,” mark the remainder of 3.6.6.a and 3.6.6.b as “Not Applicable.” If “yes,” complete 3.6.6.a and 3.6.6.b.

• Split knowledge of keys, such that key components are under the control of at least two people who only …

Added p. 81

• New security vulnerabilities are identified. <Report Findings Here>

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place removed before an application goes into production or is released to customers.

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

• Appropriate corrections are implemented prior to release.

• Appropriate corrections are implemented prior to release.

• Code review results are reviewed and approved by management prior to release.

Added p. 87

• Documented change approval by authorized parties.

Added p. 90

For the interviews at 6.5.c, summarize the relevant details discussed to verify that injection flaws are addressed by coding techniques that include:

• Utilizing parameterized queries. <Report Findings Here> 6.5.2 Buffer overflow. ☐ ☐ ☐ ☐ ☐

• Validating buffer boundaries.

• Truncating input strings.

• Prevent cryptographic flaws.

• Prevent cryptographic flaws. <Report Findings Here>

• Encrypt all sensitive communications. <Report Findings Here> 6.5.5 Improper error handling. ☐ ☐ ☐ ☐ ☐ 6.5.5 Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).

• Flagging session tokens (for example, cookies) as “secure.”

• Not exposing session IDs in the URL.

• Not exposing session IDs in the URL. <Report Findings Here>

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

• Web application vulnerability security assessments, AND/OR

- Is …

Added p. 104

• Monitored when in use.

• Disabled when not in use.

• Disabled when not in use. <Report Findings Here>

Added p. 107

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.2.1.c For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission.

<Report Findings Here> 8.2.3 Passwords/passphrases must meet the following:

• Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

• A minimum length of at least seven characters. <Report Findings Here>

<Report Findings Here> 8.2.4 Change user passwords/passphrases at least once every 90 days. ☐ ☐ ☐ ☐ ☐ 8.2.4.a For a sample of system components, inspect system configuration Identify the sample of system components selected for this testing procedure.

• Non-consumer customer user passwords/passphrases are required to change periodically; and

• Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.

• Non-consumer customer user passwords/passphrases are required to change periodically; and

• Non-consumer customer …

Added p. 126

• Make, model of device.

• Make, model of device.

• Device serial number or other method of unique identification.

• Frequency of inspections.

• Personnel are aware of procedures for inspecting devices.

• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

• Do not install, replace, or return devices without verification.

• Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

• Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested Place by unknown persons to unplug or open devices).

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

• …

Added p. 134

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

• Implemented. <Report Findings Here>

• Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

• Where there is more than one designated time server, the time servers peer with one another to keep accurate time.

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

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place central time server(s) peer with one another to keep accurate time.

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

<Report Findings Here> 10.4.2.b Examine system …

Added p. 139

• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Identify the responsible personnel interviewed who confirm that the following are reviewed at least daily:

• All security events

• All security events. <Report Findings Here>

• Logs of all critical system components. <Report Findings Here>

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

<Report Findings Here> 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

Added p. 141

• Segmentation controls (if used) Identify the documented policies and procedures examined to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

<Report Findings Here> 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:

Added p. 142

• Performing a risk assessment to determine whether further actions are Identify the documented policies and procedures examined to verify that processes are defined and implemented to respond to a security control failure, and include:

• Resuming monitoring of security controls <Report Findings Here>

• Resuming monitoring of security controls Identify the responsible personnel interviewed who confirm that processes are defined and implemented to respond to a security control failure, and include:

• Resuming monitoring of security controls <Report Findings Here> 10.8.1.b Examine records to verify that security control failures are documented to include:

Added p. 146

• The scan is performed at least quarterly for all system components and facilities.

• The scan was performed by a qualified internal resource <Report Findings Here>

Added p. 153

• At least annually <Report Findings Here> Describe how the scope of work verified that internal penetration testing is performed:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Describe how the segmentation controls verified that segmentation methods:

• Are operational and effective. <Report Findings Here>

• The penetration testing covers all segmentation controls/methods in use.

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

<Report Findings Here> 11.3.4.1 Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

• At the perimeter of the cardholder data environment.

11.5.a Verify the use of a change- detection mechanism by observing system settings and monitored files, as Describe the …

Added p. 162

<Report Findings Here> 12.3.2 Authentication for use of the technology. ☐ ☐ ☐ ☐ ☐

Identify any remote access technologies in use <Report Findings Here> Describe how configurations for remote access technologies verified that remote access sessions will be automatically disconnected after a specific period of inactivity.

• Overall accountability for maintaining PCI DSS compliance

• Monitoring all access to data

• Personnel attend security awareness training: - Upon hire, and

• Upon hire <Report Findings Here>

Added p. 172

• Designate specific personnel to be available on a 24/7 basis to respond to alerts:

• Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum.

• Specific incident response procedures.

• Business recovery and continuity procedures

• Data back-up processes

Added p. 176

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.10.6 Verify through observation, review of policies, and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

Added p. 176

• Change management processes

• Change management processes Identify the policies and procedures examined to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:

• Documenting results of the reviews

• Appendix A1 Additional PCI DSS Requirements for Shared Hosting Providers

• Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS for Card-Present POS POI terminal connections

• All CGI scripts used by an entity must be created and run as the entity’s unique user ID.

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested <Report Findings Here> A1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources:

• Bandwidth For each item in the sample of servers and hosted entities …

Added p. 183

• New POS POI terminal implementations must not use SSL or early TLS as a security control

• All POS POI terminal service providers must provide a secure service offering.

• POS POI terminals in card-present environments that can be verified as not being susceptible to any known exploits for SSL and early TLS, and the SSL/TLS termination points to which they connect, may continue using SSL/early TLS as a security control.

This Appendix only applies to entities using SSL/early TLS as a security control to protect POS POI terminals, including service providers who provide connections into POS POI terminals.

<Report Findings Here> A2.1 Where POS POI terminals (at the merchant or payment acceptance location) use SSL and/or early TLS, the entity must confirm the devices are not susceptible to any known exploits for those protocols.

Note: This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. …

Modified p. 1

PCI DSS ~~v3.2~~ Template for Report on Compliance Revision ~~1.0~~

PCI DSS v3.2.1 Template for Report on Compliance Revision 2

Removed p. 5

 Section 1: Contact Information and Report Date  Section 2: Summary Overview  Section 3: Description of Scope of Work and Approach Taken  Section 4: Details about Reviewed Environment  Section 5: Quarterly Scan Results  Section 6: Findings and Observations

Modified p. 5

Use of this Reporting Template is mandatory for all ~~v3.2~~ submissions.

Use of this Reporting Template is mandatory for all v3.2.1 submissions.

Modified p. 5

The Report on Compliance (ROC) is produced during onsite PCI DSS assessments as part of an entity’s validation process. The ROC provides details about the entity’s environment and assessment methodology, and documents the entity’s compliance status for each PCI DSS Requirement. A PCI DSS compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file …

Modified p. 8

 An organization may be asked by their acquirer to validate a subset of ~~requirements•for~~ example: using the prioritized approach to validate certain milestones.

• An organization may be asked by their acquirer to validate a subset of requirements

•for example: using the prioritized approach to validate certain milestones.

Modified p. 8

 An organization may wish to validate a new security control that impacts only a subset of ~~requirements•for~~ example, implementation of a new encryption methodology that requires assessment of PCI DSS Requirements 2, 3, and 4.

• An organization may wish to validate a new security control that impacts only a subset of requirements

•for example, implementation of a new encryption methodology that requires assessment of PCI DSS Requirements 2, 3, and 4.

Modified p. 8

 A service provider organization might offer a service that covers only a limited number of PCI DSS ~~requirements•for~~ example, a physical storage provider may only wish to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.

• A service provider organization might offer a service that covers only a limited number of PCI DSS requirements

•for example, a physical storage provider may only wish to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.

Modified p. 9

~~ One word (yes/no) Example Reporting Instruction: Indicate whether the assessed entity is an issuer or supports issuing services. (yes/no)  Document name or interviewee job title/reference~~

• In Sections ~~4.10,~~ “Documentation Reviewed,” and ~~4.11,~~ “Individuals Interviewed” below, there is a space for a reference number and it is the QSA’s choice to use the document name/interviewee job title or the reference number at the individual reporting instruction response.

• In Sections 4.9, “Documentation Reviewed,” and 4.10, “Individuals Interviewed” below, there is a space for a reference number and it is the QSA’s choice to use the document name/interviewee job title or the reference number at the individual reporting instruction response.

Modified p. 9

Example Reporting Instruction: Identify the document that defines vendor software development processes. Example Reporting Instruction: Identify the individuals interviewed who confirm that …  Sample description

• For sampling, the QSA must use the table at “Sample sets for reporting” in the Details about Reviewed Environment section of this document to fully report the sampling, but it is the QSA’s choice to use the Sample set reference number (“Sample Set-5”) or list out the items from the sample again at the …

• For sampling, the QSA must use the table at “Sample sets for reporting” in the Details about Reviewed Environment section of this document to fully report the sampling, but it is the QSA’s choice to use the Sample set reference number (“Sample Set-5”) or list out the items from the sample again at the individual reporting instruction response. If sampling is not used, then the types of components that were tested must still be identified in Section 6 Findings …

Modified p. 9

~~ Brief description/short answer~~

• Short and to the point, but provide detail and individual content that is not simply an echoing of the testing procedure or reporting instruction nor a template answer used from report-to-report, but instead relevant and specific to the assessed entity. These responses must include unique details, such as the specific system configurations reviewed (to include what the assessor observed in the

• Short and to the point, but provide detail and individual content that is not simply an echoing of the testing procedure or reporting instruction nor a template answer used from report-to-report, but instead relevant and specific to the assessed entity. These responses must include unique details, such as the specific system configurations reviewed (to include what the assessor observed in the configurations) and specific processes observed (to include a summary of what was witnessed and how that verified the …

Removed p. 10

Dependence on another service provider’s compliance where the service providers is compliant with PCI DSS v3.1, but the entity is being assessed against PCI DSS v3.2:

Removed p. 10

 The requirement and/or testing procedure exists in both standards, in which case the response noted above would likely be sufficient. Noting that the service provider is compliant with 3.1 of the PCI DSS in the response is worthwhile to address any possible changes to requirements or testing procedures. As noted above, future-dated requirements are considered Not Applicable until the future date has passed. Until that date, an acceptable answer for the accompanying “not applicable” finding might be something like: “Not Applicable, as this is a future-dated requirement. Assessor verified this is the responsibility of Service Provider X, as verified through review of x/y contract (document). Assessor reviewed the AOC for Service Provider X, dated 1/12/2015, and confirmed the SP is compliant with v3.1 of the PCI DSS.” Refer to the FAQs on the PCI SSC website at https://www.pcisecuritystandards.org/faq/ for more information.

Modified p. 10

“Assessor verified this is the responsibility of Service Provider X, as verified through review of x/y contract (document). Assessor reviewed the AOC for Service Provider X, dated MM/DD/YYYY, and confirmed the service provider was found to be PCI DSS compliant against PCI DSS ~~v3.1 (or PCI DSS v3.2)~~ for all applicable requirements, and that it covers the scope of the services used by the assessed entity.” That response could vary, but what’s important is that it is noted as “in …

“Assessor verified this is the responsibility of Service Provider X, as verified through review of x/y contract (document). Assessor reviewed the AOC for Service Provider X, dated MM/DD/YYYY, and confirmed the service provider was found to be PCI DSS compliant against PCI DSS v3.2.1 for all applicable requirements, and that it covers the scope of the services used by the assessed entity.” That response could vary, but what’s important is that it is noted as “in place” and that there …

Modified p. 11

 Use this Reporting Template when assessing against ~~v3.2~~ of the PCI DSS.

• Use this Reporting Template when assessing against v3.2.1 of the PCI DSS.

Modified p. 11

 Complete all sections in the order specified.

• Complete all sections in the order specified.

Modified p. 11

 Read and understand the intent of each Requirement and Testing Procedure.

• Read and understand the intent of each Requirement and Testing Procedure.

Modified p. 11

 Provide a response for every Testing Procedure.

• Provide a response for every Testing Procedure.

Modified p. 11

 Provide sufficient detail and information to support the designated finding, but be concise.

• Provide sufficient detail and information to support the designated finding, but be concise.

Modified p. 11

 Describe how a Requirement ~~was verified~~ per the Reporting Instruction, not just that it was verified.

• Describe how a Requirement is in place per the Reporting Instruction, not just that it was verified.

Modified p. 11

 Ensure the parts of the Testing Procedure and Reporting Instruction are addressed.

• Ensure the parts of the Testing Procedure and Reporting Instruction are addressed.

Modified p. 11

 Ensure the response covers all applicable system components.

• Ensure the response covers all applicable system components.

Modified p. 11

 Perform an internal quality assurance review of the ROC for clarity, accuracy, and quality.

• Perform an internal quality assurance review of the ROC for clarity, accuracy, and quality.

Modified p. 11

 Provide useful, meaningful diagrams, as directed.

• Provide useful, meaningful diagrams, as directed.

Modified p. 11

 Don’t report items in the “In Place” column unless they have been verified as being “in place” as stated.

• Don’t report items in the “In Place” column unless they have been verified as being “in place” as stated.

Modified p. 11

 Don’t include forward-looking statements or project plans in the “In Place” assessor response.

• Don’t include forward-looking statements or project plans in the “In Place” assessor response.

Modified p. 11

 Don’t simply repeat or echo the Testing Procedure in the response.

• Don’t simply repeat or echo the Testing Procedure in the response.

Modified p. 11

 Don’t copy responses from one Testing Procedure to another.

• Don’t copy responses from one Testing Procedure to another.

Modified p. 11

 Don’t copy responses from previous assessments.

• Don’t copy responses from previous assessments.

Modified p. 11

 Don’t include information irrelevant to the assessment.

• Don’t include information irrelevant to the assessment.

Modified p. 11

 Don’t leave any spaces blank. If a section does not apply, annotate it as such.

• Don’t leave any spaces blank. If a section does not apply, annotate it as such.

Removed p. 12

Assessor Quality Assurance (QA) Primary Reviewer for this specific report (not the general QA contact for the QSA)  QA reviewer name:

 QA reviewer e-mail address:

Modified p. 12

1. Contact Information and Report Date 1.1 Contact information ~~ Company name:~~

1. Contact Information and Report Date 1.1 Contact information

Modified p. 12

 Company contact name:

• Company contact name:

Modified p. 12

 Contact phone number:

• Contact phone number:

Modified p. 12

 Contact e-mail address:

• Contact e-mail address:

Modified p. 12

Assessor ~~Company  Company name:~~

• Assessor phone number:

Modified p. 12

 Assessor PCI credentials:

• Assessor PCI credentials:

Modified p. 12

 Assessor e-mail address:

• Assessor e-mail address:

Modified p. 12 → 13

~~(QSA, PA-QSA, etc.)  Assessor~~ phone number:

• QA reviewer phone number:

Modified p. 12 → 13

 QA reviewer ~~phone number:~~

• QA reviewer e-mail address:

Modified p. 13

 Timeframe of assessment (start date to completion date):

• Timeframe of assessment (start date to completion date):

Modified p. 13

 Identify date(s) spent onsite at the entity:

• Identify date(s) spent onsite at the entity:

Modified p. 13

 Describe the time spent onsite at the entity, time spent performing remote assessment activities and time spent on validation of remediation activities.

• Describe the time spent onsite at the entity, time spent performing remote assessment activities and time spent on validation of remediation activities.

Modified p. 13

 Disclose all services offered to the assessed entity by the QSAC, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

• Disclose all services offered to the assessed entity by the QSAC, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

Modified p. 13

 Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the QSAC:

• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the QSAC:

Modified p. 14

PCI DSS Requirement Summary of Findings (check one) Compliant ~~Non Compliant~~ Not Applicable

PCI DSS Requirement Summary of Findings (check one) Compliant Non-Compliant Not Applicable Not Tested

Modified p. 14

1. Install and maintain a firewall configuration to protect cardholder data ☐ ☐ ☐

1. Install and maintain a firewall configuration to protect cardholder data ☐ ☐ ☐ ☐

Modified p. 14

2. Do not use vendor-supplied defaults for system passwords and other security parameters ☐ ☐ ☐

2. Do not use vendor-supplied defaults for system passwords and other security parameters ☐ ☐ ☐ ☐

Modified p. 14

3. Protect stored cardholder data ☐ ☐ ☐

3. Protect stored cardholder data ☐ ☐ ☐ ☐

Modified p. 14

4. Encrypt transmission of cardholder data across open, public networks ☐ ☐ ☐

4. Encrypt transmission of cardholder data across open, public networks ☐ ☐ ☐ ☐

Modified p. 14

5. Protect all systems against malware and regularly update anti-virus software or programs ☐ ☐ ☐

5. Protect all systems against malware and regularly update anti-virus software or programs ☐ ☐ ☐ ☐

Modified p. 14

6. Develop and maintain secure systems and applications ☐ ☐ ☐

6. Develop and maintain secure systems and applications ☐ ☐ ☐ ☐

Modified p. 14

7. Restrict access to cardholder data by business need to know ☐ ☐ ☐

7. Restrict access to cardholder data by business need to know ☐ ☐ ☐ ☐

Modified p. 14

8. Identify and authenticate access to system components ☐ ☐ ☐

8. Identify and authenticate access to system components ☐ ☐ ☐ ☐

Modified p. 14

9. Restrict physical access to cardholder data ☐ ☐ ☐

9. Restrict physical access to cardholder data ☐ ☐ ☐ ☐

Modified p. 14

10. Track and monitor all access to network resources and cardholder data ☐ ☐ ☐

10. Track and monitor all access to network resources and cardholder data ☐ ☐ ☐ ☐

Modified p. 14

11. Regularly test security systems and processes ☐ ☐ ☐

11. Regularly test security systems and processes ☐ ☐ ☐ ☐

Modified p. 15

 Describe the nature of the entity’s business (what kind of work they do, etc.)

• Describe the nature of the entity’s business (what kind of work they do, etc.)

Modified p. 15

 Describe how the entity stores, processes, and/or transmits cardholder data.

• Describe how the entity stores, processes, and/or transmits cardholder data.

Modified p. 15

 Describe why the entity stores, processes, and/or transmits cardholder data.

• Describe why the entity stores, processes, and/or transmits cardholder data.

Modified p. 15

 Identify the types of payment channels the entity serves, such as card-present and card-not-present (for example, mail order/telephone order (MOTO), e- commerce).

• Identify the types of payment channels the entity serves, such as card-present and card-not-present (for example, mail order/telephone order (MOTO), e- commerce).

Modified p. 15

 Other details, if applicable:

• Other details, if applicable:

Modified p. 15

 Connections into and out of the network including demarcation points between the cardholder data environment (CDE) and other networks/zones ~~ Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as applicable  Other necessary payment components, as applicable~~

• Connections into and out of the network including demarcation points between the cardholder data environment (CDE) and other networks/zones

Modified p. 17

As noted in PCI DSS, ~~v3.2~~

• “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or if compromised could impact the CDE (e.g. authentication servers) to ensure they are included in the PCI DSS scope.” Note

• additional reporting has been added below to emphasize systems that are connected to or if …

As noted in PCI DSS, v3.2.1

• “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or if compromised could impact the CDE (e.g. authentication servers) to ensure they are included in the PCI DSS scope.” Note

• additional reporting has been added below to emphasize systems that are connected to or if …

Modified p. 17

 Describe the methods or processes (for example, the specific types of tools, observations, feedback, scans, data flow analysis) used to identify and document all existences of cardholder data (as executed by the assessed entity, assessor or a combination):

• Describe the methods or processes (for example, the specific types of tools, observations, feedback, scans, data flow analysis) used to identify and document all existences of cardholder data (as executed by the assessed entity, assessor or a combination):

Modified p. 17

 Describe the methods or processes (for example, the specific types of tools, observations, feedback, scans, data flow analysis) used to verify that no cardholder data exists outside of the defined CDE (as executed by the assessed entity, assessor or a combination):

• Describe the methods or processes (for example, the specific types of tools, observations, feedback, scans, data flow analysis) used to verify that no cardholder data exists outside of the defined CDE (as executed by the assessed entity, assessor or a combination):

Modified p. 17

 Describe how the results of the methods/processes were documented (for example, the results may be a diagram or an inventory of cardholder data locations):

• Describe how the results of the methods/processes were documented (for example, the results may be a diagram or an inventory of cardholder data locations):

Modified p. 17

 Describe how the results of the methods/processes were evaluated by the assessor to verify that the PCI DSS scope of review is appropriate:

• Describe how the results of the methods/processes were evaluated by the assessor to verify that the PCI DSS scope of review is appropriate:

Modified p. 17

 Describe why the methods (for example, tools, observations, feedback, scans, data flow ~~analysis)~~ used for scope verification are considered by the assessor to be effective and accurate:

• Describe why the methods (for example, tools, observations, feedback, scans, data flow analysis, or any environment design decisions that were made to help limit the scope of the environment) used for scope verification are considered by the assessor to be effective and accurate:

Modified p. 17

 Provide the name of the assessor who attests that the defined CDE and scope of the assessment has been verified to be accurate, to the best of the assessor’s ability and with all due diligence:

• Provide the name of the assessor who attests that the defined CDE and scope of the assessment has been verified to be accurate, to the best of the assessor’s ability and with all due diligence:

Modified p. 17 → 18

~~ People~~

• such as technical support, management, administrators, operations teams, cashiers, telephone operators, etc.:

• such as technical support, management, administrators, operations teams, cashiers, telephone operators, physical security, etc.:

Modified p. 18

 Other details, if applicable:

• Other details, if applicable:

Modified p. 18

~~ Technologies~~

• such as e-commerce systems, internal network segments, DMZ segments, processor connections, POS systems, etc.:

• such as e-commerce systems, internal network segments, DMZ segments, processor connections, POS systems, encryption mechanisms, etc.:

Modified p. 18

 Note

• this is not intended to be a list of devices but instead a list of the types of technologies, purposes, functions, etc. included in the scope.

Note

• this is not intended to be a list of devices but instead a list of the types of technologies, purposes, functions, etc. included in the scope.

Modified p. 18

~~ Locations/sites/stores~~

• such as retail outlets, data centers, corporate office locations, call centers, etc.:

• such as retail outlets, data centers, corporate office locations, call centers, etc.:

Modified p. 18

 If segmentation is used: Briefly describe how the segmentation is implemented.

• If segmentation is used: Briefly describe how the segmentation is implemented.

Modified p. 18

 Identify the technologies used and any supporting processes  Explain how the assessor validated the effectiveness of the segmentation, as follows:

− Identify the technologies used and any supporting processes − Explain how the assessor validated the effectiveness of the segmentation, as follows:

Modified p. 18

- Describe how it was verified that the segmentation is functioning as ~~intended.~~

- Describe how it was verified that the segmentation is functioning as

Modified p. 18 → 19

- Describe how it was verified that the identified security controls are in place.

- Describe how it was verified that the identified security controls are in Note

• the response must go beyond listing the activities that the assessor performed and must provide specific details of what the assessor observed to get the level of assurance that the identified security controls are in place.

Modified p. 18 → 19

 Provide the name of the assessor who attests that the segmentation was verified to be adequate to reduce the scope of the assessment AND that the technologies/processes used to implement segmentation were included in the PCI DSS assessment.

• Provide the name of the assessor who attests that the segmentation was verified to be adequate to reduce the scope of the assessment AND that the technologies/processes used to implement segmentation were included in the PCI DSS assessment.

Modified p. 20 → 21

Description of any discussions/issues between the QSA and Processing Entity on behalf of the Assessed Entity for this PCI DSS Assessment (if any) Processing Transmission ~~ Other details, if applicable (add content or tables here for brand/acquirer use, if needed):~~

Description of any discussions/issues between the QSA and Processing Entity on behalf of the Assessed Entity for this PCI DSS Assessment (if any) Processing Transmission

Modified p. 21 → 22

 If ~~there are~~ wireless ~~networks or technologies~~ in ~~use, identify and describe all wireless technologies in use that are~~ connected to or could impact the security of the cardholder data ~~environment. This would include:~~

If “yes,” indicate whether wireless is in scope (i.e. part of the CDE, connected to or could impact the security of the cardholder data environment), (yes/no):

Modified p. 21 → 22

 Wireless LANs  Wireless payment applications (for example, POS terminals)  All other wireless devices/technologies 3.8 Wireless details For each wireless technology in scope, identify the following:

− Wireless LANs − Wireless payment applications (for example, POS terminals) − All other wireless devices/technologies 3.8 Wireless details For each wireless technology in scope, identify the following:

Removed p. 22

<Insert optional data-flow diagram(s)> Cardholder data flows Types of CHD involved (for example, full track, PAN, expiry) Describe how cardholder data is transmitted and/or processed and for what purpose it is used Authorization

Modified p. 22 → 24

 All boundaries of the cardholder data environment  Any network segmentation points which are used to reduce scope of the assessment  Boundaries between trusted and untrusted networks  Wireless and wired networks  All other connection points applicable to the assessment Ensure the diagram(s) include enough detail to clearly understand how each communication point functions and is secured. (For example, the level of detail may include identifying the types of devices, device interfaces, network technologies, protocols, and security …

• All other connection points applicable to the assessment Ensure the diagram(s) include enough detail to clearly understand how each communication point functions and is secured. (For example, the level of detail may include identifying the types of devices, device interfaces, network technologies, protocols, and security controls applicable to that communication point.) <Insert detailed diagram(s)> 4.2 Description of cardholder data flows

Modified p. 24 → 26

 If sampling is not used:

• If sampling is not used:

Modified p. 24 → 26

 Provide the name of the assessor who attests that every system component and all business facilities have been assessed.

− Provide the name of the assessor who attests that every system component and all business facilities have been assessed.

Modified p. 24 → 26

 If sampling is used:

• If sampling is used:

Modified p. 24 → 26

 Provide the name of the assessor who attests that all sample sets used for this assessment are represented in the below “Sample sets for reporting” table. Examples may include, but are not limited to firewalls, application servers, retail locations, data centers, User IDs, people, etc.

− Provide the name of the assessor who attests that all sample sets used for this assessment are represented in the below “Sample sets for reporting” table. Examples may include, but are not limited to firewalls, application servers, retail locations, data centers, User IDs, people, etc.

Modified p. 24 → 27

 If standardized PCI DSS security and operational processes/controls were used for selecting sample sizes, describe how they were validated by the assessor.

− If standardized PCI DSS security and operational processes/controls were used for selecting sample sizes, describe how they were validated by the assessor.

Modified p. 25 → 27

Sample Set Sample Type/ Description (e.g., firewalls, datacenters, change records, User IDs, etc.) Listing of all items (devices, locations, change records, people, etc.) in the Sample Make/Model of Components ~~(as applicable)~~ Total Sampled Total Population Sample Set-1 Sample Set-2 Sample Set-3 Sample Set-4 ~~4.7 Service providers and other third parties with which the entity shares cardholder data or that could affect the security of cardholder data For each service provider or third party, provide:~~

Sample Set Sample Type/ Description (e.g., firewalls, datacenters, change records, User IDs, etc.) Listing of all items (devices, locations, change records, people, etc.) in the Sample Set Make/Model of Hardware Components or Version/Release of Software Components Total Sampled Total Population Sample Set-1 Sample Set-2 Sample Set-3 Sample Set-4

Modified p. 26 → 28

Note: Homegrown payment applications/solutions must be reported at the ~~sections~~ for Critical Hardware and Critical Software. It is also strongly suggested to address such homegrown payment applications/solutions below at “Any additional comments or findings” in order to represent all payment applications in the assessed environment in this table.

Note: Homegrown payment applications/solutions must be reported at the section for Critical Hardware and Critical Software. It is also strongly suggested to address such homegrown payment applications/solutions below at “Any additional comments or findings” in order to represent all payment applications in the assessed environment in this table.

Modified p. 26 → 29

PCI SSC listing reference number Expiry date of listing, if applicable  Provide the name of the assessor who attests that all PA-DSS validated payment applications were reviewed to verify they have been implemented in a PCI DSS compliant manner according to the payment application vendor’s PA-DSS Implementation Guide  Provide the name of the assessor who attests that all PCI SSC-validated P2PE applications and solutions were reviewed to verify they have been implemented in a PCI DSS compliant manner …

• Provide the name of the assessor who attests that all PCI SSC-validated P2PE applications and solutions were reviewed to verify they have been implemented in a PCI DSS compliant manner according to the P2PE application vendor’s P2PE Application Implementation Guide and the P2PE solution vendor’s P2PE Instruction Manual (PIM).

Modified p. 26 → 29

 For any of the above Third-Party Payment Applications and/or solutions that are not listed on the PCI SSC website, identify any being considered for scope reduction/exclusion/etc.

• For any of the above Third-Party Payment Applications and/or solutions that are not listed on the PCI SSC website, identify any being considered for scope reduction/exclusion/etc.

Modified p. 27 → 28

PCI SSC listing reference number Expiry date of listing, if applicable ~~ Any additional comments or findings the assessor would like to include, as applicable:~~

PCI SSC listing reference number Expiry date of listing, if applicable

Removed p. 28

List of all requirements/testing procedures with this result Summary of the issue (for example, not deemed in scope for the assessment, reliance on a third-party service provider who is compliant to PCI DSS v3.1 and hasn’t yet assessed against 3.2, etc.)

Modified p. 28 → 30

 List the requirements that apply to the MSP and are included in this assessment.

− List the requirements that apply to the MSP and are included in this assessment.

Modified p. 28 → 30

 List the requirements that are the responsibility of the MSP’s customers (and have not been included in this assessment).

− List the requirements that are the responsibility of the MSP’s customers (and have not been included in this assessment).

Modified p. 28 → 30

 Provide the name of the assessor who attests that the testing of these requirements and/or responsibilities of the MSP is accurately represented in the signed Attestation of Compliance.

− Provide the name of the assessor who attests that the testing of these requirements and/or responsibilities of the MSP is accurately represented in the signed Attestation of Compliance.

Modified p. 28 → 30

 Identify which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans.

− Identify which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans.

Modified p. 28 → 30

 Identify which of the MSP’s IP addresses are the responsibility of the MSP’s customers.

− Identify which of the MSP’s IP addresses are the responsibility of the MSP’s customers.

Modified p. 28 → 30

List of all requirements/testing procedures with this result Summary of the issue (legal obligation, etc.) 4.13 Disclosure summary for “Not Tested” responses ~~ Identify whether there were any responses indicated as “Not Tested”: (yes/no)  If “yes,” complete the table below:~~

List of all requirements/testing procedures with this result Summary of the issue (legal obligation, etc.) 4.13 Disclosure summary for “Not Tested” responses

Modified p. 30 → 32

~~5. Quarterly Scan Results 5.1 Quarterly scan results  Is this the assessed entity’s initial PCI DSS compliance validation? (yes/no) ~~ Identify how many external quarterly ASV scans were performed within the last 12 months:

• Identify how many external quarterly ASV scans were performed within the last 12 months:

Modified p. 30 → 32

 Summarize the four most recent quarterly ASV scan results in the Summary Overview as well as in comments at Requirement 11.2.2.

• Summarize the four most recent quarterly ASV scan results in the Summary Overview as well as in comments at Requirement 11.2.2.

Modified p. 30 → 32

Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:  The most recent scan result was a passing scan,  The entity has documented policies and procedures requiring quarterly scanning going forward, and  Any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.

Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:

Modified p. 30 → 32

 For each quarterly ASV scan performed within the last 12 months, identify:

• For each quarterly ASV scan performed within the last 12 months, identify:

Modified p. 30 → 32

 Provide the name of the assessor who attests that the most recent scan result was verified to be a passing scan.

• Provide the name of the assessor who attests that the most recent scan result was verified to be a passing scan.

Modified p. 30 → 32

 Identify the name of the document the assessor verified to include the entity’s documented policies and procedures requiring quarterly scanning going forward.

• Identify the name of the document the assessor verified to include the entity’s documented policies and procedures requiring quarterly scanning going forward.

Modified p. 30 → 32

 Describe how the assessor verified that any vulnerabilities noted in the initial scan have been corrected, as shown in a re-scan.

• Describe how the assessor verified that any vulnerabilities noted in the initial scan have been corrected, as shown in a re-scan.

Modified p. 32 → 34

~~ Network connections, and ~~ Changes to firewall and router configurations.

• Changes to firewall and router configurations.

Modified p. 32 → 34

~~ Testing and approval of all network connections. <Report Findings Here> ~~ Testing and approval of all changes to firewall and router configurations.

• Testing and approval of all changes to firewall and router configurations.

Modified p. 32 → 34

~~ Approved <Report Findings Here> ~~ Tested <Report Findings Here> 1.1.1.c Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested.

• Tested <Report Findings Here> 1.1.1.c Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested.

Removed p. 33

 At each Internet connection.

Modified p. 33 → 35

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested  Approved <Report Findings Here>  Tested <Report Findings Here> 1.1.2 Current diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks. ☐ ☐ ☐ ☐ ☐ 1.1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections …

• Tested <Report Findings Here> 1.1.2 Current diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks. ☐ ☐ ☐ ☐ ☐ 1.1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to the cardholder data environment, including any wireless networks.

Modified p. 33 → 35

~~ Is current. <Report Findings Here>  Includes all connections to cardholder data. <Report Findings Here> ~~ Includes any wireless network connections. <Report Findings Here> 1.1.2.b Interview responsible personnel to verify that the diagram is kept current.

• Includes any wireless network connections. <Report Findings Here> 1.1.2.b Interview responsible personnel to verify that the diagram is kept current.

Modified p. 33 → 35

 Shows all cardholder data flows across systems and networks.  Is kept current and updated as needed upon changes to the environment.

• Shows all cardholder data flows across systems and networks. • Is kept current and updated as needed upon changes to the environment.

Modified p. 33 → 35

 Shows all cardholder data flows across systems and networks.  Is kept current and updated as needed upon changes to the environment.

• Shows all cardholder data flows across systems and networks. • Is kept current and updated as needed upon changes to the environment.

Modified p. 33 → 35

Identify the firewall configuration standards document examined to verify requirements for a firewall:

Identify the firewall configuration standards document examined to verify requirements for a firewall: • At each Internet connection.

Modified p. 33 → 35

 Between any DMZ and the internal network zone.

• Between any DMZ and the internal network zone.

Modified p. 34 → 36

~~ At each Internet connection. <Report Findings Here> ~~ Between any DMZ and the internal network zone. <Report Findings Here> 1.1.5 Description of groups, roles, and responsibilities for management of network components. ☐ ☐ ☐ ☐ ☐ 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

• Between any DMZ and the internal network zone. <Report Findings Here> 1.1.5 Description of groups, roles, and responsibilities for management of network components. ☐ ☐ ☐ ☐ ☐ 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

Modified p. 36 → 38

~~ Inbound traffic <Report Findings Here> ~~ Outbound traffic <Report Findings Here> 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

• Outbound traffic <Report Findings Here> 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

Modified p. 36 → 38

~~ All other inbound traffic <Report Findings Here> ~~ All other outbound traffic <Report Findings Here> 1.2.2 Secure and synchronize router configuration files. ☐ ☐ ☐ ☐ ☐ 1.2.2.a Examine router configuration files to verify they are secured from unauthorized access.

• All other outbound traffic <Report Findings Here> 1.2.2 Secure and synchronize router configuration files. ☐ ☐ ☐ ☐ ☐ 1.2.2.a Examine router configuration files to verify they are secured from unauthorized access.

Modified p. 39 → 41

Note: Methods to obscure IP addressing may include, but are not limited to:  Network Address Translation (NAT),  Placing servers containing cardholder data behind proxy servers/firewalls,  Removal or filtering of route advertisements for private networks that employ registered addressing,  Internal use of RFC1918 address space instead of registered addresses.

Note: Methods to obscure IP addressing may include, but are not limited to: • Network Address Translation (NAT), • Placing servers containing cardholder data behind proxy servers/firewalls, • Removal or filtering of route advertisements for private networks that employ registered addressing, • Internal use of RFC1918 address space instead of registered addresses.

Modified p. 39 → 41

 Specific configuration settings are defined.

• Specific configuration settings are defined.

Modified p. 39 → 41

 Personal firewall (or equivalent functionality) is actively running.

• Personal firewall (or equivalent functionality) is actively running.

Modified p. 39 → 41

 Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.

• Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.

Modified p. 40 → 42

 Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network, (for example, laptops used by employees), and which are also used to access the CDE.

• Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network, (for example, laptops used by employees), and which are also used to access the CDE.

Modified p. 40 → 42

 Specific configuration settings are defined for personal firewall or equivalent functionality.

• Specific configuration settings are defined for personal firewall or equivalent functionality.

Modified p. 40 → 42

 Specific configuration settings are defined for personal firewall or equivalent functionality.

• Specific configuration settings are defined for personal firewall or equivalent functionality.

Modified p. 40 → 42

 Personal firewall or equivalent functionality is configured to actively run.

• Personal firewall or equivalent functionality is configured to actively run.

Modified p. 40 → 42

 Personal firewall or equivalent functionality is configured to actively run.

• Personal firewall or equivalent functionality is configured to actively run.

Modified p. 40 → 42

 Personal firewall or equivalent functionality is configured to not be alterable by users of the portable computing devices.

• Personal firewall or equivalent functionality is configured to not be alterable by users of the portable computing devices.

Modified p. 40 → 42

 Personal firewall or equivalent functionality is configured to not be alterable by users of the portable computing devices.

• Personal firewall or equivalent functionality is configured to not be alterable by users of the portable computing devices.

Modified p. 40 → 42

 Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or ~~employee-owned)~~ that connect to the Internet when outside the network, (for example, laptops used by employees), and which are also used to access the CDE.

• Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or employee- owned) that connect to the Internet when outside the network, (for example, laptops used by employees), and which are also used to access the CDE.

Removed p. 41

 Personal firewall (or equivalent functionality) is actively running.

 Personal firewall or equivalent functionality is not alterable by users of the portable computing devices.

Modified p. 41 → 42

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 1.4.b Inspect a sample of portable computing devices (including company and/or ~~employee-owned)to~~ verify that:

<Report Findings Here> 1.4.b Inspect a sample of portable computing devices (including company and/or employee-owned) to verify that:

Modified p. 41 → 42

 Personal firewall (or equivalent functionality) is installed and ~~configured per~~ the ~~organization’s specific configuration settings.~~

• Personal firewall (or equivalent functionality) is installed and Identify the sample of mobile and/or employee- owned devices selected for this testing procedure.

Modified p. 41 → 42

 Installed and configured per the organization’s specific configuration settings.

• Installed and configured per the organization’s specific configuration settings.

Modified p. 41 → 43

~~<Report Findings Here>  Actively running. <Report Findings Here> ~~ Not alterable by users of mobile and/or employee- owned devices.

• Not alterable by users of mobile and/or employee- owned devices.

Modified p. 42 → 44

~~ Removed <Report Findings Here> ~~ Disabled <Report Findings Here>

• Disabled <Report Findings Here>

Modified p. 43 → 45

 All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.

Modified p. 43 → 45

 All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.

Modified p. 43 → 45

 All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, ~~etc.)~~ are changed before a system is installed on the network.

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc. are changed before a system is installed on the network.

Removed p. 44

 From default at installation  Anytime anyone with knowledge of the keys leaves the company or changes positions.

Modified p. 44 → 45

Indicate whether there are wireless environments connected to the cardholder data environment or transmitting cardholder data. (yes/no) If “no,” mark 2.1.1 as “Not Applicable” and proceed to 2.2.

• Encryption keys were changed from default at installation Indicate whether there are wireless environments connected to the cardholder data environment or transmitting cardholder data. (yes/no) If “no,” mark 2.1.1 as “Not Applicable” and proceed to 2.2.

Modified p. 44 → 46

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~2.1.1.a Interview responsible personnel and examine supporting documentation to verify that:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place

• Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.

Modified p. 44 → 46

~~ Encryption keys were changed from default at installation  Encryption keys are changed anytime~~ anyone with knowledge of the keys leaves the company or changes positions.

• Anytime anyone with knowledge of the keys leaves the company or changes positions.

Modified p. 44 → 46

~~<Report Findings Here>~~ Identify the responsible personnel interviewed who verify that encryption keys are changed:

Identify the responsible personnel interviewed who verify that encryption keys are changed:

Modified p. 44 → 46

 Encryption keys were changed from default at installation Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.

• Encryption keys were changed from default at installation • Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.

Modified p. 44 → 46

 Default SNMP community strings are required to be changed upon installation.  Default passwords/phrases on access points are required to be changed upon installation.

• Default SNMP community strings are required to be changed upon installation. • Default passwords/phrases on access points are required to be changed upon installation.

Modified p. 44 → 46

 Default SNMP community strings are required to be changed upon installation.

• Default SNMP community strings are required to be changed upon installation.

Modified p. 44 → 46

 Default SNMP community strings are required to be changed upon installation.

• Default SNMP community strings are required to be changed upon installation.

Modified p. 44 → 46

 Default passwords/passphrases on access points are required to be changed upon installation.

• Default passwords/passphrases on access points are required to be changed upon installation.

Modified p. 44 → 46

 Default passwords/phrases on access points are required to be changed upon installation.

• Default passwords/phrases on access points are required to be changed upon installation.

Modified p. 45 → 46

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 2.1.1.c Examine vendor documentation and login to wireless devices, with system administrator help, to verify:

<Report Findings Here> 2.1.1.c Examine vendor documentation and login to wireless devices, with system administrator help, to verify:

Modified p. 45 → 46

 Default SNMP community strings are not used.  Default passwords/passphrases on access points are not used.

• Default SNMP community strings are not used. • Default passwords/passphrases on access points are not used.

Modified p. 45 → 46

~~ Default SNMP community strings are not used. ~~ Default passwords/passphrases on access points are not used.

• Default passwords/passphrases on access points are not used.

Modified p. 45 → 46

 Default SNMP community strings are not used. <Report Findings Here> ~~ Default passwords/passphrases on access points are not used.~~

• Default SNMP community strings are not used. <Report Findings Here>

Modified p. 45 → 47

~~ Authentication over wireless networks ~~ Transmission over wireless networks Identify vendor documentation examined to verify firmware on wireless devices is updated to support strong encryption for:

• Transmission over wireless networks Identify vendor documentation examined to verify firmware on wireless devices is updated to support strong encryption for:

Modified p. 45 → 47

~~ Authentication over wireless networks ~~ Transmission over wireless networks <Report Findings Here> Describe how wireless configuration settings verified that firmware on wireless devices is updated to support strong encryption for:

• Transmission over wireless networks <Report Findings Here> Describe how wireless configuration settings verified that firmware on wireless devices is updated to support strong encryption for:

Modified p. 45 → 47

~~ Authentication over wireless networks. <Report Findings Here> ~~ Transmission over wireless networks. <Report Findings Here> 2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

• Transmission over wireless networks. <Report Findings Here> 2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

Removed p. 46

<Report Findings Here> Provide the name of the assessor who attests that the system configuration standards are consistent with industry-accepted hardening standards.

Modified p. 46 → 47

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

<Report Findings Here> 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Modified p. 46 → 47

~~ Center for Internet Security (CIS)  International Organization for Standardization (ISO)  SysAdmin Audit Network Security (SANS) Institute ~~ National Institute of Standards Technology (NIST) 2.2.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards.

• National Institute of Standards Technology (NIST) 2.2.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent Identify the documented system configuration standards for all types of system components examined to verify the system configuration standards are consistent with industry-accepted hardening standards.

Modified p. 46 → 48

~~Identify~~ the ~~documented system configuration standards for all types~~ of ~~system components examined to verify~~ the system configuration standards are consistent with industry-accepted hardening standards.

Provide the name of the assessor who attests that the system configuration standards are consistent with industry-accepted hardening standards.

Modified p. 46 → 48

<Report Findings Here> Identify the policy documentation examined to verify it defines that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network <Report Findings Here> 2.2.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

<Report Findings Here> 2.2.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

Modified p. 46 → 48

Identify the responsible personnel interviewed who confirm that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

Identify the policy documentation examined to verify it defines that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network <Report Findings Here> Identify the responsible personnel interviewed who confirm that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

Removed p. 47

 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 co-existing 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 Identify the system configuration standards for all types of system components that include the following procedures:

Modified p. 47 → 49

 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 co-existing 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 …

• Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers <Report Findings Here> 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

Modified p. 47 → 49

2.2.1.a Select a sample of system components and inspect the system ~~Identify the sample of system components selected for this testing procedure.~~

2.2.1.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.

Modified p. 48 → 49

For each item in the sample, describe how system configurations verified that only one primary function per server is implemented.

<Report Findings Here> For each item in the sample, describe how system configurations verified that only one primary function per server is implemented.

Modified p. 48 → 49

<Report Findings Here> 2.2.1.b If virtualization technologies are used, inspect the system configurations to ~~verify that only one primary function is implemented per virtual system component or device.~~

<Report Findings Here> 2.2.1.b If virtualization technologies are used, inspect the system configurations to Indicate whether virtualization technologies are used. (yes/no) <Report Findings Here>

Modified p. 48 → 50

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~configurations to~~ verify that only one primary function is implemented per ~~server.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place verify that only one primary function is implemented per virtual system component or device.

Modified p. 48 → 50

~~Indicate whether virtualization technologies are used. (yes/no) <Report Findings Here>~~ If “no,” describe how systems were observed to verify that no virtualization technologies are used.

If “no,” describe how systems were observed to verify that no virtualization technologies are used.

Modified p. 48 → 50

For each item in the sample of system components from 2.2.2.a, indicate whether any insecure services, daemons, or protocols are enabled. (yes/no) If “no,” mark the remainder of 2.2.2.b and 2.2.3 as “Not Applicable.” <Report Findings Here> If “yes,” identify the responsible personnel interviewed who confirm that a documented business justification was present for each insecure service, daemon, or protocol <Report Findings Here>

For each item in the sample of system components from 2.2.2.a, indicate whether any insecure services, daemons, or protocols are enabled. (yes/no) If “no,” mark the remainder of 2.2.2.b and 2.2.3 as “Not Applicable.” <Report Findings Here> If “yes,” identify the responsible personnel interviewed who confirm that a documented business justification was present for each insecure service, daemon, or protocol <Report Findings Here> 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be …

Removed p. 49

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure

Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed.

2.2.3.a Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols.

 Documented <Report Findings Here>  Implemented <Report Findings Here> 2.2.3.b If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.

Indicate whether SSL/early TLS is used. (yes/no) If ‘no,’ mark the remainder of 2.2.3.b as ‘not applicable.’ <Report Findings Here> If ‘yes,’ provide the name of the assessor who attests that the testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS …

Modified p. 49 → 51

<Report Findings Here> 2.2.4 Configure system security parameters to prevent misuse. ☐ ☐ ☐ ☐ ☐ 2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

• Implemented <Report Findings Here> 2.2.4 Configure system security parameters to prevent misuse. ☐ ☐ ☐ ☐ ☐ 2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

Removed p. 50

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. ☐ ☐ ☐ ☐ ☐ 2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed. ☐ ☐ ☐ ☐ ☐ 2.3 Select a sample of system components and verify that non-console administrative access is encrypted by performing the following:

Modified p. 50 → 51

<Report Findings Here> ~~2.2.5.b.~~ Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.

<Report Findings Here> 2.2.5.b Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.

Modified p. 50 → 51

~~ Documented <Report Findings Here> ~~ Support secure configuration <Report Findings Here> ~~2.2.5.c.~~ Examine the documentation and security parameters to verify that only ~~documented functionality is present on the sampled system components.~~

• Support secure configuration <Report Findings Here> 2.2.5.c Examine the documentation and security parameters to verify that only Identify documentation examined for this testing procedure.

Modified p. 50 → 52

~~<Report Findings Here>~~ Describe how the security parameters verified that only documented functionality is present on the sampled system components from 2.2.5.a.

Describe how the security parameters verified that only documented functionality is present on the sampled system components from 2.2.5.a.

Modified p. 50 → 52

<Report Findings Here> 2.3 Encrypt all non-console administrative access using strong cryptography.

<Report Findings Here> 2.3 Encrypt all non-console administrative access using strong cryptography. ☐ ☐ ☐ ☐ ☐ 2.3 Select a sample of system components and verify that non-console administrative access is encrypted by performing the following:

Modified p. 50 → 52

~~<Report Findings Here>~~ For each item in the sample from 2.3:

For each item in the sample from 2.3:

Modified p. 51 → 52

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.

<Report Findings Here> 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.

Modified p. 51 → 53

~~<Report Findings Here> 2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best~~ Identify the vendor documentation examined to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

Identify the vendor documentation examined to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

Removed p. 52

<Report Findings Here> 2.3.e If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.

Indicate whether SSL/early TLS is used. (yes/no) If ‘no,’ mark the remainder of 2.3.e as ‘not applicable.’ <Report Findings Here> If ‘yes,’ provide the name of the assessor who attests that the testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS were performed.

Modified p. 52 → 53

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Place~~ practices and/or vendor recommendations.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

Modified p. 52 → 53

Identify the responsible personnel interviewed who confirm that that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

Modified p. 52 → 53

~~ Maintained <Report Findings Here> ~~ Includes a description of function/use for each <Report Findings Here> 2.4.b Interview personnel to verify the documented inventory is kept current.

• Includes a description of function/use for each <Report Findings Here> 2.4.b Interview personnel to verify the documented inventory is kept current.

Modified p. 52 → 53

<Report Findings Here> 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing ~~Identify the document reviewed to verify that security policies and operational procedures for managing~~ vendor defaults and other security parameters ~~are documented.~~

<Report Findings Here> 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are:

Modified p. 53

Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for managing vendor defaults and other security parameters are:

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for managing vendor defaults and other security parameters are: • In use

Modified p. 53

 Known to all affected parties <Report Findings Here> 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers. ☐ ☐ ☐ ☐ ☐ 2.6 Perform testing procedures A1.1 through A1.4 detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect …

• Known to all affected parties <Report Findings Here> 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers. ☐ ☐ ☐ ☐ ☐

Modified p. 53 → 54

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Place vendor defaults~~ and ~~other security parameters are:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 2.6 Perform testing procedures A1.1 through A1.4 detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities’ (merchants and service providers) hosted environment and data.

Modified p. 54 → 55

 Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.

Modified p. 54 → 55

 Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.

Modified p. 54 → 55

~~ Specific retention requirements for cardholder data ~~ Processes for secure deletion of data when no longer needed.

• Processes for secure deletion of data when no longer needed.

Modified p. 54 → 55

 A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

Modified p. 54 → 55

 Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).

• Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).

Modified p. 54 → 55

~~ Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons ~~ A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

Modified p. 54 → 55

 Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements for data retention.

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements for data retention.

Modified p. 54 → 55

 Specific requirements for retention of cardholder data.

• Specific requirements for retention of cardholder data.

Modified p. 54 → 55

 Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.

• Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.

Modified p. 54 → 55

 A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

Modified p. 55 → 56

 All locations of stored cardholder data are included in the ~~data- retention~~ and disposal processes.

• All locations of stored cardholder data are included in the data-retention and disposal processes.

Modified p. 55 → 56

 Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

• Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

Modified p. 55 → 56

 Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

• Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

Modified p. 55 → 56

 The quarterly automatic or manual process is performed for all locations of cardholder data.

• The quarterly automatic or manual process is performed for all locations of cardholder data.

Modified p. 55 → 56

 The quarterly automatic or manual process is performed for all locations of cardholder data.

• The quarterly automatic or manual process is performed for all locations of cardholder data.

Modified p. 55 → 56

 All locations of stored cardholder data are included in the data-retention and disposal processes.

• All locations of stored cardholder data are included in the data-retention and disposal processes.

Removed p. 56

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 3.1.c For a sample of system components that store cardholder data:

Modified p. 56

 Examine files and system records to verify that the data stored does not exceed the requirements defined in the data-retention policy.

• Examine files and system records to verify that the data stored does not exceed the requirements defined in the data-retention policy.

Modified p. 56

 Observe the deletion mechanism to verify data is deleted securely.

• Observe the deletion mechanism to verify data is deleted securely.

Modified p. 56

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:  There is a business justification, and ~~ The data is stored securely.~~

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if: • There is a business justification, and

Modified p. 56 → 57

~~<Report~~ Findings ~~Here>~~ Identify the interviewed personnel who confirm there is a documented business justification for the storage of sensitive authentication data.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Identify the interviewed personnel who confirm there is a documented business justification for the storage of sensitive authentication data.

Modified p. 56 → 57

<Report Findings Here> 3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine ~~If “yes” at 3.2.a, Identify~~ data stores ~~examined. <Report Findings Here>~~

<Report Findings Here> 3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.

Removed p. 57

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place data stores and system configurations to verify that the sensitive authentication data is secured.

Modified p. 57

Describe how the data stores and system configurations were examined to verify that the sensitive authentication data is secured.

If “yes” at 3.2.a, Identify data stores examined. <Report Findings Here> Describe how the data stores and system configurations were examined to verify that the sensitive authentication data is secured.

Modified p. 57 → 58

~~<Report~~ Findings ~~Here>~~ 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Note: In the normal course of business, the following …

Modified p. 57 → 58

~~ The cardholder’s name  Primary account number (PAN)  Expiration date ~~ Service code To minimize risk, store only these data elements as needed for business.

• Service code To minimize risk, store only these data elements as needed for business.

Removed p. 58

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents For each data source type below from the sample of system of components at 3.2.1, summarize the specific examples of each data source type observed to verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization. If that type of data source is not present, indicate that in the space.

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated …

Modified p. 58

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents  Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated <Report …

• If applicable, any other output observed to be generated <Report Findings Here> 3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions after authorization. ☐ ☐ ☐ ☐ 3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification For each data source type below …

Modified p. 58 → 59

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~data~~ on ~~a chip are~~ not stored after authorization:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place code or value printed on the front of the card or the signature panel (CAV2, CVC2, CVN2, CVV2, and CID data) is not stored after authorization:

Modified p. 59

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. ☐ ☐ ☐ ☐ 3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization:

• If applicable, any other output observed to be generated <Report Findings Here> 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. ☐ ☐ ☐ ☐ 3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization:

Modified p. 59

~~ Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas ~~ Database contents For each data source type below from the sample of system of components at 3.2.1, summarize the specific examples of each data source type ~~observed.~~ If that type of data source is not present, indicate that in the space.

• Database contents For each data source type below from the sample of system of components at 3.2.1, summarize the specific examples of each data source type observed to verify that PINs and encrypted PIN blocks are not stored after authorization. If that type of data source is not present, indicate that in the space.

Modified p. 59

 Incoming transaction data <Report Findings Here>  All logs (for example, transaction, history, debugging error) <Report Findings Here>  History files <Report Findings Here>  Trace files <Report Findings Here>  Database schemas <Report Findings Here>  Database contents <Report Findings Here>  If applicable, any other output observed to be generated <Report Findings Here> 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only …

• If applicable, any other output observed to be generated <Report Findings Here> 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 60

 A list of roles that need access to displays of more than first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

• A list of roles that need access to displays of more than first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

Modified p. 60

 A list of roles that need access to displays of more than first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

• A list of roles that need access to displays of more than first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access.

Modified p. 60

 PAN must be masked when displayed such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.

• PAN must be masked when displayed such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.

Modified p. 60

 All roles not specifically authorized to see the full PAN must only see masked PANs.

• All roles not specifically authorized to see the full PAN must only see masked PANs.

Modified p. 60

 All roles not specifically authorized to see the full PAN must only see masked PANs.

• All roles not specifically authorized to see the full PAN must only see masked PANs.

Modified p. 60

 PAN must be masked when displayed such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

• PAN must be masked when displayed such that only personnel with a legitimate business need can see more than first six/last four digits of the PAN.

Modified p. 60

 Full PAN is only displayed for users/roles with a documented business need.

• Full PAN is only displayed for users/roles with a documented business need.

Modified p. 60

~~<Report Findings Here> ~~ PAN is masked for all other requests. <Report Findings Here> 3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see more than first six/last four digits of the PAN.

• PAN is masked for all other requests. <Report Findings Here> 3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see more than first six/last four digits of the PAN.

Modified p. 60

 PANs are masked when displaying cardholder data.

• PANs are masked when displaying cardholder data.

Modified p. 60

~~<Report Findings Here> ~~ Only those with a legitimate business need are able to see more than first six/last four digits of the PAN.

• Only those with a legitimate business need are able to see more than first six/last four digits of the PAN.

Modified p. 61

 One-way hashes based on strong cryptography, (hash must be of the entire PAN).

• One-way hashes based on strong cryptography, (hash must be of the entire PAN).

Modified p. 61

 Truncation (hashing cannot be used to replace the truncated segment of PAN).

• Truncation (hashing cannot be used to replace the truncated segment of PAN).

Modified p. 61

 Index tokens and pads (pads must be securely stored).

• Index tokens and pads (pads must be securely stored).

Modified p. 61

 Strong cryptography with associated key-management processes and procedures.

• Strong cryptography with associated key-management processes and procedures.

Modified p. 61

~~ 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 Identify the documentation examined to verify that the PAN is rendered unreadable using any of the following methods:

• Strong cryptography, with associated key-management processes and procedures Identify the documentation examined to verify that the PAN is rendered unreadable using any of the following methods:

Modified p. 61

~~ 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 <Report Findings Here> 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).

• Strong cryptography, with associated key- management processes and procedures <Report Findings Here> 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).

Removed p. 64

• Description of the key usage for each key Identify the responsible personnel interviewed who confirm that a document exists to describe the cryptographic architecture, including:

Modified p. 64

 Access to keys is restricted to the fewest number of custodians necessary.

• Access to keys is restricted to the fewest number of custodians necessary.

Modified p. 64

 Access to keys is restricted to the fewest number of custodians necessary.

• Access to keys is restricted to the fewest number of custodians necessary.

Modified p. 64

 Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

Modified p. 64

 Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

Modified p. 64

 Key-encrypting keys are stored separately from data-encrypting keys.

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 64

 Key-encrypting keys are stored separately from data-encrypting keys.

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 64

 Keys are stored securely in the fewest possible locations and forms.

• Keys are stored securely in the fewest possible locations and forms.

Modified p. 64

 Keys are stored securely in the fewest possible locations and forms.

• Keys are stored securely in the fewest possible locations and forms.

Modified p. 64

• Inventory of any HSMs and other SCDs used for key management

• Inventory of any HSMs and other SCDs used for key management 3.5.1 Interview responsible personnel and review documentation to verify that a document exists to describe the cryptographic architecture, including:

Modified p. 64

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date Identify the responsible personnel interviewed who confirm that a document exists to describe the cryptographic architecture, including:

Modified p. 65

 Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.  Within a secure cryptographic device (such as a hardware/host security module (HSM) or PTS-approved point-of-interaction device).  As at least two full-length key components or key shares, in accordance with an industry-accepted method.

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key. • Within a secure cryptographic device (such as a hardware/host security module (HSM) or PTS-approved point-of-interaction device). • As at least two full-length key components or key shares, in accordance with an industry-accepted method.

Modified p. 66

 Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key.  Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved ~~point- of-interaction~~ device).  As key components or key shares, in accordance with an industry-accepted method.

• Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key. • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of- interaction device). • As key components or key shares, in accordance with an industry-accepted method.

Modified p. 66

 Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

Modified p. 66

 Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

Modified p. 66

 Within a secure cryptographic device (such as a hardware (host) security module (HSM) or ~~PTS-approved~~ point-of-interaction device).

• Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device).

Modified p. 66

 Within a secure cryptographic device (such as a hardware (host) security module (HSM) or ~~PTS-approved~~ point-of-interaction device).

• Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device).

Modified p. 66

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

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

Modified p. 66

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

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

Modified p. 66

~~ Encrypted with a key-encrypting key. ~~ Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved ~~point- of-interaction~~ device).  As key components or key shares, in accordance with an industry-accepted method.

• Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of- interaction device). • As key components or key shares, in accordance with an industry-accepted method.

Modified p. 66

~~<Report Findings Here>~~ Describe how system configurations and key storage locations verified that, wherever key-encrypting keys are used:

Describe how system configurations and key storage locations verified that, wherever key-encrypting keys are used:

Modified p. 67 → 66

 Key-encrypting keys are at least as strong as the data-encrypting keys they protect. ~~ Key-encrypting keys are stored separately from data-encrypting keys.~~

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

Modified p. 67

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~3.5.3.c Wherever key-encrypting~~ keys are ~~used, examine system configurations and key storage locations to verify:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 67

~~ Key-encrypting keys are at least as strong as the data-encrypting keys they protect <Report Findings Here> ~~ Key-encrypting keys are stored separately from data-encrypting keys.

• Key-encrypting keys are stored separately from data-encrypting keys.

Modified p. 68 → 67

Describe how the procedures for generating keys ~~was~~ observed to verify that strong keys are generated.

Describe how the procedures for generating keys were observed to verify that strong keys are generated.

Modified p. 68 → 67

<Report Findings Here> 3.6.2 Secure cryptographic key distribution. ☐ ☐ ☐ ☐ ☐ ~~3.6.2.a Verify that key-management procedures specify how to securely distribute keys.~~

<Report Findings Here> 3.6.2 Secure cryptographic key distribution. ☐ ☐ ☐ ☐ ☐

Modified p. 68

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~3.6.1.b Observe the~~ procedures ~~for generating keys~~ to ~~verify that strong keys are generated.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 3.6.2.a Verify that key-management procedures specify how to securely distribute keys.

Modified p. 69 → 68

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

<Report Findings Here> 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

Modified p. 69

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

• The retirement or replacement of keys when the integrity of the key has been weakened. • The replacement of known or suspected compromised keys.

Modified p. 69

 The retirement or replacement of keys when the integrity of the key has been weakened.

• The retirement or replacement of keys when the integrity of the key has been weakened.

Modified p. 69

 The replacement of known or suspected compromised keys.

• The replacement of known or suspected compromised keys.

Modified p. 69

 Any keys retained after retiring or replacing are not used for encryption operations.

• Any keys retained after retiring or replacing are not used for encryption operations.

Modified p. 69

 Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.  Keys are replaced if known or suspected to be compromised.  Any keys retained after retiring or replacing are not used for encryption operations.

• Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company. • Keys are replaced if known or suspected to be compromised. • Any keys retained after retiring or replacing are not used for encryption operations.

Modified p. 69

 Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.  Keys are replaced if known or suspected to be compromised.

• Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company. • Keys are replaced if known or suspected to be compromised. • Any keys retained after retiring or replacing are not used for encryption operations.

Modified p. 69

<Report Findings Here> 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control. ~~Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.~~

<Report Findings Here> 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Removed p. 70

 Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND  Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.

Modified p. 70

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~3.6.6.a Verify~~ that ~~manual clear-text key- management procedures specify processes for~~ the ~~use~~ of ~~the following:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place least two people who only have knowledge of their own key components; AND

• Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.

Modified p. 70

~~ Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND ~~ Dual control of keys, such that at least two people are required to perform any key- management operations and no one person has access to the authentication materials of another.

• Dual control of keys, such that at least two people are required to perform any key- management operations and no one person has access to the authentication materials of another.

Modified p. 70

<Report Findings Here> ~~3.6.6 b~~ Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:

<Report Findings Here> 3.6.6.b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:

Modified p. 70

~~ Split knowledge, AND ~~ Dual control Identify the responsible personnel interviewed for this testing procedure, if applicable.

• Dual control Identify the responsible personnel interviewed for this testing procedure, if applicable.

Modified p. 70

~~ Split knowledge <Report Findings Here> ~~ Dual Control <Report Findings Here> 3.6.7 Prevention of unauthorized substitution of cryptographic keys. ☐ ☐ ☐ ☐ ☐ 3.6.7.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.

• Dual Control <Report Findings Here> 3.6.7 Prevention of unauthorized substitution of cryptographic keys. ☐ ☐ ☐ ☐ ☐ 3.6.7.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.

Modified p. 71

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities. ☐ ☐ ☐ ☐ ☐~~ 3.6.8.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 3.6.8.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

Modified p. 71

~~ Documented,  In use, and ~~ Known to all affected parties Identify the document reviewed to verify that security policies and operational procedures for protecting stored cardholder data are documented.

• Known to all affected parties Identify the document reviewed to verify that security policies and operational procedures for protecting stored cardholder data are documented.

Removed p. 72

Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed .

 The Internet  Wireless technologies, including 802.11 and Bluetooth  Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)  General Packet Radio Service (GPRS)  Satellite communications 4.1.a Identify all locations where cardholder data is transmitted or received Identify all locations where cardholder data is transmitted or received over open, public networks.

Modified p. 72

 Only trusted keys and certificates are accepted.

• Only trusted keys and certificates are accepted.

Modified p. 72

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

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

Modified p. 72

 The encryption strength is appropriate for the encryption methodology in use.

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

Modified p. 72

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

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

Modified p. 73 → 72

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested Place~~ over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations.

• Satellite communications 4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations.

Modified p. 73 → 72

Identify the documented standards examined. <Report Findings Here> Describe how the documented standards and system configurations both verified the use of:

<Report Findings Here> Identify the documented standards examined. <Report Findings Here> Describe how the documented standards and system configurations both verified the use of:

Modified p. 73 → 72

~~ Security protocols for all locations <Report Findings Here> ~~ Strong cryptography for all locations <Report Findings Here> 4.1.b Review documented policies and procedures to verify processes are specified for the following:

• Strong cryptography for all locations <Report Findings Here> 4.1.b Review documented policies and procedures to verify processes are specified for the following:

Modified p. 73 → 72

 For acceptance of only trusted keys and/or certificates.

• For acceptance of only trusted keys and/or certificates.

Modified p. 73 → 72

 For acceptance of only trusted keys and/or certificates.

• For acceptance of only trusted keys and/or certificates.

Modified p. 73 → 72

 For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported).

• For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported).

Modified p. 73 → 72

 For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported).

• For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported).

Modified p. 73 → 72

 For implementation of proper encryption strength per the encryption methodology in use.

• For implementation of proper encryption strength per the encryption methodology in use.

Modified p. 73 → 72

 For implementation of proper encryption strength per the encryption methodology in use.

• For implementation of proper encryption strength per the encryption methodology in use.

Modified p. 73

~~<Report~~ Findings ~~Here>~~ 4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.

Modified p. 73

<Report Findings Here> 4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does ~~For all instances where cardholder data Is transmitted~~ or ~~received over open, public networks, describe how system configurations verified that the protocol:~~

<Report Findings Here> 4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations.

Modified p. 73

 Is implemented to use only secure configurations. <Report Findings Here>

• Is implemented to use only secure configurations. <Report Findings Here>

Removed p. 74

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested Place not support insecure versions or configurations.

<Report Findings Here> 4.1.h If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.

Indicate whether SSL/early TLS is used. (yes/no) If ‘no,’ mark the remainder of 4.1.h as ‘not applicable.’ <Report Findings Here> If ‘yes,’ provide the name of the assessor who attests that the testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS were performed.

Modified p. 74 → 73

 Does not support insecure versions or configurations.

• Does not support insecure versions or configurations.

Modified p. 74 → 73

For example, for browser-based implementations:  “HTTPS” appears as the browser Universal Record Locator (URL) protocol; and ~~ Cardholder data is only requested if “HTTPS” appears as part of the URL.~~

For example, for browser-based implementations: • “HTTPS” appears as the browser Universal Record Locator (URL) protocol; and

Modified p. 74

~~<Report~~ Findings ~~Here>~~ 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission. ☐ ☐ ☐ ☐ ☐ 4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings ~~Identify~~ all wireless networks ~~transmitting cardholder data or connected to the cardholder data environment.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission. ☐ ☐ ☐ ☐ ☐ 4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for …

Removed p. 75

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested Place to verify the following for all wireless networks identified:

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

Modified p. 75 → 74

 Industry best practices are used to implement strong encryption for authentication and transmission. ~~ Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission.~~

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

Modified p. 75 → 74

~~<Report Findings Here> ~~ Weak encryption is not used as a security control for authentication or transmission.

• Weak encryption is not used as a security control for authentication or transmission.

Modified p. 75

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

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 4.2.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.

Modified p. 76 → 75

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) Not Tested~~ 4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 4.3 Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

<Report Findings Here> 4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 4.3 Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

Modified p. 77 → 76

<Report Findings Here> 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. ☐ ☐ ☐ ☐ ☐ 5.1.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs; ~~ Detect all known types of malicious software,  Remove all known types of malicious software, and  Protect against all known types of malicious software.~~

<Report Findings Here> 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. ☐ ☐ ☐ ☐ ☐ 5.1.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs;

Modified p. 77 → 76

 Detect all known types of malicious software,  Remove all known types of malicious software, and  Protect against all known types of malicious software.

• Detect all known types of malicious software, • Remove all known types of malicious software, and • Protect against all known types of malicious software.

Modified p. 77 → 76

 Detect all known types of malicious software, <Report Findings Here> ~~ Remove all known types of malicious software, and <Report Findings Here>  Protect against all known types of malicious software.~~

• Detect all known types of malicious software, <Report Findings Here>

Modified p. 78 → 77

 Perform periodic scans.

• Perform periodic scans.

Modified p. 78 → 77

 Generate audit logs which are retained per PCI DSS Requirement 10.7.

• Generate audit logs which are retained per PCI DSS Requirement 10.7.

Modified p. 78 → 77

~~ Configured to perform automatic updates, and~~ Describe how anti-virus configurations, including the master installation of the software, verified anti-virus mechanisms are:

Describe how anti-virus configurations, including the master installation of the software, verified anti-virus mechanisms are:

Removed p. 79

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place  Configured to perform periodic scans.

<Report Findings Here> For each item in the sample, describe how anti-virus configurations, including the master installation of the software, verified that:

Modified p. 79 → 77

~~ Configured to perform automatic updates, and <Report Findings Here> ~~ Configured to perform periodic scans. <Report Findings Here> 5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:

• Configured to perform periodic scans. <Report Findings Here> 5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:

Modified p. 79 → 77

 The anti-virus software and definitions are current.

• The anti-virus software and definitions are current.

Modified p. 79 → 77

 Periodic scans are performed.

• Periodic scans are performed.

Modified p. 79 → 77

 The anti-virus software and definitions are current.

• The anti-virus software and definitions are current.

Modified p. 79 → 78

~~<Report Findings Here>  Periodic scans are performed. <Report Findings Here> 5.2.d Examine~~ anti-virus configurations, including the master installation of the ~~software and a sample of system components, to verify~~ that:

For each item in the sample, describe how anti-virus configurations, including the master installation of the software, verified that:

Modified p. 79 → 78

~~ Anti-virus software log generation is enabled, and ~~ Logs are retained in accordance with PCI DSS Requirement 10.7.

• Logs are retained in accordance with PCI DSS Requirement 10.7.

Modified p. 79 → 78

 Anti-virus software log generation is enabled, and. <Report Findings Here> ~~ Logs are retained in accordance with PCI DSS Requirement 10.7.~~

• Anti-virus software log generation is enabled, and. <Report Findings Here>

Modified p. 80 → 78

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 5.3.b Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that the anti-virus software cannot be disabled or altered by users.

<Report Findings Here> 5.3.b Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that the anti-virus software cannot be disabled or altered by users.

Modified p. 80 → 79

~~<Report~~ Findings ~~Here>~~ 5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are:

Modified p. 80 → 79

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for protecting systems against malware are:

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for protecting systems against malware are: • In use

Removed p. 81

 To include using reputable outside sources for security vulnerability information.

Modified p. 81 → 80

 To identify new security vulnerabilities.

• To identify new security vulnerabilities.

Modified p. 81 → 80

 To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.

• To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.

Modified p. 81 → 80

 To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.

• To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.

Modified p. 81 → 80

 To include using reputable outside sources for security vulnerability information.

• To include using reputable outside sources for security vulnerability information.

Modified p. 81 → 80

Identify the documented policies and procedures examined to confirm that processes are defined:

Identify the documented policies and procedures examined to confirm that processes are defined: • To identify new security vulnerabilities.

Modified p. 81 → 80

 To ~~identify new~~ security ~~vulnerabilities.~~

• To include using reputable outside sources for security vulnerability information.

Modified p. 81 → 80

 New security vulnerabilities are identified.

• New security vulnerabilities are identified.

Modified p. 81 → 80

 New security vulnerabilities are identified.

• New security vulnerabilities are identified.

Modified p. 81 → 80

 A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.

• A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.

Modified p. 81 → 80

 A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.

• A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.

Modified p. 81 → 80

 Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

• Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

Modified p. 82 → 81

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place  Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place • Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

Modified p. 82 → 81

Describe ~~the~~ processes observed to verify that:

Describe how processes were observed to verify that:

Modified p. 82 → 81

~~ New security vulnerabilities are identified. <Report Findings Here> ~~ A risk ranking is assigned to vulnerabilities to include identification of all “high” risk and “critical” vulnerabilities.

• A risk ranking is assigned to vulnerabilities to include identification of all “high” risk and “critical” vulnerabilities.

Modified p. 82 → 81

~~<Report Findings Here> ~~ Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

• Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

Modified p. 82 → 81

 Installation of applicable critical vendor-supplied security patches within one month of release.

• Installation of applicable critical vendor-supplied security patches within one month of release.

Modified p. 82 → 81

 Installation of all applicable ~~vendor-supplied~~ security patches within an appropriate time frame (for example, within three months).

• Installation of all applicable vendor- supplied security patches within an appropriate time frame (for example, within three months).

Modified p. 82 → 81

 Installation of applicable critical ~~vendor- supplied~~ security patches within one month of release.

• Installation of applicable critical vendor-supplied security patches within one month of release.

Modified p. 82 → 81

 Installation of all applicable vendor-supplied security patches within an appropriate time frame.

• Installation of all applicable vendor-supplied security patches within an appropriate time frame.

Modified p. 82 → 81

<Report Findings Here> 6.2.b For a sample of system components and related software, compare the list of ~~Identify~~ the ~~sample of system components and related software selected for this testing procedure.~~

<Report Findings Here> 6.2.b For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security-patch list, to verify the following:

Removed p. 83

<Report Findings Here>  All applicable vendor-supplied security patches are installed within an appropriate time frame.

Modified p. 83 → 81

 That applicable critical vendor- supplied security patches are installed within one month of release.

• That applicable critical vendor- supplied security patches are installed within one month of release.

Modified p. 83 → 81

Identify the vendor security patch list reviewed. <Report Findings Here> For each item in the sample, describe how the list of security patches installed on each system was compared to the most recent vendor security-patch list to verify that:

<Report Findings Here> Identify the vendor security patch list reviewed. <Report Findings Here> For each item in the sample, describe how the list of security patches installed on each system was compared to the most recent vendor security-patch list to verify that:

Modified p. 83 → 81

 Applicable critical vendor-supplied security patches are installed within one month of release.

• Applicable critical vendor-supplied security patches are installed within one month of release.

Modified p. 83 → 82

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place security patches installed ~~on each system to the most recent vendor security-patch list, to verify the following:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place • All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).

Modified p. 83 → 82

 All applicable vendor-supplied security patches are installed within an appropriate time ~~frame (for example, within three months).~~

• All applicable vendor-supplied security patches are installed within an appropriate time frame.

Modified p. 83 → 82

 In accordance with PCI DSS (for example, secure authentication and logging).

• In accordance with PCI DSS (for example, secure authentication and logging).

Modified p. 83 → 82

 Based on industry standards and/or best practices.

• Based on industry standards and/or best practices.

Modified p. 83 → 82

 Incorporate information security throughout the software development life cycle.

• Incorporate information security throughout the software development life cycle.

Modified p. 83 → 82

<Report Findings Here> 6.3.b Examine written ~~software~~ development processes to verify that information security is included throughout the life cycle.

<Report Findings Here> 6.3.b Examine written software- development processes to verify that information security is included throughout the life cycle.

Modified p. 83 → 82

Identify the documented ~~software development~~ processes examined to verify that information security is included throughout the life cycle.

Identify the documented software-development processes examined to verify that information security is included throughout the life cycle.

Modified p. 83 → 82

<Report Findings Here> 6.3.c Examine written ~~software~~ development processes to verify that software applications are developed in accordance with PCI DSS.

<Report Findings Here> 6.3.c Examine written software- development processes to verify that software applications are developed in accordance with PCI DSS.

Modified p. 83 → 82

Identify the documented ~~software development~~ processes examined to verify that software applications are developed in accordance with PCI DSS.

Identify the documented software-development processes examined to verify that software applications are developed in accordance with PCI DSS.

Modified p. 83 → 82

Identify the software developers interviewed who confirm that written ~~software development~~ processes are implemented.

Identify the software developers interviewed who confirm that written software-development processes are implemented.

Removed p. 84

<Report Findings Here> Identify the responsible personnel interviewed who confirm that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.

Modified p. 84 → 82

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. ☐ ☐ ☐ ☐ ☐ 6.3.1 Examine written software- development procedures and interview responsible personnel to verify that pre- production and/or custom application accounts, user IDs and/or passwords are removed before an application goes …

<Report Findings Here> 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. ☐ ☐ ☐ ☐ ☐ 6.3.1 Examine written software- development procedures and interview responsible personnel to verify that pre- production and/or custom application accounts, user IDs and/or passwords are Identify the documented software-development processes examined to verify processes define that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into …

Modified p. 84 → 83

Identify the ~~documented software-development processes examined to verify processes define~~ that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.

Identify the responsible personnel interviewed who confirm that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.

Modified p. 84 → 83

 Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines.  Appropriate corrections are implemented prior to release.  Code review results are reviewed and approved by management prior to release.

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices.

Modified p. 85 → 83

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested~~ 6.3.2.a Examine written software development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

6.3.2.a Examine written software development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

Modified p. 85 → 83

 Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.  Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5). ~~ Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release.~~

• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. • Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

Modified p. 85 → 83

 Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.

• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.

Modified p. 85 → 83

 Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

• Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

Modified p. 85 → 83

 Appropriate corrections are implemented prior to release.

• Appropriate corrections are implemented prior to release.

Modified p. 85 → 83

 Code-review results are reviewed and approved by management prior to release.

• Code-review results are reviewed and approved by management prior to release.

Modified p. 86 → 84

 Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

• Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

Modified p. 86 → 84

 Appropriate corrections are implemented prior to release.

• Appropriate corrections are implemented prior to release.

Modified p. 86 → 84

 Code-review results are reviewed and approved by management prior to release.

• Code-review results are reviewed and approved by management prior to release.

Modified p. 86 → 84

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Identify the responsible personnel interviewed for this testing procedure who confirm that all custom application code changes~~ are reviewed ~~as follows:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place

• Code-review results are reviewed and approved by management prior to release.

Modified p. 86 → 84

 Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in ~~code-review~~ techniques and secure coding practices.

• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code- review techniques and secure coding practices.

Modified p. 86 → 84

 Code changes are reviewed by individuals other than the originating code author.

• Code changes are reviewed by individuals other than the originating code author.

Modified p. 86 → 84

~~<Report Findings Here> ~~ Code changes are reviewed by individuals who are knowledgeable in code-review techniques and secure coding practices.

• Code changes are reviewed by individuals who are knowledgeable in code-review techniques and secure coding practices.

Modified p. 86 → 84

~~<Report Findings Here> ~~ Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

• Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).

Modified p. 86 → 84

~~<Report Findings Here> ~~ Appropriate corrections are implemented prior to release.

• Appropriate corrections are implemented prior to release.

Modified p. 86 → 84

~~<Report Findings Here> ~~ Code-review results are reviewed and approved by management prior to release.

• Code-review results are reviewed and approved by management prior to release.

Modified p. 87 → 85

 Development/test environments are separate from production environments with access control in place to enforce separation.

• Development/test environments are separate from production environments with access control in place to enforce separation.

Modified p. 87 → 85

 Development/test environments are separate from production environments with access control in place to enforce separation.

• Development/test environments are separate from production environments with access control in place to enforce separation.

Modified p. 87 → 85

 A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

• A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

Modified p. 87 → 85

 A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

• A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

Modified p. 87 → 85

 Production data (live PANs) are not used for testing or development.

• Production data (live PANs) are not used for testing or development.

Modified p. 87 → 85

 Production data (live PANs) are not used for testing or development.

• Production data (live PANs) are not used for testing or development.

Modified p. 87 → 85

 Test data and accounts are removed before a production system becomes active.

• Test data and accounts are removed before a production system becomes active.

Modified p. 87 → 85

 Test data and accounts are removed before a production system becomes active.

• Test data and accounts are removed before a production system becomes active.

Modified p. 87 → 85

 Change control procedures related to implementing security patches and software modifications are documented.

• Change control procedures related to implementing security patches and software modifications are documented.

Modified p. 87 → 85

 Change-control procedures related to implementing security patches and software modifications are documented.

• Change-control procedures related to implementing security patches and software modifications are documented.

Modified p. 89 → 87

~~ Documentation of impact.  Documented change approval by authorized parties. ~~ Functionality testing to verify that the change does not adversely impact the security of the system.  Back-out procedures.

• Functionality testing to verify that the change does not adversely impact the security of the system. • Back-out procedures.

Modified p. 89 → 87

Identify the documented change-control procedures examined to verify procedures are defined for:

Identify the documented change-control procedures examined to verify procedures are defined for: • Documentation of impact.

Modified p. 89 → 87

 Documentation of impact.

• Documentation of impact.

Modified p. 89 → 87

 Documented change approval by authorized parties.

• Documented change approval by authorized parties.

Modified p. 89 → 87

 Functionality testing to verify that the change does not adversely impact the security of the system.

• Functionality testing to verify that the change does not adversely impact the security of the system.

Modified p. 89 → 87

 Back-out procedures.

• Back-out procedures.

Modified p. 91 → 89

<Report Findings Here> 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

<Report Findings Here> 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. ☐ ☐ ☐ ☐ ☐ 6.4.6 For a sample of significant changes, examine change records, interview personnel and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change.

Modified p. 92 → 89

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 6.5 Address common coding vulnerabilities in software-development processes as follows:

<Report Findings Here> 6.5 Address common coding vulnerabilities in software-development processes as follows:

Modified p. 92 → 89

 Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.

• Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.

Modified p. 92 → 89

 Develop applications based on secure coding guidelines.

• Develop applications based on secure coding guidelines.

Modified p. 92 → 90

6.5.a Examine software development policies and procedures to verify that up- to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 6.5.a Examine software development policies and procedures to verify that up- to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance.

Modified p. 92 → 90

<Report Findings Here> ~~6.5.c.~~ Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:

<Report Findings Here> 6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:

Removed p. 93

 Prevent cryptographic flaws. <Report Findings Here>  Use strong cryptographic algorithms and keys. <Report Findings Here> 6.5.4 Insecure communications. ☐ ☐ ☐ ☐ ☐ 6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Modified p. 93 → 90

 Validating input to verify user data cannot modify meaning of commands and queries.  Utilizing parameterized queries.

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

Modified p. 93 → 90

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

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

Modified p. 93 → 91

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Place~~ responsible personnel to verify that ~~injection flaws~~ are addressed by coding techniques that include:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 6.5.2 Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include:

Modified p. 93 → 91

<Report Findings Here> ~~ Utilizing parameterized queries. <Report Findings Here> 6.5.2 Buffer overflow.~~ ☐ ☐ ☐ ☐ ☐ ~~6.5.2~~ Examine software-development policies and procedures and interview responsible personnel to verify that ~~buffer overflows are~~ addressed by coding techniques ~~that include:~~

• Truncating input strings. <Report Findings Here> 6.5.3 Insecure cryptographic storage. ☐ ☐ ☐ ☐ ☐ 6.5.3 Examine software-development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that:

Modified p. 93 → 91

 Validating buffer boundaries. ~~ Truncating input strings.~~

• Validating buffer boundaries. <Report Findings Here>

Modified p. 93 → 91

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that buffer overflows are addressed by coding techniques that include:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that buffer overflows are addressed by coding techniques that include:

Modified p. 93 → 91

~~ Validating buffer boundaries.~~ <Report Findings Here> ~~ Truncating input strings. <Report Findings Here> 6.5.3~~ Insecure ~~cryptographic storage.~~ ☐ ☐ ☐ ☐ ☐ ~~6.5.3~~ Examine software-development policies and procedures and interview responsible personnel to verify that insecure ~~cryptographic storage is~~ addressed by coding techniques ~~that:~~

• Use strong cryptographic algorithms and keys. <Report Findings Here> 6.5.4 Insecure communications. ☐ ☐ ☐ ☐ ☐ 6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Modified p. 93 → 91

~~ Prevent cryptographic flaws. ~~ Use strong cryptographic algorithms and keys.

• Use strong cryptographic algorithms and keys.

Modified p. 93 → 91

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that insecure cryptographic storage is addressed by coding techniques that:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that insecure cryptographic storage is addressed by coding techniques that:

Modified p. 93 → 91

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that insecure communications are addressed by coding techniques that properly:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that insecure communications are addressed by coding techniques that properly:

Modified p. 93 → 91

 Authenticate all sensitive communications. <Report Findings Here> ~~ Encrypt all sensitive communications. <Report Findings Here>~~

• Authenticate all sensitive communications. <Report Findings Here>

Modified p. 94 → 91

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that improper error handling is addressed by coding techniques that do not leak information via error messages.

For the interviews at 6.5.c, summarize the relevant details discussed to verify that improper error handling is addressed by coding techniques that do not leak information via error messages.

Modified p. 94 → 91

<Report Findings Here> 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). ☐ ☐ ☐ ☐ ☐ 6.5.6 Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

<Report Findings Here> 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). ☐ ☐ ☐ ☐ ☐

Modified p. 94 → 92

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~6.5.5 Improper error handling. ☐ ☐ ☐ ☐ ☐ 6.5.5 Examine-software development~~ policies and procedures and interview responsible personnel to verify that ~~improper error handling is addressed by~~ coding techniques that ~~do not leak information via error messages (for example, by returning generic rather than specific error details).~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 6.5.6 Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

Modified p. 94 → 92

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

For the interviews at 6.5.c, summarize the relevant details discussed to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

Modified p. 94 → 92

 Validating all parameters before inclusion.  Utilizing context-sensitive escaping.

• Validating all parameters before inclusion. • Utilizing context-sensitive escaping.

Modified p. 94 → 92

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that cross-site scripting (XSS) is addressed by coding techniques that include:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that cross-site scripting (XSS) is addressed by coding techniques that include:

Modified p. 94 → 92

~~ Validating all parameters before inclusion. <Report Findings Here> ~~ Utilizing context-sensitive escaping. <Report Findings Here> 6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions). ☐ ☐ ☐ ☐ ☐

• Utilizing context-sensitive escaping. <Report Findings Here> 6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions). ☐ ☐ ☐ ☐ ☐ 6.5.8 Examine software-development policies and procedures and interview responsible personnel to verify that improper access control

•such as insecure direct object references, failure to restrict URL access, and directory traversal

•is addressed by coding technique that include:

Modified p. 95 → 92

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that improper access control is addressed by coding techniques that include:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that improper access control is addressed by coding techniques that include:

Modified p. 95 → 92

 Proper authentication of users. <Report Findings Here>  Sanitizing input. <Report Findings Here>  Not exposing internal object references to users. <Report Findings Here>  User interfaces that do not permit access to unauthorized functions.

• Validating all parameters before inclusion. <Report Findings Here>

• Proper authentication of users. <Report Findings Here> • Sanitizing input. <Report Findings Here> • Not exposing internal object references to users. <Report Findings Here> • Proper authentication of users.

• Not exposing internal object references to users.

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

Modified p. 95 → 93

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 6.5.8 Examine software-development policies and procedures and interview responsible personnel to verify that improper access control

•such as insecure direct object references, failure to restrict URL access, and directory traversal

•is addressed by coding technique that include:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested

Modified p. 95 → 93

~~ Proper authentication of users.  Sanitizing input.  Not exposing internal object references to users. ~~ User interfaces that do not permit access to unauthorized functions.

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

Modified p. 95 → 93

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

For the interviews at 6.5.c, summarize the relevant details discussed to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Modified p. 95 → 93

For the interviews at ~~6.5.d,~~ summarize the relevant details discussed to verify that broken authentication and session management are addressed via coding techniques that commonly include:

For the interviews at 6.5.c, summarize the relevant details discussed to verify that broken authentication and session management are addressed via coding techniques that commonly include:

Modified p. 95 → 93

 Flagging session tokens (for ~~example~~ cookies) as “secure.” <Report Findings Here> ~~ Not exposing session IDs in the URL. <Report Findings Here>~~

• Flagging session tokens (for example, cookies) as “secure.” <Report Findings Here>

Removed p. 96

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place  Flagging session tokens (for example cookies) as “secure.”  Not exposing session IDs in the URL.  Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Modified p. 96 → 93

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

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

Modified p. 97 → 94

 Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.

Modified p. 97 → 94

 Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

• Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Modified p. 97 → 94

 Examine documented processes, interview personnel, and examine records of application security assessments to verify that ~~public-facing~~ web applications are ~~reviewed•using~~ either manual or automated For each public-facing web application, identify which of the two methods are implemented:

• Examine documented processes, interview personnel, and examine records of application security assessments to verify that public- facing web applications are reviewed

•using either manual or automated vulnerability security For each public-facing web application, identify which of the two methods are implemented:

Modified p. 97 → 94

~~ Web application vulnerability security assessments, AND/OR ~~ Automated technical solution that detects and prevents web-based attacks, such as web application firewalls.

• Automated technical solution that detects and prevents web-based attacks, such as web application firewalls.

Modified p. 98 → 95

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~vulnerability security~~ assessment tools or methods•as follows: - At least annually. - After any changes. - By an organization that specializes in application security. - That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment. - That all vulnerabilities are corrected. - That the application is re-evaluated after the corrections.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place assessment tools or methods•as follows: - At least annually.

Modified p. 98 → 95

 Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows: ~~- Is situated in front of public-facing web applications to detect and prevent web-based attacks.~~

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

Modified p. 98 → 95

 By an organization that specializes in application security.

• By an organization that specializes in application security.

Modified p. 98 → 95

 That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment.

• That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment.

Modified p. 98 → 95

~~ That all vulnerabilities are corrected ~~ That the application is re-evaluated after the corrections.

• That the application is re-evaluated after the corrections.

Modified p. 99 → 96

 By an organization that specializes in application security.

• By an organization that specializes in application security.

Modified p. 99 → 96

 That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment.

• That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment.

Modified p. 99 → 96

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place - Is actively running and up-to-date as applicable. - Is generating audit logs. - Is configured to either block ~~web- based~~ attacks, or generate an alert that is immediately investigated.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place - Is actively running and up-to-date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert that is immediately investigated.

Modified p. 99 → 96

Identify the responsible personnel interviewed who confirm that public-facing web applications are reviewed, as follows:

Identify the responsible personnel interviewed who confirm that public-facing web applications are reviewed, as follows: • At least annually.

Modified p. 99 → 96

 That all vulnerabilities are corrected.

• That all vulnerabilities are corrected.

Modified p. 99 → 96

 That the application is re-evaluated after the corrections.

• That the application is re-evaluated after the corrections.

Modified p. 99 → 96

~~ At least annually. <Report Findings Here>  After any changes. <Report Findings Here> ~~ By an organization that specialized in application security.

• By an organization that specialized in application security.

Modified p. 99 → 96

~~<Report Findings Here> ~~ That at a minimum, all vulnerabilities in requirement 6.5 are included in the assessment.

• That at a minimum, all vulnerabilities in requirement 6.5 are included in the assessment.

Modified p. 99 → 96

~~<Report Findings Here> ~~ That all vulnerabilities are corrected. <Report Findings Here> ~~ That the application is re-evaluated after the corrections.~~

• That all vulnerabilities are corrected. <Report Findings Here>

Modified p. 100 → 97

 Is situated in front of public-facing web applications to detect and prevent ~~web- based~~ attacks.

• Is situated in front of public-facing web applications to detect and prevent web-based attacks.

Modified p. 100 → 97

 Is actively running and up-to-date as applicable.

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

Modified p. 100 → 97

 Is generating audit logs.

• Is generating audit logs.

Modified p. 100 → 97

 Is configured to either block web-based attacks, or generate an alert that is immediately investigated.

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

Modified p. 100 → 97

 Is situated in front of public-facing web applications to detect and prevent web- based attacks.

• Is situated in front of public-facing web applications to detect and prevent web- based attacks.

Modified p. 100 → 97

~~<Report Findings Here> ~~ Is actively running and up-to-date as applicable.

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

Modified p. 100 → 97

~~<Report Findings Here>  Is generating audit logs. <Report Findings Here> ~~ Is configured to either block web-based attacks, or generate an alert that is immediately investigated.

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

Modified p. 100 → 97

<Report Findings Here> 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 6.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing ~~Identify the document examined to verify that security policies and operational procedures for developing~~ and maintaining secure systems and applications ~~are documented.~~

<Report Findings Here> 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 6.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are:

Removed p. 101

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place and maintaining secure systems and applications are:

Modified p. 101 → 97

Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for developing and maintaining secure systems and applications are:

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for developing and maintaining secure systems and applications are: • In use

Modified p. 102 → 98

 Defining access needs and privilege assignments for each role.

• Defining access needs and privilege assignments for each role.

Modified p. 102 → 98

 Defining access needs and privilege assignments for each role.

• Defining access needs and privilege assignments for each role.

Modified p. 102 → 98

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

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

Modified p. 102 → 98

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

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

Modified p. 102 → 98

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

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

Modified p. 102 → 98

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

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

Modified p. 102 → 98

~~ Assignment of access based on individual personnel’s job classification and function ~~ Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.

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

Modified p. 102 → 98

~~ System components and data resources that each role needs to access for their job function. ~~ Level of privilege required (for example, user, administrator, etc.) for accessing resources.

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

Modified p. 102 → 98

 System components and data resources that each role needs to access for their job function.

• System components and data resources that each role needs to access for their job function. • Identification of privilege necessary for each role to perform their job function.

Removed p. 103

 Necessary for that individual’s job function.

Modified p. 103 → 98

 System components and data resources that each role needs to access for their job function.

• System components and data resources that each role needs to access for their job function.

Modified p. 103 → 99

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested ~~Place  Identification of privilege necessary for each role to perform their job function.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested

Modified p. 103 → 99

~~<Report Findings Here> ~~ Identification of privilege necessary for each role to perform their job function.

• Identification of privilege necessary for each role to perform their job function.

Modified p. 103 → 99

 Assigned only to roles that specifically require such privileged access.  Restricted to least privileges necessary to perform job responsibilities.

• Assigned only to roles that specifically require such privileged access. • Restricted to least privileges necessary to perform job responsibilities.

Modified p. 103 → 99

 Assigned only to roles that specifically require such privileged access.

• Assigned only to roles that specifically require such privileged access.

Modified p. 103 → 99

 Restricted to least privileges necessary to perform job responsibilities.

• Restricted to least privileges necessary to perform job responsibilities.

Modified p. 103 → 99

 Restricted to least privileges necessary to perform job responsibilities.

• Restricted to least privileges necessary to perform job responsibilities.

Modified p. 103 → 99

 Necessary for that individual’s job function.  Restricted to least privileges necessary to perform job responsibilities.

• Necessary for that individual’s job function. • Restricted to least privileges necessary to perform job responsibilities.

Modified p. 103 → 99

<Report Findings Here> Identify the responsible management personnel interviewed to confirm that privileges assigned are:

<Report Findings Here> Identify the responsible management personnel interviewed to confirm that privileges assigned are: • Necessary for that individual’s job function.

Modified p. 103 → 99

~~ Necessary for that individual’s job function. <Report Findings Here> ~~ Restricted to least privileges necessary to perform job responsibilities.

• Restricted to least privileges necessary to perform job responsibilities.

Modified p. 104 → 100

~~ Documented approval exists for the assigned privileges.  The approval was by authorized parties. ~~ That specified privileges match the roles assigned to the individual.

• That specified privileges match the roles assigned to the individual.

Modified p. 104 → 100

 Documented approval exists for the assigned privileges.

• Documented approval exists for the assigned privileges.

Modified p. 104 → 100

~~<Report Findings Here>  The approval was by authorized parties. <Report Findings Here> ~~ That specified privileges match the roles assigned to the individual.

• That specified privileges match the roles assigned to the individual.

Modified p. 106 → 102

 Assign all users a unique ID before allowing them to access system components or cardholder data.

• Assign all users a unique ID before allowing them to access system components or cardholder data.

Modified p. 106 → 102

 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

• Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Modified p. 106 → 102

 Immediately revoke access for any terminated users.

• Immediately revoke access for any terminated users.

Modified p. 106 → 102

 Remove/disable inactive user accounts at least every 90 days.

• Remove/disable inactive user accounts at least every 90 days.

Modified p. 106 → 102

 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows: ~~- Enabled only during the time period needed and disabled when not in use. - Monitored when in use.~~

• Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

Modified p. 106 → 102

 Limit repeated access attempts by locking out the user ID after not more than six attempts.

• Limit repeated access attempts by locking out the user ID after not more than six attempts.

Modified p. 106 → 102

 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

• Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

Modified p. 106 → 102

 If a session has been idle for more than 15 minutes, require the user to re-authenticate to ~~re-activate~~ the terminal or session.

• If a session has been idle for more than 15 minutes, require the user to re-authenticate to re- activate the terminal or session.

Modified p. 107 → 103

 For the sample of privileged user IDs. <Report Findings Here>  For the sample of general user IDs. <Report Findings Here> 8.1.3 Immediately revoke access for any terminated users. ☐ ☐ ☐ ☐ ☐ 8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists

•for both local and remote access

•to verify that their IDs have been deactivated or removed from the access lists.

• For the sample of privileged user IDs. <Report Findings Here> • For the sample of general user IDs. <Report Findings Here> 8.1.3 Immediately revoke access for any terminated users. ☐ ☐ ☐ ☐ ☐ 8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists

•for both local and remote access

•to verify that their IDs have been deactivated or removed from the access lists.

Modified p. 108 → 104

 Enabled only during the time period needed and disabled when not in use. ~~ Monitored when in use.~~

• Enabled only during the time period needed and disabled when not in use.

Modified p. 108 → 104

~~ Disabled when not in use. ~~ Enabled only when needed by the third party, and disabled when not in use.

• Enabled only when needed by the third party, and disabled when not in use.

Modified p. 108 → 104

 Disabled when not in use.

• Disabled when not in use.

Modified p. 108 → 104

 Enabled only when needed by the third party, and disabled when not in use.

• Enabled only when needed by the third party, and disabled when not in use.

Modified p. 108 → 104

~~ Disabled when not in use. <Report Findings Here> ~~ Enabled only when needed by the third party, and disabled when not in use.

• Enabled only when needed by the third party, and disabled when not in use.

Modified p. 109 → 105

 Something you know, such as a password or passphrase.

• Something you know, such as a password or passphrase.

Modified p. 109 → 105

 Something you have, such as a token device or smart card.

• Something you have, such as a token device or smart card.

Modified p. 109 → 105

 Something you are, such as a biometric.

• Something you are, such as a biometric.

Modified p. 110 → 106

 Examine documentation describing the authentication method(s) used.

• Examine documentation describing the authentication method(s) used.

Modified p. 110 → 106

 For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

• For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

Removed p. 111

For each item in the sample at 8.2.1.a, describe how password files verified that passwords are unreadable during transmission.

Modified p. 111 → 106

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 8.2.1.b For a sample of system components, examine password files to verify that passwords are unreadable during storage.

<Report Findings Here> 8.2.1.b For a sample of system components, examine password files to verify that passwords are unreadable during storage.

Modified p. 111 → 107

~~<Report Findings Here> 8.2.1.c~~ For a sample ~~of system components, examine~~ data transmissions ~~to verify~~ that passwords are unreadable during transmission.

For each item in the sample at 8.2.1.a, describe how data transmissions verified that passwords are unreadable during transmission.

Removed p. 112

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.2.3 Passwords/passphrases must meet the following:

Modified p. 112 → 107

 Require a minimum length of at least seven characters. ~~ Contain both numeric and alphabetic characters.~~

• Require a minimum length of at least seven characters.

Modified p. 112 → 108

 Require a minimum length of at least seven characters. ~~ Contain both numeric and alphabetic characters.~~

• Require a minimum length of at least seven characters.

Modified p. 112 → 108

8.2.3.a For a sample of system components, inspect system configuration settings to verify that user password/passphrase parameters are set to require at least the following strength/complexity:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.2.3.a For a sample of system components, inspect system configuration settings to verify that user password/passphrase parameters are set to require at least the following strength/complexity:

Modified p. 112 → 108

 Require a minimum length of at least seven characters.

• Require a minimum length of at least seven characters.

Modified p. 112 → 108

 Contain both numeric and alphabetic characters.

• Contain both numeric and alphabetic characters.

Modified p. 112 → 108

 Require a minimum length of at least seven characters.

• Require a minimum length of at least seven characters.

Modified p. 112 → 108

~~<Report Findings Here> ~~ Contain both numeric and alphabetic characters. <Report Findings Here> 8.2.3.b Additional procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that non- consumer customer passwords/passphrases are required to meet at least the following strength/complexity:

• Contain both numeric and alphabetic characters. <Report Findings Here> 8.2.3.b Additional procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that non- consumer customer passwords/passphrases are required to meet at least the following strength/complexity:

Modified p. 112 → 108

 A minimum length of at least seven characters.

• A minimum length of at least seven characters.

Modified p. 112 → 108

 Non-consumer customer passwords/passphrases are required to contain both numeric and alphabetic characters.

• Non-consumer customer passwords/passphrases are required to contain both numeric and alphabetic characters.

Modified p. 112 → 108

~~ A minimum length of at least seven characters. <Report Findings Here> ~~ Non-consumer customer passwords/passphrases are required to contain both numeric and alphabetic characters.

• Non-consumer customer passwords/passphrases are required to contain both numeric and alphabetic characters.

Removed p. 113

 Non-consumer customer user passwords/passphrases are required to change periodically; and  Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.

 Non-consumer customer user passwords/passphrases are required to change periodically; and  Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.

 Non-consumer customer user passwords/passphrases are required to change periodically; and <Report Findings Here>  Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.

<Report Findings Here> 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used. ☐ ☐ ☐ ☐ ☐ 8.2.5.a For a sample of system components, obtain and inspect system Identify the sample of system components selected for this testing procedure.

Modified p. 113 → 109

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~8.2.4 Change user passwords/passphrases at least once every 90 days. ☐ ☐ ☐ ☐ ☐ 8.2.4.a For a sample of system components, inspect system configuration~~ settings to verify that user password/passphrase parameters are set to require users to change passwords/passphrases at least once every 90 days.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place settings to verify that user password/passphrase parameters are set to require users to change passwords/passphrases at least once every 90 days.

Modified p. 113 → 109

<Report Findings Here> For each item in the sample, describe how system configuration settings verified that ~~user~~ password/passphrase parameters are set to require ~~users to change~~ passwords/passphrases ~~at least once every 90 days.~~

<Report Findings Here> For each item in the sample, describe how system configuration settings verified that password/passphrase parameters are set to require that new passwords/passphrases cannot be the same as the four previously used passwords/passphrases.

Removed p. 114

<Report Findings Here> 8.2.5.b Additional Procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords/passphrases cannot be the same as the previous four passwords/passphrases.

Modified p. 114 → 110

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Place configuration settings~~ to verify that ~~password/passphrases parameters are set to require that~~ new passwords/passphrases cannot be the same as the four ~~previously used~~ passwords/passphrases.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.2.5.b Additional Procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords/passphrases cannot be the same as the previous four passwords/passphrases.

Modified p. 114 → 110

 First-time passwords/passphrases must be set to a unique value for each user.

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

Modified p. 114 → 110

 First-time passwords/passphrases must be changed after the first use.

• First-time passwords/passphrases must be changed after the first use.

Modified p. 114 → 110

 Reset passwords/passphrases must be set to a unique value for each user.

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

Modified p. 114 → 110

 Reset passwords/passphrases must be changed after the first use.

• Reset passwords/passphrases must be changed after the first use.

Modified p. 114 → 110

 Set first-time passwords/passphrases to a unique value for each new user.

• Set first-time passwords/passphrases to a unique value for each new user.

Modified p. 114 → 110

~~<Report Findings Here> ~~ Set first-time passwords/passphrases to be changed after first use.

• Set first-time passwords/passphrases to be changed after first use.

Removed p. 115

<Report Findings Here> 8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

Modified p. 115 → 110

~~<Report Findings Here> ~~ Set reset passwords/passphrases to be changed after first use.

• Set reset passwords/passphrases to be changed after first use.

Modified p. 115 → 111

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~ Set reset passwords/passphrases~~ to ~~a unique value for each existing user.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

Modified p. 115 → 111

<Report Findings Here> Describe the multi-factor authentication methods observed to be in place for a personnel non-console log ins to the CDE.

<Report Findings Here> Describe the multi-factor authentication methods observed to be in place for administrator personnel non-console log ins to the CDE.

Modified p. 115 → 111

<Report Findings Here> 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including ~~third party~~ access for support or maintenance) originating from outside the entity’s network. ☐ ☐ ☐ ☐ ☐ 8.3.2.a Examine system configurations for remote access servers and systems to Describe how system configurations for remote access servers and systems verified that multi-factor authentication is required for:

<Report Findings Here> 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.

Modified p. 115 → 111

 All remote access by personnel, both user and administrator, and <Report Findings Here>

• All remote access by personnel, both user and administrator, and <Report Findings Here>

Removed p. 116

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place verify multi-factor authentication is required for:

<Report Findings Here> 8.4 Document and communicate authentication policies and procedures to all users including:

Modified p. 116 → 111

~~ All remote access by personnel, both user and administrator, and ~~ All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

• All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

Modified p. 116 → 111

 All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

• All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

Modified p. 116 → 112

 Instructions not to reuse previously used passwords.

• Instructions not to reuse previously used passwords.

Modified p. 116 → 112

 Instructions to change passwords if there is any suspicion the password could be compromised.

• Instructions to change passwords if there is any suspicion the password could be compromised.

Modified p. 117 → 112

 Instructions to change passwords if there is any suspicion the password could be compromised.

• Instructions to change passwords if there is any suspicion the password could be compromised.

Modified p. 117 → 112

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 8.4.b Review authentication policies and procedures that are distributed to users and verify they include:

<Report Findings Here> 8.4.b Review authentication policies and procedures that are distributed to users and verify they include:

Modified p. 117 → 112

 Instructions for users not to reuse previously used passwords.

• Instructions for users not to reuse previously used passwords.

Modified p. 117 → 112

 Instructions for users not to reuse previously used passwords.

• Instructions for users not to reuse previously used passwords.

Modified p. 117 → 112

 That users should change passwords if there is any suspicion the password could be compromised.

• That users should change passwords if there is any suspicion the password could be compromised.

Modified p. 117 → 113

~~<Report~~ Findings ~~Here>~~ 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

Modified p. 117 → 113

 Generic user IDs are disabled or removed.

• Generic user IDs are disabled or removed.

Modified p. 117 → 113

 Generic user IDs are disabled or removed.

• Generic user IDs are disabled or removed.

Modified p. 117 → 113

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

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

Modified p. 117 → 113

 Shared and generic user IDs are not used to administer any system components.

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

Modified p. 117 → 113

~~ Shared user IDs for system administration activities and~~ Identify the sample of system components selected for this testing procedure.

Identify the sample of system components selected for this testing procedure.

Modified p. 117 → 113

~~ Generic user IDs are disabled or removed. <Report Findings Here> ~~ Shared user IDs for system administration activities and other critical functions do not exist.

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

Removed p. 118

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place other critical functions do not exist.

 Shared and generic user IDs are not used to administer any system components.

Modified p. 118 → 113

 Shared and generic user IDs are not used to administer any system components.

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

Modified p. 118 → 114

~~<Report Findings Here>~~ Identify the responsible personnel interviewed who confirm that different authentication credentials are used for access to each customer <Report Findings Here> 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) use of these mechanisms must be assigned as follows:

Identify the responsible personnel interviewed who confirm that different authentication credentials are used for access to each customer <Report Findings Here> 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) use of these mechanisms must be assigned as follows:

Modified p. 118 → 114

 Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.

• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.

Modified p. 118 → 114

 Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

Modified p. 119 → 114

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested~~ 8.6.a Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include:

8.6.a Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include:

Modified p. 119 → 114

 Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.

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

Modified p. 119 → 114

 Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.

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

Modified p. 119 → 114

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

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

Modified p. 119 → 114

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

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

Modified p. 119 → 115

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

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

Modified p. 119 → 115

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

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

Modified p. 119 → 115

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

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

Modified p. 119 → 115

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

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

Modified p. 120 → 115

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 8.7.b Examine database and application configuration settings to verify that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures).

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

Modified p. 120 → 115

 Identify applications with access to the database. <Report Findings Here>  Describe how database access control settings, database application configuration settings and related application IDs verified that application IDs can only be used by the applications.

Identify applications with access to the database. <Report Findings Here> Describe how database access control settings, database application configuration settings and related application IDs verified that application IDs can only be used by the applications.

Modified p. 120 → 115

<Report Findings Here> 8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ ~~8.8 Examine documentation and interview personnel to verify that security policies and operational procedures for identification and authentication are:~~

<Report Findings Here> 8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐

Modified p. 120 → 116

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for identification and authentication are:

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for identification and authentication are: • In use

Modified p. 121 → 117

 Verify that access is controlled with badge readers or other devices including authorized badges and lock and key.

• Verify that access is controlled with badge readers or other devices including authorized badges and lock and key.

Modified p. 121 → 117

 Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder data environment and verify that they are “locked” to prevent unauthorized use.

• Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder data environment and verify that they are “locked” to prevent unauthorized use.

Modified p. 121 → 117

~~ All computer rooms <Report Findings Here>  All data centers <Report Findings Here> ~~ Any other physical areas <Report Findings Here> For each area identified (add rows as needed), complete the following:

• Any other physical areas <Report Findings Here> For each area identified (add rows as needed), complete the following:

Modified p. 122 → 118

<Report Findings Here> Describe how physical and/or logical controls were observed to be in place to restrict access to ~~publicly-~~ accessible network jacks.

<Report Findings Here> Describe how physical and/or logical controls were observed to be in place to restrict access to publicly accessible network jacks.

Modified p. 122 → 118

 Wireless access points <Report Findings Here>  Wireless gateways <Report Findings Here>  Wireless handheld devices <Report Findings Here>  Network/communications hardware <Report Findings Here>  Telecommunication lines <Report Findings Here> 9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:

• Telecommunication lines <Report Findings Here> 9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:

Modified p. 122 → 118

 Identifying onsite personnel and visitors (for example, assigning badges).

• Identifying onsite personnel and visitors (for example, assigning badges).

Modified p. 122 → 118

 Changes to access requirements.

• Changes to access requirements.

Modified p. 122 → 118

 Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

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

Modified p. 123 → 119

~~ Identifying onsite personnel and visitors (for example, assigning badges),  Changing access requirements, and ~~ Revoking terminated onsite personnel and expired visitor identification (such as ID badges).

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

Modified p. 123 → 119

~~ Identifying onsite personnel and visitors (for example, assigning badges),  Changing access requirements, and ~~ Revoking terminated onsite personnel and expired visitor identification (such as ID badges).

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

Modified p. 123 → 119

~~ Visitors are clearly identified, and ~~ It is easy to distinguish between onsite personnel and visitors.

• It is easy to distinguish between onsite personnel and visitors.

Modified p. 123 → 119

~~ Visitors are clearly identified, and <Report Findings Here> ~~ It is easy to distinguish between onsite personnel and visitors.

• It is easy to distinguish between onsite personnel and visitors.

Modified p. 123 → 119

 Access must be authorized and based on individual job function.

• Access must be authorized and based on individual job function.

Modified p. 123 → 119

 Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

• Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

Removed p. 124

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.3.a For a sample of onsite personnel with physical access to sensitive areas, interview responsible personnel and observe access control lists to verify that:

 Access to the sensitive area is authorized.

 Access is required for the individual’s job function.

 Access to the sensitive area is authorized. <Report Findings Here>  Access is required for the individual’s job function. <Report Findings Here> 9.3.b Observe personnel accessing sensitive areas to verify that all personnel are authorized before being granted access.

Modified p. 124 → 119

~~Identify the~~ sample of onsite personnel with physical access to sensitive ~~areas that were~~ interviewed for this testing procedure.

9.3.a For a sample of onsite personnel with physical access to sensitive areas, Identify the sample of responsible personnel interviewed for this testing procedure.

Modified p. 124 → 120

Identify the documented procedures examined to verify that visitors must be authorized before they are granted access to, and escorted at all times within, areas where cardholder data is processed or ~~maintained.:~~

Identify the documented procedures examined to verify that visitors must be authorized before they are granted access to, and escorted at all times within, areas where cardholder data is processed or maintained.

Modified p. 125 → 121

~~ The facility. <Report Findings Here> ~~ Computer rooms and data centers where cardholder data is stored or transmitted.

• Computer rooms and data centers where cardholder data is stored or transmitted.

Modified p. 126 → 122

~~ The visitor’s name,  The firm represented, and ~~ The onsite personnel authorizing physical access.

• The onsite personnel authorizing physical access.

Modified p. 126 → 122

~~ The visitor’s name,  The firm represented, and ~~ The onsite personnel authorizing physical access.

• The onsite personnel authorizing physical access.

Modified p. 126 → 122

Provide the name of the assessor who attests that the visitor log contains:

Provide the name of the assessor who attests that the visitor log contains: • The visitor’s name,

Modified p. 126 → 122

<Report Findings Here> 9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location’s security at least annually. ☐ ☐ ☐ ☐ ☐ ~~9.5.1.~~ Verify that the storage location security is reviewed at least annually to confirm that backup media storage is secure.

<Report Findings Here> 9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location’s security at least annually. ☐ ☐ ☐ ☐ ☐ 9.5.1 Verify that the storage location security is reviewed at least annually to confirm that backup media storage is secure.

Modified p. 128 → 124

Identify the media ~~inventories~~ logs reviewed. <Report Findings Here> Describe how the media inventory logs verified that:

Identify the media inventory logs reviewed. <Report Findings Here> Describe how the media inventory logs verified that:

Modified p. 128 → 124

 Media inventory logs of all media were observed to be maintained.

• Media inventory logs of all media were observed to be maintained.

Modified p. 128 → 124

~~<Report Findings Here> ~~ Media inventories are performed at least annually. <Report Findings Here> 9.8 Destroy media when it is no longer needed for business or legal reasons as follows: ☐ ☐ ☐ ☐ ☐ 9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following:

• Media inventories are performed at least annually. <Report Findings Here> 9.8 Destroy media when it is no longer needed for business or legal reasons as follows: ☐ ☐ ☐ ☐ ☐ 9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following:

Modified p. 128 → 124

 Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the ~~hard- copy~~ materials cannot be reconstructed.

• Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

Modified p. 128 → 124

 Storage containers used for materials that are to be destroyed must be secured.

• Storage containers used for materials that are to be destroyed must be secured.

Modified p. 128 → 124

 Storage containers used for materials that are to be destroyed must be secured.

• Storage containers used for materials that are to be destroyed must be secured.

Modified p. 128 → 124

 Cardholder data on electronic media must be rendered unrecoverable (e.g. via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).

• Cardholder data on electronic media must be rendered unrecoverable (e.g. via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).

Modified p. 128 → 124

 Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

• Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

Modified p. 128 → 124

 Cardholder data on electronic media must be rendered unrecoverable (e.g. via a secure wipe program in accordance with ~~industry- accepted~~ standards for secure deletion, or by physically destroying the media).

• Cardholder data on electronic media must be rendered unrecoverable (e.g. via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).

Removed p. 130

 Maintaining a list of devices.

Modified p. 130 → 126

 Maintaining a list of devices.

• Maintaining a list of devices.

Modified p. 130 → 126

 Periodically inspecting devices to look for tampering or substitution.

• Periodically inspecting devices to look for tampering or substitution.

Modified p. 130 → 126

 Periodically inspecting devices to look for tampering or substitution.

• Periodically inspecting devices to look for tampering or substitution.

Modified p. 130 → 126

 Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices.

• Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices.

Modified p. 130 → 126

Identify the documented policies and procedures examined to verify they include:

Identify the documented policies and procedures examined to verify they include: • Maintaining a list of devices.

Modified p. 130 → 126

Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices.

• Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices.

Modified p. 130 → 126

~~ Make, model of device. ~~ Location of device (for example, the address of the site or facility where the device is located). ~~ Device serial number or other method of unique identification.~~

• Location of device (for example, the address of the site or facility where the device is located).

Modified p. 130 → 126

~~ Make, model of device. ~~ Location of device (for example, the address of the site or facility where the device is located).  Device serial number or other method of unique identification.

• Location of device (for example, the address of the site or facility where the device is located). • Device serial number or other method of unique identification.

Modified p. 130 → 126

 Make, model of device.

• Make, model of device.

Modified p. 130 → 126

 Location of device (for example, the address of the site or facility where the device is located).

• Location of device (for example, the address of the site or facility where the device is located).

Modified p. 130 → 126

 Device serial number or other method of unique identification.

• Device serial number or other method of unique identification.

Removed p. 131

 Procedures for inspecting devices.

 Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.  Do not install, replace, or return devices without verification.  Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).  Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

Modified p. 131 → 127

 Procedures for inspecting devices. ~~ Frequency of inspections.~~

• Procedures for inspecting devices.

Modified p. 131 → 127

Identify the documented procedures examined to verify that processes are defined to include the following:

Identify the documented procedures examined to verify that processes are defined to include the following: • Procedures for inspecting devices.

Modified p. 131 → 127

 Frequency of inspections.

• Frequency of inspections.

Modified p. 131 → 127

~~ Personnel are aware of procedures for inspecting devices. ~~ All devices are periodically inspected for evidence of tampering and substitution.

• All devices are periodically inspected for evidence of tampering and substitution.

Modified p. 131 → 127

 Personnel are aware of procedures for inspecting devices.

• Personnel are aware of procedures for inspecting devices.

Modified p. 131 → 127

 All devices are periodically inspected for evidence of tampering and substitution.

• All devices are periodically inspected for evidence of tampering and substitution.

Modified p. 131 → 127

 All devices are periodically inspected for evidence of tampering.

• All devices are periodically inspected for evidence of tampering.

Modified p. 131 → 127

~~<Report Findings Here> ~~ All devices are periodically inspected for evidence of substitution.

• All devices are periodically inspected for evidence of substitution.

Modified p. 132 → 128

 Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.  Not to install, replace, or return devices without verification.  Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).  Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices. • Not to install, replace, or return devices without verification. • Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices). • Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

Modified p. 132 → 128

 Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

Modified p. 132 → 128

 Not to install, replace, or return devices without verification.

• Not to install, replace, or return devices without verification.

Modified p. 132 → 128

 Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

Modified p. 132 → 128

 Reporting all suspicious behavior to appropriate personnel (for example, a manager or security officer).

• Reporting all suspicious behavior to appropriate personnel (for example, a manager or security officer).

Modified p. 132 → 128

 Reporting tampering or substitution of devices.

• Reporting tampering or substitution of devices.

Removed p. 133

 In use <Report Findings Here>  Known to all affected parties <Report Findings Here>

Modified p. 133 → 128

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) Not Tested~~ 9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have received training and are aware of the procedures for the following:

<Report Findings Here> 9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have received training and are aware of the procedures for the following:

Modified p. 133 → 128

 Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.  Not to install, replace, or return devices without verification.  Being aware of suspicious behavior around devices (for example, attempts ~~by unknown persons to unplug or open devices).  Reporting suspicious behavior and indications~~ of ~~device tampering or substitution to appropriate~~ personnel ~~(for example, to a manager or security officer).~~

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices. • Not to install, replace, or return devices without verification. • Being aware of suspicious behavior around devices (for example, attempts Identify the sample of personnel at point-of-sale locations interviewed.

Modified p. 133 → 128

 Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.

Modified p. 133 → 128

~~<Report Findings Here> ~~ Not to install, replace, or return devices without verification.

• Not to install, replace, or return devices without verification.

Modified p. 133 → 128

~~<Report Findings Here> ~~ Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

• Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

Modified p. 133 → 129

~~<Report Findings Here> ~~ Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

Modified p. 134 → 130

 Audit trails are enabled and active for system components.

• Audit trails are enabled and active for system components.

Modified p. 134 → 130

 Audit trails are enabled and active for system components.

• Audit trails are enabled and active for system components.

Modified p. 134 → 130

 Access to system components is linked to individual users.

• Access to system components is linked to individual users.

Modified p. 134 → 130

 Access to system components is linked to individual users.

• Access to system components is linked to individual users.

Modified p. 134 → 130

 Audit trails are enabled and active for system components.

• Audit trails are enabled and active for system components.

Modified p. 134 → 130

~~<Report Findings Here> ~~ Access to system components is linked to individual users.

• Access to system components is linked to individual users.

Removed p. 135

<Report Findings Here> Identify the sample of audit logs selected for 10.2.1-10.2.7.

Modified p. 135 → 130

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 10.2 Implement automated audit trails for all system components to reconstruct the following events: ☐ ☐ ☐ ☐ ☐ 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:

<Report Findings Here> 10.2 Implement automated audit trails for all system components to reconstruct the following events: ☐ ☐ ☐ ☐ ☐ 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:

Modified p. 135 → 130

 All individual access to cardholder data.

• All individual access to cardholder data.

Modified p. 135 → 130

 All actions taken by any individual with root or administrative privileges.

• All actions taken by any individual with root or administrative privileges.

Modified p. 135 → 130

 Access to all audit trails.

• Access to all audit trails.

Modified p. 135 → 130

 Invalid logical access attempts.

• Invalid logical access attempts.

Modified p. 135 → 130

 Use of and changes to identification and authentication mechanisms, including: o All elevation of privileges. o All changes, additions, or deletions to any account with root or administrative privileges.

• Use of and changes to identification and authentication mechanisms, including: o All elevation of privileges. o All changes, additions, or deletions to any account with root or administrative privileges.

Modified p. 135 → 130

 Initialization of audit logs.

• Initialization of audit logs.

Modified p. 135 → 130

 Stopping or pausing of audit logs.

• Stopping or pausing of audit logs.

Modified p. 135 → 130

 Creation and deletion of system level objects.

• Creation and deletion of system level objects.

Modified p. 135 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that all individual access to cardholder data is logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that all individual access to cardholder data is logged.

Modified p. 135 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings ~~verifiedall~~ actions taken by any individual with root or administrative privileges are logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that all actions taken by any individual with root or administrative privileges are logged.

Modified p. 136 → 131

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 10.2.3 Access to all audit trails. ☐ ☐ ☐ ☐ ☐ 10.2.3 Verify access to all audit trails is logged.

<Report Findings Here> 10.2.3 Access to all audit trails. ☐ ☐ ☐ ☐ ☐ 10.2.3 Verify access to all audit trails is logged.

Modified p. 136 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that access to all audit trails is logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that access to all audit trails is logged.

Modified p. 136 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that invalid logical access attempts are logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that invalid logical access attempts are logged.

Modified p. 136 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that use of identification and authentication mechanisms is logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that use of identification and authentication mechanisms is logged.

Modified p. 136 → 131

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that all elevation of privileges is logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that all elevation of privileges is logged.

Modified p. 136 → 132

~~<Report~~ Findings ~~Here>~~ 10.2.5.c Verify all changes, additions, or deletions to any account with root or administrative privileges are logged.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 10.2.5.c Verify all changes, additions, or deletions to any account with root or administrative privileges are logged.

Modified p. 136 → 132

~~ Initialization of audit logs. ~~ Stopping or pausing of audit logs.

• Stopping or pausing of audit logs.

Modified p. 136 → 132

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that initialization of audit logs is logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that initialization of audit logs is logged.

Modified p. 136 → 132

<Report Findings Here> For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that stopping and pausing of audit logs is logged.

<Report Findings Here> For all items in the sample at 10.2, describe how audit logs and audit log settings verified that stopping and pausing of audit logs is logged.

Modified p. 136 → 132

For all items in the sample at 10.2, describe how ~~configuration~~ settings verified that creation and deletion of system level objects are logged.

For all items in the sample at 10.2, describe how audit logs and audit log settings verified that creation and deletion of system level objects are logged.

Removed p. 137

 User identification  Type of event  Date and time  Success or failure indication  Origination of event <Report Findings Here> 10.3.1 User identification ☐ ☐ ☐ ☐ ☐ 10.3.1 Verify user identification is included in log entries.

Modified p. 137 → 132

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 10.3 Record at least the following audit trail entries for all system components for each event: ☐ ☐ ☐ ☐ ☐ 10.3 Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:

<Report Findings Here> 10.3 Record at least the following audit trail entries for all system components for each event: ☐ ☐ ☐ ☐ ☐ 10.3 Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:

Modified p. 137 → 132

~~ User identification  Type of event  Date and time  Success or failure indication ~~ Origination of event <Report Findings Here> Identify the sample of audit logs from 10.2.1-10.2.7 observed to verify the following are included in log entries:

• Origination of event <Report Findings Here> Identify the sample of audit logs from 10.2.1-10.2.7 observed to verify the following are included in log entries:

Modified p. 137 → 133

<Report Findings Here> 10.3.3 Date and time ☐ ☐ ☐ ☐ ☐ 10.3.3 Verify ~~date and time~~ stamp is included in log entries.

<Report Findings Here> 10.3.3 Date and time ☐ ☐ ☐ ☐ ☐ 10.3.3 Verify date-and-time stamp is included in log entries.

Modified p. 137 → 133

<Report Findings Here> 10.3.4 Success or failure indication ☐ ☐ ☐ ☐ ☐

<Report Findings Here> 10.3.4 Success or failure indication ☐ ☐ ☐ ☐ ☐ 10.3.4 Verify success or failure indication is included in log entries.

Removed p. 138

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 10.3.4 Verify success or failure indication is included in log entries.

Identify the time synchronization technologies in use. (If NTP, include version) <Report Findings Here> Identify the documented time-synchronization configuration standards examined to verify that time synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

Modified p. 138 → 133

For all logs in the sample at 10.3, describe how the audit logs ~~verifiedsuccess~~ or failure indication is included in log entries.

For all logs in the sample at 10.3, describe how the audit logs verified that success or failure indication is included in log entries.

Modified p. 138 → 133

For all logs in the sample at 10.3, describe how the audit logs ~~verifiedorigination~~ of event is included in log entries.

For all logs in the sample at 10.3, describe how the audit logs verified that origination of event is included in log entries.

Modified p. 138 → 133

For all logs in the sample at 10.3, describe how the audit logs ~~verifiedthe~~ identity or name of affected data, system component, or resource is included in log entries.

For all logs in the sample at 10.3, describe how the audit logs verified that the identity or name of affected data, system component, or resource is included in log entries.

Modified p. 138 → 134

~~ Implemented. <Report Findings Here> ~~ Kept current, per the documented process. <Report Findings Here> 10.4.1 Critical systems have the correct and consistent time. ☐ ☐ ☐ ☐ ☐ 10.4.1.a Examine the process for acquiring, distributing and storing the correct time within the organization to verify that:

• Kept current, per the documented process. <Report Findings Here> 10.4.1 Critical systems have the correct and consistent time. ☐ ☐ ☐ ☐ ☐ 10.4.1.a Examine the process for acquiring, distributing and storing the correct time within the organization to verify that:

Removed p. 139

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place  Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.  Where there is more than one designated time server, the time servers peer with one another to keep accurate time.  Systems receive time information only from designated central time server(s).

 Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

Modified p. 139 → 134

 Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

• Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

Modified p. 139 → 134

~~<Report Findings Here> ~~ Where there is more than one designated time server, the time servers peer with one another to keep accurate time.

• Where there is more than one designated time server, the time servers peer with one another to keep accurate time.

Modified p. 139 → 134

~~<Report Findings Here> ~~ Systems receive time information only from designated central time server(s).

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

Modified p. 139 → 134

 Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.  Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.  Systems receive time only from designated central time server(s).

• Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

Modified p. 139 → 134

Identify the sample of system components selected for 10.4.1.b-10.4.2.b <Report Findings Here> For all items in the sample, describe how the time-related system-parameter settings verified:

• Only the designated central time server(s) receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

• Where there is more than one designated time server, the designated Identify the sample of system components selected for 10.4.1.b-10.4.2.b <Report Findings Here> For all items in the sample, describe how the time-related system-parameter settings verified:

Modified p. 139 → 134

~~<Report Findings Here> ~~ Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.

• Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.

Modified p. 139 → 135

~~<Report Findings Here> ~~ Systems receive time only from designated central time server(s).

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

Modified p. 139 → 135

~~<Report Findings Here> 10.4.2.b Examine system configurations, time synchronization settings and logs, and processes to verify that any changes~~ For all items in the sample from 10.4.1, describe how configuration settings and time synchronization settings verified that any changes to time settings on critical systems are logged.

For all items in the sample from 10.4.1, describe how configuration settings and time synchronization settings verified that any changes to time settings on critical systems are logged.

Removed p. 140

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place to time settings on critical systems are logged, monitored, and reviewed.

Modified p. 140 → 135

For all items in the sample from 10.4.1, describe how the examined logs verified that any changes to time settings on critical systems are logged.

<Report Findings Here> For all items in the sample from 10.4.1, describe how the examined logs verified that any changes to time settings on critical systems are logged.

Modified p. 140 → 135

~~ Logged <Report Findings Here>  Monitored <Report Findings Here> ~~ Reviewed <Report Findings Here> 10.4.3 Time settings are received from industry-accepted time sources. ☐ ☐ ☐ ☐ ☐ 10.4.3 Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock). Optionally, those updates can be ~~encrypted with a symmetric key, and access control lists can be created that specify~~ the ~~IP addresses~~ of ~~client …~~

• Reviewed <Report Findings Here> 10.4.3 Time settings are received from industry-accepted time sources. ☐ ☐ ☐ ☐ ☐ 10.4.3 Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock). Optionally, those updates can be Identify the sample of time servers selected for this testing procedure.

Modified p. 140 → 136

~~ That the time servers receive time updates from specific, industry-accepted external sources. OR <Report Findings Here> ~~ That time updates are encrypted with a symmetric key, and access control lists specify the IP addresses of client machines.

• That time updates are encrypted with a symmetric key, and access control lists specify the IP addresses of client machines.

Modified p. 140 → 136

<Report Findings Here> 10.5 Secure audit trails so they cannot be altered. ☐ ☐ ☐ ☐ ☐

<Report Findings Here> 10.5 Secure audit trails so they cannot be altered. ☐ ☐ ☐ ☐ ☐ 10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered as follows:

Modified p. 141 → 136

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~10.5 Interview system administrators~~ and ~~examine system configurations and permissions to verify~~ that ~~audit trails are secured so~~ that ~~they cannot~~ be ~~altered as follows:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).

Modified p. 141 → 136

 Only individuals who have a job-related need can view audit trail files.

• Only individuals who have a job-related need can view audit trail files.

Modified p. 141 → 136

 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

• Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

Modified p. 141 → 136

 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter, including: - That current audit trail files are promptly backed up to the centralized log server or media - The frequency that audit trail files are backed up - That the centralized log server or media is difficult to alter  Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal log …

• Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter, including: - That current audit trail files are promptly backed up to the centralized log server or media - The frequency that audit trail files are backed

Modified p. 141 → 136

 Use file-integrity monitoring or ~~change- detection~~ software on logs to ensure that existing log data cannot be changed without generating alerts.

• Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts.

Modified p. 141 → 136

<Report Findings Here> 10.5.1 Limit viewing of audit trails to those with a job-related need. ☐ ☐ ☐ ☐ ☐ ~~10.5.1 Only individuals who have a job- related need can view audit trail files.~~

<Report Findings Here> 10.5.1 Limit viewing of audit trails to those with a job-related need. ☐ ☐ ☐ ☐ ☐

Modified p. 142 → 137

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ CCW N/A Not Tested~~ 10.5.2 Protect audit trail files from unauthorized modifications. ☐ ☐ ☐ ☐ ☐ 10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

<Report Findings Here> 10.5.2 Protect audit trail files from unauthorized modifications. ☐ ☐ ☐ ☐ ☐ 10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

Removed p. 143

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 10.6 Perform the following:

 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components Identify the responsible personnel interviewed who confirm that the following are reviewed at least daily:

 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions.

Modified p. 143 → 138

~~ All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components ~~ Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

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

Modified p. 143 → 138

~~ All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components ~~ Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

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

Modified p. 143 → 138

 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions.

• All security events • Logs of all system components that store, process, or transmit CHD and/or SAD • Logs of all critical system components • Logs of all servers and system components that perform security functions.

Modified p. 143 → 139

<Report Findings Here> ~~10.6.1.b Observe~~ processes ~~and interview personnel~~ to verify that the following are reviewed at least daily:

<Report Findings Here> Describe how processes were observed to verify that the following are reviewed at least daily:

Removed p. 144

<Report Findings Here> Identify the responsible personnel interviewed who confirm that reviews are performed in accordance with organization’s policies and risk management strategy.

Modified p. 144 → 139

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~Place  Logs of all servers~~ and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Describe how processes were observed to verify that the following are reviewed at least daily:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested 10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily:

Modified p. 144 → 139

~~ All security events. <Report Findings Here> ~~ Logs of all system components that store, process, or transmit CHD and/or SAD.

• Logs of all system components that store, process, or transmit CHD and/or SAD.

Modified p. 144 → 139

~~<Report Findings Here>  Logs of all critical system components. <Report Findings Here> ~~ Logs of all servers and system components that perform security functions.

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

Modified p. 144 → 139

<Report Findings Here> 10.6.2.b Examine the organization’s risk assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.

<Report Findings Here> 10.6.2.b Examine the organization’s risk assessment documentation and interview personnel to verify that reviews are performed in accordance with Identify the organization’s risk assessment documentation examined to verify that reviews are performed in accordance with the organization’s policies and risk management strategy.

Modified p. 144 → 140

Identify the ~~organization’s risk assessment documentation examined to verify~~ that reviews are performed in accordance with ~~the~~ organization’s policies and risk management strategy.

Identify the responsible personnel interviewed who confirm that reviews are performed in accordance with organization’s policies and risk management strategy.

Modified p. 144 → 140

<Report Findings Here> 10.6.3 Follow up exceptions and anomalies identified during the review process. ☐ ☐ ☐ ☐ ☐

<Report Findings Here> 10.6.3 Follow up exceptions and anomalies identified during the review process. ☐ ☐ ☐ ☐ ☐ 10.6.3.a Examine security policies and procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.

Removed p. 145

<Report Findings Here> Describe how processes were observed to verify that at least the last three months’ logs are immediately available for analysis.

Modified p. 145 → 140

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested ~~10.6.3.a Examine security~~ policies and ~~procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place organization’s policies and risk management strategy.

Modified p. 145 → 140

 Audit log retention policies.

• Audit log retention policies.

Modified p. 145 → 140

 Audit log retention policies.

• Audit log retention policies.

Modified p. 145 → 140

 Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.

• Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.

Modified p. 145 → 140

 Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.

• Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.

Modified p. 145 → 140

<Report Findings Here> 10.7.c Interview personnel and observe processes to verify that at least the last three months’ logs are immediately available for analysis.

<Report Findings Here> 10.7.c Interview personnel and observe processes to verify that at least the last Identify the responsible personnel interviewed who confirm that at least the last three months’ logs are immediately available for analysis.

Modified p. 145 → 141

~~Identify the responsible personnel interviewed who confirm~~ that at least the last three months’ logs are immediately available for analysis.

Describe how processes were observed to verify that at least the last three months’ logs are immediately available for analysis.

Removed p. 146

 Firewalls  IDS/IPS  FIM  Anti-virus  Physical access controls  Logical access controls  Audit logging mechanisms  Segmentation controls (if used) Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.

 Firewalls  IDS/IPS  FIM  Anti-virus  Physical access controls  Logical access controls  Audit logging mechanisms  Segmentation controls (if used) Identify the documented policies and procedures examined to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:.

<Report Findings Here> Describe how the detection and alerting processes verified that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.

Modified p. 146 → 141

10.8.a Examine documented policies and procedures to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure ~~of:.~~

• Segmentation controls (if used) 10.8.a Examine documented policies and procedures to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

Modified p. 146 → 141

~~ Firewalls  IDS/IPS  FIM  Anti-virus  Physical access controls  Logical access controls  Audit logging mechanisms ~~ Segmentation controls (if used) <Report Findings Here> 10.8.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.

• Segmentation controls (if used) <Report Findings Here> 10.8.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that Identify the responsible personnel interviewed who confirm that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.

Modified p. 146 → 142

~~Identify~~ the ~~responsible personnel interviewed who confirm~~ that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.

Describe how examination of the detection and alerting processes verified that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.

Modified p. 146 → 143

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~10.8 Additional requirement for service providers only: Implement~~ a ~~process for~~ the ~~timely detection and reporting of failures of critical~~ security ~~control systems, including but not limited to~~ failure ~~of:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place required as a result of the security failure

Removed p. 147

 Restoring security functions  Identifying and documenting the duration (date and time start to end) of the security 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 Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.

 Restoring security functions  Identifying and documenting the duration (date and time start to end) of the security 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 …

Modified p. 147 → 141

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~10.8.1 Additional requirement~~ for ~~service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place three months’ logs are immediately available for analysis.

Modified p. 147 → 142

10.8.1.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond to a security control failure, and include:

• Resuming monitoring of security controls 10.8.1.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond to a security control failure, and include:

Removed p. 148

 Restoring security functions  Identifying and documenting the duration (date and time start to end) of the security 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 <Report Findings Here> 10.8.1.b Examine records to verify that security control failures are documented to include:

Modified p. 148 → 142

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place ~~ 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 Identify the responsible personnel interviewed who confirm that processes are defined and implemented to respond to a security control …

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ CCW N/A Not Tested Place failure of a critical security control results in the generation of an alert.

Modified p. 148 → 143

~~ Identification of cause(s) of the failure, including root cause  Duration (date and time start and end) of the security failure ~~ Details of the remediation required to address the root cause Identify the sample of records examined to verify that security control failures are documented to include:

• Details of the remediation required to address the root cause Identify the sample of records examined to verify that security control failures are documented to include:

Modified p. 148 → 143

~~ Identification of cause(s) of the failure, including root cause  Duration (date and time start and end) of the security failure ~~ Details of the remediation required to address the root cause <Report Findings Here> For each sampled record, describe how the documented security control failures include:

• Details of the remediation required to address the root cause <Report Findings Here> For each sampled record, describe how the documented security control failures include:

Modified p. 148 → 143

~~ Identification of cause(s) of the failure, including root cause  Duration (date and time start and end) of the security failure ~~ Details of the remediation required to address the root cause <Report Findings Here> 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐

• Details of the remediation required to address the root cause <Report Findings Here> 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐

Modified p. 150 → 145

 WLAN cards inserted into system components.

• WLAN cards inserted into system components.

Modified p. 150 → 145

 WLAN cards inserted into system components.

• WLAN cards inserted into system components.

Modified p. 150 → 145

 Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.).

• Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.).

Modified p. 150 → 145

 Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.).

• Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.).

Modified p. 150 → 145

 Wireless devices attached to a network port or network device.

• Wireless devices attached to a network port or network device.

Modified p. 150 → 145

 Wireless devices attached to a network port or network device.

• Wireless devices attached to a network port or network device.

Modified p. 150 → 145

Indicate whether wireless scanning is utilized. (yes/no) If ‘no,’ mark the remainder of 11.1.c as ‘not applicable.’

Indicate whether wireless scanning is utilized. (yes/no) If ‘no,’ mark the remainder of 11.1.c as ‘not applicable.’ <Report Findings Here>

Removed p. 151

 Unauthorized wireless access points are identified.

Modified p. 151 → 146

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place  Authorized and unauthorized wireless access points are identified, and ~~ The scan is performed at least quarterly for all system components and facilities.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place • Authorized and unauthorized wireless access points are identified, and

Modified p. 151 → 146

If ‘yes,’ Identify/describe the output from recent wireless scans examined to verify that:

If ‘yes,’ Identify/describe the output from recent wireless scans examined to verify that: • Authorized wireless access points are identified.

Modified p. 151 → 146

~~ Authorized~~ wireless access points are identified.

• Unauthorized wireless access points are identified.

Modified p. 151 → 146

 The scan is performed at least quarterly.

• The scan is performed at least quarterly.

Modified p. 151 → 146

 The scan covers all system components.

• The scan covers all system components.

Modified p. 151 → 146

 The scan covers all facilities.

• The scan covers all facilities.

Modified p. 153 → 148

~~ The scan was performed by a qualified internal resource <Report Findings Here> ~~ Organizational independence of the tester exists. <Report Findings Here> 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

• Organizational independence of the tester exists. <Report Findings Here> 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

Modified p. 154 → 149

 For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

• For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

Modified p. 154 → 149

 For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

• For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

Modified p. 155 → 150

 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).

Modified p. 155 → 150

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

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

Modified p. 155 → 150

 Includes testing from both inside and outside of the network.

• Includes testing from both inside and outside of the network.

Modified p. 155 → 150

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

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

Modified p. 155 → 150

 Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.

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

Modified p. 155 → 150

 Specifies retention of penetration testing results and remediation activities results.

• Specifies retention of penetration testing results and remediation activities results.

Modified p. 156 → 151

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

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

Modified p. 156 → 151

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

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

Modified p. 156 → 151

 Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.

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

Modified p. 156 → 151

 Specifies retention of penetration testing results and remediation activities results.

• Specifies retention of penetration testing results and remediation activities results.

Modified p. 156 → 151

 Is based on industry-accepted penetration testing approaches.

• Is based on industry-accepted penetration testing approaches.

Modified p. 156 → 151

 Includes testing from both inside and outside the network.

• Includes testing from both inside and outside the network.

Modified p. 156 → 151

 Based on industry-accepted penetration testing approaches.

• Based on industry-accepted penetration testing approaches.

Modified p. 156 → 151

 Coverage for the entire CDE perimeter and critical systems.

• Coverage for the entire CDE perimeter and critical systems.

Modified p. 156 → 151

 Testing from both inside and outside the network.

• Testing from both inside and outside the network.

Modified p. 156 → 151

 Testing to validate any segmentation and scope reduction controls.

• Testing to validate any segmentation and scope reduction controls.

Modified p. 156 → 151

 Review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Review and consideration of threats and vulnerabilities experienced in the last 12 months.

Modified p. 156 → 151

 Retention of penetration testing results and remediation activities results.

• Retention of penetration testing results and remediation activities results.

Modified p. 157 → 152

 Based on industry-accepted penetration testing approaches.

• Based on industry-accepted penetration testing approaches.

Modified p. 157 → 152

 Coverage for the entire CDE perimeter and critical systems.

• Coverage for the entire CDE perimeter and critical systems.

Modified p. 157 → 152

 Testing from both inside and outside the network.

• Testing from both inside and outside the network.

Modified p. 157 → 152

 Testing to validate any segmentation and scope reduction controls.

• Testing to validate any segmentation and scope reduction controls.

Modified p. 157 → 152

 Review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Review and consideration of threats and vulnerabilities experienced in the last 12 months.

Modified p. 157 → 152

 Retention of penetration testing results and remediation activities results.

• Retention of penetration testing results and remediation activities results.

Modified p. 157 → 152

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~Place~~ Identify the responsible personnel interviewed who confirm the penetration•testing methodology implemented includes at least the following:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Identify the responsible personnel interviewed who confirm the penetration•testing methodology implemented includes at least the following:

Modified p. 157 → 152

~~ Per the defined methodology  At least annually ~~ After any significant changes to the environment Identify the documented external penetration test results reviewed to verify that external penetration testing is performed:

• After any significant changes to the environment Identify the documented external penetration test results reviewed to verify that external penetration testing is performed:

Modified p. 157 → 152

~~ Per the defined methodology ~~ At least annually <Report Findings Here> Describe how the scope of work verified that external penetration testing is performed:

• At least annually <Report Findings Here> Describe how the scope of work verified that external penetration testing is performed:

Modified p. 157 → 152

~~ Per the defined methodology ~~ At least annually <Report Findings Here>

• At least annually <Report Findings Here>

Modified p. 158 → 153

~~ Per~~ the ~~defined methodology~~ Identify the documented internal penetration test results reviewed to verify that internal penetration testing is performed:

• After any significant changes to the environment Identify the documented internal penetration test results reviewed to verify that internal penetration testing is performed:

Modified p. 158 → 153

 Per the defined methodology ~~ At least annually <Report Findings Here>~~

• Per the defined methodology

Modified p. 159 → 153

~~ Per the defined methodology ~~ At least annually <Report Findings Here> Indicate whether any significant internal infrastructure or application upgrade or modification occurred during the past 12 months. (yes/no) <Report Findings Here> ~~Identify the documented internal penetration test results reviewed to verify that internal penetration tests are performed after significant internal infrastructure or application upgrade.~~

• At least annually <Report Findings Here> Indicate whether any significant internal infrastructure or application upgrade or modification occurred during the past 12 months. (yes/no) <Report Findings Here>

Modified p. 159 → 154

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~Place  At least annually  After any significant changes~~ to ~~the environment Describe how the scope of work verified~~ that internal penetration ~~testing is performed:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Identify the documented internal penetration test results reviewed to verify that internal penetration tests are performed after significant internal infrastructure or application upgrade.

Removed p. 160

<Report Findings Here> Describe how the segmentation controls verified that segmentation methods:

Modified p. 160 → 154

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested~~ 11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

Modified p. 160 → 154

Indicate whether segmentation is used to isolate the CDE from other networks. (yes/no) If “no,” mark the remainder of ~~11.3.4.a~~ and ~~11.3.4.b~~ as “Not Applicable.” <Report Findings Here> If “yes,” identify the defined penetration-testing methodology examined to verify procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out- of-scope systems from systems in the CDE.

Indicate whether segmentation is used to isolate the CDE from other networks. (yes/no) If “no,” mark the remainder of 11.3.4.a, 11.3.4.b and 11.3.4.c as “Not Applicable.” <Report Findings Here> If “yes,” identify the defined penetration-testing methodology examined to verify procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out- of-scope systems from systems in the CDE.

Modified p. 160 → 155

~~ Are operational and effective. <Report Findings Here> ~~ Isolate all out-of-scope systems from systems in the CDE.

• Isolate all out-of-scope systems from systems in the CDE.

Modified p. 160 → 155

 Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.  The penetration testing covers all segmentation controls/methods in use.  The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

• Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.

Modified p. 160 → 155

 Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.

• Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.

Modified p. 160 → 155

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

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

Removed p. 161

11.3.4.1.a Examine the results from the most recent penetration test to verify that:  Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

Modified p. 161 → 156

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place ~~11.3.4.1 Additional requirement for service providers only: If segmentation~~ is ~~used, confirm PCI DSS scope by performing penetration testing on~~ segmentation controls at least every six months and after any changes to segmentation controls/methods. ~~Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place 11.3.4.1.a Examine the results from the most recent penetration test to verify that:

• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

Modified p. 161 → 156

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

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

Modified p. 161 → 156

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

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

Modified p. 161 → 156

 Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

Modified p. 161 → 156

 At the perimeter of the cardholder data environment.

• At the perimeter of the cardholder data environment.

Modified p. 161 → 156

 At critical points in the cardholder data environment.

• At critical points in the cardholder data environment.

Removed p. 162

<Report Findings Here>  At critical points in the cardholder data environment.

Modified p. 162 → 156

Describe how system configurations ~~verifiedthat~~ techniques are in place to monitor all traffic:

<Report Findings Here> Describe how system configurations verified that techniques are in place to monitor all traffic:

Modified p. 162 → 156

 At the perimeter of the cardholder data environment.

• At the perimeter of the cardholder data environment.

Modified p. 162 → 157

 At critical points in the cardholder data environment.

• At critical points in the cardholder data environment.

Modified p. 162 → 157

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place  At ~~the perimeter of~~ the cardholder data environment.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place • At critical points in the cardholder data environment.

Modified p. 162 → 157

 Configured per vendor instructions to ensure optimal protection.

• Configured per vendor instructions to ensure optimal protection.

Modified p. 162 → 157

~~<Report Findings Here> ~~ Maintained per vendor instructions to ensure optimal protection.

• Maintained per vendor instructions to ensure optimal protection.

Modified p. 162 → 157

~~<Report Findings Here> ~~ Updated per vendor instructions to ensure optimal protection.

• Updated per vendor instructions to ensure optimal protection.

Removed p. 163

Examples of files that should be monitored:  System executables  Application executables  Configuration and parameter files  Centrally stored, historical or archived, log and audit files  Additional critical files determined by entity (i.e., through risk assessment or other means) Identify the results from monitored files reviewed to verify the use of a change-detection mechanism.

<Report Findings Here>  Perform critical file comparisons at least weekly. <Report Findings Here> 11.5.1 Implement a process to respond to any alerts generated by the change-detection solution. ☐ ☐ ☐ ☐ ☐ 11.5.1 Interview personnel to verify that all alerts are investigated and resolved.

Modified p. 163 → 158

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~11.5.a Verify the use of a change- detection mechanism by observing system settings and monitored files, as~~ well as reviewing results from monitoring activities.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place well as reviewing results from monitoring activities.

Modified p. 163 → 158

~~<Report Findings Here>~~ Describe how the following verified the use of a change-detection mechanism:

• Additional critical files determined by entity (i.e., through risk assessment or other means) Describe how the following verified the use of a change-detection mechanism:

Modified p. 163 → 158

~~ System settings <Report Findings Here> ~~ Monitored files <Report Findings Here> 11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification (including changes, additions and deletions) of critical files, and to perform critical file comparisons at least weekly.

• Monitored files <Report Findings Here> 11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification (including changes, additions and deletions) of critical files, and to perform critical file comparisons at least weekly.

Modified p. 163 → 158

 Alert personnel to unauthorized modification (including changes, additions and deletions) of critical files.

• Alert personnel to unauthorized modification (including changes, additions and deletions) of critical files.

Modified p. 163 → 158

Identify the responsible personnel interviewed who confirm that all alerts are investigated and resolved <Report Findings Here> 11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 11.6 Examine documentation and interview personnel to verify that security ~~Identify the document reviewed to verify that security~~ policies and operational procedures for security monitoring and testing ~~are documented.~~

Identify the responsible personnel interviewed who confirm that all alerts are investigated and resolved <Report Findings Here> 11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties. ☐ ☐ ☐ ☐ ☐ 11.6 Examine documentation and interview personnel to verify that security policies and operational procedures for security monitoring and testing are:

Removed p. 164

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place policies and operational procedures for security monitoring and testing are:

Modified p. 164 → 158

~~ Documented,  In use, and ~~ Known to all affected parties.

• Known to all affected parties.

Modified p. 164 → 158

Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for security monitoring and testing are:

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for security monitoring and testing are:

Modified p. 165 → 159

 All relevant personnel. <Report Findings Here>  All relevant vendors and business partners. <Report Findings Here> 12.1.1 Review the security policy at least annually and update the policy when business objectives or the risk environment change. ☐ ☐ ☐ ☐ ☐ 12.1.1 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.

• All relevant personnel. <Report Findings Here> • All relevant vendors and business partners. <Report Findings Here> 12.1.1 Review the security policy at least annually and update the policy when business objectives or the risk environment change. ☐ ☐ ☐ ☐ ☐ 12.1.1 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.

Modified p. 165 → 159

~~ Reviewed at least annually. <Report Findings Here> ~~ Updated as needed to reflect changes to business objectives or the risk environment.

• Updated as needed to reflect changes to business objectives or the risk environment.

Modified p. 165 → 159

 Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), ~~ Identifies critical assets, threats, and vulnerabilities, and  Results in a formal, documented analysis of risk.~~

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),

Modified p. 165 → 159

 Identifies critical assets, threats, and vulnerabilities ~~ Results in a formal, documented analysis of risk.~~

• Identifies critical assets, threats, and vulnerabilities

Modified p. 165 → 159

 Identifies critical assets, threats, and vulnerabilities ~~ Results in a formal, documented analysis of risk.~~

• Identifies critical assets, threats, and vulnerabilities

Modified p. 167 → 161

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~Identify the usage policies for all identified critical technologies reviewed~~ to verify the following policies ~~(12.3.1-12.3.10)~~ are ~~defined:~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Place responsible personnel to verify the following policies are implemented and followed:

Modified p. 167 → 161

 Explicit approval from authorized parties to use the technologies.

• Explicit approval from authorized parties to use the technologies.

Modified p. 167 → 161

 All technology use to be authenticated with user ID and password or other authentication item.

• All technology use to be authenticated with user ID and password or other authentication item.

Modified p. 167 → 161

 A list of all devices and personnel authorized to use the devices.

• A list of all devices and personnel authorized to use the devices.

Modified p. 167 → 161

 A method to accurately and readily determine owner, contact information, and purpose.

• A method to accurately and readily determine owner, contact information, and purpose.

Modified p. 167 → 161

 Acceptable uses for the technology.

• Acceptable uses for the technology.

Modified p. 167 → 161

 Acceptable network locations for the technology.

• Acceptable network locations for the technology.

Modified p. 167 → 161

 A list of company-approved products.

• A list of company-approved products.

Modified p. 167 → 161

 Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

• Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

Modified p. 167 → 161

 Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

• Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

Modified p. 167 → 161

 Prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

• Prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

Modified p. 168 → 162

 Explicit approval from authorized parties to use the technologies.

• Explicit approval from authorized parties to use the technologies.

Modified p. 168 → 162

 All technology use to be authenticated with user ID and password or other authentication item.

• All technology use to be authenticated with user ID and password or other authentication item.

Modified p. 168 → 162

 A list of all devices and personnel authorized to use the devices.

• A list of all devices and personnel authorized to use the devices.

Modified p. 168 → 162

 A method to accurately and readily determine owner, contact information, and purpose.

• A method to accurately and readily determine owner, contact information, and purpose.

Modified p. 168 → 162

 Acceptable uses for the technology.

• Acceptable uses for the technology.

Modified p. 168 → 162

 Acceptable network locations for the technology.

• Acceptable network locations for the technology.

Modified p. 168 → 162

 A list of company-approved products.

• A list of company-approved products.

Modified p. 168 → 162

 Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

• Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

Modified p. 168 → 162

 Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

• Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

Modified p. 168 → 162

 Prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

• Prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

Modified p. 169 → 163

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~12.3.2 Authentication for use of the technology. ☐ ☐ ☐ ☐ ☐~~ 12.3.2 Verify that the usage policies include processes for all technology use to be authenticated with user ID and password or other authentication item (for example, token).

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.3.2 Verify that the usage policies include processes for all technology use to be authenticated with user ID and password or other authentication item (for example, token).

Modified p. 169 → 163

<Report Findings Here> 12.3.3 A list of all such devices and personnel with access. ☐ ☐ ☐ ☐ ☐ 12.3.3 Verify that the usage policies define:

<Report Findings Here> 12.3.3 A list of all such devices and personnel with access. ☐ ☐ ☐ ☐ ☐ 12.3.3 Verify that the usage policies define: • A list of all critical devices, and

Modified p. 169 → 163

~~ A list of all critical devices, and ~~ A list of personnel authorized to use the devices.

• A list of personnel authorized to use the devices.

Modified p. 169 → 163

~~ A list of all critical devices, and ~~ A list of personnel authorized to use the devices.

• A list of personnel authorized to use the devices.

Modified p. 169 → 163

Provide the name of the assessor who attests that the usage policies were verified to define:

Provide the name of the assessor who attests that the usage policies were verified to define: • A list of all critical devices, and

Modified p. 169 → 163

Provide the name of the assessor who attests that the usage policies were verified to define a method to accurately and readily determine:

Provide the name of the assessor who attests that the usage policies were verified to define a method to accurately and readily determine: • Owner

Modified p. 169 → 163

 Contact Information <Report Findings Here> 12.3.5 Acceptable uses of the technology. ☐ ☐ ☐ ☐ ☐ 12.3.5 Verify that the usage policies define acceptable uses for the technology.

• Contact Information <Report Findings Here> 12.3.5 Acceptable uses of the technology. ☐ ☐ ☐ ☐ ☐ 12.3.5 Verify that the usage policies define acceptable uses for the technology.

Modified p. 169 → 163

<Report Findings Here> 12.3.7 List of company-approved products. ☐ ☐ ☐ ☐ ☐

<Report Findings Here> 12.3.7 List of company-approved products. ☐ ☐ ☐ ☐ ☐ 12.3.7 Verify that the usage policies include a list of company-approved products.

Removed p. 170

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.3.7 Verify that the usage policies include a list of company-approved products.

Identify any remote access technologies in use <Report Findings Here> . Describe how configurations for remote access technologies verified that remote access sessions will be automatically disconnected after a specific period of inactivity.

Modified p. 170 → 164

~~<Report~~ Findings ~~Here>~~ 12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. ☐ ☐ ☐ ☐ ☐ 12.3.8.a Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity. ☐ ☐ ☐ ☐ ☐ 12.3.8.a Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.

Removed p. 171

 Overall accountability for maintaining PCI DSS compliance  Defining a charter for a PCI DSS compliance program and communication to executive management

Modified p. 171 → 164

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ Not Tested~~ 12.3.10.b For personnel with proper authorization, verify that usage policies require the protection of cardholder data in accordance with PCI DSS Requirements.

<Report Findings Here> 12.3.10.b For personnel with proper authorization, verify that usage policies require the protection of cardholder data in accordance with PCI DSS Requirements.

Modified p. 171 → 165

~~<Report~~ Findings ~~Here>~~ 12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel. ☐ ☐ ☐ ☐ ☐ 12.4.a Verify that information security policy and procedures clearly define information security responsibilities for all personnel.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel. ☐ ☐ ☐ ☐ ☐ 12.4.a Verify that information security policy and procedures clearly define information security responsibilities for all personnel.

Modified p. 171 → 165

12.4.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance Identify the documentation examined to verify that executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.

• Defining a charter for a PCI DSS compliance program and communication to executive management 12.4.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance Identify the documentation examined to verify that executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.

Modified p. 172 → 166

 The formal assignment of information security to a Chief Security Officer or other security- knowledgeable member of management.

• The formal assignment of information security to a Chief Security Officer or other security- knowledgeable member of management.

Modified p. 172 → 166

 The formal assignment of information security to a Chief Security Officer or other security- knowledgeable member of management.

• The formal assignment of information security to a Chief Security Officer or other security- knowledgeable member of management.

Modified p. 172 → 166

 The following information security responsibilities are specifically and formally assigned:

• The following information security responsibilities are specifically and formally assigned:

Modified p. 172 → 166

 The following information security responsibilities are specifically and formally assigned:

• The following information security responsibilities are specifically and formally assigned:

Modified p. 172 → 166

 Establishing security policies and procedures.

• Establishing security policies and procedures.

Modified p. 172 → 166

 Documenting security policies and procedures.

• Documenting security policies and procedures.

Modified p. 172 → 166

 Distributing security policies and procedures.

• Distributing security policies and procedures.

Modified p. 172 → 166

 Monitoring and analyzing security alerts.

• Monitoring and analyzing security alerts.

Modified p. 172 → 166

 Distributing information to appropriate information security and business unit management personnel.

• Distributing information to appropriate information security and business unit management personnel.

Modified p. 173 → 167

 Establishing security incident response and escalation procedures.

• Establishing security incident response and escalation procedures.

Modified p. 173 → 167

 Documenting security incident response and escalation procedures.

• Documenting security incident response and escalation procedures.

Modified p. 173 → 167

 Distributing security incident response and escalation procedures.

• Distributing security incident response and escalation procedures.

Modified p. 173 → 167

~~ Monitoring all access to data ~~ Controlling all access to data <Report Findings Here> 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. ☐ ☐ ☐ ☐ ☐ 12.6.a Review the security awareness program to verify it provides awareness to all personnel about the cardholder data security policy and procedures.

• Controlling all access to data <Report Findings Here> 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. ☐ ☐ ☐ ☐ ☐ 12.6.a Review the security awareness program to verify it provides awareness to all personnel about the cardholder data security policy and procedures.

Modified p. 174 → 168

 The security awareness program provides multiple methods of communicating awareness and educating personnel.

• The security awareness program provides multiple methods of communicating awareness and educating personnel.

Modified p. 174 → 168

~~ Personnel attend security awareness training: - Upon hire, and - At least annually ~~ Personnel acknowledge, in writing or electronically and at least annually, that they have read and understand the information security policy.

• Personnel acknowledge, in writing or electronically and at least annually, that they have read and understand the information security policy.

Modified p. 174 → 168

~~ Upon hire <Report Findings Here> ~~ At least annually <Report Findings Here> 12.6.1.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.

• At least annually <Report Findings Here> 12.6.1.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.

Modified p. 175 → 169

 Acknowledge that they have read and understand the information security policy (including whether this is in writing or electronic).

• Acknowledge that they have read and understand the information security policy (including whether this is in writing or electronic).

Modified p. 175 → 169

~~<Report Findings Here> ~~ Provide an acknowledgement at least annually. <Report Findings Here> 12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

• Provide an acknowledgement at least annually. <Report Findings Here> 12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

Modified p. 178 → 172

 Create the incident response plan to be implemented in the event of system breach.

• Create the incident response plan to be implemented in the event of system breach.

Modified p. 178 → 172

 Test the plan at least annually.

• Test the plan at least annually.

Modified p. 178 → 172

~~ Designate specific personnel to be available on a 24/7 basis to respond to alerts: - 24/7 incident monitoring - 24/7 incident response ~~ Provide appropriate training to staff with security breach response responsibilities.

• Provide appropriate training to staff with security breach response responsibilities.

Modified p. 178 → 172

 Include alerts from security monitoring systems, including but not limited to ~~intrusion- detection,~~ intrusion-prevention, firewalls, and file-integrity monitoring systems.

• Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.

Modified p. 178 → 172

 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

• Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

Modified p. 179 → 173

 Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum.  Specific incident response procedures.  Business recovery and continuity procedures.  Data back-up processes.  Analysis of legal requirements for reporting compromises.  Coverage and responses of all critical system components.  Reference or inclusion of incident response procedures from the payment brands.

• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum. • Specific incident response procedures. • Business recovery and continuity procedures. • Data back-up processes. • Analysis of legal requirements for reporting compromises. • Coverage and responses of all critical system components. • Reference or inclusion of incident response procedures from the payment brands.

Modified p. 179 → 173

 Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum.  Specific incident response procedures.  Business recovery and continuity procedures  Data back-up processes  Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database).  Coverage and responses for all critical …

• Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database). • Coverage and responses for all critical system components. • Reference or inclusion of incident response procedures from the payment brands.

Modified p. 179 → 173

 Roles and responsibilities.

• Roles and responsibilities.

Modified p. 179 → 173

 Communication strategies.

• Communication strategies.

Modified p. 179 → 173

 Requirement for notification of the payment brands.

• Requirement for notification of the payment brands.

Modified p. 179 → 173

 Specific incident response procedures.

• Specific incident response procedures.

Modified p. 179 → 173

 Business recovery and continuity procedures.

• Business recovery and continuity procedures.

Modified p. 179 → 173

 Data back-up processes.

• Data back-up processes.

Modified p. 179 → 173

 Analysis of legal requirements for reporting compromises.

• Analysis of legal requirements for reporting compromises.

Modified p. 179 → 173

 Coverage for all critical system components.

• Coverage for all critical system components.

Modified p. 179 → 173

 Responses for all critical system components.

• Responses for all critical system components.

Modified p. 179 → 173

 Reference or inclusion of incident response procedures from the payment brands.

• Reference or inclusion of incident response procedures from the payment brands.

Modified p. 180 → 174

<Report Findings Here> 12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. ☐ ☐ ☐ ☐ ☐ 12.10.3 Verify through observation, review of policies, and interviews of responsible personnel that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or ~~Identify the document requiring 24/7 incident response and monitoring coverage for:~~

<Report Findings Here> 12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. ☐ ☐ ☐ ☐ ☐ 12.10.3 Verify through observation, review of policies, and interviews of responsible personnel that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.

Modified p. 180 → 174

 Any evidence of unauthorized activity.

• Any evidence of unauthorized activity.

Removed p. 181

<Report Findings Here> Describe how it was observed that designated personnel are available for 24/7 incident response and monitoring coverage for:

 Any evidence of unauthorized activity.

Modified p. 181 → 174

 Any evidence of unauthorized activity.

• Any evidence of unauthorized activity.

Modified p. 181 → 174

Identify the responsible personnel interviewed who confirm 24/7 incident response and monitoring coverage for:

<Report Findings Here> Identify the responsible personnel interviewed who confirm 24/7 incident response and monitoring coverage for:

Modified p. 181 → 175

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~Place reports~~ of unauthorized ~~critical system or content file changes.~~

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Describe how it was observed that designated personnel are available for 24/7 incident response and monitoring coverage for:

• Any evidence of unauthorized activity.

Modified p. 181 → 175

<Report Findings Here> 12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems. ☐ ☐ ☐ ☐ ☐

<Report Findings Here> 12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems. ☐ ☐ ☐ ☐ ☐ 12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems are covered in the Incident Response Plan.

Removed p. 182

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems are covered in the Incident Response Plan.

 According to lessons learned.

Modified p. 182 → 175

<Report Findings Here> 12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. ☐ ☐ ☐ ☐ ☐ 12.10.6 Verify through observation, review of policies, and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

<Report Findings Here> 12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. ☐ ☐ ☐ ☐ ☐

Modified p. 182 → 176

Identify the documented policy reviewed to verify that processes are defined to modify and evolve the incident response plan:

Identify the documented policy reviewed to verify that processes are defined to modify and evolve the incident response plan: • According to lessons learned.

Modified p. 182 → 176

 To incorporate industry developments.

• To incorporate industry developments.

Modified p. 182 → 176

 To incorporate industry developments.

• To incorporate industry developments.

Modified p. 182 → 176

 According to lessons learned.

• According to lessons learned.

Modified p. 182 → 176

 According to lessons learned. <Report Findings Here> ~~ To incorporate industry developments. <Report Findings Here>~~

• According to lessons learned. <Report Findings Here>

Removed p. 183

 Daily log reviews  Firewall rule-set reviews  Applying configuration standards to new systems  Responding to security alerts  Change management processes

 Daily log reviews  Firewall rule-set reviews  Applying configuration standards to new systems  Responding to security alerts  Change management processes Identify the policies and procedures examined to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:

Modified p. 183 → 176

~~PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ Not Tested~~ 12.11 Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:

• To incorporate industry developments. <Report Findings Here> 12.11 Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:

Modified p. 183 → 177

12.11.a Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.11.a Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:

Modified p. 183 → 177

~~ Daily log reviews  Firewall rule-set reviews  Applying configuration standards to new  Responding to security alerts ~~ Change management processes <Report Findings Here> 12.11.b Interview responsible personnel and examine records of reviews to verify that reviews are performed at least quarterly Identify the document(s) related to reviews examined to verify that reviews are performed at least quarterly.

• Change management processes <Report Findings Here> 12.11.b Interview responsible personnel and examine records of reviews to verify that reviews are performed at least quarterly Identify the document(s) related to reviews examined to verify that reviews are performed at least quarterly.

Modified p. 183 → 177

<Report Findings Here> Identify the responsible personnel interviewed who confirm that reviews are performed at least quarterly <Report Findings Here>

<Report Findings Here> Identify the responsible personnel interviewed who confirm that reviews are performed at least quarterly <Report Findings Here> 12.11.1 Additional requirement for service providers only: Maintain documentation of quarterly review process to include:

Removed p. 184

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested 12.11.1 Additional requirement for service providers only: Maintain documentation of quarterly review process to include:

Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement 12.11.1.a Examine documentation from the quarterly reviews to verify they include:

Modified p. 184 → 177

~~ Documenting results of the reviews ~~ Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance ~~program~~

• Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program.

Modified p. 184 → 177

 Documenting results of the reviews.

• Documenting results of the reviews.

Modified p. 184 → 177

 Documenting results of the reviews.

• Documenting results of the reviews.

Modified p. 184 → 177

 Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance ~~program.~~

• Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program 12.11.1.a Examine documentation from the quarterly reviews to verify they include:

Modified p. 184 → 177

 Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program.

• Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program.

Modified p. 185 → 178

~~ Appendix A1 Additional PCI DSS Requirements for Shared Hosting Providers  Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS ~~ Appendix A3: Designated Entities Supplemental Validation Guidance and applicability information is provided within each section.

• Appendix A3: Designated Entities Supplemental Validation Guidance and applicability information is provided within each section.

Modified p. 186 → 179

 No entity on the system can use a shared web server user ID.

• No entity on the system can use a shared web server user ID.

Modified p. 187 → 180

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~ All CGI scripts used by an entity must be created and run as the entity’s unique user ID.~~

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested

Removed p. 188

<Report Findings Here> For each item in the sample of servers and hosted entities from A1.1, describe how the system configuration settings verified restrictions are in place for the use of:

 Disk space <Report Findings Here>  Bandwidth <Report Findings Here> <Report Findings Here> <Report Findings Here> A1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10. ☐ ☐ ☐ ☐ ☐ For each item in the sample of servers and hosted entities from A1.1, describe how processes were observed to verify the following:

Modified p. 188 → 180

~~Assessor’s Response Summary of Assessment~~ Findings ~~(check one) In Place w/ Not Tested  Read~~ permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

<Report Findings Here> − Write permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

Modified p. 188 → 180

<Report Findings Here> ~~ Write~~ permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

<Report Findings Here> − Access permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

Modified p. 188 → 180

~~<Report Findings Here>  Access~~ permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

− Read permissions are only assigned for the files and directories the hosted entity owns, or for necessary systems files.

Removed p. 189

<Report Findings Here> A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. ☐ ☐ ☐ ☐ ☐ A1.4 Verify the shared hosting provider has written policies that provide for a timely forensics investigation of related servers in the event of a compromise.

Modified p. 189 → 181

~~ Logs are enabled for common third- party applications.  Logs are active by default. ~~ Logs are available for review by the owning entity.  Log locations are clearly communicated to the owning entity.

• Logs are available for review by the owning entity. • Log locations are clearly communicated to the owning entity.

Modified p. 189 → 181

 Logs are enabled for common third-party applications.

• Logs are enabled for common third-party applications.

Modified p. 189 → 181

~~<Report Findings Here> ~~ Logs are active by default.

• Logs are active by default.

Modified p. 189 → 181

~~<Report Findings Here> ~~ Logs are available for review by the owning entity.

• Logs are available for review by the owning entity.

Modified p. 189 → 181

~~<Report Findings Here> ~~ Log locations are clearly communicated to the owning entity.

• Log locations are clearly communicated to the owning entity.

Modified p. 189 → 182

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~A1.3~~ Verify the shared hosting provider has ~~enabled logging as follows,~~ for ~~each merchant and service provider environment:~~

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. ☐ ☐ ☐ ☐ ☐ A1.4 Verify the shared hosting provider has written policies that provide for a timely forensics investigation of related servers in the event of a compromise.

Removed p. 190

 New implementations must not use SSL or early TLS as a security control  All service providers must provide a secure service offering by June 30, 2016  After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet).

 POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after 30th June, 2018.

This Appendix applies to entities using SSL/early TLS as a security control to protect the CDE and/or CHD (for example, SSL/early TLS used to meet PCI DSS Requirement 2.2.3, 2.3, or 4.1), Refer to the current PCI SSC Information Supplement Migrating from SSL …

Modified p. 190 → 183

SSL and early TLS ~~should~~ not be used as a security control to meet these ~~requirements.~~ To support entities working to migrate away from SSL/early ~~TLS,~~ the following provisions are included:

SSL and early TLS must not be used as a security control to meet these requirements, except in the case of POS POI terminal connections as detailed in this appendix. To support entities working to migrate away from SSL/early TLS on POS POI terminals, the following provisions are included:

Modified p. 190 → 183

~~ Prior to June 30, 2018,~~ existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

• Service providers supporting existing POS POI terminal implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Removed p. 191

 Confirm the devices are not susceptible to any known exploits for those protocols.

 Have a formal Risk Mitigation and Migration Plan in place.

A2.1 For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS:

 Complete A2.2 below.

For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS:

 Confirm whether the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.(yes/no) If “yes,” complete the remainder of A2.1 If “no,” Complete A2.2 below <Report Findings Here> Identify the documentation examined to verify that the devices are not susceptible to any known exploits for SSL/early TLS.

Modified p. 191 → 184

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested ~~A2.1 Where~~ POS POI ~~terminals (and~~ the ~~SSL/TLS termination points to which they connect) use SSL and/or early TLS,~~ the ~~entity must either:~~

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Indicate whether the assessed entity is using SSL / early TLS for POS POI terminal connections. (yes/no) If “no,” mark the below as “Not Applicable” (no further explanation required) If “yes,” complete the following (as applicable):

Modified p. 191 → 184

~~ Confirm~~ the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

A2.1 For POS POI terminals using SSL and/or early TLS, confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

Modified p. 191 → 184

<Report Findings Here> A2.2 ~~Entities~~ with existing ~~implementations (other than as allowed~~ in ~~A.2.1)~~ that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. ☐ ☐ ☐ ☐ ☐

<Report Findings Here> A2.2 Requirement for Service Providers Only: All service providers with existing connection points to POS POI terminals referred to in A2.1 that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. ☐ ☐ ☐ ☐ ☐

Removed p. 192

 Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;  Risk-assessment results and risk-reduction controls in place;  Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;  Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;  Overview of migration project plan including target migration completion date no later than June 30, 2018.

Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A.2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service.

Modified p. 192 → 185

 Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;  Risk-assessment results and risk- reduction controls in place;  Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;  Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;  Overview of migration project plan ~~including target migration completion date no later than June …~~

• Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment; • Risk-assessment results and risk- reduction controls in place; • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS; • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments; • Overview of migration project plan to replace SSL/early TLS at a future date.

Modified p. 192 → 185

<Report Findings Here> A2.3 ~~Additional~~ Requirement for Service Providers Only: All service providers must provide a secure service ~~offering by June 30, 2016.~~

<Report Findings Here> A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering. ☐ ☐ ☐ ☐ ☐ A2.3 Examine system configurations and supporting documentation to verify the service provider offers a secure protocol option for their service.

Modified p. 192 → 185

~~A2.3 Examine system configurations and supporting documentation to verify the~~ Identify the supporting documentation reviewed to verify the service provider offers a secure protocol option for their service <Report Findings Here>

Identify the supporting documentation reviewed to verify the service provider offers a secure protocol option for their service <Report Findings Here> Identify the sample of system components examined for this testing procedure.

Removed p. 193

Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested service provider offers a secure protocol option for their service.

.Identify the sample of system components examined for this testing procedure.

Modified p. 194 → 186

 Reporting Template for use with the PCI DSS Designated Entities Supplemental Validation  Supplemental Attestation of Compliance for Onsite Assessments

• Designated Entities These documents are available in the PCI SSC Document Library.

• Reporting Template for use with the PCI DSS Designated Entities Supplemental Validation

Modified p. 195 → 187

~~1. Meet the intent and rigor of the original PCI DSS requirement.~~ 2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See ~~Navigating PCI DSS~~ for the intent of each PCI DSS requirement.) ~~3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) …~~

2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Guidance Column for the intent of each PCI DSS requirement.)

Modified p. 195 → 187

a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review. For example, passwords for non-console administrative access must be sent encrypted to mitigate the risk of intercepting clear-text administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex passwords, etc.) to compensate for lack of encrypted passwords, since those other password requirements do not mitigate the risk of interception of clear-text passwords. Also, the other …

Document Comparison

From Revision History

Content Changes