Document Comparison

PCI-DSS-v3-2-1-ROC-Reporting-Template-r2.pdf PCI-DSS-v4-0-ROC-Template-r1.pdf
15% similar
190 → 486 Pages
65337 → 104793 Words
713 Content Changes

From Revision History

  • February 2014 PCI DSS 3.0, Revision 1.0 To introduce the template for submitting Reports on Compliance.
  • April 2015 PCI DSS 3.1, Revision 1.0 Revision to align with changes from PCI DSS 3.0 to PCI DSS 3.1 (see PCI DSS – Summary of Changes from PCI DSS
  • March 2022 PCI DSS 4.0 Updates to align with the changes from PCI DSS v3.2.1 to PCI DSS v4.0 (see PCI DSS – Summary of Changes from PCI DSS Version 3.2.1 to 4.0 for details of changes). Also includes corrections and edits made for clarification and/or
  • December 2022 PCI DSS 4.0 Revision 1 Updates include minor clarifications, corrections to typographical errors, and removal of In Place with Remediation as a
  • December 2022 © 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved. Page iii

Content Changes

713 content changes. 319 administrative changes (dates, page numbers) hidden.

Added p. 2
December 2022 PCI DSS 4.0 Revision 1 Updates include minor clarifications, corrections to typographical errors, and removal of In Place with Remediation as a reporting option.
Added p. 6
The tables in this template may be modified to increase/decrease the number of rows or to change the column width. Additional appendices may be added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos to the title page below, is acceptable.

Do not delete any content from Part I or Part II of this document. The Instruction pages may be deleted; however, the assessor must follow these instructions while documenting the assessment. The addition of text or rows is acceptable, within reason, as noted above. Refer to the PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions document on the PCI SSC website for further guidance.

 Part I: Assessment Overview
Added p. 7
• Build and Maintain a Secure Network and Systems

• Protect Account Data

• Maintain a Vulnerability Management Program

• Implement Strong Access Control Measures

• Regularly Monitor and Test Networks

• Maintain an Information Security Policy

• Appendix B: Compensating Controls

• Appendix D: Customized Approach

• Appendix E: Customized Approach Template Part I must be thoroughly and accurately completed to provide proper context for the assessment findings in Part II. The ROC Template includes tables with reporting instructions built-in to help assessors provide all required information throughout the document. Responses must be specific and focus on concise quality of detail, rather than lengthy, repeated verbiage. Use of template language for descriptions is discouraged and details must be specifically relevant to the assessed entity.

Refer to the following table when considering which selection to make. Only one assessment finding may be selected at the sub-requirement level and reporting associated with that assessment finding must be consistent across all …
Added p. 9
In Figure 1, the Assessment Finding at 1.1.1 is Not Tested if either 1.1.1.a or 1.1.1.b are concluded to be Not Tested.

Describe why this requirement was excluded from the assessment.

Describe how the testing and evidence demonstrates the requirement is Not in Place. If the requirement is Not in Place due to a legal restriction, the assessor must describe the statutory law or regulation that prohibits the requirement from being met.

Figure 1. Example Requirement Requirement Description 1.1 Example Requirement Description

PCI DSS Requirement 1.1.1 Example Requirement Assessment Findings (select one) In Place Not Applicable Not Tested Not in Place Describe why the assessment finding was selected.

Note: Include all details as noted in the “Required Reporting” column of the table in Assessment Findings in the ROC Template Instructions.
Added p. 10
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.1.1.a Example testing procedure Example reporting instruction <Enter Response Here> 1.1.1.b Example testing procedure Example reporting instruction <Enter Response Here>

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

Items marked as Not Applicable require that the assessor render an opinion that the item is not applicable; however, with Not Tested, the assessor is simply following the entity’s instructions to not test something with no opinion needed from the assessor.
Added p. 12
That response could vary, but what’s important is that it is noted as In Place, and that there has been a level of testing by the assessor to support the conclusion that this responsibility is verified and that the responsible party has been tested against the requirement and found to be compliant.
Added p. 13
Assessment When to Use This Approach Using Figure 2 Customized Approach Focuses on the Customized Approach Objective of each PCI DSS Requirement (if applicable), allowing entities to implement controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. The customized approach supports innovation in security practices, allowing entities greater flexibility to show how their current security controls meet PCI DSS requirements. Refer to the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures for the Customized Approach Objective. Note: Compensating Controls are not an option for the Customized Approach For “Validation Method

• Customized Approach”

• If the Customized Approach is not used, select “No” for Customized Approach acknowledgement check box, and mark the relevant reporting instruction as Not Applicable.

• If the Customized Approach is used, complete the following: o Select “Yes” for Customized Approach acknowledgement check box. o …
Added p. 15
The response would be either “Yes” or “No” as shown:

Note: The applicability of some reporting instructions may be dependent on the response of a previous reporting instruction. If applicable, the reporting instruction will direct the assessor to a subsequent instruction based on the yes/no answer.

Identify Identify the evidence reference number(s) from Section 6 for all documentation examined for this testing procedure.

The response would include the relevant item(s) requested. Example Reporting Instruction: “Identify the evidence reference number(s) from Section 6 for all documentation examined for this testing procedure.” Example Response: Doc-01 OR Doc-01 (Company XYZ Information Security Policy) Note: When a reference number is available, it is required; however, the assessor also has the option to list individual items in addition to the reference number.

Describe Describe why the assessment finding was selected.

The response would include a detailed description of the item or activity in question

• for example, details of how the …
Added p. 19
<Enter Response Here> <Enter Response Here> Identify 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, Secure Software Assessor, etc.) <Enter Response Here> <Enter Response Here> Assessor Quality Assurance (QA) Primary Reviewer for this specific report (not the general QA contact for the QSA Company) QA reviewer name: <Enter Response Here> QA reviewer phone number: <Enter Response Here> QA reviewer e-mail address: <Enter Response Here> QA Reviewer’s PCI Credentials: (See the current QSA Qualification Requirements for acceptable credentials) <Enter Response Here>
Added p. 20
<Enter Response Here> Date assessment began: Note: This is the first date that evidence was gathered, or observations were made.

<Enter Response Here> Date assessment ended: Note: This is the last date that evidence was gathered, or observations were made.

<Enter Response Here> 1.3 Remote Assessment Activities Overview of Remote Testing Activity To what extent were remote testing methods used for this assessment? ☐ All testing was performed onsite ☐ A combination of onsite and remote testing methods was used ☐ All testing was performed remotely If remote testing was used for any part of the assessment, briefly describe why onsite testing was not feasible or practical.
Added p. 21
Describe the methods used to perform the remote testing.

Describe any alternative and any additional testing activities that were performed to confirm assurance in the test result.

Examine documentation ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Interview personnel ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Examine/observe live data ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Observe process being performed ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Observe physical environment ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Interactive testing ☐ Yes ☐ No <Enter Response Here> <Enter Response Here> Assessor Assurance in Assessment Result If remote testing methods were used for the assessment, identify whether the assessor was able to:

Complete a thorough assessment using appropriate remote testing activities as described in QSA Program Guide? ☐ Yes ☐ No Achieve a high degree of confidence that the assessment resulted …
Added p. 22
Indicate whether the QSA Company provided any consultation on the development or implementation of controls used for the Customized Approach. Note: This does not apply to the assessment of the Customized Approach.

☐ Yes ☐ No If “Yes,” describe the nature of the consultation. <Enter Response Here> Disclose all products or services provided to the assessed entity by the QSA Company that are not listed above and that were reviewed during this assessment or could reasonably be viewed to affect independence of assessment.
Added p. 23
☐ Yes ☐ No If yes, identify the Assessor Company(s) utilized during the assessment. <Enter Response Here> 1.6 Additional Information/Reporting Identify the number of consecutive years (including the current year) the QSA Company has issued ROCs for this entity.

<Enter Response Here> 1.7 Overall Assessment Result Indicate below whether a full or partial assessment was completed. Select only one.

☐ Full Assessment: All requirements have been assessed and therefore no requirements were marked as Not Tested.

☐ Partial Assessment: One or more requirements have not been assessed and were therefore marked as Not Tested. Any requirement not assessed is noted as Not Tested in section 1.8.1 below.

Overall Assessment Result (Select only one) Compliant: All sections of the PCI DSS ROC are complete, and all assessed requirements are marked as being either In Place or Not Applicable, resulting in an overall COMPLIANT rating; thereby the assessed entity has demonstrated compliance with all PCI DSS …
Added p. 24
PCI DSS Requirement Assessment Finding Select all options that apply.

Select If Below Method(s) Was In Place Not Applicable Not Tested Not in Place Compensating Customized
Added p. 25
Not Applicable Not Tested Not in Place Due to a Legal Restriction Not in Place Not Due to a Legal Restriction Compensating Customized <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> Optional: Additional Assessor Comments This optional field is provided for the assessor to document any additional information that is relevant to the entity being assessed and that may or may not have impacted the findings of this assessment.
Added p. 26
Attestation of independence

• This assessment was conducted strictly in accordance with all applicable requirements set forth in the Payment Card Industry Data Security Standard Qualification Requirements for Assessors, including but not limited to the requirements therein regarding independence, independent judgment and objectivity, disclosure, conflicts of interest, misrepresentations, and instruction of employees;

• This assessment was conducted in a manner intended to preserve at all times the professional judgment, integrity, impartiality, and professional skepticism of the Assessor Company;

• This Report on Compliance accurately identifies, describes, represents, and characterizes all factual evidence that the QSA Company and its Assessor Employees gathered, generated, discovered, reviewed, and/or determined in their sole discretion to be relevant to this assessment in the course of performing the assessment; and

• The judgments, conclusions, and findings contained in this Report on Compliance (a) accurately reflect and are based solely upon the factual evidence described immediately above, (b) reflect the independent …
Added p. 28
As noted in Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures: “The minimum steps for an entity to confirm the accuracy of their PCI DSS scope are specified in PCI DSS Requirement 12.5.2. The entity is expected to retain documentation to show how PCI DSS scope was determined. The documentation is retained for assessor review and for reference during the entity’s next PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor validates that the scope of the assessment is accurately defined and documented.” Describe how the assessor’s evaluation of scope differs from the assessed entity’s evaluation of scope as documented in Requirement 12.5. If no difference was identified, mark as “Not Applicable.” <Enter Response Here> Provide the name of the assessor who attests that:

• They have performed an independent evaluation of the scope of the assessed entity’s PCI DSS environment.

• If the assessor’s …
Added p. 29
• The type of SAQ applied.

• The eligibility criteria for the applicable SAQ.

• How the assessor verified that the assessed entity’s environment meets the eligibility criteria. If not used mark as “Not Applicable.” <Enter Response Here> Additional information, if applicable: <Enter Response Here> 3.2 Segmentation Indicate whether the assessed entity has used segmentation to reduce the scope of the assessment. Note: An environment with no segmentation is considered a “flat” network where all systems are considered to be in scope.

• Describe how the segmentation is implemented, including the technologies and processes used.
Added p. 29
• Describe the environments that were confirmed to be out of scope as a result of the segmentation methods.
Added p. 30
☐ Yes ☐ No If “Yes,” provide the following information regarding items the organization uses from PCI SSC's Lists of Validated Products and Solutions:

Name of PCI SSC validated product or Version of product or

PCI SSC Standard to which product or solution was validated

PCI SSC listing reference number Expiry date of listing <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> Provide the name of the assessor who attests that they have read the instruction manual associated with each of the software/solution(s) listed above and confirmed that the merchant has implemented the solution per the instructions and detail in the instruction manual.

• If “Yes,” complete the following: Note: If multiple sampling methodologies are used, clearly respond for each methodology.

• Describe how the samples are appropriate and representative of the overall …
Added p. 32
 Shows all connections between the CDE and other networks, including any wireless networks.

 Is accurate and up to date with any changes to the environment.

 Illustrates how system components storing cardholder data are not directly accessible from the untrusted networks.

 Includes the techniques (such as intrusion-detection systems and/or intrusion-prevention systems) that are in place to monitor all traffic:

 Shows all account data flows across systems and networks.

 Are accurate and up to date.

Description of Account Data Flows Identify in which of the following account data flows the assessed entity participates: Note: These data flows must be described in detail in the sections of the table that follow.

☐ Authorization ☐ Capture ☐ Settlement ☐ Chargeback/Dispute ☐ Refunds ☐ Other Identify and describe all data flows. Descriptions should include how and where account data enters the environment, is transmitted, is processed, is stored, and how and why any personnel access the …
Added p. 34
Data Store1 File name(s), Table names(s) and/or Field Names Account Data Elements Stored2 How Data Is Secured3 How Access to Data Stores Is <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> 1 Database name, file server name, and so on. 2 For example, PAN, expiry, cardholder name, and so on. 3 For example, what type of encryption and strength. 4 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. 35
Note: The list of files and tables that store SAD in the table below must be supported by an inventory created (or obtained from the assessed entity) and retained by the assessor in the workpapers.

Data Store1 File name(s), Table names(s) and/or Field Names Is SAD Stored Pre- authorization?

Is SAD Stored as Part of Issuer Functions? How Data Is Secured2 <Enter Response Here> <Enter Response Here> ☐ Yes <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ Yes <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ Yes <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ Yes <Enter Response Here> 1 Database name, file server name, and so on. 2 For example, what type of encryption and strength, and so on.
Added p. 35
 Store, process, or transmit account data on the entity’s behalf (for example, payment gateways, payment processors, payment service providers [PSPs])  Manage system components included in the entity’s PCI DSS assessment (for example, via network security control services, anti- malware services, security incident and event management [SIEM], web-hosting companies, IaaS, PaaS, SaaS, FaaS, etc.)  Could impact the security of the entity’s account data (for example, vendors providing support via remote access, and/or bespoke software developers).

Company Name Identify what account data is shared or, if account data is not shared, how the organization could impact the security of account data1 Describe the purpose for utilizing the service provider2 Has the third party been assessed separately against PCI DSS? If Yes, identify the date and PCI DSS version of the AOC.

If No, were the services provided by the third party included in this assessment? Yes No Date Version Yes No …
Added p. 37
Note: This section must align with networks identified on the network diagram.

Network Name (In Scope) Type of Network Function/Purpose of Network <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> 4.6 In-scope Locations/Facilities Identify and provide details for all types of physical locations/facilities (for example, retail locations, corporate offices, data centers, call centers and mail rooms) in scope. Add rows, as needed.
Added p. 38
Function Name Function Description <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> 4.8 In-scope System Component Types Identify all types of system components in scope.

“System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include, but are not limited to:

 Systems that store, process, or transmit account data (for example, payment terminals, authorization systems, clearing systems, payment middleware systems, payment back-office systems, shopping cart and store front systems, payment gateway/switch systems, fraud monitoring systems).
Added p. 39
 Systems that facilitate segmentation (for example, internal network security controls).

 Systems that could impact the security of account data or the CDE (for example, name resolution, or e-commerce [web] redirection servers).

 Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

 Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private clouds, cloud-based identity and access management, CDEs residing on premises or in the cloud, service meshes with containerized applications, and container orchestration tools.

 Network components, including but not limited to network security controls, switches, routers, VoIP network devices, wireless access points, network appliances, and other security appliances.

 Server types, including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

 End-user devices, such as computers, laptops, workstations, administrative workstations, tablets, and mobile devices.

 Printers, and multi-function devices …
Added p. 41
When sampling is used the assessor must identify the items in the population that were tested (for example, as “Sample Set-1”) as part of the sample in the table below and include all of the sub-requirements where that sample set was used. All unique sample sets must be documented in this table.

Note: For items where the total population fluctuates or is difficult to determine, the assessor may work with the assessed entity to provide an estimated total population in the total population column below.

Tested Sample Set Reference Identify All Sub- Requirements Where the Sample Set is Sample Type/ Description1 Identify All Items in the Sample Set2 Selection Method3 Total Sampled Total Population <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response …
Added p. 42
 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 assessment, four passing quarterly scans must have occurred.

Date of the Scan(s) Name of ASV that Performed the Scan Were any vulnerabilities found that resulted in a failed initial scan? For all scans resulting in a Fail, provide date(s) of re- scans showing that the vulnerabilities have been corrected Yes No <Enter Response Here> <Enter Response Here> ☐ ☐ <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ ☐ <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ ☐ <Enter Response Here> <Enter Response Here> <Enter Response Here> ☐ ☐ <Enter Response Here> Indicate whether this is the assessed entity’s initial PCI …
Added p. 43
Date of the Scan(s) Was the scan performed via authenticated scanning?

Were any high-risk or critical vulnerabilities per the entity’s vulnerability risk rankings at Requirement 6.3.1 found? For all scans where high-risk or critical vulnerabilities were found, provide date(s) of re-scans showing that the vulnerabilities have been corrected.

Yes No Yes No <Enter Response Here> ☐ ☐ ☐ ☐ <Enter Response Here> <Enter Response Here> ☐ ☐ ☐ ☐ <Enter Response Here> <Enter Response Here> ☐ ☐ ☐ ☐ <Enter Response Here> <Enter Response Here> ☐ ☐ ☐ ☐ <Enter Response Here> Indicate if this is the assessed entity’s initial PCI DSS compliance validation ☐ Yes ☐ No If yes, Identify the name of the document the assessor verified to include the entity’s documented policies and procedures requiring quarterly scanning going forward.
Added p. 44
<Enter Response Here> Identify the entity or entities who controls the evidence repositories. <Enter Response Here> Indicate whether the entity or entities in control of the evidence repositories understands that all evidence from this assessment must be maintained for a minimum of 3 years and must be made available to PCI SSC upon request.

☐ Yes ☐ No 6.2 Documentation Evidence Identify all evidence for any testing procedure requiring a review of documents such as policies, procedures, standards, records, inventories, vendor documentation, and diagrams. Include the following: (Add rows as needed) Reference Number Document Name (including version, if applicable) Brief Description of Document Document Revision Date (if applicable) EXAMPLE: Doc-1 Company XPY Information Security Policy Information Security Policy 2021-02-18 <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response …
Added p. 45
Information Security Manager <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> 6.4 Observation Evidence Identify all evidence for testing procedures requiring an observation, such as observation notes for observed processes. Include the following: (Add rows as needed) Reference Number Title of Workpaper with Observation Notes Observed Process Brief Description of the EXAMPLE: Proc-1 Assessor notes from observation of visitor badge processes Visitor Badge Process Process for allocating and collecting/expiring visitor badges <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> …
Added p. 47
Requirement 1: Install and Maintain Network Security Controls Requirement Description 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.
Added p. 50
<Enter Response Here> 1.1.2.b Interview personnel responsible for performing activities in Requirement 1 to verify that roles and responsibilities are assigned as documented and are understood.
Added p. 51
PCI DSS Requirement 1.2.1 Configuration standards for NSC rulesets are:
Added p. 52
PCI DSS Requirement 1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.2.a Examine documented procedures to verify that changes to network connections and configurations of NSCs are included in the formal change control process in accordance with Requirement 6.5.1.
Added p. 53
<Enter Response Here> 1.2.2.b Examine network configuration settings to identify changes made to network connections. Interview responsible personnel and examine change control records to verify that identified changes to network connections were approved and managed in accordance with Requirement 6.5.1.

Identify the evidence reference number(s) from Section 6 for all network configuration settings examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all change control records examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all network configuration settings examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all change control records examined for this testing procedure.
Added p. 54
PCI DSS Requirement 1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.
Added p. 55
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.3.a Examine diagram(s) and network configurations to verify that an accurate network diagram(s) exists in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all diagrams examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all network configurations examined for this testing procedure.

<Enter Response Here> 1.2.3.b Examine documentation and interview responsible personnel to verify that the network diagram(s) is accurate and updated when there are changes to the environment.

PCI DSS Requirement 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:

• Shows all account data flows across systems and networks.

• Updated as needed upon changes to the environment.
Added p. 56
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.4.a Examine data-flow diagram(s) and interview personnel to verify the diagram(s) show all account data flows in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all data-flow diagram(s) examined for this testing procedure.

<Enter Response Here> 1.2.4.b Examine documentation and interview responsible personnel to verify that the data-flow diagram(s) is accurate and updated when there are changes to the environment.

PCI DSS Requirement 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.5.a Examine documentation to verify that a list exists of all allowed services, protocols, and ports, including business justification and approval for each.
Added p. 60
PCI DSS Requirement 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.7.a Examine documentation to verify procedures are defined for reviewing configurations of NSCs at least once every six months.

<Enter Response Here> 1.2.7.b Examine documentation of reviews of configurations for NSCs and interview responsible personnel to verify that reviews occur at least once every six months.

<Enter Response Here> 1.2.7.c Examine configurations for NSCs to verify that configurations identified as no longer being supported by a business justification are removed or updated.
Added p. 62
PCI DSS Requirement 1.2.8 Configuration files for NSCs are:

• Secured from unauthorized access.

• Kept consistent with active network configurations.
Added p. 63
Identify the evidence reference number(s) from Section 6 for all configuration files examined for this testing procedure.

<Enter Response Here> Requirement Description 1.3 Network access to and from the cardholder data environment is restricted.

PCI DSS Requirement 1.3.1 Inbound traffic to the CDE is restricted as follows:

• To only traffic that is necessary.

• All other traffic is specifically denied.
Added p. 64
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.3.1.a Examine configuration standards for NSCs to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement.

<Enter Response Here> 1.3.1.b Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement.

• To only traffic that is necessary.

• All other traffic is specifically denied.

PCI DSS Requirement 1.3.2 Outbound traffic from the CDE is restricted as follows:
Added p. 66
<Enter Response Here> 1.3.2.b Examine configurations of NSCs to verify that outbound traffic from the CDE is restricted in accordance with all elements specified in this requirement.

PCI DSS Requirement 1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that:

• All wireless traffic from wireless networks into the CDE is denied by default.

• Only wireless traffic with an authorized business purpose is allowed into the CDE.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.3.3 Examine configuration settings and network diagrams to verify that NSCs are implemented between all wireless networks and the CDE, in accordance with all elements specified in this requirement.
Added p. 68
PCI DSS Requirement 1.4.1 NSCs are implemented between trusted and untrusted networks.
Added p. 69
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all network diagrams examined for this testing procedure.

<Enter Response Here> 1.4.1.b Examine network configurations to verify that NSCs are in place between trusted and untrusted networks, in accordance with the documented configuration standards and network diagrams.

Identify the evidence reference number(s) from Section 6 for all network configurations examined for this testing procedure.

PCI DSS Requirement 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:

• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.

• Stateful responses to communications initiated by system components in a trusted network.

• All other traffic is denied.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.4.2 Examine vendor documentation and configurations of NSCs to verify that inbound traffic from untrusted networks to trusted networks is restricted in accordance with all elements specified in this requirement.
Added p. 71
PCI DSS Requirement 1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.
Added p. 72
PCI DSS Requirement 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.4.4.a Examine the data-flow diagram and network diagram to verify that it is documented that system components storing cardholder data are not directly accessible from the untrusted networks.

Identify the evidence reference number(s) from Section 6 for all data-flow diagram examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all network diagram examined for this testing procedure.

<Enter Response Here> 1.4.4.b Examine configurations of NSCs to verify that controls are implemented such that system components storing cardholder data are not directly accessible from untrusted networks.

PCI DSS Requirement 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.
Added p. 75
<Enter Response Here> 1.4.5.b Interview personnel and examine documentation to verify that controls are implemented such that any disclosure of internal IP addresses and routing information is limited to only authorized parties.
Added p. 76
PCI DSS Requirement 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:

• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.

• Security controls are actively running.

• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.5.1.a Examine policies and configuration standards and interview personnel to verify security controls for computing devices that connect to both untrusted networks, and the CDE, are implemented in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all policies examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all configuration …
Added p. 81
PCI DSS Requirement 2.2.1 Configuration standards are developed, implemented, and maintained to:

• Cover all system components.

• Address all known security vulnerabilities.

• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.

• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.

• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.2.1.a Examine system configuration standards to verify they define processes that include all elements specified in this requirement.
Added p. 82
<Enter Response Here> 2.2.1.b Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
Added p. 82
<Enter Response Here> 2.2.1.c Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment.

PCI DSS Requirement 2.2.2 Vendor default accounts are managed as follows:

• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.

• If the vendor default account(s) will not be used, the account is removed or disabled.

Identify the evidence reference number(s) from Section 6 for all configuration files examined for this testing procedure.
Added p. 84
<Enter Response Here> 2.2.2.b Examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observations(s) conducted for this testing procedure.

<Enter Response Here> 2.2.2.c Examine configuration files and interview personnel to verify that all vendor default accounts that will not be used are removed or disabled.

PCI DSS Requirement 2.2.3 Primary functions requiring different security levels are managed as follows:

• Only one primary function exists on a system component, OR

• Primary functions with differing security levels that exist on the same system component are isolated from each other, OR

• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
Added p. 86
<Enter Response Here> 2.2.3.b Examine system configurations to verify that primary functions requiring different security levels are managed per one of the ways specified in this requirement.

<Enter Response Here> 2.2.3.c Where virtualization technologies are used, examine the system configurations to verify that system functions requiring different security levels are managed in one of the following ways:

• Functions with differing security needs do not co-exist on the same system component.

• Functions with differing security needs that exist on the same system component are isolated from each other.

• Functions with differing security needs on the same system component are all secured to the level required by the function with the highest security need.
Added p. 87
PCI DSS Requirement 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
Added p. 88
<Enter Response Here> 2.2.4.b Examine system configurations to verify the following:

• All unnecessary functionality is removed or disabled.

• Only required functionality, as documented in the configuration standards, is enabled.

PCI DSS Requirement 2.2.5 If any insecure services, protocols, or daemons are present:

• Business justification is documented.

• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.2.5.a If any insecure services, protocols, or daemons are present, examine system configuration standards and interview personnel to verify they are managed and implemented in accordance with all elements specified in this requirement.

<Enter Response Here> 2.2.5.b If any insecure services, protocols, or daemons, are present, examine configuration settings to verify that additional security features are implemented to reduce the risk of using insecure services, daemons, and protocols.

PCI DSS Requirement 2.2.6 System security parameters are configured to prevent …
Added p. 91
<Enter Response Here> 2.2.6.b Interview system administrators and/or security managers to verify they have knowledge of common security parameter settings for system components.

<Enter Response Here> 2.2.6.c Examine system configurations to verify that common security parameters are set appropriately and in accordance with the system configuration standards.

PCI DSS Requirement 2.2.7 All non-console administrative access is encrypted using strong cryptography.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.2.7.a Examine system configuration standards to verify they include encrypting all non-console administrative access using strong cryptography.

<Enter Response Here> 2.2.7.b Observe an administrator log on to system components and examine system configurations to verify that non-console administrative access is managed in accordance with this requirement.

Identify the evidence reference number(s) from Section 6 for all observation(s) of administrator log on(s) for this testing procedure.
Added p. 93
Identify the evidence reference number(s) from Section 6 for all settings for system components and authentication services examined for this testing procedure.

<Enter Response Here> 2.2.7.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.
Added p. 94
PCI DSS Requirement 2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:

• Default wireless encryption keys.

• Passwords on wireless access points.

• Any other security-related wireless vendor defaults.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.3.1.a Examine policies and procedures and interview responsible personnel to verify that processes are defined for wireless vendor defaults to either change them upon installation or to confirm them to be secure in accordance with all elements of this requirement.

<Enter Response Here> 2.3.1.b Examine vendor documentation and observe a system administrator logging into wireless devices to verify: o SNMP defaults are not used. o Default passwords/passphrases on wireless access points are not used.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the observation(s) of administrator log in(s) for …
Added p. 97
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all key-management documentation examined for this testing procedure.

Requirement 3: Protect Stored Account Data Requirement Description 3.1 Processes and mechanisms for protecting stored account data are defined and understood.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.1.2.a Examine documentation to verify that descriptions of roles and responsibilities performing activities in Requirement 3 are documented and assigned.
Added p. 101
• Coverage for all locations of stored account data.

• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.2.1 and must be fully considered during a PCI DSS assessment.

• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.2.1.a Examine the data retention and disposal policies, procedures, and processes and interview personnel to verify processes are defined to include all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all files and system records examined for this testing procedure.

<Enter Response Here> 3.2.1.c Observe the mechanisms used to render account data unrecoverable to verify data cannot …
Added p. 103
PCI DSS Requirement 3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.
Added p. 104
<Enter Response Here> 3.3.1.b If SAD is received, examine the documented procedures and observe the secure data deletion processes to verify the data is rendered unrecoverable upon completion of the authorization process.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the observation(s) of the secure data deletion processes for this testing procedure.

PCI DSS Requirement 3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.1.1 Examine data sources to verify that the full contents of any track are not stored upon completion of the authorization process.
Added p. 106
PCI DSS Requirement 3.3.1.2 The card verification code is not retained upon completion of the authorization process.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.1.2 Examine data sources, to verify that the card verification code is not stored upon completion of the authorization process.

PCI DSS Requirement 3.3.1.3 The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.1.3 Examine data sources, to verify that PINs and PIN blocks are not stored upon completion of the authorization process.

PCI DSS Requirement 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
Added p. 109
Identify the evidence reference number(s) from Section 6 for all data stores examined for this testing procedure.
Added p. 109
• Limited to that which is needed for a legitimate issuing business need and is secured.

• Encrypted using strong cryptography. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment.

Identify the evidence reference number(s) from Section 6 for all data stores examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all documented policies examined for this testing procedure.

<Enter Response Here> Requirement Description 3.4 Access to displays of full PAN and ability to copy PAN is restricted.
Added p. 112
<Enter Response Here> 3.4.1.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displayed, and that only those with a legitimate business need are able to see more than the BIN and/or last four digits of the PAN.

Identify the evidence reference number(s) from Section 6 for all displays of PAN examined for this testing procedure.

PCI DSS Requirement 3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 114
• Technical controls prevent all personnel not specifically authorized from copying and/or relocating PAN.

• A list of personnel with permission to copy and/or relocate PAN is maintained, together with the documented, explicit authorization and legitimate, defined business need.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all documented evidence for technical controls examined for this testing procedure.

<Enter Response Here> 3.4.2.b Examine configurations for remote-access technologies to verify that technical controls to prevent copy and/or relocation of PAN for all personnel, unless explicitly authorized.

<Enter Response Here> 3.4.2.c Observe processes and interview personnel to verify that only personnel with documented, explicit authorization and a legitimate, defined business need have permission to copy and/or relocate PAN when using remote-access technologies.

Identify the evidence reference number(s) from Section 6 for all observations(s) conducted for this testing procedure.

<Enter Response Here> Requirement Description 3.5 Primary account number (PAN) is secured wherever it is stored.

PCI …
Added p. 116
Identify the evidence reference number(s) from Section 6 for all implemented controls examined for this testing procedure.

PCI DSS Requirement 3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7. Note: This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 118
<Enter Response Here> 3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7.

<Enter Response Here> 3.5.1.1.c Examine data repositories to verify the PAN is rendered unreadable.

Identify the evidence reference number(s) from Section 6 for all data repositories examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all audit logs examined for this testing procedure.

PCI DSS Requirement 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media OR

• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1. Note: This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered …
Added p. 119
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.5.1.2.a Examine encryption processes to verify that, if disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media, OR

• If used for non-removable electronic media, examine encryption processes used to verify that PAN is also rendered unreadable via another method that meets Requirement 3.5.1.

Identify the evidence reference number(s) from Section 6 for all encryption processes examined for this testing procedure.
Added p. 120
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the observation(s) of the encryption processes for this testing procedure.

PCI DSS Requirement 3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:

• Logical access is managed separately and independently of native operating system authentication and access control mechanisms.

• Decryption keys are not associated with user accounts.

• Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.5.1.3.a If disk-level or partition-level encryption is used to render PAN unreadable, examine the system configuration and observe the authentication process to verify that logical access is implemented in accordance with all elements specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of …
Added p. 123
PCI DSS Requirement 3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

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

• Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1 and must be fully considered during a PCI DSS assessment.

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.6.1.1 Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to …
Added p. 127
<Enter Response Here> 3.6.1.2.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt stored account data exist in one (or more) of the forms specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all key storage locations examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all key storage locations examined for this testing procedure.

<Enter Response Here> 3.6.1.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

PCI DSS Requirement 3.6.1.3 Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.6.1.3 Examine user access lists to verify that access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.

Identify the evidence reference number(s) from Section 6 for …
Added p. 130
Identify the evidence reference number(s) from Section 6 for all key storage locations examined for this testing procedure.
Added p. 130
<Enter Response Here> Requirement Description 3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

PCI DSS Requirement 3.7.1 Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.1.a Examine the documented key- management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the methods for generating keys for this testing procedure.

PCI DSS Requirement 3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.
Added p. 133
Identify the evidence reference number(s) from Section 6 for the documented key management policies and procedures examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the method for distributing keys for this testing procedure.

PCI DSS Requirement 3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.3.a Examine the documented key- management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the method for storing keys for this testing procedure.

PCI DSS Requirement 3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated …
Added p. 136
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of key storage locations for this testing procedure.

PCI DSS Requirement 3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:

• The key has reached the end of its defined cryptoperiod.

• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.
Added p. 138
PCI DSS Requirement 3.7.6 Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.6.a Examine the documented key- management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control.

Identify the evidence reference number(s) from Section 6 for all documented key- management policies and procedures examined for this testing procedure.
Added p. 142
PCI DSS Requirement 3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.
Added p. 143
Identify the evidence reference number(s) from Section 6 for all documentation or other evidence examined for this testing procedure.

PCI DSS Requirement 3.7.9 Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks Requirement Description 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
Added p. 148
PCI DSS Requirement 4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be fully considered during a PCI DSS assessment.

• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 4.2.1.a Examine documented policies and procedures and interview personnel to verify processes are defined to include all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for the documented policies and procedures examined for this testing procedure.

<Enter …
Added p. 151
4.2.1.1.b Examine the inventory of trusted keys and certificates to verify it is kept up to date.

Identify the evidence reference number(s) from Section 6 for all inventories of trusted keys examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 4.2.1.2 Examine system configurations to verify that wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 4.2.2.a Examine documented policies and procedures to verify that processes are defined to secure PAN with strong cryptography whenever sent over end-user messaging technologies.

Requirement 5: Protect All Systems and Networks from Malicious Software Requirement Description 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
Added p. 158
PCI DSS Requirement 5.2.1 An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware.
Added p. 159
<Enter Response Here> 5.2.1.b For any system components without an anti-malware solution, examine the periodic evaluations to verify the component was evaluated and the evaluation concludes that the component is not at risk from malware.

Identify the evidence reference number(s) from Section 6 for all periodic evaluations examined for this testing procedure.

PCI DSS Requirement 5.2.2 The deployed anti-malware solution(s):

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.2.2 Examine vendor documentation and configurations of the anti-malware solution(s) to verify that the solution:

PCI DSS Requirement 5.2.3 Any system components that are not at risk for malware are evaluated periodically to include the following:

• A documented list of all system components not at risk for malware.

• Identification and evaluation of evolving malware threats for those system components.

• Confirmation whether such system components continue to not require anti-malware protection.
Added p. 162
<Enter Response Here> 5.2.3.b Interview personnel to verify that the evaluations include all elements specified in this requirement.

<Enter Response Here> 5.2.3.c Examine the list of system components identified as not at risk of malware and compare to the system components without an anti-malware solution deployed per Requirement 5.2.1 to verify that the system components match for both requirements.

Identify the evidence reference number(s) from Section 6 for all lists of system components examined for this testing procedure.

PCI DSS Requirement 5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 164
Identify the evidence reference number(s) from Section 6 for the targeted risk analysis examined for this testing procedure.

<Enter Response Here> 5.2.3.1.b Examine documented results of periodic evaluations of system components identified as not at risk for malware and interview personnel to verify that evaluations are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

Identify the evidence reference number(s) from Section 6 for all documented results of periodic evaluations of system components examined for this testing procedure.
Added p. 165
PCI DSS Requirement 5.3.1 The anti-malware solution(s) is kept current via automatic updates.
Added p. 166
<Enter Response Here> 5.3.1.b Examine system components and logs, to verify that the anti- malware solution(s) and definitions are current and have been promptly deployed Identify the evidence reference number(s) from Section 6 for all system components examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all logs examined for this testing procedure.

PCI DSS Requirement 5.3.2 The anti-malware solution(s):

• Performs continuous behavioral analysis of systems or processes.
Added p. 168
<Enter Response Here> 5.3.2.b Examine system components, including all operating system types identified as at risk for malware, to verify the solution(s) is enabled in accordance with at least one of the elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all system components examined for this testing procedure.

<Enter Response Here> 5.3.2.c Examine logs and scan results to verify that the solution(s) is enabled in accordance with at least one of the elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all logs examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all scan results examined for this testing procedure.

PCI DSS Requirement 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement …
Added p. 170
<Enter Response Here> 5.3.2.1.b Examine documented results of periodic malware scans and interview personnel to verify scans are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

Identify the evidence reference number(s) from Section 6 for all documented results of periodic malware scans examined for this testing procedure.

PCI DSS Requirement 5.3.3 For removable electronic media, the anti-malware solution(s):

• Performs automatic scans of when the media is inserted, connected, or logically mounted, OR

• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Identify the evidence reference number(s) from Section 6 for all system components examined for this testing procedure.

<Enter Response Here> 5.3.3.c Examine logs and scan results to verify that the solution(s) …
Added p. 172
<Enter Response Here> 5.3.3.b Examine system components with removable electronic media connected to verify that the solution(s) is enabled in accordance with at least one of the elements as specified in this requirement.

PCI DSS Requirement 5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.3.4 Examine anti-malware solution(s) configurations to verify logs Identify the evidence reference number(s) from Section 6 for all anti-malware <Enter Response Here>
Added p. 174
PCI DSS Requirement 5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.
Added p. 175
Identify the evidence reference number(s) from Section 6 for all anti-malware solution configurations examined for this testing procedure.

<Enter Response Here> 5.3.5.b Interview responsible personnel and observe processes to verify that any requests to disable or alter anti-malware mechanisms are specifically documented and authorized by management on a case-by-case basis for a limited time period.
Added p. 176
PCI DSS Requirement 5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 177
Identify the evidence reference number(s) from Section 6 for all observation(s) of implemented processes for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all mechanisms examined for this testing procedure.

Requirement 6: Develop and Maintain Secure Systems and Software Requirement Description 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
Added p. 180
<Enter Response Here> 6.1.2.b Interview personnel responsible for performing activities in Requirement 6 to verify that roles and responsibilities are assigned as documented and are understood.

<Enter Response Here> Requirement Description 6.2 Bespoke and custom software are developed securely.

PCI DSS Requirement 6.2.1 Bespoke and custom software are developed securely, as follows:

• Based on industry standards and/or best practices for secure development.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.2.1 Examine documented software development procedures to verify that processes are defined that include all elements specified in this requirement.
Added p. 182
PCI DSS Requirement 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:

• On software security relevant to their job function and development languages.

• Including secure software design and secure coding techniques.

• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
Added p. 183
Identify the evidence reference number(s) from Section 6 for all software development procedures examined for this testing procedure.

<Enter Response Here> 6.2.2.b Examine training records and interview personnel to verify that software development personnel working on bespoke and custom software received software security training that is relevant to their job function and development languages in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all training records examined for this testing procedure.

• Code reviews look for both existing and emerging software vulnerabilities.
Added p. 185
<Enter Response Here> 6.2.3.b Examine evidence of changes to bespoke and custom software to verify that the code changes were reviewed in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all evidence of changes examined for this testing procedure.

PCI DSS Requirement 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:

Identify the evidence reference number(s) from Section 6 for all evidence of changes examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.2.3.1.a If manual code reviews are performed for bespoke and custom software prior to release to production, examine documented software development procedures and interview responsible personnel to verify that processes are defined for manual code reviews to be conducted in accordance with all elements specified in this requirement.

<Enter Response Here> 6.2.3.1.b Examine evidence of …
Added p. 190
PCI DSS Requirement 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.3.2.a Examine documentation and interview personnel to verify that an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software is maintained, and that the inventory is used to identify and address vulnerabilities.

<Enter Response Here> 6.3.2.b Examine software documentation, including for bespoke and custom software that integrates third-party software components, and compare it to the inventory to verify that the inventory includes the bespoke and custom software and third-party software components.

Identify the evidence reference number(s) from Section 6 …
Added p. 193
<Enter Response Here> 6.3.3.b Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all system components and related software examined for this testing procedure.
Added p. 194
PCI DSS Requirement 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:

• At least once every 12 months and after significant changes.

• By an entity that specializes in application security.

• Including, at a minimum, all common software attacks in Requirement 6.2.4.

• All vulnerabilities are ranked in accordance with requirement 6.3.1.

• All vulnerabilities are corrected.

• The application is re-evaluated after the corrections OR

• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:

• Installed in front of public-facing web applications to detect and prevent web-based attacks.

• Actively running and up to date as applicable.

• Generating audit logs.

• Configured to either block web-based attacks or generate an alert that is immediately investigated. Note: This requirement …
Added p. 196
• If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public- facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR

• If an automated technical solution(s) is installed that continually detects and prevents web-based attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s).

Identify the evidence reference number(s) from Section 6 for all documented processes examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all records of application security assessments examined for this testing procedure.
Added p. 197
• Actively running and up to date as applicable.

• Generating audit logs.

PCI DSS Requirement 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:

• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.

• Configured to either block web-based attacks or generate an alert that is immediately investigated. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. This new requirement will replace Requirement 6.4.1 once its effective date is reached.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.4.2 For public-facing web applications, examine the system configuration settings and audit logs, and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks is in …
Added p. 199
PCI DSS Requirement 6.4.3 All payment page scripts that are loaded and executed in the consumer's browser are managed as follows:

• A method is implemented to confirm that each script is authorized.

• A method is implemented to assure the integrity of each script.

• An inventory of all scripts is maintained with written justification as to why each is necessary. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 200
<Enter Response Here> 6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all inventory records examined for this testing procedure.
Added p. 201
PCI DSS Requirement 6.5.1 Changes to all system components in the production environment are made according to established procedures that include:

• Reason for, and description of, the change.

• Procedures to address failures and return to a secure state.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.5.1.a Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement.

<Enter Response Here> 6.5.1.b Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement.

PCI DSS Requirement 6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
Added p. 204
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of the affected systems/networks for this testing procedure.

PCI DSS Requirement 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.
Added p. 206
<Enter Response Here> 6.5.3.b Examine network documentation and configurations of network security controls to verify that the pre-production environment is separate from the production environment(s).

Identify the evidence reference number(s) from Section 6 for all network documentation examined for this testing procedure.

<Enter Response Here> 6.5.3.c Examine access control settings to verify that access controls are in place to enforce separation between the pre-production and production environment(s).

PCI DSS Requirement 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
Added p. 208
<Enter Response Here> 6.5.4.b Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed.
Added p. 208
PCI DSS Requirement 6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.5.5.a Examine policies and procedures to verify that processes are defined for not using live PANs in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.

<Enter Response Here> 6.5.5.b Observe testing processes and interview personnel to verify procedures are in place to ensure live PANs are not used in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the testing processes for this testing procedure.
Added p. 210
Identify the evidence reference number(s) from Section 6 for all pre-production test data examined for this testing procedure.

PCI DSS Requirement 6.5.6 Test data and test accounts are removed from system components before the system goes into production.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the testing processes for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.5.6.a Examine policies and procedures to verify that processes are defined for removal of test data and test accounts from system components before the system goes into production.

<Enter Response Here> 6.5.6.b Observe testing processes for both off-the-shelf software and in- house applications, and interview personnel to verify test data and test accounts are removed before a system goes into production.

<Enter Response Here> 6.5.6.c Examine data and accounts for recently installed or updated off- the-shelf software and in-house applications to verify there is no test data …
Added p. 215
<Enter Response Here> 7.1.2.b Interview personnel with responsibility for performing activities in Requirement 7 to verify that roles and responsibilities are assigned as and are understood.
Added p. 216
PCI DSS Requirement 7.2.1 An access control model is defined and includes granting access as follows:

• Appropriate access depending on the entity's business and access needs.

<Enter Response Here> Validation Method

• Defined Approach Indicate whether a Compensating Control was used: ☐ Yes ☐ No If “Yes”, Identify the aspect(s) of the requirement where the Compensating Control(s) was used.

Note: The use of Compensating Controls must also be documented in Appendix C.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.1.a Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement.

<Enter Response Here> 7.2.1.b Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement.

PCI DSS Requirement 7.2.2 Access is assigned to users, including privileged users, based on:

• Job classification and function.

<Enter Response Here> Testing Procedures Reporting Instructions …
Added p. 220
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all documented approvals examined for this testing procedure.

PCI DSS Requirement 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:

• At least once every six months.

• To ensure user accounts and access remain appropriate based on job function.

• Any inappropriate access is addressed.

• Management acknowledges that access remains appropriate. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 222
<Enter Response Here> 7.2.4.b Interview responsible personnel and examine documented results of periodic reviews of user accounts to verify that all the results are in accordance with all elements specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the documented results of periodic reviews of user accounts examined for this testing procedure.

PCI DSS Requirement 7.2.5 All application and system accounts and related access privileges are assigned and managed as follows:

• Based on the least privileges necessary for the operability of the system or application.

• Access is limited to the systems, applications, or processes that specifically require their use. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.5.a Examine policies and procedures to verify they define …
Added p. 225
<Enter Response Here> 7.2.5.1.c Interview responsible personnel and examine documented results of periodic reviews of system and application accounts and related privileges to verify that the reviews occur in accordance with all elements specified in this requirement.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all documented results of periodic reviews examined for this testing procedure.

PCI DSS Requirement 7.2.6 All user access to query repositories of stored cardholder data is restricted as follows:

• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.

• Only the responsible administrator(s) can directly access or query repositories of stored CHD.
Added p. 227
<Enter Response Here> 7.2.6.b Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement.
Added p. 230
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.3.2 Examine vendor documentation and system settings to verify that the access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function.

PCI DSS Requirement 7.3.3 The access control system(s) is set to “deny all” by default.
Added p. 232
Requirement 8: Identify Users and Authenticate Access to System Components Requirement Description 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.1.1 Examine documentation and interview personnel to verify that security policies and operational procedures that are identified in Requirement 8 are managed in accordance with all elements specified in this requirement.

<Enter Response Here> 8.1.2.b Interview personnel with responsibility for performing activities in Requirement 8 to verify that roles Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Added p. 235
Requirement Description 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.

Identify the evidence reference number(s) from Section 6 for all audit logs examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.1.a Interview responsible personnel to verify that all users are assigned a unique ID for access to system components and cardholder data.

<Enter Response Here> 8.2.1.b Examine audit logs and other evidence to verify that access to system components and cardholder data can be uniquely identified and associated with individuals.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for any other evidence examined for this testing procedure.

PCI DSS Requirement 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:

• Account use is prevented unless needed for an exceptional circumstance.

• …
Added p. 238
<Enter Response Here> 8.2.2.c Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.

PCI DSS Requirement 8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
Added p. 240
• Authorized with the appropriate approval.

• Implemented with only the privileges specified on the documented approval.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.4 Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions) and examine system settings to verify the activity has been managed in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all documented authorizations examined for this testing procedure.

PCI DSS Requirement 8.2.5 Access for terminated users is immediately revoked.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.5.a Examine information sources for terminated users and review Identify the evidence reference number(s) from Section 6 for all information <Enter Response Here>
Added p. 243
Identify the evidence reference number(s) from Section 6 for all current user access lists examined for this testing procedure.

PCI DSS Requirement 8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.6 Examine user accounts and last logon information, and interview personnel to verify that any inactive user accounts are removed or disabled within 90 days of inactivity.

Identify the evidence reference number(s) from Section 6 for all user accounts and last login information examined for this testing procedure.

• Use is monitored for unexpected activity.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for any other evidence examined for this testing procedure.
Added p. 246
PCI DSS Requirement 8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.8 Examine system configuration settings to verify that system/session idle timeout features for user sessions have been set to 15 minutes or less.
Added p. 248
PCI DSS Requirement 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.1.a Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement.

<Enter Response Here> 8.3.1.b For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s).

Identify the evidence reference number(s) from Section 6 for all observation(s) of each type of authentication factor used for this testing procedure.

PCI DSS Requirement 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
Added p. 251
Identify the evidence reference number(s) from Section 6 for all repositories of authentication factors examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all data transmissions examined for this testing procedure.

PCI DSS Requirement 8.3.3 User identity is verified before modifying any authentication factor.
Added p. 253
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of security personnel for this testing procedure.

PCI DSS Requirement 8.3.4 Invalid authentication attempts are limited by:

• Locking out the user ID after not more than 10 attempts.

• Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.4.a Examine system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than 10 invalid logon attempts.

<Enter Response Here> 8.3.4.b Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed.

PCI DSS Requirement 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, …
Added p. 257
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.6 Examine system configuration settings to verify that user password/passphrase complexity parameters are set in accordance with all elements specified in this requirement.

PCI DSS Requirement 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
Added p. 260
Identify the evidence reference number(s) from Section 6 for all procedures examined for this testing procedure.

PCI DSS Requirement 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:

• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Added p. 262
PCI DSS Requirement 8.3.10 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including:

• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed. Note: This requirement for service providers will be superseded by Requirement 8.3.10.1 as of 31 March 2025.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.10 Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, examine guidance provided to customer users to verify that the guidance includes all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all guidance provided to customer users examined for this testing procedure.

PCI DSS Requirement 8.3.10.1 Additional requirement for service providers …
Added p. 268
PCI DSS Requirement 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.
Added p. 269
PCI DSS Requirement 8.4.2 MFA is implemented for all access into the CDE. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.4.2.a Examine network and/or system configurations to verify MFA is implemented for all access into the CDE.

Identify the evidence reference number(s) from Section 6 for all network and/or system configurations examined for this testing procedure.

<Enter Response Here> 8.4.2.b Observe personnel logging in to the CDE and examine evidence to verify that MFA is required.

Identify the evidence reference number(s) from Section 6 for all observation(s) of personnel logging into the CDE for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for any additional evidence examined for this testing procedure.

PCI DSS Requirement 8.4.3 MFA is implemented for …
Added p. 272
<Enter Response Here> Requirement Description 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.

PCI DSS Requirement 8.5.1 MFA systems are implemented as follows:

• The MFA system is not susceptible to replay attacks.

• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.

• At least two different types of authentication factors are used.

• Success of all authentication factors is required before access is granted. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 274
Identify the evidence reference number(s) from Section 6 for all vendor system documentation examined for this testing procedure.

<Enter Response Here> 8.5.1.b Examine system configurations for the MFA implementation to verify it is configured in accordance with all elements specified in this requirement.

<Enter Response Here> 8.5.1.c Interview responsible personnel and observe processes to verify that any requests to bypass MFA are specifically documented and authorized by management on an exception basis, for a limited time period.

<Enter Response Here> 8.5.1.d Observe personnel logging into system components in the CDE to verify that access is granted only after all authentication factors are successful.

Identify the evidence reference number(s) from Section 6 for all observation(s) of personnel logging into system components in the CDE for this testing procedure.

<Enter Response Here> 8.5.1.e Observe personnel connecting remotely from outside the entity’s network to verify that access is granted only after all authentication factors are successful.

Identify the evidence …
Added p. 275
PCI DSS Requirement 8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows:

• Interactive use is prevented unless needed for an exceptional circumstance.

• Interactive use is limited to the time needed for the exceptional circumstance.

• Business justification for interactive use is documented.

• Interactive use is explicitly approved by management.

• Individual user identity is confirmed before access to account is granted.

• Every action taken is attributable to an individual user. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.6.1 Examine application and system accounts that can be used interactively and interview administrative personnel to verify that application and system accounts are managed in accordance with all elements specified in this requirement.

Identify the evidence …
Added p. 278
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all system development procedures examined for this testing procedure.

<Enter Response Here> 8.6.2.b Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login, to verify passwords/passphrases for those accounts are not present.

Identify the evidence reference number(s) from Section 6 for all scripts, configuration/property files, and bespoke and custom source code examined for this testing procedure.

PCI DSS Requirement 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:

• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.

• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases. Note: This requirement is a best practice until 31 …
Added p. 280
<Enter Response Here> 8.6.3.b Examine the entity’s targeted risk analysis for the change frequency and complexity for passwords/passphrases used for interactive login to application and system accounts to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1 and addresses:

• The frequency defined for periodic changes to application and system passwords/passphrases.

• The complexity defined for passwords/passphrases and appropriateness of the complexity relative to the frequency of changes.

<Enter Response Here> 8.6.3.c Interview responsible personnel and examine system configuration settings to verify that passwords/passphrases for any application and system accounts that can be used for interactive login are protected against misuse in accordance with all elements specified in this requirement.

Requirement 9: Restrict Physical Access to Cardholder Data Requirement Description 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
Added p. 284
PCI DSS Requirement 9.2.1 Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.
Added p. 285
Identify the evidence reference number(s) from Section 6 for all observation(s) of the entry controls for this testing procedure.

PCI DSS Requirement 9.2.1.1 Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows:

• Entry and exit points to/from sensitive areas within the CDE are monitored.

• Collected data is reviewed and correlated with other entries.

• Collected data is stored for at least three months, unless otherwise restricted by law.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.2.1.1.a Observe locations where individual physical access to sensitive areas within the CDE occurs to verify that either video cameras or physical access control mechanisms (or both) are in place to monitor the entry and exit points.

Identify the evidence reference number(s) from Section 6 for all observation(s) of locations where individual physical access to sensitive areas within the CDE …
Added p. 287
Identify the evidence reference number(s) from Section 6 for all observation(s) of the physical access control mechanisms for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all video cameras examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of the locations of publicly accessible network jacks for this testing procedure.

PCI DSS Requirement 9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted.
Added p. 290
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of the locations of hardware and lines for this testing procedure.

PCI DSS Requirement 9.2.4 Access to consoles in sensitive areas is restricted via locking when not in use.

Identify the evidence reference number(s) from Section 6 for all observation(s) of a system administrator’s attempt to log into consoles in sensitive areas for this testing procedure.

<Enter Response Here> Requirement Description 9.3 Physical access for personnel and visitors is authorized and managed.

PCI DSS Requirement 9.3.1 Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including:

• Identifying personnel.
Added p. 293
<Enter Response Here> 9.3.1.b Observe identification methods, such as ID badges, and processes to verify that personnel in the CDE are clearly identified.

Identify the evidence reference number(s) from Section 6 for all observation(s) of all identification methods and processes for this testing procedure.

PCI DSS Requirement 9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled as follows:

• Access is revoked immediately upon termination.
Added p. 295
Identify the evidence reference number(s) from Section 6 for all observation(s) of personnel in sensitive areas for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all physical access control lists examined for this testing procedure.

<Enter Response Here> 9.3.1.1.b Observe processes and interview personnel to verify that access of all personnel is revoked immediately upon termination.

<Enter Response Here> 9.3.1.1.c For terminated personnel, examine physical access controls lists and interview responsible personnel to verify that all physical access mechanisms (such as keys, access cards, etc.) were returned or disabled.

Identify the evidence reference number(s) from Section 6 for all physical access control lists examined for this testing procedure.

PCI DSS Requirement 9.3.2 Procedures are implemented for authorizing and managing visitor access to the CDE, including:

• Visitors are authorized before entering.

• Visitors are escorted at all times.

• Visitors are clearly identified and given a badge or other identification that …
Added p. 297
<Enter Response Here> 9.3.2.b Observe processes when visitors are present in the CDE and interview personnel to verify that visitors are:

• Authorized before entering the CDE.

• Escorted at all times within the CDE.

Identify the evidence reference number(s) from Section 6 for all observation(s) of processes when visitors are present in the CDE for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the use of visitor badges or other identification for this testing procedure.

<Enter Response Here> 9.3.2.d Observe visitors in the CDE to verify that:

• Visitor badges or identification easily distinguish visitors from personnel.
Added p. 298
Identify the evidence reference number(s) from Section 6 for all visitor badges or other identification examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of evidence in the badging system for this testing procedure.

PCI DSS Requirement 9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.3.3 Observe visitors leaving the facility and interview personnel to verify visitor badges or other identification are surrendered or deactivated before visitors leave the facility or at the date of expiration. upon departure or expiration.

Identify the evidence reference number(s) from Section 6 for all observation(s) of visitors leaving the facility for this testing procedure.

• The visitor’s name and the organization represented.

• The date and time of the visit.
Added p. 301
Identify the evidence reference number(s) from Section 6 for all visitor logs examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all visitor logs examined for this testing procedure.

<Enter Response Here> 9.3.4.b Examine the visitor log and verify that the log contains:

• The visitor’s name and the organization represented.

<Enter Response Here> 9.3.4.c Examine visitor log storage locations and interview responsible personnel to verify that the log is retained for at least three months, unless otherwise restricted by law.

Identify the evidence reference number(s) from Section 6 for all visitor log storage locations examined for this testing procedure.
Added p. 302
PCI DSS Requirement 9.4.1 All media with cardholder data is physically secured.
Added p. 303
PCI DSS Requirement 9.4.1.1 Offline media backups with cardholder data are stored in a secure location.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.1.1.a Examine documentation to verify that procedures are defined for physically securing offline media backups with cardholder data in a secure location.

<Enter Response Here> 9.4.1.1.b Examine logs or other documentation and interview responsible personnel at the storage location to verify that offline media backups are stored in a secure location.

Identify the evidence reference number(s) from Section 6 for all logs or other documentation examined for this testing procedure.

PCI DSS Requirement 9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.1.2.a Examine documentation to verify that procedures are defined for reviewing the security of the offline Identify the evidence reference number(s) from Section 6 …
Added p. 306
9.4.1.2.b Examine documented procedures, logs, or other documentation, and interview responsible personnel at the storage location(s) to verify that the storage location’s security is reviewed at least once every 12 months.

Identify the evidence reference number(s) from Section 6 for all documented procedures, logs, or other documentation examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.2.a Examine documentation to verify that procedures are defined for classifying media with cardholder data in accordance with the sensitivity of the data.

Identify the evidence reference number(s) from Section 6 for all media logs or other documentation examined for this testing procedure.

PCI DSS Requirement 9.4.3 Media with cardholder data sent outside the facility is secured as follows:

• Media sent outside the facility is logged.

• Offsite tracking logs include details about media location.
Added p. 309
Identify the evidence reference number(s) from Section 6 for all offsite tracking logs examined for this testing procedure.

PCI DSS Requirement 9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals).

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.4.a Examine documentation to verify that procedures are defined to ensure that media moved outside the facility is approved by management.

<Enter Response Here> 9.4.4.b Examine offsite media tracking logs and interview responsible personnel to verify that proper management authorization is obtained for all media moved outside the facility (including media distributed to individuals).

Identify the evidence reference number(s) from Section 6 for all offsite media tracking logs examined for this testing procedure.
Added p. 312
<Enter Response Here> 9.4.5.b Examine electronic media inventory logs and interview responsible personnel to verify that logs are maintained.

Identify the evidence reference number(s) from Section 6 for all electronic media inventory logs examined for this testing procedure.

PCI DSS Requirement 9.4.5.1 Inventories of electronic media with cardholder data are conducted at least once every 12 months.

Identify the evidence reference number(s) from Section 6 for all electronic media inventory logs examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.5.1.a Examine documentation to verify that procedures are defined to conduct inventories of electronic media with cardholder data at least once every 12 months.

<Enter Response Here> 9.4.5.1.b Examine electronic media inventory logs and interview personnel to verify that electronic media inventories are performed at least once every 12 months.

PCI DSS Requirement 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal …
Added p. 315
Identify the evidence reference number(s) from Section 6 for the periodic media destruction policy examined for this testing procedure.

<Enter Response Here> 9.4.6.b Observe processes and interview personnel to verify that hard- copy materials are cross-cut shredded, incinerated, or pulped such that cardholder data cannot be reconstructed.

PCI DSS Requirement 9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following:

• The electronic media is destroyed.

• The cardholder data is rendered unrecoverable so that it cannot be reconstructed.

Identify the evidence reference number(s) from Section 6 for the periodic media destruction policy examined for this testing procedure.
Added p. 317
<Enter Response Here> 9.4.7.b Observe the media destruction process and interview responsible personnel to verify that electronic media with cardholder data is destroyed via one of the methods specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all observation(s) of the media destruction process for this testing procedure.

<Enter Response Here> Requirement Description 9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.5.1 Examine documented policies and procedures to verify that processes are defined that include all elements specified in this requirement.
Added p. 320
Identify the evidence reference number(s) from Section 6 for all observation(s) of the POI devices and device locations for this testing procedure.

PCI DSS Requirement 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.5.1.2.a Examine documented procedures to verify processes are defined for periodic inspections of POI device surfaces to detect tampering and unauthorized substitution.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of the inspection processes for this testing procedure.

PCI DSS Requirement 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI …
Added p. 323
<Enter Response Here> 9.5.1.2.1.b Examine documented results of periodic device inspections and interview personnel to verify that the frequency and type of POI device inspections performed match what is defined in the entity’s targeted risk analysis conducted for this requirement.

Identify the evidence reference number(s) from Section 6 for the documented results of periodic device inspections examined for this testing procedure.
Added p. 325
Identify the evidence reference number(s) from Section 6 for all training materials examined for this testing procedure.
Added p. 326
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data Requirement Description 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.1.2.a Examine documentation to verify that descriptions of roles and responsibilities for performing Identify the evidence reference number(s) from Section 6 for all documentation examined for this testing procedure.
Added p. 329
10.1.2.b Interview personnel with responsibility for performing activities in Requirement 10 to verify that roles and responsibilities are assigned as defined and are understood.
Added p. 330
PCI DSS Requirement 10.2.1 Interview the system administrator and examine system configurations to verify that audit logs are enabled and active for all system components.
Added p. 331
PCI DSS Requirement 10.2.1.1 Audit logs capture all individual user access to cardholder data.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.1 Examine audit log configurations and log data to verify that all individual user access to cardholder data is logged.
Added p. 333
PCI DSS Requirement 10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.2 Examine audit log configurations and log data to verify Identify the evidence reference number(s) from Section 6 for all audit log <Enter Response Here>
Added p. 334
Identify the evidence reference number(s) from Section 6 for all log data examined for this testing procedure.

PCI DSS Requirement 10.2.1.3 Audit logs capture all access to audit logs.
Added p. 335
PCI DSS Requirement 10.2.1.4 Audit logs capture all invalid logical access attempts.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.4 Examine audit log configurations and log data to verify that invalid logical access attempts are captured.

PCI DSS Requirement 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to:

• Creation of new accounts.

• Elevation of privileges.

• All changes, additions, or deletions to accounts with administrative access.
Added p. 338
PCI DSS Requirement 10.2.1.6 Audit logs capture the following:

• All initialization of new audit logs, and

• All starting, stopping, or pausing of the existing audit logs.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.6 Examine audit log configurations and log data to verify that all elements specified in this requirement are captured.

PCI DSS Requirement 10.2.1.7 Audit logs capture all creation and deletion of system-level objects.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.7 Examine audit log configurations and log data to verify that creation and deletion of system level objects is captured.

PCI DSS Requirement 10.2.2 Audit logs record the following details for each auditable event:

• User identification.

• Success and failure indication.

• Origination of event.

• Identity or name of affected data, system component, resource, or service (for example, name and protocol).

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.2 Interview personnel and …
Added p. 343
PCI DSS Requirement 10.3.1 Read access to audit logs files is limited to those with a job-related need.
Added p. 344
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all system configurations and privileges examined for this testing procedure.

PCI DSS Requirement 10.3.2 Audit log files are protected to prevent modifications by individuals.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.3.2 Examine system configurations and privileges and interview system administrators to verify that current audit log files are protected from modifications by individuals via access control mechanisms, physical segregation, and/or network segregation.

Identify the evidence reference number(s) from Section 6 for all system configurations and privileges examined for this testing procedure.

PCI DSS Requirement 10.3.3 Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify.
Added p. 347
Identify the evidence reference number(s) from Section 6 for all backup configurations or log files examined for this testing procedure.

PCI DSS Requirement 10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.3.4 Examine system settings, monitored files, and results from monitoring activities to verify the use of file integrity monitoring or change- detection software on audit logs.
Added p. 348
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all monitored files examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all results from monitoring activities examined for this testing procedure.
Added p. 349
PCI DSS Requirement 10.4.1 The following audit logs are reviewed at least once daily:

• Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers).

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.4.1.a Examine security policies and procedures to verify that processes are defined for reviewing all elements specified in this requirement at least once daily.
Added p. 350
<Enter Response Here> 10.4.1.b Observe processes and interview personnel to verify that all elements specified in this requirement are reviewed at least once daily Identify the evidence reference number(s) from Section 6 for all observation(s) of processes for this testing procedure.

PCI DSS Requirement 10.4.1.1 Automated mechanisms are used to perform audit log reviews. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Added p. 352
Identify the evidence reference number(s) from Section 6 for all log review mechanisms examined for this testing procedure.

PCI DSS Requirement 10.4.2 Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.4.2.a Examine security policies and procedures to verify that processes are defined for reviewing logs of all other system components periodically.

<Enter Response Here> 10.4.2.b Examine documented results of log reviews and interview personnel to verify that log reviews are performed periodically.

Identify the evidence reference number(s) from Section 6 for all documented results of log reviews examined for this testing procedure.

PCI DSS Requirement 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1 Note: This requirement is a best …
Added p. 355
<Enter Response Here> 10.4.2.1.b Examine documented results of periodic log reviews of all other system components (not defined in Requirement 10.4.1) and interview personnel to verify log reviews are performed at the frequency specified in the entity’s targeted risk analysis performed for this requirement.

Identify the evidence reference number(s) from Section 6 for the documented results of all other system components (not defined in Requirement 10.4.1) examined for this testing procedure.

PCI DSS Requirement 10.4.3 Exceptions and anomalies identified during the review process are addressed.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process.

<Enter Response Here> 10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed.
Added p. 357
PCI DSS Requirement 10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
Added p. 358
• Procedures for retaining audit log history for at least 12 months, with at least the most recent three months immediately available online.

<Enter Response Here> 10.5.1.b Examine configurations of audit log history, interview personnel and examine audit logs to verify that audit logs history is retained for at least 12 months.

<Enter Response Here> 10.5.1.c Interview personnel and observe processes to verify that at least the most recent three months’ audit log history is immediately available for analysis.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the observation(s) of processes for this testing procedure.
Added p. 359
PCI DSS Requirement 10.6.1 System clocks and time are synchronized using time-synchronization technology.
Added p. 360
PCI DSS Requirement 10.6.2 Systems are configured to the correct and consistent time as follows:

• One or more designated time servers are in use.

• Only the designated central time server(s) receives time from external sources.

• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).

• The designated time server(s) accept time updates only from specific industry-accepted external sources.

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

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.6.2 Examine system configuration settings for acquiring, distributing, and storing the correct time to verify the settings are configured in accordance with all elements specified in this requirement.

PCI DSS Requirement 10.6.3 Time synchronization settings and data are protected as follows:

• Access to time data is restricted to only personnel with a business need.

• Any changes to time settings on critical systems are logged, monitored, and …
Added p. 363
Identify the evidence reference number(s) from Section 6 for all system configurations and time- synchronization settings examined for this testing procedure.

<Enter Response Here> 10.6.3.b Examine system configurations and time synchronization settings and logs and observe processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.

Identify the evidence reference number(s) from Section 6 for all system configurations time synchronization settings examined for this testing procedure.
Added p. 364
PCI DSS Requirement 10.7.1 Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Added p. 364
• Anti-malware solutions.

• Physical access controls.

• Logical access controls.

• Audit logging mechanisms.

• Segmentation controls (if used). Note: This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.7.1.a Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.

<Enter Response Here> 10.7.1.b Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.

Identify the evidence reference number(s) from Section 6 for all observation(s) of detection and alerting processes conducted for this testing procedure.

• …
Added p. 369
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.7.3.a Examine documentation and interview personnel to verify that processes are defined and implemented to respond to a failure of any critical security control system and include at least all elements specified in this requirement.

<Enter Response Here> 10.7.3.b Examine records to verify that failures of critical security control systems are documented to include:

• Identification of cause(s) of the failure.

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

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

Identify the evidence reference number(s) from Section 6 for all records examined for this testing procedure.

Requirement 11: Test Security of Systems and Networks Regularly Requirement Description 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.1.1 Examine documentation and interview personnel to verify …
Added p. 373
PCI DSS Requirement 11.2.1 Authorized and unauthorized wireless access points are managed as follows:

• The presence of wireless (Wi-Fi) access points is tested for,

• Testing, detection, and identification occurs at least once every three months.

• If automated monitoring is used, personnel are notified via generated alerts.

<Enter Response Here> 11.2.1.b Examine the methodology(ies) in use and the resulting documentation, and interview personnel to verify processes are defined to detect and identify both authorized and unauthorized wireless access points in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for the methodology(ies) in use and resulting documentation examined for this testing procedure.

<Enter Response Here> 11.2.1.c Examine wireless assessment results and interview personnel to verify that wireless assessments were conducted in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all wireless assessment results examined for this testing procedure.

PCI DSS …
Added p. 376
<Enter Response Here> Requirement Description 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.

• At least once every three months.

• Rescans are performed that confirm all high-risk and critical vulnerabilities (as noted above) have been resolved.

• Scan tool is kept up to date with latest vulnerability information.
Added p. 378
Identify the evidence reference number(s) from Section 6 for all internal scan report results examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all internal scan report results examined for this testing procedure.

<Enter Response Here> 11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities (identified in PCI DSS Requirement 6.3.1) are resolved.

<Enter Response Here> 11.3.1.c Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.

Identify the evidence reference number(s) from Section 6 for all scan tool configurations examined for this testing procedure.

<Enter Response Here> 11.3.1.d Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.

PCI DSS Requirement 11.3.1.1 All …
Added p. 380
<Enter Response Here> 11.3.1.1.b Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all internal scan report results or other documentation examined for this testing procedure.

PCI DSS Requirement 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows:

• Systems that are unable to accept credentials for authenticated scanning are documented.

• Sufficient privileges are used for those systems that accept credentials for scanning.

• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2. Note: …
Added p. 382
Identify the evidence reference number(s) from Section 6 for all examine scan report results examined for this testing procedure.

<Enter Response Here> 11.3.1.2.c If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2.

Identify the evidence reference number(s) from Section 6 for all accounts examined for this testing procedure.

<Enter Response Here> 11.3.1.2.d Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined.

PCI DSS Requirement 11.3.1.3 Internal vulnerability scans are performed after any significant change as follows:

• High-risk and critical vulnerabilities (per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• Rescans are conducted as needed.

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
Added p. 384
Identify the evidence reference number(s) from Section 6 for all change control documentation examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all internal scan reports examined for this testing procedure.

<Enter Response Here> 11.3.1.3.b Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that high-risk and critical vulnerabilities as defined in Requirement 6.3.1 were resolved.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all internal scan and rescan reports examined for this testing procedure.

• At least once every three months.

PCI DSS Requirement 11.3.2 External vulnerability scans are performed as follows:

• By PCI SSC Approved Scanning Vendor (ASV).

• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

• Rescans are conducted as needed.

• Scans are performed by qualified personnel …
Added p. 386
<Enter Response Here> 11.3.2.b Examine the ASV scan report from each scan and rescan run in the last 12 months to verify that vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met.

Identify the evidence reference number(s) from Section 6 for all ASV scan report results examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all ASV scan reports examined for this testing procedure.

PCI DSS Requirement 11.3.2.1 External vulnerability scans are performed after any significant change as follows:

Identify the evidence reference number(s) from Section 6 for all change control documentation examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.3.2.1.a Examine change control documentation and external scan reports to verify that system components were scanned after any significant changes.

<Enter Response Here> 11.3.2.1.b Interview personnel and examine external scan and rescan reports to verify that external …
Added p. 391
Identify the evidence reference number(s) from Section 6 for the scope of work examined for this testing procedure.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the results from the most recent internal penetration test examined for this testing procedure.

• At least once every 12 months

• After any significant infrastructure or application upgrade or change

PCI DSS Requirement 11.4.3 External penetration testing is performed:

• By a qualified internal resource or qualified external third party

Identify the evidence reference number(s) from Section 6 for the scope of work examined for this testing procedure.
Added p. 393
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for the results from the most recent external penetration test examined for this testing procedure.

PCI DSS Requirement 11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:

• In accordance with the entity's assessment of the risk posed by the security issue as defined in Requirement 6.3.1.

• Penetration testing is repeated to verify the corrections.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.4.4 Examine penetration testing results to verify that noted exploitable vulnerabilities and security weaknesses were corrected in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all penetration testing results examined for this testing procedure.

PCI DSS Requirement 11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:

• Confirming effectiveness of any use of …
Added p. 400
Identify the evidence reference number(s) from Section 6 for all evidence examined for this testing procedure.

<Enter Response Here> Requirement Description 11.5 Network intrusions and unexpected file changes are detected and responded to.

PCI DSS Requirement 11.5.1 Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows:

• All traffic is monitored at the perimeter of the CDE.

• All traffic is monitored at critical points in the CDE.

• Personnel are alerted to suspected compromises.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all network diagrams examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.5.1.a Examine system configurations and network diagrams to verify that intrusion-detection and/or intrusion-prevention techniques are in place to monitor all traffic:
Added p. 402
PCI DSS Requirement 11.5.1.1 Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.5.1.1.a Additional testing procedure for service provider assessments only: Examine documentation and configuration settings to verify that methods to detect and alert on/prevent covert malware communication channels are in place and operating.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all configuration settings examined for this testing procedure.

<Enter Response Here> 11.5.1.1.b Additional testing procedure for service provider assessments only: Examine the entity’s incident-response plan (Requirement 12.10.1) to verify it requires and defines a response in the event that covert malware communication channels are detected.

Identify the evidence reference …
Added p. 407
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all monitoring activities examined for this testing procedure.

<Enter Response Here> 11.6.1.b Examine configuration settings to verify the mechanism is configured in accordance with all elements specified in this requirement.

<Enter Response Here> 11.6.1.c If the mechanism functions are performed at an entity-defined frequency, examine the entity’s targeted risk analysis for determining the frequency to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.

<Enter Response Here> 11.6.1.d Examine configuration settings and interview personnel to verify the mechanism functions are performed either:

• At the frequency defined in the entity’s targeted risk analysis performed for this requirement.

Requirement 12: Support Information Security with Organizational Policies and Programs Requirement Description 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.

• Disseminated to all relevant personnel, as …
Added p. 410
• Reviewed at least once every 12 months.
Added p. 411
Identify the evidence reference number(s) from Section 6 for all information security policies examined for this testing procedure.

PCI DSS Requirement 12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.1.3.a Examine the information security policy to verify that they clearly define information security roles and responsibilities for all personnel.

<Enter Response Here> 12.1.3.c Examine documented evidence to verify personnel acknowledge their information security responsibilities.

Identify the evidence reference number(s) from Section 6 for all documented evidence examined for this testing procedure.

PCI DSS Requirement 12.1.4 Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management.
Added p. 414
<Enter Response Here> Requirement Description 12.2 Acceptable use policies for end-user technologies are defined and implemented.

PCI DSS Requirement 12.2.1 Acceptable use policies for end-user technologies are documented and implemented, including:

• List of products approved by the company for employee use, including hardware and software.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.2.1 Examine the acceptable use policies for end-user technologies and interview responsible personnel to verify processes are documented and implemented in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all acceptable use policies examined for this testing procedure.
Added p. 416
PCI DSS Requirement 12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:

• Identification of the assets being protected.

• Identification of the threat(s) that the requirement is protecting against.

• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.

• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.

• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.

• Performance of updated risk analyses when needed, as determined by the annual review. Note: This requirement is a best practice until 31 March 2025, after which it will be required and …
Added p. 419
PCI DSS Requirement 12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:

• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.

• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.

• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.3.3 Examine documentation for cryptographic suites and protocols in use and interview personnel to verify the documentation and review is in accordance with all elements specified in this requirement.

PCI DSS Requirement 12.3.4 Hardware and software technologies in use are reviewed at least …
Added p. 429
Identify the evidence reference number(s) from Section 6 for the inventory examined for this testing procedure.

<Enter Response Here> 12.5.1.b Interview personnel to verify the inventory is kept current.

PCI DSS Requirement 12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).

• Updating all data-flow diagrams per Requirement 1.2.4.

• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.

• Identifying all system components in the CDE, connected to the CDE, or that could impact …
Added p. 431
Identify the evidence reference number(s) from Section 6 for all documented results of scope reviews examined for this testing procedure.

PCI DSS Requirement 12.5.2.1 Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Identify the evidence reference number(s) from Section 6 for all documented results of scope reviews examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.5.2.1.a Additional testing procedure for service provider assessments only: Examine documented results of scope reviews and interview personnel to verify that reviews per Requirement 12.5.2 are performed:

• …
Added p. 434
<Enter Response Here> 12.5.3.b Additional testing procedure for service provider assessments only: Examine documentation (for example, meeting minutes) and interview responsible personnel to verify that significant changes to organizational structure resulted in documented reviews that included all elements specified in this requirement, with results communicated to executive management.
Added p. 435
PCI DSS Requirement 12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy and procedures, and their role in protecting the cardholder data.
Added p. 436
Identify the evidence reference number(s) from Section 6 for the security awareness program examined for this testing procedure.

PCI DSS Requirement 12.6.2 The security awareness program is:

• Reviewed at least once every 12 months, and

• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity's CDE, or the information provided to personnel about their role in protecting cardholder data. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.6.2 Examine security awareness program content, evidence of reviews, and interview personnel to verify that the security awareness program is in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all security awareness program content examined for this testing procedure.

<Enter …
Added p. 439
Identify the evidence reference number(s) from Section 6 for all security awareness program records examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all security awareness program materials examined for this testing procedure.

Identify the evidence reference number(s) from Section 6 for all security awareness program materials examined for this testing procedure.

<Enter Response Here> 12.6.3.d Examine security awareness program materials and personnel acknowledgments to verify that personnel acknowledge at least once every 12 months that they have read and understand the information security policy and procedures.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all personnel acknowledgments examined for this testing procedure.

PCI DSS Requirement 12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:

• Phishing and related attacks.

• Social engineering. Note: This requirement is a best practice until 31 March 2025, …
Added p. 441
Identify the evidence reference number(s) from Section 6 for all security awareness training content examined for this testing procedure.

PCI DSS Requirement 12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Identify the evidence reference number(s) from Section 6 for all security awareness training content examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.6.3.2 Examine security awareness training content to verify it includes awareness about acceptable use of end-user technologies in accordance with Requirement 12.2.1.

<Enter Response Here> Requirement Description 12.7 Personnel are screened to reduce risks from insider threats.

PCI DSS Requirement 12.7.1 Potential personnel who will have access to the CDE are screened, within the constraints of local laws, …
Added p. 445
PCI DSS Requirement 12.8.2 Written agreements with TPSPs are maintained as follows:

• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.

• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity's CDE.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.8.2.a Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement.

<Enter Response Here> 12.8.2.b Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all written agreements examined …
Added p. 449
12.8.4.b Examine documentation and interview responsible personnel to verify that the PCI DSS compliance status of each TPSP is monitored at least once every 12 months.

PCI DSS Requirement 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.8.5.a Examine policies and procedures to verify that processes are defined to maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both the TPSP and the entity.

<Enter Response Here> Requirement Description 12.9 Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.9.1 Additional testing procedure for service provider assessments only: Examine TPSP policies, procedures, and …
Added p. 453
<Enter Response Here> Requirement Description 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

PCI DSS Requirement 12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:

• Incident response procedures with specific containment and mitigation activities for different types of incidents.
Added p. 455
Identify the evidence reference number(s) from Section 6 for all incident response plans examined for this testing procedure.

<Enter Response Here> 12.10.1.b Interview personnel and examine documentation from previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.

• Reviewed and the content is updated as needed.

• Tested, including all elements listed in Requirement 12.10.1.

• Tested, including all elements listed in Requirement 12.10.1.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.10.2 Interview personnel and review documentation to verify that, at least once every 12 months, the security incident response plan is:

• Reviewed and updated as needed.

PCI DSS Requirement 12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
Added p. 458
PCI DSS Requirement 12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.10.4 Examine training documentation and interview incident response personnel to verify that personnel are appropriately and periodically trained on their incident response responsibilities.

PCI DSS Requirement 12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.10.4.1.a Examine the entity’s targeted risk analysis for the frequency of training for incident response personnel to verify the risk analysis was performed in accordance …
Added p. 462
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all observation(s) of incident response processes for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.10.6.a Examine policies and procedures to verify that processes are defined to modify and evolve the security incident response plan according to lessons learned and to incorporate industry developments.

<Enter Response Here> 12.10.6.b Examine the security incident response plan and interview responsible personnel to verify that the incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

Identify the evidence reference number(s) from Section 6 for the security incident response plan examined for this testing procedure.

PCI DSS Requirement 12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:

• Determining what to do if PAN is discovered outside the CDE, including its …
Added p. 465
<Enter Response Here> 12.10.7.b Interview personnel and examine records of response actions to verify that incident response procedures are performed upon detection of stored PAN anywhere it is not expected.

<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all records of response actions examined for this testing procedure.

<Enter Response Here> Appendix A Additional PCI DSS Requirements A1 Additional PCI DSS Requirements for Multi-Tenant Service Providers Requirement Description A1.1 Multi-tenant service providers protect and separate all customer environments and data.

PCI DSS Requirement A1.1.1 Logical separation is implemented as follows:

• The provider cannot access its customers' environments without authorization.

• Customers cannot access the provider's environment without authorization. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.1.1 Examine documentation and system …
Added p. 467
PCI DSS Requirement A1.1.2 Controls are implemented such that each customer only has permission to access its own cardholder data and CDE.
Added p. 468
<Enter Response Here> A1.1.2.b Examine system configurations to verify that customers have privileges established to only access their own account data and CDE.

PCI DSS Requirement A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.1.3 Examine customer privileges to verify each customer can only access resources allocated to them.

Identify the evidence reference number(s) from Section 6 for all customer privileges examined for this testing procedure.

PCI DSS Requirement A1.1.4 The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.1.4 Examine the results from the most …
Added p. 473
Identify the evidence reference number(s) from Section 6 for the documented procedures examined for this testing procedure.

PCI DSS Requirement A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:

• Customers can securely report security incidents and vulnerabilities to the provider.

• The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1. Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Identify the evidence reference number(s) from Section 6 for the documented procedures examined for this testing procedure.

<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.2.3 Examine documented procedures and interview personnel to verify that the provider has a mechanism for reporting and addressing suspected or confirmed security incidents and vulnerabilities, in accordance with all elements specified in …
Added p. 475
PCI DSS Requirement A2.1.1 Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols.

PCI DSS Requirement A2.1.2 Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place that includes:
Added p. 477
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A2.1.2 Additional testing procedure for service provider assessments only: Review the documented Risk Mitigation and Migration Plan to verify it includes all elements specified in this requirement.

PCI DSS Requirement A2.1.3 Additional requirement for service providers only: All service providers provide a secure service offering.
Added p. 478
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A2.1.3 Additional testing procedure for service provider assessments only: Examine system configurations and supporting documentation to verify the service provider offers a secure protocol option for its service.
Added p. 479
 PCI DSS v4.0 Supplemental Report on Compliance Template - Designated Entities Supplemental Validation  PCI DSS v4.0 Supplemental Attestation of Compliance for Report on Compliance - Designated Entities Supplemental Validation These documents are available in the PCI SSC Document Library.

4. When evaluating “above and beyond” for compensating controls, consider the following:

Note: All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS assessment. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Entities should be aware that a given compensating control will not be effective in all environments. 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 …
Added p. 482
Required Number and Definition: <Enter Response Here> Information Required Explanation

<Enter Response Here> Identify the objective met by the compensating control (note: this can be, but is not required to be, the stated Customized Approach Objective for the PCI DSS requirement).
Added p. 483
The entity implementing a customized approach must satisfy the following criteria:

 Document and maintain evidence about each customized control, including all information specified in the Controls Matrix Template in Appendix E1 of the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures.

 Perform and document a targeted risk analysis (PCI DSS Requirement 12.3.2) for each customized control, including all information specified in the Targeted Risk Analysis Template in Appendix E2 of the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures.

 Perform testing of each customized control to prove effectiveness, and document testing performed, methods used, what was tested, when testing was performed, and results of testing in the controls matrix.

 Monitor and maintain evidence about the effectiveness of each customized control.

 Provide completed controls matrix(es), targeted risk analysis, testing evidence, and evidence of customized control effectiveness to its assessor.

The assessor performing an assessment …
Added p. 484
 The use of the customized approach may be regulated by organizations that manage compliance programs (for example, payment brands and acquirers). Therefore, questions about use of a customized approach must be referred to those organizations, including, for example, whether an entity is required to use a QSA, or may use an ISA to complete an assessment using the customized approach.

Note: Compensating controls are not an option with the customized approach. Because the customized approach allows an entity to determine and design the controls needed to meet a requirement’s Customized Approach Objective, the entity is expected to effectively implement the controls it designed for that requirement without needing to also implement alternate, compensating controls.
Added p. 485
Requirement Number and Definition: <Enter Response Here> Identify the customized control name / identifier for each control used to meet the Customized Approach Objective. (Note: use the Customized Control name from the assessed entity’s controls matrix) <Enter Response Here> Describe each control used to meet the Customized Approach Objective. (Note: Refer to the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures for the Customized Approach Objective) <Enter Response Here> Describe how the control(s) meet the Customized Approach Objective. <Enter Response Here> Identify the Controls Matrix documentation reviewed that supports a customized approach for this requirement.

<Enter Response Here> Identify the Targeted Risk Analysis documentation reviewed that supports the customized approach for this requirement.

<Enter Response Here> Identify name(s) of the assessor(s) who attests that:

• The entity completed the Controls Matrix including all information specified in the Controls Matrix Template in Appendix E1 of Payment Card Industry Data Security …
Added p. 486
<Enter Response Here> Identify all evidence examined for this testing procedure.

<Enter Response Here> Identify all evidence examined for this testing procedure.

<Enter Response Here> Describe the results of the testing performed by the assessor for this testing procedure and how these results verify the implemented controls meet the Customized Approach Objective.

<Enter Response Here> Document the testing procedures derived and performed by the assessor to validate the controls are maintained to ensure ongoing effectiveness; for example, how the entity monitors for control effectiveness and how control failures are detected, responded to, and the actions taken. Note 1: Technical reviews (for example, reviewing configuration settings, operating effectiveness, etc.) should be performed where possible and appropriate. Note 2: Add additional rows for each assessor-derived testing procedure, as needed. Ensure that all rows to the right of the “Assessor-derived testing procedure” are copied for each assessor-derived testing procedure that is added.

<Assessor-derived testing procedure> Identify what …
Modified p. 1
Payment Card Industry (PCI) Data Security Standard Report on Compliance
Payment Card Industry Data Security Standard
Modified p. 1
PCI DSS v3.2.1 Template for Report on Compliance Revision 2
PCI DSS v4.0 Report on Compliance Template Revision 1
Removed p. 2
This document is intended for use with PCI DSS v 3.2.1 r1.
Modified p. 2
July 2014 PCI DSS 3.0, Revision 1.1 Errata - Minor edits made to address typos and general errors, slight addition of content
July 2014 PCI DSS 3.0, Revision 1.1 Errata - Minor edits made to address typos and general errors, slight addition of content.
Removed p. 5
Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be modified to increase/decrease the number of rows, or to change column width. Additional appendices may be added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos, is acceptable.

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as the report is written and for the recipient in understanding the context the responses and conclusions are made. Addition of text or sections is applicable within reason, as noted above. Refer to the “Frequently Asked Questions for …
Modified p. 5 → 6
Use of this Reporting Template is mandatory for all v3.2.1 submissions.
Use of this ROC Template is mandatory for all PCI DSS v4.0 submissions.
Modified p. 5 → 6
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 …
The ROC is completed during 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 assessment results for each PCI DSS requirement. A PCI DSS compliance assessment involves thorough testing and assessment activities, from which the assessor will generate evidence (assessment workpapers). These workpapers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, …
Modified p. 5 → 6
• Section 1: Contact Information and Report Date
• Section 1: Contact Information and Summary of Results
Modified p. 5 → 6
• Section 2: Summary Overview
• Section 2: Business Overview
Modified p. 5 → 7
• Section 6: Findings and Observations
• Section 6: Evidence (Assessment Workpapers)  Part II: Findings and Observations
Removed p. 6
• Appendix D: Segmentation and Sampling of Business Facilities/System Components (diagram) The first five sections must be thoroughly and accurately completed, in order for the assessment findings in Section 6 and any applicable responses in the Appendices to have the proper context. The Reporting Template includes tables with Reporting Instructions built-in to help assessors provide all required information throughout the document. Responses should be specific, but efficient. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage. Parroting the testing procedure within a description is discouraged, as it does not add any level of assurance to the narrative. Use of template language for summaries and descriptions is discouraged and details should be specifically relevant to the assessed entity.

ROC Summary of Assessor Findings With the Reporting Template, an effort was made to efficiently use space, and as such, there is one response column for results/evidence (“ROC Reporting …
Modified p. 6 → 7
Appendices B and C: Compensating Controls and Compensating Controls Worksheet (as applicable)
Appendix C: Compensating Controls Worksheet
Modified p. 6 → 8
Refer to the “Frequently Asked Questions for use with ROC Reporting Template for PCI DSS v3.x” document on the PCI SSC website for further guidance.
Refer to the PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions document on the PCI SSC website for further guidance.
Modified p. 6 → 8
In Place The expected testing has been performed, and all elements of the requirement have been met as stated.
Assessment When to Use This Assessment Finding Using Figure 1 Required Reporting In Place The expected testing has been performed, and all elements of the requirement have been met.
Modified p. 6 → 8
In the sample, the Summary of Assessment Findings at 1.1 is “in place” if all report findings are in place for 1.1.a and 1.1.b or a combination of in place and not applicable.
In Figure 1, the Assessment Finding at 1.1.1 is In Place if all report findings are In Place for 1.1.1.a and 1.1.1.b or a combination of In Place and Not Applicable.
Removed p. 7
In Place w/ CCW (Compensating Control Worksheet) The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.

All responses in this column require completion of a Compensating Control Worksheet (CCW) Information on the use of compensating controls and guidance on how to complete the worksheet is provided in the PCI DSS.

In the sample, the Summary of Assessment Findings at 1.1 is “in place with CCW” if all report findings are in place for 1.1.a and 1.1.b with the use of a CCW for one or both (completed at the end of the report) or a combination of in place with CCW and not applicable.

All “not applicable” responses require reporting on testing performed to confirm the “not applicable” status. Note that a “Not Applicable” response still requires a detailed description explaining how it was determined that the requirement does not apply. In scenarios …
Modified p. 7 → 8
**Note, future-dated requirements are considered Not Applicable until the future date has passed. While it is true that the requirement is likely not tested (hence the original instructions), it is not required to be tested until the future date has passed, and the requirement is therefore not applicable until that date. As such, a “Not Applicable” response to future-dated requirements is accurate, whereas a “Not Tested” response would imply there was not any consideration as to whether it could apply …
In Figure 1, the Assessment Finding at 1.1.1 is Not Applicable if both 1.1.1.a and 1.1.1.b are concluded to be Not Applicable. A requirement is applicable if any aspects of the requirement apply to the environment being assessed, and a Not Applicable designation in the Assessment Findings should not be used in this scenario. Note: Requirements and/or individual bullets within a requirement noted as a best practice until its effective date are considered Not Applicable until the future date has …
Modified p. 7 → 9
Not in Place Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before it will be known if they are in place.
Not in Place Some or all elements of the requirement have not been met, are in the process of being implemented, or require further testing before it will be known if they are In Place. This response is also used if a requirement cannot be met due to a legal restriction, meaning that meeting the requirement would contravene a local or regional law or regulation. The assessor must confirm that a statutory law or regulation exists that prohibits the requirement …
Modified p. 7 → 9
In the sample, the Summary of Assessment Findings at 1.1 is “not in place” if either 1.1.a or 1.1.b are concluded to be “not in place.” (Not Applicable) The requirement does not apply to the organization’s environment.
In Figure 1, the Assessment Finding at 1.1.1 is Not in Place if either 1.1.1.a or 1.1.1.b are concluded to be Not in Place.
Removed 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.

Requirement X: Sample Note

• checkboxes have been added to the “Summary of Assessment Findings” so that the assessor may double click to check the applicable summary result. Hover over the box you’d like to mark and click once to mark with an ‘x’. To remove a mark, hover over the box and click again.
Modified p. 8 → 11
If a requirement is completely excluded from review without any consideration as to whether it could apply, the “Not Tested” option should be selected. Examples of situations where this could occur may include:
If a requirement is completely excluded from review without any consideration as to whether it could apply, the Not Tested option must be selected. Examples of situations where this could occur may include:
Modified p. 8 → 11
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 or brand to validate a subset of requirements•for example, using the prioritized approach to validate certain milestones.
Modified p. 8 → 11
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 want only to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.
Modified p. 8 → 11
In these scenarios, the organization only wishes to validate certain PCI DSS requirements even though other requirements might also apply to their environment. Compliance is determined by the brands and acquirers, and the AOCs they see will be clear in what was tested and not tested. They will decide whether to accept a ROC with something “not tested,” and the QSA should speak with them if any exception like this is planned. This should not change current practice, just reporting.
In these scenarios, the organization wants only to validate certain PCI DSS requirements, even though other requirements might also apply to their environment. The resulting AOC(s) must be clear in what was tested and not tested.
Removed p. 9
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) In Place with CCW Not Applicable Not Tested Not in Place 1.1 Sample sub-requirement ☐ ☐ ☐ ☐ ☐ 1.1.a Sample testing procedure Reporting Instruction <Report Findings Here> 1.1.b Sample testing procedure Reporting Instruction <Report Findings Here> ROC Reporting Details The reporting instructions in the Reporting Template explain the intent of the response required. There is no need to repeat the testing procedure or the reporting instruction within each assessor response. As noted earlier, responses should be specific and relevant to the assessed entity. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage and should avoid parroting of the testing procedure without additional detail or generic template language.

• Document name or interviewee job title/reference

• In Sections 4.9, “Documentation Reviewed,” and 4.10, “Individuals Interviewed” below, there is a …
Modified p. 9 → 15
Assessor responses will generally fall into categories such as the following:
Assessor responses generally fall into categories, such as the following:
Modified p. 9 → 15
• One word (yes/no) Example Reporting Instruction: Indicate whether the assessed entity is an issuer or supports issuing services. (yes/no)
Reporting Instruction Term Example Usage Description of Response Indicate Indicate whether the assessed entity is an issuer or supports issuing services.
Removed p. 10
Example Reporting Instruction: Describe the procedures for secure key distribution that were observed to be implemented. Example Reporting Instruction: For the interview, summarize the relevant details discussed that verify … Dependence on another service provider’s compliance:

Generally, when reporting on a requirement where a third-party service provider is responsible for the tasks, an acceptable response for an “in place” finding may be something like:
Modified p. 10 → 12
“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 …
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 YYYY-MM-DD, and confirmed the service provider was found to be PCI DSS compliant against PCI DSS vX.X for all applicable requirements, and that it covers the scope of the services used by the assessed entity.
Removed p. 11
• Complete all sections in the order specified.

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

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

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

• Don’t simply repeat or echo the Testing Procedure in the response.
Modified p. 11 → 16
• Use this Reporting Template when assessing against v3.2.1 of the PCI DSS.
• Use this Reporting Template when assessing against v4.0 of the PCI DSS.
Modified p. 11 → 16
• Provide sufficient detail and information to support the designated finding, but be concise.
• Provide sufficient detail and information to thoroughly document the assessment.
Modified p. 11 → 16
• Ensure the parts of the Testing Procedure and Reporting Instruction are addressed.
• Ensure all parts of the Testing Procedure and Reporting Instruction are addressed.
Modified p. 11 → 16
• Ensure the response covers all applicable system components.
• Ensure the response covers all applicable system components, business functions, or facilities.
Modified p. 11 → 16
• Provide useful, meaningful diagrams, as directed.
• Provide useful, meaningful diagrams as directed.
Removed p. 12
1. Contact Information and Report Date 1.1 Contact information

• Company contact name:

• Contact phone number:

• Contact e-mail address:

• Lead Assessor name:

• Assessor PCI credentials:

• Assessor phone number:

• Assessor e-mail address:

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

• QA reviewer phone number:

• QA reviewer e-mail address:

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

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

• Version of the PCI Data Security Standard used for the assessment (should be 3.2.1):

• Disclose all services offered to the assessed entity by the QSAC, including but …
Modified p. 13 → 20
Identify date(s) spent onsite at the entity:
<Enter Response Here> Identify the date(s) spent onsite at the assessed entity.
Modified p. 13 → 22
Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the QSAC:
<Enter Response Here> Describe efforts made to ensure no conflict of interest resulted from the above- mentioned products and services provided by the QSA Company.
Removed p. 14
PCI DSS Requirement Summary of Findings (check one) Compliant Non-Compliant Not Applicable Not Tested

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

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

3. Protect stored cardholder data ☐ ☐ ☐ ☐

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

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

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

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

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

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

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

11. Regularly test security systems and processes ☐ ☐ …
Removed p. 15
• Describe the nature of the entity’s business (what kind of work they do, etc.)

Note: This is not intended to be a cut-and-paste from above, but should build on the understanding of the business and the impact this can have upon the security of cardholder data.

Note: This is not intended to be a cut-and-paste from above, but should build on the understanding of the business and the impact this can have upon the security of cardholder data.

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

• 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).
Removed 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
Modified p. 15 → 27
Note: This is not intended to be a cut-and-paste from the entity’s website, but should be a tailored description that shows the assessor understands the business of the entity being assessed.
Describe the nature of the entity’s business (what kind of work they do, etc.). Note: This is not intended to be a cut-and-paste from the entity’s website but should be a tailored description that shows the assessor understands the business of the entity being assessed.
Modified p. 15 → 37
Describe how the entity stores, processes, and/or transmits cardholder data.
Describe all networks that store, process, and/or transmit Account Data:
Removed p. 17
3. Description of Scope of Work and Approach Taken 3.1 Assessor’s validation of defined cardholder data environment and scope accuracy Document how the assessor validated the accuracy of the defined CDE/PCI DSS scope for the assessment, including:

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 compromised could impact the CDE.

• 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 …
Removed p. 18
• such as technical support, management, administrators, operations teams, cashiers, telephone operators, physical security, etc.:

Note

• this is not intended to be a list of individuals interviewed, but instead a list of the types of people, teams, etc. who were included in the scope.

• such as payment channels, business functions, etc.:

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

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.

• Locations/sites/stores

• such as retail outlets, data centers, corporate office locations, call centers, etc.:
Removed p. 18
• Identify whether the assessed entity has used network segmentation to reduce the scope of the assessment. (yes/no) Note -- An environment with no segmentation is considered a “flat” network where all systems are considered in scope due to a lack of segmentation.

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

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

- Describe the methods used to validate the effectiveness of the segmentation (for example, observed configurations of implemented technologies, tools used, network traffic analysis, etc.).

- Describe how it was verified that the segmentation is functioning as
Modified p. 18 → 29
• If segmentation is not used: Provide the name of the assessor who attests that the whole network has been included in the scope of the assessment.
• If “No,” provide the name of the assessor who attests that the entire network has been included in the scope of the assessment.
Removed p. 19
- Identify the security controls that are in place to ensure the integrity of the segmentation mechanisms (e.g., access controls, change management, logging, monitoring, etc.).

- 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. 19 → 29
• 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 this PCI DSS assessment.
Removed p. 20
Network Name (in scope) Function/ Purpose of Network Describe any networks confirmed to be out of scope:

Network Name (out of scope) Function/ Purpose of Network
Modified p. 20 → 37
Network Name (in scope) Function/ Purpose of Network Describe all networks that do not store, process and/or transmit CHD, but are still in scope (e.g., connected to the CDE or provide management functions to the CDE):
Network Name (In scope) Type of Network Function/ Purpose of Network <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> <Enter Response Here> Describe all networks that do not store, process, and/or transmit Account Data but are still in scope•for example, connected to the CDE or provide management functions to the CDE, etc.:
Removed p. 21
Identify All Processing and Transmitting Entities (i.e. Acquirer/ Bank/ Brands) Directly Connected? (yes/no) Reason(s) for Connection:

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):
Removed p. 21
List all countries where the entity conducts business.

(If there are no international entities, then the country where the assessment is occurring should be included at a minimum.) International Entity Name Facilities in this country reviewed:

As part of this assessment Separately

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

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

− 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:

Identified wireless technology For each wireless technology in scope, identify the following (yes/no):

Whether the technology is used to store, process or transmit CHD Whether the technology …
Removed p. 24
4. Details about Reviewed Environment 4.1 Detailed network diagram(s) Provide one or more detailed diagrams to illustrate each communication/connection point between in scope networks/environments/facilities. Diagrams should include the following:

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

• 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 controls applicable to that communication point.) <Insert detailed diagram(s)> 4.2 Description of cardholder data flows

Note: The term “Capture” in Section 4.2 of the ROC Template refers to the specific transaction activity, while the use of “capture” in PCI DSS Requirement 9.9 refers to the receiving of cardholder data via physical contact with a payment card (e.g. via swipe or …
Modified p. 24 → 32
All boundaries of the cardholder data environment
At the perimeter of the cardholder data environment.
Modified p. 24 → 32
• Boundaries between trusted and untrusted networks
 Illustrates all network security controls that are defined for connection points between trusted and untrusted networks.
Removed 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)
Modified p. 25 → 34
Note: The list of files and tables that store cardholder data in the table below must be supported by an inventory created (or obtained from the client) and retained by the assessor in the work papers.
Note: The list of files and tables that store account data in the table below must be supported by an inventory created (or obtained from the assessed entity) and retained by the assessor in the workpapers.
Removed p. 26
• including homegrown components. Critical software includes e-commerce applications, applications accessing CHD for non-payment functions (fraud modeling, credit verification, etc.), software performing security functions or enforcing PCI DSS controls, underlying operating systems that store, process or transmit CHD, system management software, virtualization management software, and other critical software

• including homegrown software/applications. For each item in the list, provide details for the hardware and software as indicated below. Add rows, as needed.

Critical Hardware Critical Software Role/Functionality Type of Device (for example, firewall, server, IDS, etc.) Vendor Make/Model Name of Software Version or 4.5 Sampling Identify whether sampling was used during the assessment.

• If sampling is not used:

• If sampling is used:

− 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 …
Modified p. 26 → 31
− Provide the name of the assessor who attests that every system component and all business facilities have been assessed.
• If “No,” provide the name of the assessor who attests that every item in each population has been assessed.
Removed p. 27
− If standardized PCI DSS security and operational processes/controls were used for selecting sample sizes, describe how they were validated by the assessor.
Removed p. 27
Note: If sampling is used, this section MUST be completed. When a reporting instruction asks to identify a sample, the QSA may either refer to the Sample Set Reference Number (for example “Sample Set-1”) OR list the sampled items individually in the response. Examples of sample sets may include, but are not limited to, firewalls, application servers, retail locations, data centers, User IDs, people, etc. Add rows as needed.

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
Removed p. 28
Company Name What data is shared (for example, PAN, expiry date, etc.) The purpose for sharing the data (for example, third-party storage, transaction processing, etc.) Status of PCI DSS Compliance (Date of AOC and version #) 4.8 Third-party payment applications/solutions Use the table on the following page to identify and list all third-party payment application products and version numbers in use, including whether each payment application has been validated according to PA-DSS or PCI P2PE. Even if a payment application has been PA-DSS or PCI P2PE validated, the assessor still needs to verify that the application has been implemented in a PCI DSS compliant manner and environment, and according to the payment application vendor’s PA-DSS Implementation Guide for PA-DSS applications or P2PE Implementation Manual (PIM) and P2PE application vendor’s P2PE Application Implementation Guide for PCI P2PE applications/solutions.

Note: It is not a PCI DSS requirement to use PA-DSS validated applications. Please …
Modified p. 28 → 35
Note: These entities are subject to PCI DSS Requirement 12.8.
These entities are subject to PCI DSS Requirement 12.8.
Removed p. 29
PCI SSC listing reference number Expiry date of listing, if applicable
Removed p. 29
• 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).

• 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.
Removed p. 29
(optional) Document Name (including version, if applicable) Brief description of document purpose Document date (latest version date) 4.10 Individuals interviewed Identify and list the individuals interviewed. Include the following:

Number (optional) Employee Name Role/Job Title Organization Is this person an ISA? (yes/no)
Modified p. 29 → 30
Any additional comments or findings the assessor would like to include, as applicable:
<Enter Response Here> Any additional comments or findings the assessor would like to include, if applicable.
Removed p. 30
• Identify whether the entity being assessed is a managed service provider. (yes/no)

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

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

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

− 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 the responsibility of the MSP’s customers.
Removed p. 30
• Identify whether there were any responses indicated as “In Place with Compensating Control.” (yes/no)

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:
Modified p. 30 → 29
• If “yes,” complete the table below:
• If “Yes,” complete the following:
Removed p. 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:

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

• The most recent scan result was a passing scan,

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

Date of the scan(s) Name of ASV that performed the scan Were any vulnerabilities found that resulted in a failed initial scan? (yes/no) For all scans resulting in a Fail, provide date(s) of re-scans showing that the vulnerabilities have been corrected If this is the initial PCI DSS compliance validation, complete the following:

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

• Identify the …
Modified p. 32 → 42
Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:
It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:
Modified p. 32 → 43
The entity has documented policies and procedures requiring quarterly scanning going forward, and
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.
Modified p. 32 → 43
• 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.
For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
Modified p. 32 → 43
Assessor comments, if applicable:
<Enter Response Here> Assessor comments, if applicable: <Enter Response Here>
Removed p. 33
Provide the name of the assessor who attests that the ASV and the entity have completed the Attestations of Scan Compliance confirming that all externally accessible (Internet- facing) IP addresses in existence at the entity were appropriately scoped for the ASV scans:

6. Findings and Observations Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder 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 1.1 Establish and implement firewall and router configuration standards that include the following:
Removed p. 34
• Network connections, and

• Changes to firewall and router configurations.

Identify the document(s) reviewed to verify procedures define the formal processes for:

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

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

<Report Findings Here> 1.1.1.b For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested.

Identify the sample of records for network connections that were selected for this testing procedure.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that network connections were approved and tested.

<Report Findings Here> Describe how the sampled records verified that network connections were:

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

Identify the sample of records …
Removed p. 36
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.1.4.b Verify that the current network diagram is consistent with the firewall configuration standards.

Provide the name of the assessor who attests that the current network diagram is consistent with the firewall configuration standards.

<Report Findings Here> 1.1.4.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, per the documented configuration standards and network diagrams.

Describe how network configurations verified that, per the documented configuration standards and network diagrams, a firewall is in place:

• 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 …
Removed p. 38
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.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.

Identify the firewall and router configuration standards document(s) reviewed to verify they identify inbound and outbound traffic necessary for the cardholder data environment.

<Report Findings Here> 1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Describe how firewall and router configurations verified that the following traffic is limited to that which is necessary for the cardholder data environment:

• 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 …
Removed p. 39
Describe how firewall and router configurations verified that the DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

<Report Findings Here> 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. ☐ ☐ ☐ ☐ ☐ 1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.

Describe how firewall and router configurations verified that configurations limit inbound Internet traffic to IP addresses within the DMZ.

<Report Findings Here> 1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.

(For example, block traffic originating from the Internet with an internal source address) ☐ ☐ ☐ ☐ ☐

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.3.3 Examine firewall and router configurations …
Modified p. 43 → 78
Identify the document reviewed to verify that security policies and operational procedures for managing firewalls are documented.
PCI DSS Requirement 2.1.1 All security policies and operational procedures that are identified in Requirement 2 are:
Removed p. 44
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

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 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, POS terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.

2.1.a Choose a sample of system components, and attempt to log on (with system administrator help) to the devices and applications using default vendor- supplied accounts and passwords, to verify that ALL default passwords (including those on operating systems, software that provides security services, application and system accounts, POS terminals, and Simple Network Management Protocol (SNMP) community strings) …
Removed p. 45
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.c Interview personnel and examine supporting documentation to verify that:

• 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. 45
Identify the responsible personnel interviewed who verify that:

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

<Report Findings Here> Identify supporting documentation examined to verify that:

<Report Findings Here> 2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

2.1.1.a Interview responsible personnel and examine supporting documentation to verify that:

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

Identify the responsible personnel interviewed who verify that:

<Report Findings Here> Identify supporting documentation examined …
Removed p. 47
<Report Findings Here> 2.1.1.d Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for:

• Authentication over wireless networks

• 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 <Report Findings Here> Describe how wireless configuration settings verified that firmware on wireless devices is updated to support strong encryption for:

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

Identify vendor documentation examined to verify other security-related wireless vendor defaults were changed, if applicable.

<Report Findings Here> Describe how wireless configuration settings verified that other security-related wireless vendor defaults were changed, if applicable.

<Report Findings Here> 2.2 Develop configuration …
Modified p. 49 → 59
• Implementing additional security features for any required services, protocols or daemons that are considered to be insecure
PCI DSS Requirement 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.
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 Place verify that only one primary function is implemented per virtual system component or device.

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

<Report Findings Here> For each virtual system component and device in the sample, describe how system configurations verified that only one primary function is implemented per virtual system component or device.

<Report Findings Here> 2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system. ☐ ☐ ☐ ☐ ☐ 2.2.2.a Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled.

<Report Findings Here> For each item in the sample, describe how the enabled system services, daemons, and protocols verified …
Modified p. 50
• Documented <Report Findings Here>
<Enter Response Here>
Modified p. 50 → 60
Describe how configuration settings verified that security features for all insecure services, daemons, or protocols are:
<Enter Response Here> 1.2.6.b Examine configuration settings for NSCs to verify that the defined security features are implemented for each identified insecure service, protocol, and port.
Modified p. 50 → 67
<Report Findings Here> Identify the sample of virtual system components or devices selected for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all network diagrams examined for this testing procedure.
Removed p. 51
• 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.

<Report Findings Here> For the interview, summarize the relevant details discussed to verify that they have knowledge of common security parameter settings for system components.

Identify the system configuration standards examined to verify that common security parameter settings are included.

<Report Findings Here> For each item in the sample, describe how the common security parameters verified that they are set appropriately and in accordance with the configuration standards.

<Report Findings Here> 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, …
Modified p. 51 → 50
Identify the system administrators and/or security managers interviewed for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Modified p. 51
• Documented <Report Findings Here>
<Enter Response Here>
Modified p. 51 → 52
<Report Findings Here> 2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.
<Enter Response Here> 1.2.1.b Examine configuration settings for NSC rulesets to verify that rulesets are implemented according to the configuration standards.
Modified p. 51 → 58
<Report Findings Here> 2.2.4.b Examine the system configuration standards to verify that common security parameter settings are included.
<Enter Response Here> 1.2.5.b Examine configuration settings for NSCs to verify that only approved services, protocols, and ports are in use.
Removed p. 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 Place documented functionality is present on the sampled system components.

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

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

Identify the sample of system components selected for 2.3.a-2.3.d.

<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.
Removed p. 52
Describe how the administrator log on to each system verified that a strong encryption method is invoked before the administrator’s password is requested.

<Report Findings Here> Describe how system configurations for each system verified that a strong encryption method is invoked before the administrator’s password is requested.

<Report Findings Here> Identify the strong encryption method used for non-console administrative access.

<Report Findings Here> 2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.

Describe how services and parameter files on systems verified that Telnet and other insecure remote-login commands are not available for non- console access.

<Report Findings Here> 2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.

Describe how the administrator log on to each system verified that administrator access to any web- based management interfaces was …
Modified p. 53
• Maintained <Report Findings Here>
<Enter Response Here>
Removed p. 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 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.

Indicate whether the assessed entity is a shared hosting provider. (yes/no) <Report Findings Here> If “yes,” provide the name of the assessor who attests that Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers has been completed.

Requirement 3: Protect stored cardholder data

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

3.1.a Examine the data-retention and disposal policies, procedures and processes to verify they include the following for all cardholder data (CHD) storage:

• Limiting data storage …
Modified p. 55 → 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 3.1 Keep cardholder data storage to a minimum by implementing data-retention and disposal policies, procedures and processes that include at least the following for all CHD storage:
PCI DSS Requirement 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:
Modified p. 55 → 101
• 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 or regulatory, and/or business requirements.
Modified p. 55 → 101
• Specific retention requirements for cardholder data
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
Modified p. 55 → 101
• Processes for secure deletion of data when no longer needed.
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
Modified p. 55 → 102
Identify the data-retention and disposal documentation examined to verify policies, procedures, and processes define the following for all cardholder data (CHD) storage:
Identify the evidence reference number(s) from Section 6 for all data retention and disposal policies, procedures, and processes examined for this testing procedure.
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.b Interview personnel to verify that:

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

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

• 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.
Removed p. 56
<Report Findings Here> 3.1.c For a sample of system components that store cardholder data:

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

<Report Findings Here> For each item in the sample, describe how files and system records verified that the data stored does not exceed the requirements defined in the data-retention policy.

<Report Findings Here> Describe how the deletion mechanism was observed to verify data is deleted securely.

<Report Findings Here> 3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

• The data is stored securely.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

Indicate whether the assessed entity is an issuer or supports issuing service. (yes/no) <Report Findings Here> If “yes,” complete the responses for 3.2.a and 3.2.b and mark 3.2.c and 3.2.d as “Not Applicable.” If …
Modified p. 56 → 86
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all system configurations examined for this testing procedure.
Modified p. 56 → 102
Examine files and system records to verify that the data stored does not exceed the requirements defined in the data-retention policy.
<Enter Response Here> 3.2.1.b Examine files and system records on system components where account data is stored to verify that the data storage amount and retention time does not exceed the requirements defined in the data retention policy.
Modified p. 56 → 109
It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

• There is a business justification, and
PCI DSS Requirement 3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is:
Modified p. 56 → 110
3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.3.a Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine documented policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.
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 Identify the interviewed personnel who confirm there is a documented business justification for the storage of sensitive authentication data.

<Report Findings Here> For the interview, summarize the relevant details of the business justification described.

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.

<Report Findings Here> 3.2.c For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization.

Indicate whether sensitive authentication data is received. (yes/no) <Report Findings Here> If “yes,” complete 3.2.c and 3.2.d.

If “no,” mark the remainder of 3.2.c and 3.2.d as “Not Applicable” and proceed to 3.2.1.

Identify the document(s) …
Modified p. 57 → 110
<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.
<Enter Response Here> 3.3.3.b Additional testing procedure for issuers and companies that support issuing services and store sensitive authentication data: Examine data stores and system configurations to verify that the sensitive authentication data is stored securely.
Removed p. 58
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 data elements from the magnetic stripe may need to be retained:

• The cardholder’s name

• Primary account number (PAN)

• Service code To minimize risk, store only these data elements as needed for business.
Removed p. 58
• Database contents Identify the sample of system components selected for 3.2.1-3.2.3.

<Report Findings Here> For each data source type below from the sample of system of components examined, summarize the specific examples of each data source type observed to verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization. If that type of data source is not present, indicate that in the space.
Removed p. 58
• 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 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 (CAV2, CVC2, CVN2, CVV2, and CID data) is not stored after authorization. If that type of data source is not present, indicate that in the space.

PCI DSS Requirements …
Modified p. 59 → 111
• 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.
PCI DSS Requirement 3.4.1 PAN is masked when displayed (the BIN 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 the BIN and last four digits of the PAN.
Removed p. 60
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.3.a Examine written policies and procedures for masking the display of PANs to verify:

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

Identify the document(s) reviewed to verify that written policies and procedures for masking the displays of PANs include the following:

• 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 → 112
• 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 is masked when displayed such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
Modified p. 60 → 112
<Report Findings Here> 3.3.b Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests.
<Enter Response Here> 3.4.1.b Examine system configurations to verify that full PAN is only displayed for roles with a documented business need, and that PAN is masked for all other requests.
Removed p. 61
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.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

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

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

• 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 …
Modified p. 61 → 115
• One-way hashes based on strong cryptography, (hash must be of the entire PAN).
• One-way hashes based on strong cryptography of the entire PAN.
Modified p. 61 → 116
Identify the sample of data repositories selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all data repositories examined for this testing procedure.
Removed p. 62
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 confirm that the PAN is rendered unreadable.

For each item in the sample, describe how the sample of removable media confirmed that the PAN is rendered unreadable.

<Report Findings Here> For each item in the sample, describe how the sample of audit logs, including payment application logs, confirmed that the PAN is rendered unreadable or is not present in the logs.

Identify whether hashed and truncated versions of the same PAN are present in the environment (yes/no) If ‘no,’ mark 3.4.e as ‘not applicable’ and proceed to 3.4.1.

<Report Findings Here> If ‘yes,’ describe the implemented controls examined to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

<Report Findings Here> 3.4.1 If disk encryption is used (rather than file- or column-level database …
Modified p. 62 → 116
<Report Findings Here> 3.4.e If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
<Enter Response Here> 3.5.1.c If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Modified p. 62 → 118
<Report Findings Here> 3.4.d Examine a sample of audit logs, including payment application logs, to confirm that PAN is rendered unreadable or is not present in the logs.
<Enter Response Here> 3.5.1.1.d Examine audit logs, including payment application logs, to verify the PAN is rendered unreadable.
Modified p. 62 → 121
Identify the sample of audit logs, including payment application logs, selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all files containing authentication factors examined for this testing procedure.
Removed p. 63
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 For each disk encryption mechanism in use, describe how the authentication process was observed to verify that logical access to encrypted file systems is separate from the native operating system’s authentication mechanism.

<Report Findings Here> 3.4.1.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

Describe how processes were observed to verify that cryptographic keys are stored securely.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that cryptographic keys are stored securely.

<Report Findings Here> 3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored.

Note: If disk encryption is not used to encrypt removable media, the data stored on …
Modified p. 63 → 122
<Report Findings Here> 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:
PCI DSS Requirement 3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:
Removed p. 64
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 Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

Identify the documented key-management policies and processes examined to verify processes are defined to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

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

<Report Findings Here> 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:
Removed p. 64
• 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:

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

• Inventory of any HSMs and other SCDs used for key management <Report Findings Here>
Modified p. 64 → 129
• Keys are stored securely in the fewest possible locations and forms.
PCI DSS Requirement 3.6.1.4 Cryptographic keys are stored in the fewest possible locations.
Removed p. 65
• Inventory of any HSMs and other SCDs used for key management Identify the documentation reviewed to verify that it contains a description of the cryptographic architecture, including:

• Inventory of any HSMs and other SCDs used for key management <Report Findings Here> 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary. ☐ ☐ ☐ ☐ ☐ 3.5.2 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.

Identify user access lists examined. <Report Findings Here> Describe how the user access lists verified that access to keys is restricted to the fewest number of custodians necessary.

<Report Findings Here> 3.5.3 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored …
Removed p. 67
Describe how the procedures for generating keys were observed to verify that strong keys are generated.

<Report Findings Here> 3.6.2 Secure cryptographic key distribution. ☐ ☐ ☐ ☐ ☐
Modified p. 67 → 131
Identify the documented key-management procedures examined to verify procedures specify how to generate strong keys.
Identify the evidence reference number(s) from Section 6 for all documented key- management policies and procedures examined for this testing procedure.
Modified p. 67 → 131
<Report Findings Here> 3.6.1.b Observe the procedures for generating keys to verify that strong keys are generated.
<Enter Response Here> 3.7.1.b Observe the method for generating keys to verify that strong keys are generated.
Modified p. 67 → 144
3.6.a Additional Procedure for service provider assessments only: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.9 Additional testing procedure for service provider assessments only: If the service provider shares cryptographic keys with its customers for transmission or storage of account data, examine the documentation that the service provider provides to its customers to verify it includes guidance on how to securely transmit, store, and update customers’ keys in accordance with all elements specified in Requirements 3.7.1 through 3.7.8 above.
Removed 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.2.a Verify that key-management procedures specify how to securely distribute keys.

Identify the documented key-management procedures examined to verify procedures specify how to securely distribute keys.

<Report Findings Here> 3.6.3 Secure cryptographic key storage. ☐ ☐ ☐ ☐ ☐ 3.6.3.a Verify that key-management procedures specify how to securely store keys.

<Report Findings Here> 3.6.3.b Observe the method for storing keys to verify that keys are stored securely.

Describe how the method for storing keys was observed to verify that keys are stored securely.

<Report Findings Here> 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application …
Modified p. 68 → 133
<Report Findings Here> 3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.
<Enter Response Here> 3.7.2.b Observe the method for distributing keys to verify that keys are distributed securely.
Modified p. 68 → 134
Describe how the method for distributing keys was observed to verify that keys are distributed securely.
<Enter Response Here> 3.7.3.b Observe the method for storing keys to verify that keys are stored securely.
Modified p. 68 → 134
Identify the documented key-management procedures examined to verify procedures specify how to securely store keys.
Identify the evidence reference number(s) from Section 6 for the documented key- management policies and procedures examined for this testing procedure.
Modified p. 68 → 135
Identify the responsible personnel interviewed who confirm that keys are changed at the end of the defined cryptoperiod(s).
• A process for key changes at the end of the defined cryptoperiod.
Modified p. 68 → 136
<Report Findings Here> 3.6.4.b Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s).
<Enter Response Here> 3.7.4.b Interview personnel, examine documentation, and observe key storage locations to verify that keys are changed at the end of the defined cryptoperiod(s).
Removed p. 69
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:

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

• The replacement of known or suspected compromised keys.

Identify the documented key-management procedures examined to verify that key-management processes specify the following:

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

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

• Keys …
Modified p. 69 → 137
Any keys retained after retiring or replacing are not used for encryption operations.
Retired or replaced keys are not used for encryption operations.
Modified p. 69 → 137
• The replacement of known or suspected compromised keys.
• The key is suspected of or known to be compromised.
Modified p. 69 → 138
<Report Findings Here> 3.6.5.b Interview personnel to verify the following processes are implemented:
<Enter Response Here> 3.7.5.b Interview personnel to verify that processes are implemented in accordance with all elements specified in this requirement.
Removed 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 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.

Identify the documented key-management procedures examined to verify that manual clear-text key-management procedures define processes for the use of the following:

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

• …
Modified p. 70 → 136
Identify the responsible personnel interviewed for this testing procedure, if applicable.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Modified p. 70 → 139
<Report Findings Here> 3.6.6.b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:
<Enter Response Here> 3.7.6.b Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control.
Modified p. 70 → 140
Identify the documented key-management procedures examined to verify that key-management procedures specify processes to prevent unauthorized substitution of keys.
PCI DSS Requirement 3.7.7 Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.
Modified p. 70 → 141
<Report Findings Here> 3.6.7.b Interview personnel and/or observe process to verify that unauthorized substitution of keys is prevented.
<Enter Response Here> 3.7.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.
Removed 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.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.

Identify the documented key-management procedures examined to verify that key-management procedures specify processes for key custodians to acknowledge that they understand and accept their key-custodian responsibilities.

Describe how key custodian acknowledgements or other evidence were observed to verify that key custodians have acknowledged that they understand and accept their key-custodian responsibilities.

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

• Known to …
Modified p. 71 → 143
<Report Findings Here> 3.6.8.b Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their key-custodian responsibilities.
<Enter Response Here> 3.7.8.b Examine documentation or other evidence showing that key custodians have provided acknowledgments in accordance with all elements specified in this requirement.
Modified p. 71 → 145
• Known to all affected parties <Report Findings Here>
• Known to all affected parties.
Removed p. 72
Requirement 4: Encrypt transmission of cardholder data across open, public networks

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

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

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

• The Internet

• Wireless technologies, including 802.11 and Bluetooth

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

• General Packet Radio Service (GPRS)

• Satellite communications 4.1.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.

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

<Report …
Modified p. 73 → 149
<Report Findings Here> 4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.
<Enter Response Here> 4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected.
Modified p. 73 → 149
<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.
<Enter Response Here> 4.2.1.b Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement.
Removed p. 74
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 all wireless networks identified:

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

Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment.

<Report Findings Here> Identify the documented standards examined. <Report Findings Here> Describe how the documented standards and system configuration settings both verified the following …
Modified p. 74 → 151
• Industry best practices are used to implement strong encryption for authentication and transmission.
PCI DSS Requirement 4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.
Modified p. 74 → 152
Describe how processes for sending PAN were observed to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.
PCI DSS Requirement 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.
Modified p. 74 → 153
<Report Findings Here> Describe how the sample of outbound transmissions verified that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end- user messaging technologies.
<Enter Response Here> 4.2.2.b Examine system configurations and vendor documentation to verify that PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.
Removed p. 75
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.

Identify the policy document that prohibits PAN from being sent via end-user messaging technologies under any circumstances.

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

Identify the document reviewed to verify that security policies and operational procedures for encrypting transmissions of cardholder data are documented.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for …
Modified p. 76 → 159
Detect all known types of malicious software,
Detects all known types of malware.
Modified p. 76 → 159
Protect against all known types of malicious software.
Removes, blocks, or contains all known types of malware.
Modified p. 76 → 160
Remove all known types of malicious software, and
Detects all known types of malware.
Modified p. 76 → 160
Detect all known types of malicious software,
Removes, blocks, or contains all known types of malware.
Removed p. 77
Identify the sample of system components (including all operating system types commonly affected by malicious software) selected for this testing procedure.

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 evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software.

For the interview, summarize the relevant details discussed to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, and that such systems continue to not require anti-virus software.

<Report Findings Here> 5.2 Ensure that all anti-virus mechanisms are maintained as follows:

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

5.2.a Examine policies and procedures to verify that anti-virus software and definitions are required to be …
Modified p. 77 → 167
Perform periodic scans.
Performs periodic scans and active or real-time scans. OR
Removed p. 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 Place software and a sample of system components, to verify that:

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

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

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

<Report Findings Here> 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be …
Modified p. 78 → 159
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all system components examined for this testing procedure.
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 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:

Identify the document reviewed to verify that security policies and operational procedures for protecting systems against malware are documented.

<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

Requirement 6: Develop and maintain secure systems and applications

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.1 …
Modified p. 82 → 180
Incorporate information security throughout the software development life cycle.
Incorporating consideration of information security issues during each stage of the software development lifecycle.
Removed p. 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 Place 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.

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

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle.

Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

6.3.2.a Examine written …
Removed p. 83
Identify the documented software-development processes examined to verify processes define that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

• 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. 83 → 184
<Report Findings Here> 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
PCI DSS Requirement 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
Modified p. 83 → 185
Code review results are reviewed and approved by management prior to release.
Reviewed and approved by management prior to release.
Modified p. 83 → 185
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).
Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.
Removed p. 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 Place

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

Identify the responsible personnel interviewed for this testing procedure who confirm that all custom application code changes are reviewed as follows:

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

<Report Findings Here> 6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.

<Report Findings Here> For each item in the sample, describe how code review processes were observed to verify custom application code is reviewed as follows:

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

• Code changes are reviewed by individuals who are …
Modified p. 84 → 200
Identify the sample of recent custom application changes selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Removed p. 85
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.4 Follow change control processes and procedures for all changes to system components. The processes must include the following: ☐ ☐ ☐ ☐ ☐ 6.4 Examine policies and procedures to verify the following are defined:

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

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

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

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

• Test data …
Modified p. 85 → 189
Identify the documented policies and procedures examined to verify that the following are defined:
Identify the evidence reference number(s) from Section 6 for all policies and procedures examined for this testing procedure.
Removed p. 86
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 enforce separation between the development/test environments and the production environment(s).

Describe how the access control settings verified that access controls are in place to enforce separation between the development/test environments and the production environment(s).

<Report Findings Here> 6.4.2 Separation of duties between development/test and production environments. ☐ ☐ ☐ ☐ ☐ 6.4.2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.

Identify the personnel assigned to development/test environments interviewed who confirm that separation of duties is in place between development/test environments and the production environment.

<Report Findings Here> Identify the personnel assigned to production environments interviewed who confirm that separation of duties is in place …
Modified p. 87 → 201
• Documentation of impact.
• Documentation of security impact.
Modified p. 87 → 201
Functionality testing to verify that the change does not adversely impact the security of the system.

• Back-out procedures.
Testing to verify that the change does not adversely impact system security.
Modified p. 87 → 202
Identify the documented change-control procedures examined to verify procedures are defined for:

• Documentation of impact.
Identify the evidence reference number(s) from Section 6 for all documented change control procedures examined for this testing procedure.
Removed p. 88
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.4.5.b For a sample of system components, interview responsible personnel to determine recent changes. Trace those changes back to related change control documentation. For each change examined, perform the following:

<Report Findings Here> Identify the responsible personnel interviewed to determine recent changes.

<Report Findings Here> 6.4.5.1 Documentation of impact. ☐ ☐ ☐ ☐ ☐ 6.4.5.1 Verify that documentation of impact is included in the change control documentation for each sampled change.

For each change from 6.4.5.b, describe how the documentation of impact is included in the change control documentation for each sampled change.

<Report Findings Here> 6.4.5.2 Documented change approval by authorized parties. ☐ ☐ ☐ ☐ ☐ 6.4.5.2 Verify that documented approval by authorized parties is present for each sampled change.

For each change from 6.4.5.b, describe how documented …
Modified p. 88 → 201
<Report Findings Here> 6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.
For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
Modified p. 88 → 202
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all recent changes to system components examined for this testing procedure.
Modified p. 88 → 202
<Report Findings Here> For each item in the sample, identify the sample of changes and the related change control documentation selected for this testing procedure (through 6.4.5.4).
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all change control documentation examined for this testing procedure.
Modified p. 88 → 206
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all access control settings examined for this testing procedure.
Removed p. 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.4.5.4 Back-out procedures. ☐ ☐ ☐ ☐ ☐ 6.4.5.4 Verify that back-out procedures are prepared for each sampled change.

For each change from 6.4.5.b, describe how the change control documentation verified that back-out procedures are prepared.

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

Identify whether a significant change occurred within the past 12 months. (yes/no) If “yes,” complete the following:

If “no,” mark the rest of …
Modified p. 89 → 211
<Report Findings Here> Identify the sample of change records examined for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all accounts examined for this testing procedure.
Removed p. 90
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.

Identify the document reviewed to verify that up-to- date training in secure coding techniques is required for developers at least annually.

<Report Findings Here> Identify the industry best practices and guidance on which the training is based.

<Report Findings Here> 6.5.b Examine records of training to verify that software developers receive up-to- date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities Identify the records of training that were examined to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding …
Removed p. 90
• Validating input to verify user data cannot modify meaning of commands and queries.

• Utilizing parameterized queries.

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

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

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

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:

• Validating buffer boundaries.

• Truncating input strings.

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

• Validating buffer boundaries. <Report Findings Here>

• Truncating input strings. <Report Findings Here> …
Removed p. 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.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.

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.

Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external):

Indicate whether web applications and application interfaces are present. (yes/no) If “no,” mark the below 6.5.7-6.5.10 as “Not Applicable.” If “yes,” complete the following:

<Report Findings Here> 6.5.7 Cross-site scripting (XSS). ☐ ☐ ☐ ☐ ☐ 6.5.7 Examine software-development policies and procedures and interview responsible personnel to verify that …
Removed p. 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 vulnerability security For each public-facing web application, identify which of the two methods are implemented:

• Web application vulnerability security assessments, AND/OR

• Automated technical solution that detects and prevents web-based attacks, such as web application firewalls.

<Report Findings Here> If application vulnerability security assessments are indicated above:

Describe the tools and/or methods used (manual or automated, or a combination of both).

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.

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

- …
Removed p. 96
• By an organization that specializes in application security.

• That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment.

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.

Identify the responsible personnel interviewed who confirm that public-facing web applications are reviewed, as follows:

• At least annually.

• That all vulnerabilities are corrected.

<Report Findings Here> Describe how the records of application vulnerability security assessments verified that public-facing web applications are reviewed as follows:

• At least annually. <Report Findings Here>

• After any changes. <Report Findings Here>

• By an organization that specialized in application security.

• That at a minimum, all vulnerabilities in requirement 6.5 are included …
Modified p. 96 → 206
<Report Findings Here> Identify the records of application vulnerability security assessments examined for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all configurations examined for this testing procedure.
Removed p. 97
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 who confirm that the above automated technical solution is in place as follows:

• Is situated in front of public-facing web applications to detect and prevent web-based attacks.

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

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

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

<Report Findings Here> Describe how the system configuration settings verified that the above automated technical solution is in place as follows:

• Is situated in front of public-facing web applications to detect and prevent web- based attacks.

• Is generating audit logs. <Report Findings Here>

<Report Findings Here> 6.7 …
Removed p. 98
• 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.

Identify the selected sample of roles for this testing procedure.

<Report Findings Here> For each role in the selected sample, describe how the role was examined to verify access needs are defined and include:
Modified p. 98 → 216
Assignment of access based on individual personnel’s job classification and function.
Access to system components and data resources that is based on users' job classification and functions.
Modified p. 98 → 216
Level of privilege required (for example, user, administrator, etc.) for accessing resources.
The least privileges required (for example, user, administrator) to perform a job function.
Modified p. 98 → 217
Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities.
Least privileges necessary to perform job responsibilities.
Removed p. 99
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested

• Identification of privilege necessary for each role to perform their job function.

<Report Findings Here> 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. ☐ ☐ ☐ ☐ ☐ 7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is:

• Assigned only to roles that specifically require such privileged access.

• Restricted to least privileges necessary to perform job responsibilities.

Identify the responsible personnel interviewed who confirm that access to privileged user IDs is:

• Assigned only to roles that specifically require such privileged access.
Removed p. 99
<Report Findings Here> 7.1.2.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are:

• Necessary for that individual’s job function.

• Restricted to least privileges necessary to perform job responsibilities.

<Report Findings Here> Identify the responsible management personnel interviewed to confirm that privileges assigned are:

• Necessary for that individual’s job function.

<Report Findings Here> For the interview, summarize the relevant details discussed to confirm that privileges assigned to each sample user ID are:

• Necessary for that individual’s job function. <Report Findings Here>

<Report Findings Here> 7.1.3 Assign access based on individual personnel’s job classification and function. ☐ ☐ ☐ ☐ ☐ 7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.

<Report Findings Here> Identify the responsible management personnel interviewed who confirm that privileges assigned are based on that …
Modified p. 99 → 217
Identify the sample of user IDs with privileged access selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all access control model settings examined for this testing procedure.
Modified p. 99 → 218
Identify the sample of user IDs selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all user access settings examined for this testing procedure.
Removed p. 100
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested For the interview, summarize the relevant details discussed to confirm that privileges assigned to each sample user ID are based on that individual’s job classification and function.

<Report Findings Here> For each user ID in the selected sample, describe how:

• Documented approval exists for the assigned privileges.

• The approval was by authorized parties. <Report Findings Here>

• That specified privileges match the roles assigned to the individual.

This access control system(s) must include the following:
Removed p. 100
Identify vendor documentation examined. <Report Findings Here> Describe how system settings and the vendor documentation verified that access control systems are in place on all system components.

<Report Findings Here> 7.2.2 Assignment of privileges to individuals based on job classification and function. ☐ ☐ ☐ ☐ ☐ 7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.

<Report Findings Here> 7.2.3 Default “deny-all” setting. ☐ ☐ ☐ ☐ ☐
Modified p. 100 → 220
<Report Findings Here> 7.1.4 Require documented approval by authorized parties specifying required privileges. ☐ ☐ ☐ ☐ ☐ 7.1.4 Select a sample of user IDs and compare with documented approvals to verify that:
<Enter Response Here> 7.2.3.b Examine user IDs and assigned privileges, and compare with documented approvals to verify that:
Modified p. 100 → 220
• The approval was by authorized parties.
• The approval was by authorized personnel.
Modified p. 100 → 220
That specified privileges match the roles assigned to the individual.
Specified privileges match the roles assigned to the individual.
Modified p. 100 → 220
Identify the sample of user IDs selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all user IDs and assigned privileges examined for this testing procedure.
Modified p. 100 → 228
<Report Findings Here> 7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
PCI DSS Requirement 7.3.1 An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
Modified p. 100 → 229
Describe how system settings and the vendor documentation at 7.2.1 verified that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.
PCI DSS Requirement 7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function.
Removed p. 101
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 7.2.3 Confirm that the access control systems have a default “deny-all” setting.

Describe how system settings and the vendor documentation at 7.2.1 verified that access control systems have a default “deny-all” setting.

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

Identify the document reviewed to verify that security policies and operational procedures for restricting access to cardholder data are documented.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the above documented security policies and operational procedures for restricting access to cardholder data are:

Requirement 8: Identify and …
Modified p. 102 → 235
• Assign all users a unique ID before allowing them to access system components or cardholder data.
PCI DSS Requirement 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.
Modified p. 102 → 240
• Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
PCI DSS Requirement 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
Modified p. 102 → 243
• Immediately revoke access for any terminated users.
•have been returned or deactivated for terminated users.
Modified p. 102 → 245
• Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
PCI DSS Requirement 8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
Removed p. 103
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.1.1 Interview administrative personnel to confirm that all users are assigned a unique ID for access to system components or cardholder data.

Identify the responsible administrative personnel interviewed who confirm that all users are assigned a unique ID for access to system components or cardholder data.

<Report Findings Here> 8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects. ☐ ☐ ☐ ☐ ☐ 8.1.2 For a sample of privileged user IDs and general user IDs, examine associated authorizations and observe system settings to verify each user ID and privileged user ID has been implemented with only the privileges specified on the documented approval.

<Report Findings Here> Describe how observed system settings and the associated authorizations verified that each ID has been implemented with …
Modified p. 103 → 238
Identify the sample of privileged user IDs selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all user account lists examined for this testing procedure.
Modified p. 103 → 241
<Report Findings Here> Identify the sample of general user IDs selected for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all system settings examined for this testing procedure.
Modified p. 103 → 243
<Report Findings Here> 8.1.3.b Verify all physical authentication methods

•such as, smart cards, tokens, etc.
<Enter Response Here> 8.2.5.b Interview responsible personnel to verify that all physical authentication factors

•such as, smart cards, tokens, etc.
Removed p. 104
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.1.4 Remove/disable inactive user accounts within 90 days. ☐ ☐ ☐ ☐ ☐ 8.1.4 Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.

Describe how user accounts were observed to verify that any inactive accounts over 90 days old are either removed or disabled.

<Report Findings Here> 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows:

• Monitored when in use.

8.1.5.a Interview personnel and observe processes for managing accounts used by third parties to access, support, or maintain system components to verify that accounts used for remote access are:

• Disabled when not in use.

• Disabled when not in use.
Removed p. 104
Identify the responsible personnel interviewed who confirm that accounts used by third parties for remote access are:

<Report Findings Here> Describe how processes for managing third party accounts were observed to verify that accounts used for remote access are:

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

<Report Findings Here> 8.1.5.b Interview personnel and observe processes to verify that third party remote access accounts are monitored while being used.

Identify the responsible personnel interviewed who confirm that accounts used by third parties for remote access are monitored while being used.

<Report Findings Here> Describe how processes for managing third party remote access were observed to verify that accounts are monitored while being used.

<Report Findings Here> 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. ☐ ☐ ☐ ☐ ☐ 8.1.6.a For a sample of system components, inspect system configuration settings to verify that authentication parameters are …
Removed p. 105
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.1.6.b Additional procedure for service provider assessments only: Review internal processes and customer/user documentation, and observe implemented processes to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

Additional procedure for service provider assessments only, identify the documented internal processes and customer/user documentation reviewed to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

<Report Findings Here> Describe how implemented processes were observed to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

<Report Findings Here> 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. ☐ ☐ ☐ ☐ ☐ 8.1.7 For a sample …
Modified p. 105 → 246
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Modified p. 105 → 248
• Something you are, such as a biometric.
• Something you are, such as a biometric element.
Removed p. 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 To verify that users are authenticated using unique ID and additional authentication (for example, a password/phrase) for access to the cardholder data environment, perform the following:

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

Identify the document describing the authentication method(s) used that was reviewed to verify that the methods require users to be authenticated using a unique ID and additional authentication for access to the cardholder data environment.

<Report Findings Here> Describe the authentication methods used (for example, a password or passphrase, a token device or smart card, a biometric, etc.) for each type of system component.

<Report Findings Here> For each type of authentication method used …
Modified p. 106 → 251
<Report Findings Here> Identify the sample of system components selected for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all system configuration settings examined for this testing procedure.
Modified p. 106 → 251
<Report Findings Here> 8.2.1.b For a sample of system components, examine password files to verify that passwords are unreadable during storage.
<Enter Response Here> 8.3.2.b Examine repositories of authentication factors to verify that they are unreadable during storage.
Modified p. 106 → 259
Examine documentation describing the authentication method(s) used.
Guidance on selecting strong authentication factors.
Removed 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.1.d Additional procedure for service provider assessments only: Observe password files to verify that non-consumer customer passwords are unreadable during storage.

Additional procedure for service provider assessments only: for each item in the sample at 8.2.1.a, describe how password files verified that non-consumer customer passwords are unreadable during storage.

<Report Findings Here> 8.2.1.e Additional procedure for service provider assessments only: Observe data transmissions to verify that non- consumer customer passwords are unreadable during transmission.

Additional procedure for service provider assessments only: for each item in the sample at 8.2.1.a, describe how password files verified that non-consumer customer passwords are unreadable during transmission.

<Report Findings Here> 8.2.2 Verify user identity …
Removed p. 107
Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.
Modified p. 107 → 251
For each item in the sample at 8.2.1.a, describe how data transmissions verified that passwords are unreadable during transmission.
<Enter Response Here> 8.3.2.c Examine data transmissions to verify that authentication factors are unreadable during transmission.
Removed p. 108
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:

<Report Findings Here> For each item in the sample, describe how system configuration settings verified that user password/passphrase parameters are set to require 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:

Additional procedure for service provider assessments only: Identify the documented internal processes and customer/user documentation reviewed to verify that non-consumer customer passwords/passphrases are required to meet at least the following strength/complexity:

• A minimum length …
Modified p. 108 → 274
Identify the sample of system components selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all system configurations examined for this testing procedure.
Removed p. 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 Place settings to verify that user password/passphrase parameters are set to require users to change passwords/passphrases at least once every 90 days.

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> 8.2.4.b Additional procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that:

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

Additional procedure for service provider assessments only, identify the documented internal processes and customer/user documentation reviewed to verify that:

• Non-consumer customer users are given guidance as to when, and under …
Modified p. 109 → 262
Non-consumer customer user passwords/passphrases are required to change periodically; and
Guidance for customers to change their user passwords/passphrases periodically.
Removed p. 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 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.

Additional procedure for service provider assessments only, identify the documented internal processes and customer/user documentation reviewed to verify that new non-consumer customer user passwords/passphrases cannot be the same as the previous four passwords/passphrases.

<Report Findings Here> Describe how internal processes were observed to verify that new non-consumer customer user passwords/passphrases cannot be the same as the previous four passwords/passphrases.

<Report Findings Here> 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use. ☐ ☐ ☐ ☐ ☐ 8.2.6 Examine password procedures and observe security …
Modified p. 110 → 253
Identify the documented password procedures examined to verify the procedures define that:
Identify the evidence reference number(s) from Section 6 for all procedures examined for this testing procedure.
Modified p. 110 → 254
First-time passwords/passphrases must be changed after the first use.
Forced to be changed immediately after the first use.
Modified p. 110 → 254
• Set reset passwords/passphrases to a unique value for each existing user.
• Set to a unique value for first-time use and upon reset.
Modified p. 110 → 261
Reset passwords/passphrases must be changed after the first use.
Passwords/passphrases are changed at least once every 90 days, OR
Modified p. 110 → 264
Set first-time passwords/passphrases to be changed after first use.
Passwords/passphrases are changed at least once every 90 days, OR
Removed p. 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 8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.
Removed p. 111
<Report Findings Here> Describe how the configurations verify that multi-factor authentication is required for all non-console access into 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.

<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 verify multi-factor authentication is required for:

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

Describe how system configurations for remote access servers and systems verified that multi-factor authentication is required for:

• All remote access by personnel, both user and administrator, and <Report Findings Here>

<Report Findings Here> For …
Modified p. 111 → 269
Identify the sample of network and/or system components examined for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all network and/or system configurations examined for this testing procedure.
Modified p. 111 → 269
<Report Findings Here> 8.3.1.b Observe a sample of administrator personnel login to the CDE and verify that at least two of the three authentication methods are used.
<Enter Response Here> 8.4.1.b Observe administrator personnel logging into the CDE and verify that MFA is required.
Modified p. 111 → 269
Identify the sample of administrator personnel observed logging in to the CDE.
Identify the evidence reference number(s) from Section 6 for all observation(s) of administrator personnel logging into the CDE for this testing procedure.
Modified p. 111 → 271
• All remote access by personnel, both user and administrator, and
• All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
Modified p. 111 → 272
<Report Findings Here> 8.3.2.b Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.
<Enter Response Here> 8.4.3.b Observe personnel (for example, users and administrators) connecting remotely to the network and verify that multi-factor authentication is required.
Modified p. 111 → 272
Identify the sample of personnel observed connecting remotely to the network.
Identify the evidence reference number(s) from Section 6 for all observation(s) of personnel connecting remotely to the network for this testing procedure.
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.4 Document and communicate authentication policies and procedures to all users including:
Removed p. 112
Identify the documented policies and procedures examined to verify authentication procedures define that authentication procedures and policies are distributed to all users.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that authentication policies and procedures are distributed to all users.

• Guidance on selecting strong authentication credentials.

• Guidance on selecting strong authentication credentials.

• Instructions for users not to reuse previously used passwords.

• Instructions for users not to reuse previously used passwords.

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

<Report Findings Here> For each user in the sample, summarize the relevant details discussed that verify that they are familiar with authentication policies and procedures.
Modified p. 112 → 259
• Guidance on selecting strong authentication credentials.
• Guidance for how users should protect their authentication factors.
Modified p. 112 → 259
• Instructions not to reuse previously used passwords.
• Instructions not to reuse previously used passwords/passphrases.
Modified p. 112 → 259
• Instructions to change passwords if there is any suspicion the password could be compromised.
• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
Modified p. 112 → 259
Identify the documented authentication policies and procedures that are distributed to users reviewed to verify they include:
PCI DSS Requirement 8.3.8 Authentication policies and procedures are documented and communicated to all users including:
Modified p. 112 → 260
8.4.a Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.8.a Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.
Modified p. 112 → 260
<Report Findings Here> 8.4.b Review authentication policies and procedures that are distributed to users and verify they include:
<Enter Response Here> 8.3.8.b Review authentication policies and procedures that are distributed to users and verify they include the elements specified in this requirement.
Modified p. 112 → 260
<Report Findings Here> 8.4.c Interview a sample of users to verify that they are familiar with authentication policies and procedures.
<Enter Response Here> 8.3.8.c Interview users to verify that they are familiar with authentication policies and procedures.
Modified p. 112 → 260
Identify the sample of users interviewed for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Removed p. 113
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:

• Generic user IDs are disabled or removed.

• Generic user IDs are disabled or removed.

• Shared user IDs do not exist for system administration and other critical functions.
Removed p. 113
8.5.a For a sample of system components, examine user ID lists to verify the following:

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

<Report Findings Here> For each item in the sample, describe how the user ID lists verified that:

• Generic user IDs are disabled or removed. <Report Findings Here>

<Report Findings Here> 8.5.b Examine authentication policies and procedures to verify that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited.

Identify the documented policies and procedures examined to verify authentication policies/procedures define that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited.

<Report Findings Here> 8.5.c Interview system administrators to verify that group and shared IDs and/or passwords or other authentication methods are not distributed, even if requested.

Identify the system administrators …
Removed p. 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 Place and interview personnel to verify that different authentication credentials are used for access to each customer.

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:

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

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

<Report Findings Here> 8.6.b Interview security personnel to verify authentication …
Modified p. 114 → 260
Identify the documented authentication policies and procedures examined to verify the procedures for using authentication mechanisms define that:
Identify the evidence reference number(s) from Section 6 for all authentication policies and procedures examined for this testing procedure.
Modified p. 114 → 266
Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
Factors are assigned to an individual user and not shared among multiple users.
Modified p. 114 → 266
• 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 ensure only the intended user can use that factor to gain access.
Modified p. 114 → 267
• Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.
<Enter Response Here> 8.3.11.b Interview security personnel to verify authentication factors are assigned to an individual user and not shared among multiple users.
Modified p. 114 → 267
<Report Findings Here> 8.6.c Examine system configuration settings and/or physical controls, as applicable, to verify that controls are implemented to ensure only the intended account can use that mechanism to gain access.
<Enter Response Here> 8.3.11.c Examine system configuration settings and/or observe physical controls, as applicable, to verify that controls are implemented to ensure only the intended user can use that factor to gain access.
Removed p. 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 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

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

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

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

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

Identify all databases containing cardholder data. <Report Findings Here> Describe how database and/or application configuration settings verified that all users are authenticated prior to access.

<Report Findings Here> 8.7.b Examine database and application configuration settings to verify that all …
Modified p. 117 → 285
Describe how either the video cameras or access control mechanisms (or both) were observed to be protected from tampering and/or disabling.
• Monitoring devices or mechanisms are protected from tampering or disabling.
Modified p. 117 → 286
<Report Findings Here> 9.1.1.b Verify that either video cameras or access control mechanisms (or both) are protected from tampering or disabling.
<Enter Response Here> 9.2.1.1.b Observe locations where individual physical access to sensitive areas within the CDE occurs to verify that either video cameras or physical access control mechanisms (or both) are protected from tampering or disabling.
Modified p. 117 → 291
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.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.2.4 Observe a system administrator’s attempt to log into consoles in sensitive areas and verify that they are “locked” to prevent unauthorized use.
Removed p. 118
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.1.1.c Verify that data from video cameras and/or access control mechanisms is reviewed, and that data is stored for at least three months.

For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.

Identify the responsible personnel interviewed who confirm that physical and/or logical controls are 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.

<Report Findings Here> 9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines. ☐ …
Modified p. 118 → 287
Describe how the data from video cameras and/or access control mechanisms were observed to be reviewed.
• Collected data from video cameras and/or physical access control mechanisms is reviewed and correlated with other entries.
Modified p. 118 → 287
<Report Findings Here> Describe how data was observed to be stored for at least three months.
• Collected data is stored for at least three months.
Modified p. 118 → 287
<Report Findings Here> 9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks.
PCI DSS Requirement 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
Modified p. 118 → 291
Changes to access requirements.
Managing changes to an individual's physical access requirements.
Modified p. 118 → 291
• Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
• Revoking or terminating personnel identification.
Removed p. 119
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.2.a Review documented processes to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors.

Verify procedures include the following:

• Identifying onsite personnel and visitors (for example, assigning badges),

• Identifying onsite personnel and visitors (for example, assigning badges),

• Changing access requirements, and

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

Identify the documented processes reviewed to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors, including the following:

<Report Findings Here> 9.2.b Examine identification methods (such as ID badges) and observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:

• Visitors are clearly identified, and

• It is easy to distinguish …
Modified p. 119 → 291
Describe how access to the identification process was observed to be limited to authorized personnel.
• Limiting access to the identification process or system to authorized personnel.
Modified p. 119 → 293
<Report Findings Here> 9.2.c Verify that access to the identification process (such as a badge system) is limited to authorized personnel.
<Enter Response Here> 9.3.1.c Observe processes to verify that access to the identification process, such as a badge system, is limited to authorized personnel.
Modified p. 119 → 294
• Access must be authorized and based on individual job function.
• Access is authorized and based on individual job function.
Modified p. 119 → 294
Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.
All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.
Removed p. 120
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested Place interview responsible personnel and observe access control lists to verify that:

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

Describe how personnel accessing sensitive areas were observed to verify that all personnel are authorized before being granted access.

<Report Findings Here> 9.3.c Select a sample of recently terminated employees and review access control lists to verify the personnel do not have physical access to sensitive areas.

Identify the sample of users recently terminated. <Report Findings Here> For all items in the sample, provide the name of the assessor who attests that the access control lists were reviewed to verify the personnel do not have physical access to sensitive areas.

<Report Findings Here> 9.4 …
Removed p. 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.

<Report Findings Here> Identify the responsible personnel interviewed who confirm 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.

PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.4.1.b Observe the use of visitor badges or other identification to verify that a physical token badge does not permit unescorted access to physical areas where cardholder data is processed or maintained.

<Report Findings Here> 9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel. ☐ ☐ ☐ ☐ ☐ 9.4.2.a Observe people within …
Modified p. 121 → 297
Describe how the use of visitor badges or other identification was observed to verify that a physical token badge does not permit unescorted access to physical areas where cardholder data is processed or maintained.
<Enter Response Here> 9.3.2.c Observe the use of visitor badges or other identification to verify that the badge or other identification does not permit unescorted access to the CDE.
Modified p. 121 → 297
Describe how visitor badges or other identification were verified to expire.
• Visitor badges or other identification are being used for all visitors.
Modified p. 121 → 300
<Report Findings Here> 9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted.
PCI DSS Requirement 9.3.4 A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas, including:
Modified p. 121 → 300
Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log.
• The name of the personnel authorizing physical access.
Modified p. 121 → 300
Retain this log for a minimum of three months, unless otherwise restricted by law.
• Retaining the log for at least three months, unless otherwise restricted by law.
Removed p. 122
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.4.4.b Verify that the log contains:

• The visitor’s name,

• The firm represented, and

• The firm represented, and

Provide the name of the assessor who attests that the visitor log contains:

• The visitor’s name,

• The onsite personnel authorizing physical access.

<Report Findings Here> 9.4.4.c Verify that the log is retained for at least three months.

Describe how visitor logs were observed to be retained for at least three months.

<Report Findings Here> 9.5 Physically secure all media. ☐ ☐ ☐ ☐ ☐ 9.5 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes).

Identify the documented procedures for protecting cardholder data reviewed to verify controls for physically securing all media are defined.

<Report Findings Here> 9.5.1 Store media …
Modified p. 122 → 301
• The onsite personnel authorizing physical access.
• The personnel authorizing physical access.
Modified p. 122 → 306
Describe how media was observed to be classified so the sensitivity of the data can be determined.
PCI DSS Requirement 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.
Modified p. 122 → 307
<Report Findings Here> 9.6.1 Classify media so the sensitivity of the data can be determined. ☐ ☐ ☐ ☐ ☐ 9.6.1 Verify that all media is classified so the sensitivity of the data can be determined.
<Enter Response Here> 9.4.2.b Examine media logs or other documentation to verify that all media is classified in accordance with the sensitivity of the data.
Modified p. 122 → 308
<Report Findings Here> 9.6.2 Send the media by secured courier or other delivery method that can be accurately tracked. ☐ ☐ ☐ ☐ ☐
• Media is sent by secured courier or other delivery method that can be accurately tracked.
Removed p. 123
Identify the responsible personnel interviewed who confirm that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.

<Report Findings Here> Describe how the offsite tracking records verified that all media is logged and sent via secured courier or other delivery method that can be tracked.

Identify the sample of recent offsite tracking logs for all media selected.

<Report Findings Here> For each item in the sample, describe how tracking details were observed to be documented.

<Report Findings Here> 9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals). ☐ ☐ ☐ ☐ ☐ 9.6.3 Select a recent sample of several days of offsite tracking logs for all media. From examination of the logs and interviews with responsible personnel, verify proper management authorization is obtained whenever media is moved from a …
Modified p. 123 → 309
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.6.2.a Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.
<Enter Response Here> 9.4.3.b Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.
Modified p. 123 → 309
<Report Findings Here> Identify the records examined for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all records examined for this testing procedure.
Modified p. 123 → 309
<Report Findings Here> 9.6.2.b Select a recent sample of several days of offsite tracking logs for all media, and verify tracking details are documented.
<Enter Response Here> 9.4.3.c Examine offsite tracking logs for all media to verify tracking details are documented.
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.7.1 Review media inventory logs to verify that logs are maintained and media inventories are performed at least annually.

Identify the media inventory logs reviewed. <Report Findings Here> Describe how the media inventory logs verified that:

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

• 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 …
Modified p. 124 → 311
• Media inventory logs of all media were observed to be maintained.
PCI DSS Requirement 9.4.5 Inventory logs of all electronic media with cardholder data are maintained.
Modified p. 124 → 314
Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.
Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.
Modified p. 124 → 315
• Storage containers used for materials that are to be destroyed must be secured.
<Enter Response Here> 9.4.6.c Observe storage containers used for materials that contain information to be destroyed to verify that the containers are secure.
Removed p. 125
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.8.1.a Interview personnel and examine procedures to verify that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

Identify the responsible personnel interviewed who confirm that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

<Report Findings Here> Provide the name of the assessor who attests that the procedures state that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance that hardcopy materials cannot be reconstructed.

Describe how the storage containers used for materials to be destroyed were verified to be secured.

<Report Findings Here> 9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. ☐ ☐ ☐ ☐ ☐ 9.8.2 Verify …
Modified p. 125 → 315
<Report Findings Here> 9.8.1.b Examine storage containers used for materials that contain information to be destroyed to verify that the containers are secured.
Identify the evidence reference number(s) from Section 6 for all observation(s) of the storage containers used for materials that contain information to be destroyed for this testing procedure.
Modified p. 125 → 317
<Report Findings Here> 9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
PCI DSS Requirement 9.5.1 POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following:
Removed p. 126
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.9 Examine documented policies and procedures to verify they include:

• Periodically inspecting devices to look for tampering or substitution.

• Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices.

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

9.9.1.a Examine the list of devices to verify it includes:

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

• Device serial number or other method of unique identification.

<Report Findings Here> For all items in the sample, describe how the devices and device locations were …
Modified p. 126 → 297
Identify the sample of devices from the list selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all observations(s) conducted for this testing procedure.
Modified p. 126 → 301
Make, model of device.
Date and time of visit.
Modified p. 126 → 317
• Maintaining a list of devices.
• Maintaining a list of POI devices.
Modified p. 126 → 317
• Periodically inspecting devices to look for tampering or substitution.
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.
Modified p. 126 → 317
• 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 unauthorized substitution of devices.
Modified p. 126 → 318
Identify the documented policies and procedures examined to verify they include:

• Maintaining a list of devices.
Identify the evidence reference number(s) from Section 6 for policies and procedures examined for this testing procedure.
Modified p. 126 → 319
<Report Findings Here> 9.9.1 Maintain an up-to-date list of devices. The list should include the following:
PCI DSS Requirement 9.5.1.1 An up-to-date list of POI devices is maintained, including:
Modified p. 126 → 319
Make, model of device.
Make and model of the device.
Modified p. 126 → 319
• Device serial number or other method of unique identification.
• Device serial number or other methods of unique identification.
Modified p. 126 → 319
Make, model of device.
Location of device.
Modified p. 126 → 320
Identify the documented up-to-date list of devices examined to verify it includes:
Identify the evidence reference number(s) from Section 6 for all lists of POI devices examined for this testing procedure.
Modified p. 126 → 320
<Report Findings Here> 9.9.1.b Select a sample of devices from the list and observe devices and device locations to verify that the list is accurate and up-to-date.
<Enter Response Here> 9.5.1.1.b Observe POI devices and device locations and compare to devices in the list to verify that the list is accurate and up to date.
Modified p. 126 → 320
<Report Findings Here> 9.9.1.c Interview personnel to verify the list of devices is updated when devices are added, relocated, decommissioned, etc.
<Enter Response Here> 9.5.1.1.c Interview personnel to verify the list of POI devices is updated when devices are added, relocated, decommissioned, etc.
Removed p. 127
PCI DSS Requirements and Testing Procedures Reporting Instruction Reporting Details: Assessor’s Response Summary of Assessment Findings (check one) Not Tested 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

9.9.2.a Examine documented procedures to verify processes are defined to include the following:

• Procedures for inspecting devices.

• Frequency of inspections.

• Frequency of inspections.

Identify the documented procedures examined to verify that processes are defined to include the following:

• Procedures for inspecting devices.

• All devices are periodically inspected for evidence of …
Modified p. 127 → 321
<Report Findings Here> 9.9.2.b Interview responsible personnel and observe inspection processes to verify:
<Enter Response Here> 9.5.1.2.b Interview responsible personnel and observe inspection processes to verify:
Modified p. 127 → 321
• All devices are periodically inspected for evidence of tampering and substitution.
• All devices are periodically inspected for evidence of tampering and unauthorized substitution.
Modified p. 127 → 324
Personnel are aware of procedures for inspecting devices.
Being aware of suspicious behavior around devices.
Modified p. 127 → 324
<Report Findings Here> 9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:
PCI DSS Requirement 9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:
Modified p. 127 → 324
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.
Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.
Modified p. 127 → 324
Do not install, replace, or return devices without verification.
Procedures to ensure devices are not installed, replaced, or returned without verification.
Modified p. 127 → 324
Report 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.
Removed p. 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.a Review training materials for personnel at point-of-sale locations to verify it includes training in the following:

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

Identify the training materials for personnel at point-of-sale locations that were reviewed to verify the materials include training in the following:

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify …
Modified p. 128 → 325
<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:
<Enter Response Here> 9.5.1.3.b Interview personnel in POI environments to verify they have received training and know the procedures for all elements specified in this requirement.
Removed p. 129
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).

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

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

Identify the document reviewed to verify that security policies and operational procedures for restricting physical access to cardholder data are documented.

<Report Findings Here> Identify the responsible …
Removed p. 130
Identify the system administrator(s) interviewed who confirm that:

<Report Findings Here> Describe how audit trails were observed to verify 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:

Identify the responsible personnel interviewed who confirm the following from 10.2.1-10.2.7 are logged:

• All individual access to cardholder data.

• All actions taken by any individual with root or administrative privileges.

• Access to all audit trails.

• Invalid logical access attempts.

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

• Initialization of audit logs.

• Stopping or pausing of audit logs.

• Creation and deletion of system level objects.
Removed p. 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 Identify the sample of audit logs selected for 10.2.1-10.2.7.

<Report Findings Here> 10.2.1 All individual user accesses to cardholder data. ☐ ☐ ☐ ☐ ☐ 10.2.1 Verify 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.

<Report Findings Here> 10.2.2 All actions taken by any individual with root or administrative privileges. ☐ ☐ ☐ ☐ ☐ 10.2.2 Verify all 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.

<Report Findings Here> …
Removed 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.

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.

<Report Findings Here> Describe how processes were examined to verify that time synchronization technologies are:

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

Describe how the process for acquiring, distributing, and storing the correct time within the organization was examined to verify the following:

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

<Report Findings Here> 10.4.1.b Observe the time-related system-parameter settings for a sample of system components to verify:

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

• Where there is more than one designated time server, the designated …
Modified p. 134 → 373
• Implemented. <Report Findings Here>
<Enter Response Here>
Removed p. 135
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).

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

<Report Findings Here> 10.4.2 Time data is protected. ☐ ☐ ☐ ☐ ☐ 10.4.2.a Examine system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data.

For all items in the sample from 10.4.1, describe how configuration settings verified that access to time data is restricted to only personnel with a business need to access time data.

<Report Findings Here> 10.4.2.b Examine system configurations, time synchronization settings and logs, and processes to verify that any changes to time settings on critical systems are logged, …
Removed p. 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 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).

• That time updates are encrypted with a symmetric key, and access control lists specify the IP addresses of client machines.

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

Identify the system administrators interviewed who confirm that audit trails are secured so that they cannot be altered as follows (from 10.5.1-10.5.5):

• Only individuals who have a job-related …
Removed p. 138
• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

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

• 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 documented security policies and procedures examined to verify that procedures define reviewing the following at least daily, either manually or via log tools:
Removed p. 138
<Report Findings Here> Describe the manual or log tools used for daily review of logs.

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:

• 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

<Report Findings Here> Describe how processes were observed to verify that the following are reviewed at least daily:

• All security events. <Report Findings Here>

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

<Report Findings Here> 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, …
Modified p. 140 → 374
Identify the documented security policies and procedures examined to verify that procedures define the following:
Identify the evidence reference number(s) from Section 6 for all policies and procedures examined for this testing procedure.
Modified p. 140 → 382
<Report Findings Here> 10.6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed.
<Enter Response Here> 11.3.1.2.b Examine scan report results and interview personnel to verify that authenticated scans are performed.
Removed p. 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 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.

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

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

• 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 …
Removed p. 142
• 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:

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

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

• 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 …
Removed p. 143
• 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 <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> 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. ☐ ☐ ☐ ☐ ☐

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.9 Examine documentation and interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are:

Identify the document reviewed …
Modified p. 145 → 374
11.1.a Examine policies and procedures to verify processes are defined for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.2.1.a Examine policies and procedures to verify processes are defined for managing both authorized and unauthorized wireless access points with all elements specified in this requirement.
Removed p. 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.

If ‘yes,’ Identify/describe the output from recent wireless scans examined to verify that:

• Authorized wireless access points are identified.

• The scan is performed at least quarterly.

• The scan covers all system components.

• The scan covers all facilities.

Indicate whether automated monitoring is utilized. (yes/no) <Report Findings Here> If “no,” mark the remainder of 11.1.d as “Not Applicable.” If “yes,” complete the following:

Identify and describe any automated monitoring technologies in use.

<Report Findings Here> For each monitoring technology in use, describe how the technology generates alerts to personnel.

<Report Findings Here> 11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification. ☐ ☐ ☐ ☐ …
Modified p. 146 → 373
Unauthorized wireless access points are identified.
All authorized and unauthorized wireless access points are detected and identified,
Modified p. 146 → 374
<Report Findings Here> 11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.
<Enter Response Here> 11.2.1.d If automated monitoring is used, examine configuration settings to verify the configuration will generate alerts to notify personnel.
Removed p. 147
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 related responses to verify action is taken when unauthorized wireless access points are found.

For the interview, summarize the relevant details discussed that verify that action is taken when unauthorized wireless access points are found.

<Report Findings Here> Describe how the recent wireless scans and related responses verified that action is taken when unauthorized wireless access points are found.

<Report Findings Here> 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated …
Removed p. 147
11.2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period.

Identify the internal vulnerability scan reports and supporting documentation reviewed.

<Report Findings Here> Provide the name of the assessor who attests that four quarterly internal scans were verified to have occurred in the most recent 12-month period.

<Report Findings Here> 11.2.1.b Review the scan reports and verify that all “high-risk” vulnerabilities are addressed and the scan process includes rescans to verify that the “high- Identify the documented process for quarterly internal scanning to verify the process defines performing rescans as part of the quarterly internal scan process.
Modified p. 147 → 387
<Report Findings Here> Identify the recent wireless scans inspected for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all external scan reports examined for this testing procedure.
Removed p. 148
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 risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

For each of the four internal quarterly scans indicated at 11.2.1.a, indicate whether a rescan was required. (yes/no) <Report Findings Here> If “yes,” describe how rescans were verified to be performed until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

<Report Findings Here> Indicate whether a qualified internal resource performs the scan. (yes/no) If “no,” mark the remainder of 11.2.1.c as “Not Applicable.” If “yes,” complete the following:

<Report Findings Here> For the interview, summarize the relevant details discussed that verify:

• 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) …
Modified p. 148 → 372
Identify the responsible personnel interviewed for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Modified p. 148 → 384
<Report Findings Here> 11.2.1.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
<Enter Response Here> 11.3.1.3.c Interview personnel to verify that internal scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Removed p. 149
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.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, no automatic failures).

<Report Findings Here> For each of the four external quarterly scans indicated at 11.2.2.a, indicate whether a rescan was necessary. (yes/no) <Report Findings Here> If “yes,” describe how the results of the rescan verified that the ASV Program Guide requirements for a passing scan have been met.

Provide the name of the assessor who attests that the external scan reports were reviewed and verified to have been completed by a PCI SSC-Approved Scanning Vendor (ASV).

<Report Findings Here> 11.2.3 Perform internal and external scans, and rescans as needed, after any significant …
Modified p. 149 → 376
For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
High-risk and critical vulnerabilities (per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
Modified p. 149 → 385
Provide the name of the assessor who attests that the results of each quarterly scan were reviewed and verified that the ASV Program Guide requirements for a passing scan have been met.
• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
Modified p. 149 → 386
<Report Findings Here> 11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).
<Enter Response Here> 11.3.2.c Examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).
Modified p. 149 → 386
Identify the change control documentation and scan reports reviewed for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all ASV scan reports examined for this testing procedure.
Modified p. 149 → 386
For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.
Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
Removed p. 150
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.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Indicate whether an internal resource performed the scans. (yes/no) If “no,” mark the remainder of 11.2.3.c as “Not Applicable.” If “yes,” complete the following:

<Report Findings Here> Describe how the personnel who perform the scans demonstrated they are qualified to perform the scans.

<Report Findings Here> 11.3 Implement a methodology for penetration testing that includes at least the following:

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

• Includes testing from both inside and outside of the network.

• Includes testing to validate any segmentation and scope reduction controls.
Removed p. 150
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Specifies retention of penetration testing results and remediation activities results.
Modified p. 150 → 376
<Report Findings Here> Describe how organizational independence of the tester was observed to exist.
• Scans are performed by qualified personnel and organizational independence of the tester exists.
Modified p. 150 → 388
Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).
Industry-accepted penetration testing approaches.
Removed p. 151
• Includes coverage for the entire CDE perimeter and critical systems.

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

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

• Specifies retention of penetration testing results and remediation activities results.

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 Examine penetration-testing methodology and interview responsible personnel to verify a methodology is implemented and includes at least the following:

• Is based on industry-accepted penetration testing approaches.

• Includes testing from both inside and outside the network.

• Based on industry-accepted penetration testing approaches.
Modified p. 151 → 388
Identify the documented penetration-testing methodology examined to verify a methodology is implemented that includes at least the following:
PCI DSS Requirement 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity and includes:
Modified p. 151 → 388
• Testing to validate any segmentation and scope reduction controls.
• Testing to validate any segmentation and scope-reduction controls.
Modified p. 151 → 388
Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.
Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
Modified p. 151 → 388
Defines network-layer penetration tests to include components that support network functions as well as operating systems.
Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
Modified p. 151 → 388
• Retention of penetration testing results and remediation activities results.
• Retention of penetration testing results and remediation activities results for at least 12 months.
Removed p. 152
• Based on industry-accepted penetration testing approaches.

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:

• Coverage for the entire CDE perimeter and critical systems.

• Testing from both inside and outside the network.

• Testing to validate any segmentation and scope reduction controls.

• Review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Retention of penetration testing results and remediation activities results.

<Report Findings Here> 11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

• After any significant changes to the environment Identify the documented external penetration test results reviewed to verify …
Modified p. 152 → 390
• Per the defined methodology
• Per the entity's defined methodology
Modified p. 152 → 392
• Per the defined methodology
• Per the entity's defined methodology
Modified p. 152 → 395
Per the defined methodology
According to the entity's defined penetration testing methodology
Modified p. 152 → 396
11.3.1.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:
<Enter Response Here> 11.4.5.b Examine the results from the most recent penetration test to verify the penetration test covers and addresses all elements specified in this requirement.
Removed p. 153
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 whether any significant external infrastructure or application upgrade or modification occurred during the past 12 months.

<Report Findings Here> Identify the documented penetration test results reviewed to verify that external penetration tests are performed after significant external infrastructure or application upgrade.

Indicate whether an internal resource performed the test. (yes/no) If “no,” mark the remainder of 11.3.1.b as “Not Applicable.” If “yes,” complete the following:

<Report Findings Here> Describe how the personnel who perform the penetration tests demonstrated they are qualified to perform the tests.

<Report Findings Here> 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

• After any significant changes …
Modified p. 153 → 391
11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed as follows:
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.4.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement.
Modified p. 153 → 396
<Report Findings Here> 11.3.1.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
<Enter Response Here> 11.4.5.c Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Modified p. 153 → 397
<Report Findings Here> Describe how organizational independence of the tester was observed to exist.
• Organizational independence of the tester exists (not required to be a QSA or ASV).
Modified p. 153 → 397
Per the defined methodology
According to the entity's defined penetration testing methodology.
Removed p. 154
Indicate whether an internal resource performed the test. (yes/no) If “no,” mark the remainder of 11.3.2.b as “Not Applicable.” If “yes,” complete 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 documented internal penetration test results reviewed to verify that internal penetration tests are performed after significant internal infrastructure or application upgrade.

<Report Findings Here> Describe how the personnel who perform the penetration tests demonstrated they are qualified to perform the tests <Report Findings Here> Describe how organizational independence of the tester was observed to exist.

<Report Findings Here> 11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. ☐ ☐ ☐ ☐ ☐ 11.3.3 Examine penetration testing results to verify that noted exploitable vulnerabilities were corrected and that repeated testing confirmed the vulnerability was corrected.

Identify the documented …
Modified p. 154 → 391
<Report Findings Here> 11.3.2.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
<Enter Response Here> 11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third- party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Modified p. 154 → 396
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.
<Enter Response Here> Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.4.5.a Examine segmentation controls and review penetration- testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods in accordance with all elements specified in this requirement.
Removed p. 155
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>

• Isolate all out-of-scope systems from systems in the CDE.

<Report Findings Here> 11.3.4.b Examine the results from the most recent penetration test to verify that:

Describe how the personnel who perform the penetration tests demonstrated they are qualified to perform the tests.

<Report Findings Here> Describe how organizational independence of the tester was observed to exist.

<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.
Modified p. 155 → 393
<Report Findings Here> 11.3.4.c Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
<Enter Response Here> 11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third- party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Modified p. 155 → 395
Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.
At least once every 12 months and after any changes to segmentation controls/methods
Modified p. 155 → 395
The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems
Modified p. 155 → 397
Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.
At least once every six months and after any changes to segmentation controls/methods.
Modified p. 155 → 397
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.
Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
Modified p. 155 → 397
The penetration testing covers all segmentation controls/methods in use.
Covering all segmentation controls/methods in use.
Modified p. 155 → 398
Identify the documented results from the most recent penetration test examined to verify that:
Identify the evidence reference number(s) from Section 6 for the results from the most recent penetration test examined for this testing procedure.
Removed p. 156
Describe how the personnel who perform the penetration tests demonstrated they are qualified to perform the tests.

<Report Findings Here> Describe how organizational independence of the tester was observed to exist.

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.

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

• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.

• The penetration …
Modified p. 156 → 395
The penetration testing covers all segmentation controls/methods in use.
Covering all segmentation controls/methods in use
Modified p. 156 → 396
Identify the documented results from the most recent penetration test examined to verify that:
Identify the evidence reference number(s) from Section 6 for all results from the most recent penetration test examined for this testing procedure.
Modified p. 156 → 398
<Report Findings Here> 11.3.4.1.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
<Enter Response Here> 11.4.6.b Additional testing procedure for service provider assessments only: Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Modified p. 156 → 400
Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.
• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.
Modified p. 156 → 401
• At the perimeter of the cardholder data environment.
• At the perimeter of the CDE.
Modified p. 156 → 401
• At critical points in the cardholder data environment.
• At critical points in the CDE.
Removed p. 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 critical points in the cardholder data environment.

Describe how system configurations for intrusion- detection and/or intrusion-prevention techniques verified that they are configured to alert personnel of suspected compromises.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that the generated alerts are received as intended.

<Report Findings Here> 11.4.c Examine IDS/IPS configurations and vendor documentation to verify intrusion-detection, and/or intrusion- prevention techniques are configured, maintained, and updated per vendor instructions to ensure optimal protection.

Identify the vendor document(s) examined to verify defined vendor instructions for intrusion-detection and/or intrusion-prevention techniques.

<Report Findings Here> Describe how IDS/IPS configurations and vendor documentation verified that intrusion-detection, and/or intrusion-prevention techniques are:

• Configured per vendor instructions to ensure optimal protection.

• Maintained per vendor instructions to ensure optimal protection.

• Updated per vendor instructions to ensure optimal …
Modified p. 157 → 401
<Report Findings Here> 11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises.
<Enter Response Here> 11.5.1.b Examine system configurations and interview responsible personnel to verify intrusion-detection and/or intrusion- prevention techniques alert personnel of suspected compromises.
Removed p. 158
• System settings <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/ Not Tested Place well as reviewing results from monitoring activities.

Examples of files that should be monitored:

• System executables

• Application executables

• Centrally stored, historical or archived, log and audit files

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

Describe how system settings verified that the change-detection mechanism is configured to:

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

Identify the responsible personnel interviewed who confirm that all alerts are investigated and resolved <Report Findings Here> 11.6 Ensure that …
Modified p. 158 → 403
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.
To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
Modified p. 158 → 405
Alert personnel to unauthorized modification (including changes, additions and deletions) of critical files.
To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
Modified p. 158 → 424
Configuration and parameter files
Applying configuration standards to new systems.
Removed p. 159
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.1 Establish, publish, maintain, and disseminate a security policy. ☐ ☐ ☐ ☐ ☐ 12.1 Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

<Report Findings Here> Describe how the information security policy was verified to be published and disseminated to:

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

Describe how the information security policy was verified …
Removed p. 159
Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.

12.2.a Verify that an annual risk- assessment process is documented that:

• Identifies critical assets, threats, and vulnerabilities

• Identifies critical assets, threats, and vulnerabilities

Provide the name of the assessor who attests that the documented annual risk-assessment process:
Modified p. 159 → 408
Requirement 12: Maintain a policy that addresses information security for all personnel
PCI DSS Requirement 12.1.1 An overall information security policy is:
Modified p. 159 → 410
Identify the documented information security policy examined.
PCI DSS Requirement 12.1.2 The information security policy is:
Modified p. 159 → 410
• Updated as needed to reflect changes to business objectives or the risk environment.
• Updated as needed to reflect changes to business objectives or risks to the environment.
Removed p. 160
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.2.b Review risk-assessment documentation to verify that the risk- assessment process is performed at least annually and upon significant changes to the environment.

Identify the risk assessment result documentation reviewed to verify that the risk-assessment process is performed at least annually and upon significant changes to the environment.

<Report Findings Here> 12.3 Develop usage policies for critical technologies and define proper use of these technologies.

Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Ensure these usage policies require the following:
Removed p. 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 Place responsible personnel to verify the following policies are implemented and followed:

Identify the usage policies for all identified critical technologies reviewed to verify the following policies (12.3.1-12.3.10) are defined:

• All technology use to be authenticated with user ID and password or other authentication item.

• A list of all devices and personnel authorized to use the devices.

• A method to accurately and readily determine owner, contact information, and purpose.

• Acceptable network locations for the technology.

• A list of company-approved products.

• Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

• Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

• Prohibit copying, moving, or storing of cardholder data onto local hard …
Modified p. 161 → 414
• Explicit approval from authorized parties to use the technologies.
• Explicit approval by authorized parties.
Modified p. 161 → 414
• Acceptable uses for the technology.
• Acceptable uses of the technology.
Removed p. 162
• All technology use to be authenticated with user ID and password or other authentication item.

• A list of all devices and personnel authorized to use the devices.

• A method to accurately and readily determine owner, contact information, and purpose.

• Acceptable network locations for the technology.

• A list of company-approved products.

• Automatic disconnect of sessions for remote- access technologies after a specific period of inactivity.

• Activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

• Prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

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 usage policies for all identified critical technologies are implemented and …
Modified p. 165 → 412
<Report Findings Here> 12.4.b Interview a sample of responsible personnel to verify they understand the security policies.
<Enter Response Here> 12.1.3.b Interview personnel in various roles to verify they understand their information security responsibilities.
Modified p. 165 → 422
<Report Findings Here> 12.4.1 Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
PCI DSS Requirement 12.4.1 Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include:
Modified p. 165 → 422
• Overall accountability for maintaining PCI DSS compliance
• Overall accountability for maintaining PCI DSS compliance.
Modified p. 165 → 422
<Report Findings Here> 12.4.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under which the PCI DSS compliance program is organized and communicated to executive management.
• Defining a charter for a PCI DSS compliance program and communication to executive management.
Removed p. 166
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.5 Examine information security policies and procedures to verify:

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

• The following information security responsibilities are specifically and formally assigned:

• The following information security responsibilities are specifically and formally assigned:

<Report Findings Here> 12.5.1 Establish, document, and distribute security policies and procedures. ☐ ☐ ☐ ☐ ☐ 12.5.1 Verify that responsibility for establishing, documenting and distributing security policies and procedures is formally assigned.
Removed p. 166
• Establishing security policies and procedures.

• Distributing security policies and procedures.

<Report Findings Here> 12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel. ☐ ☐ ☐ ☐ ☐ 12.5.2 Verify that responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel is formally assigned.

• Monitoring and analyzing security alerts.

• Distributing information to appropriate information security and business unit management personnel.

<Report Findings Here> 12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. ☐ ☐ ☐ ☐ ☐
Modified p. 166 → 424
Documenting security policies and procedures.
Responding to security alerts.
Modified p. 166 → 425
Identify the information security policies and procedures reviewed to verify:
Identify the evidence reference number(s) from Section 6 for all policies and procedures examined for this testing procedure.
Removed p. 167
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.5.3 Verify that responsibility for establishing, documenting, and distributing security incident response and escalation procedures is formally assigned.

• Establishing security incident response and escalation procedures.

• Documenting security incident response and escalation procedures.

• Distributing security incident response and escalation procedures.

<Report Findings Here> 12.5.4 Administer user accounts, including additions, deletions, and modifications. ☐ ☐ ☐ ☐ ☐ 12.5.4 Verify that responsibility for administering (adding, deleting, and modifying) user account and authentication management is formally assigned.

Provide the name of the assessor who attests that responsibilities were verified to be formally assigned for administering user account and authentication management.

<Report Findings Here> 12.5.5 Monitor and control all access to data. ☐ ☐ ☐ ☐ ☐ 12.5.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.

• Monitoring all …
Modified p. 168 → 389
Identify the documented security awareness program procedures and additional documentation examined to verify that:
Identify the evidence reference number(s) from Section 6 for all documentation examined for this testing procedure.
Modified p. 168 → 391
Identify the sample of personnel interviewed for this testing procedure..
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Modified p. 168 → 438
Personnel attend security awareness training: - Upon hire, and
PCI DSS Requirement 12.6.3 Personnel receive security awareness training as follows:
Modified p. 168 → 438
• Personnel acknowledge, in writing or electronically and at least annually, that they have read and understand the information security policy.
• Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.
Modified p. 168 → 439
• The security awareness program provides multiple methods of communicating awareness and educating personnel.
<Enter Response Here> 12.6.3.b Examine security awareness program materials to verify the program includes multiple methods of communicating awareness and educating personnel.
Modified p. 168 → 439
• 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.
<Enter Response Here> 12.6.3.c Interview personnel to verify they have completed awareness training and are aware of their role in protecting cardholder data.
Removed p. 169
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.6.2 Verify that the security awareness program requires personnel to acknowledge, in writing or electronically, at least annually that they have read and understand the information security policy.

Describe how it was observed that, per the security awareness program, all personnel:

• Acknowledge that they have read and understand the information security policy (including whether this is in writing or electronic).

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

Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a …
Removed p. 169
Identify the Human Resources personnel interviewed who confirm background checks are conducted (within the constraints of local laws) prior to hire on potential personnel who will have access to cardholder data or the cardholder data environment.

<Report Findings Here> Describe how it was observed that background checks are conducted (within the constraints of local laws) prior to hire on potential personnel who will have access to cardholder data or the cardholder data environment.

<Report Findings Here> 12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows: ☐ ☐ ☐ ☐ ☐ 12.8 Through observation, review of policies and procedures, and review of supporting documentation, verify that processes are implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data as follows:

Identify the documented policies and …
Modified p. 169 → 445
<Report Findings Here> 12.8.1 Maintain a list of service providers including a description of the service provided. ☐ ☐ ☐ ☐ ☐
12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided.
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.8.1 Verify that a list of service providers is maintained and includes a list of the services provided.

Describe how the documented list of service providers was observed to be maintained (kept up-to- date) and includes a list of the services provided.

<Report Findings Here> 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have …
Removed p. 170
Describe how written agreements for each service provider were observed to include an acknowledgement by service providers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer.

<Report Findings Here> 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. ☐ ☐ ☐ ☐ ☐ 12.8.3 Verify that policies and procedures are documented and implemented including proper due diligence prior to engaging any service provider.

Identify the policies and procedures reviewed to verify that processes included proper due diligence prior to engaging any service provider.

<Report Findings Here> Describe how it was observed that the above policies and procedures are implemented.

<Report Findings Here> 12.8.4 Maintain a program to monitor service …
Modified p. 171 → 450
Describe how it was observed that the entity maintains information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
<Enter Response Here> 12.8.5.b Examine documentation and interview personnel to verify the entity maintains information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both entities.
Modified p. 171 → 450
<Report Findings Here> 12.9 Additional requirement for service providers only: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
PCI DSS Requirement 12.9.1 Additional requirement for service providers only: TPSPs acknowledge in writing to customers that they are responsible for the security of account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE.
Removed p. 172
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 of the customer’s cardholder data environment.

Describe how the templates used for written agreement verified that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

<Report Findings Here> 12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach. ☐ ☐ ☐ ☐ ☐ 12.10 Examine the incident response plan and related procedures to verify entity is prepared to respond immediately to a system breach by performing the following:

Identify the documented incident response plan and related procedures examined …
Removed p. 173
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.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
Removed p. 173
• Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum.

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

• Reference or inclusion of incident response procedures from the payment brands.

Provide the name of the assessor who attests that the incident response plan was verified to include:

• Roles and responsibilities.

• Communication strategies.

• Requirement for notification of the payment brands.

• Business recovery and continuity procedures.

• Data back-up processes.

• Analysis of legal requirements for reporting compromises.

• Coverage for all critical system components.

• Responses for all critical system components.

• Reference or inclusion of incident response procedures from the payment brands.

<Report …
Modified p. 173 → 453
• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum.
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
Modified p. 173 → 453
• Data back-up processes.
• Data backup processes.
Modified p. 173 → 455
12.10.1.a Verify that the incident response plan includes:
PCI DSS Requirement 12.10.2 At least once every 12 months, the security incident response plan is:
Removed p. 174
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 verify that the documented incident response plan and procedures were followed.

<Report Findings Here> For each item in the sample, describe how the documented incident response plan and procedures were observed to be followed.

<Report Findings Here> 12.10.2 Review and test the plan at least annually, including all elements listed in Requirement 12.10.1. ☐ ☐ ☐ ☐ ☐ 12.10.2 Interview personnel and review documentation from testing to verify that the plan is tested at least annually and that testing includes all elements listed in Requirement 12.10.1.

Identify the responsible personnel interviewed who confirm that the incident response plan is tested at least annually and that testing includes all elements listed in Requirement 12.10.1.

<Report Findings Here> Identify documentation reviewed from testing to verify that the incident response plan is tested …
Removed p. 174
<Report Findings Here> Identify the responsible personnel interviewed who confirm 24/7 incident response and monitoring coverage for:

• Detection of unauthorized wireless access points.
Modified p. 174 → 455
Identify the sample of previously reported incidents or alerts selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Removed p. 175
• Detection of unauthorized wireless access points.

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.

<Report Findings Here> 12.10.4 Provide appropriate training to staff with security breach response responsibilities. ☐ ☐ ☐ ☐ ☐ 12.10.4 Verify through observation, review of policies, and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained.

Identify the responsible personnel interviewed who confirm that staff with responsibilities for security breach response are periodically trained.

<Report Findings Here> Identify the documented policy reviewed to verify that staff with responsibilities for security breach response are periodically trained.

<Report Findings Here> Describe how it was observed that staff with responsibilities for security breach response are periodically trained.

<Report Findings Here> …
Modified p. 175 → 462
<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. ☐ ☐ ☐ ☐ ☐
PCI DSS Requirement 12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
Removed 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.

Identify the documented policy reviewed to verify that processes are defined to modify and evolve the incident response plan:

• According to lessons learned.

• To incorporate industry developments.

• To incorporate industry developments.

<Report Findings Here> Identify the responsible personnel interviewed who confirm that processes are implemented to modify and evolve the incident response plan:

• According to lessons learned.

<Report Findings Here> Describe how it was observed that processes are implemented to modify and evolve the incident response plan:

• According to lessons learned. <Report Findings Here>

• To incorporate industry developments. <Report Findings Here> 12.11 Additional requirement for service …
Removed p. 176
• Change management processes

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:

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

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

<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 …
Removed p. 178
• 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 Guidance and applicability information is provided within each section.
Removed p. 179
Note: If the entity is not a shared hosting provider (and the answer at 2.6 was “no,” indicate the below as “Not Applicable.” Otherwise, complete the below.
Removed p. 179
Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested Indicate whether the assessed entity is a shared hosting provider (indicated at Requirement 2.6). (yes/no) If “no,” mark the below as “Not Applicable” (no further explanation required) If “yes,” complete the following:

<Report Findings Here> A1 Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A1.1 through A1.4:

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.

Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

A1 Specifically for a PCI DSS assessment of a shared hosting provider, to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data, select a sample of …
Modified p. 179 → 463
<Report Findings Here> Identify the sample of servers selected for this testing procedure.
<Enter Response Here> Identify the evidence reference number(s) from Section 6 for all interview(s) conducted for this testing procedure.
Removed p. 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.

<Report Findings Here> For each item in the sample, describe how the system configurations verified that all hosted entities’ application processes are run using the unique ID of that entity.

<Report Findings Here> Describe how the hosted entities’ application processes were observed to be running using the unique ID of the entity.

<Report Findings Here> A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only. ☐ ☐ ☐ ☐ ☐ A1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

For each item in the sample of servers and hosted entities from A1.1, perform the following:

Describe how the system configurations verified that user IDs for hosted entities’ application processes are not privileged users.

<Report Findings …
Modified p. 180 → 465
Identify the sample of hosted merchants and service providers (hosted entities) selected for this testing procedure.
Identify the evidence reference number(s) from Section 6 for the documented incident response procedures examined for this testing procedure.
Removed p. 181
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 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. ☐ ☐ ☐ ☐ ☐ A1.3 Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment:

For each item in the sample of servers …
Modified p. 181 → 470
• Logs are enabled for common third- party applications.
• Logs are enabled for common third-party applications.
Modified p. 181 → 470
• Logs are available for review by the owning entity.

• Log locations are clearly communicated to the owning entity.
• Logs are available for review only by the owning customer.
Modified p. 181 → 470
• Log locations are clearly communicated to the owning entity.
• Log locations are clearly communicated to the owning customer.
Removed p. 182
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.

Identify the document examined to verify that written policies provide for a timely forensics investigation of related servers in the event of a compromise.
Removed p. 183
The PCI DSS requirements directly affected are:

Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.

Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.

Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

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:

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

• Service providers supporting existing POS POI terminal implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration …
Removed p. 184
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):

<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. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.2 and A2.3 apply to POS POI service providers.

Identify the documentation examined to verify that the POS POI terminals using SSL and/or early TLS are not …
Removed p. 185
Assessor’s Response Summary of Assessment Findings (check one) In Place w/ Not Tested A2.2 Review the documented Risk Mitigation and Migration Plan to verify it includes:

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

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

Identify the supporting documentation reviewed to verify the service provider …
Modified p. 185 → 476
• 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;
• Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of environment.
Modified p. 185 → 476
• Risk-assessment results and risk- reduction controls in place;
• Risk-assessment results and risk-reduction controls in place.
Modified p. 185 → 476
• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;
• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS.
Modified p. 185 → 476
• Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;
• Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments.
Modified p. 185 → 477
Identify the documented Risk Mitigation and Migration Plan reviewed to verify it includes:
Identify the evidence reference number(s) from Section 6 for the documented Risk Mitigation and Migration Plan examined for this testing procedure.
Removed p. 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.

Note: The items at a) through c) below are intended as examples only. All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS review. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Companies should be aware that a particular compensating control will not be effective in all environments.

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 …
Modified p. 187 → 480
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.)
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. To understand the intent of a requirement, see the Customized Approach Objective for most PCI DSS requirements. If a requirement is not eligible for the Customized Approach and therefore does not have a Customized Approach Objective, refer to the Purpose in the Guidance column for that requirement.
Modified p. 187 → 480
3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) When evaluating “above and beyond” for compensating controls, consider the following:
3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
Modified p. 187 → 480
4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
5. Address the additional risk imposed by not adhering to the PCI DSS requirement.
Modified p. 187 → 481
The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to validate that each compensating control adequately addresses the risk the original PCI DSS requirement was designed to address, per items 1-4 above. To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete.
The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to confirm that each compensating control adequately addresses the risk that the original PCI DSS requirement was designed to address, per items 1-6 above.
Modified p. 188 → 482
Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Note: Only entities that have legitimate and documented technological or business constraints can consider the use of compensating controls to achieve compliance.
Modified p. 188 → 482
1. Constraints List constraints precluding compliance with the original requirement.
1. Constraints Document the legitimate technical or business constraints precluding compliance with the original requirement.
Modified p. 188 → 482
2. Objective Define the objective of the original control; identify the objective met by the compensating control.
3. Objective Define the objective of the original control (for example, the Customized Approach Objective).
Modified p. 188 → 482
3. Identified Risk Identify any additional risk posed by the lack of the original control.
4. Identified Risk Identify any additional risk posed by the lack of the original control.
Modified p. 188 → 482
4. Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any.
2. Definition of Compensating Define the compensating controls, explain how they address the objectives of the original control and the increased risk, if any.
Modified p. 188 → 482
6. Maintenance Define process and controls in place to maintain compensating controls.
6. Maintenance Define process(es) and controls in place to maintain compensating controls.
Removed p. 189
Requirement Number: 8.1.1

• Are all users identified with a unique user ID before allowing them to access system components or cardholder data? Information Required Explanation

1. Constraints List constraints precluding compliance with the original requirement.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a “root” login. It is not possible for Company XYZ to manage the “root” login nor is it feasible to log all “root” activity by each user.

2. Objective Define the objective of the original control; identify the objective met by the compensating control.

The objective of requiring unique logins is twofold. First, it is not considered acceptable from a security perspective to share login credentials. Secondly, having shared logins makes it impossible to state definitively that a person is responsible for a particular action.

3. Identified Risk Identify any additional risk posed by the lack of the original control.

Additional risk is introduced to the access control …