Document Diff - PCI Watch

Added p. 2

February 2014 PCI DSS 3.0, Revision 1.0 To introduce the template for submitting Reports on Compliance.

This document is intended for use with version 3.0 of the PCI Data Security Standard.

July 2014 PCI DSS 3.0, Revision 1.1 Errata - Minor edits made to address typos and general errors, slight addition of content.

Added p. 2

PCI DSS 3.2.1 Revision 1.0 Revision to align with changes from PCI DSS 3.2 to PCI DSS 3.2.1 (see PCI DSS

• Summary of Changes from PCI DSS Version 3.2 to 3.2.1 for details of changes). Also includes minor corrections and edits made for clarification and/or format.

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

• Summary of Changes from PCI DSS Version 4.0 to 4.0.1 for details of changes to PCI DSS and see PCI DSS ROC Template

PCI DSS v4.0.1 Revision 1 Correction to Assessment Findings selection options in Appendix A1 and A2 to remove duplicate columns.

Added back inadvertently removed row of Assessment Finding selection options in Requirements 10.2.1.4, 10.2.1.5, 10.3.3, 12.1.4, and 12.6.3.2.

Added p. 2

PCI DSS v4.0.1 Revision 3 In section “6.2 Sampling,” added a row at the end of the table for “If ‘Yes’” responses.

Added p. 6

Use of this ROC Template is mandatory for all PCI DSS v4.0.1 submissions when documenting the results of a detailed PCI DSS assessment (as contrasted with a less detailed PCI DSS self-assessment documented in a Self-Assessment Questionnaire (SAQ)).

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 …

Added p. 7

 Part I: Assessment Overview

• Section 1: Contact Information and Summary of Results

• Section 2: Business Overview

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

• Section 4: Details about Reviewed Environment

• Section 5: Quarterly Scan Results  Part II: Sampling and Evidence, Findings and Observations

• Section 6: Sampling and Evidence

• Section 7: Findings and Observations o Build and Maintain a Secure Network and Systems o Protect Account Data o Maintain a Vulnerability Management Program o Implement Strong Access Control Measures o Regularly Monitor and Test Networks o Maintain an Information Security Policy o Appendix A: Additional PCI DSS Requirements o Appendix B: Compensating Controls o Appendix C: Compensating Controls Worksheet o Appendix D: Customized Approach o Appendix E: Customized Approach Template Part I and Section 6 of Part II must be thoroughly and accurately completed to provide proper context for the Findings and Observations in Section 7 of …

Added p. 8

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 required documents, including the AOC.

Refer to the PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions document on the PCI SSC website for further guidance.

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

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.

Describe how the testing and evidence demonstrates the requirement is In Place.

Not Applicable The requirement does not apply to the organization’s environment.

Not Applicable responses require reporting on testing performed to confirm …

Added p. 9

(See “What is the difference between Not Applicable and Not Tested?” in the following section for examples of when this option should be used.)

Note: Where Not Tested is used, the assessment is considered a Partial Assessment.

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.

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 from being met.

Note: Contractual obligations or legal …

Added p. 10

Refer to the PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions document on the PCI SSC website for further guidance.

It is possible for different aspects of a requirement to be met with a combination of these approaches. For example, if there are several types of system components that apply to a certain requirement, system component X may be met with a compensating control, while system component Y may be met as stated with the defined approach, and system component Z may be met with a customized approach.

Refer to the following table when considering whether to select one or both of these methods. If both methods were used for a sub- requirement, select both boxes; if neither method is used for a sub-requirement, do not select either box.

Used When to Use Method Using Figure 1 Required Reporting Compensating Control A compensating control has been implemented to meet some …

Added p. 11

Figure 1. Example Requirement Requirement Description 1.1 Example Requirement Description

PCI DSS Requirement 1.1.1 Example Requirement Assessment Findings (select one) Select If Below Method(s) Was Used In Place Not Applicable Not Tested Not in Place Compensating Control* Customized Approach* ☐ ☐ ☐ ☐ ☐ ☐ Describe why the assessment finding was selected.

Added p. 11

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.1.1.a Example testing procedure Example reporting instruction 1.1.1.b Example testing procedure Example reporting instruction

Added p. 12

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:

 An organization may be asked by their acquirer or brand to validate a subset of requirements•for example, using the PCI DSS Prioritized Approach to validate certain milestones.

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

 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 to validate only the physical security controls per PCI DSS Requirement 9 for their storage facility.

In these scenarios, the organization wants to validate only certain PCI DSS requirements, even though …

Added p. 13

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.

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

Assessor responses generally fall into categories, such as the following:

Reporting Instruction Term Example Usage Description of Response Indicate Indicate whether the assessed entity is an issuer or supports issuing services.

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

Added p. 15

• Use this Reporting Template when assessing to PCI DSS 4.0.1.

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

• Provide a response for every Testing Procedure.

• Provide sufficient detail and information to thoroughly document the assessment.

• Ensure sufficient detail and information are included in the workpaper evidence.

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

• Ensure the response covers all applicable system components, business functions, or facilities.

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

• Provide useful, meaningful diagrams as directed.

• Do not select the In Place response without verification that the requirement is met (plans to meet a requirement in the future do not warrant an In Place response)

• Do not copy responses from one requirement to another without first confirming that the response is fully applicable to each requirement.

• Do not copy responses from previous …

Added p. 16

PCI DSS v4.0.1 Report on Compliance Entity Name:

Date Assessment Ended:

Added p. 17

DBA (doing business as):

Company main website:

Contact phone number:

Contact e-mail address:

Assessed Entity Internal Security Assessors Identify all Internal Security Assessors (ISAs) involved in the assessment. If there were none, mark as Not Applicable. (Add rows as needed) Qualified Security Assessor Company Company name:

Added p. 18

Assessor phone number:

Assessor e-mail address:

Assessor certificate number:

Additional Assessors Identify 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:

Identify all other assessors involved in the assessment. If there were none, mark as Not Applicable. (Add rows as needed) Assessor name: Assessor certificate number:

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

QA reviewer phone number:

QA reviewer e-mail address:

QA reviewer’s PCI credentials or certificate number:

(See the current QSA Qualification Requirements for acceptable credentials)

Added p. 19

Date assessment ended:

Note: The “Date of Report” indicates the completion date of the ROC, and therefore must be no earlier than the date on which the QSA Company and assessed entity agree on the final version of the ROC.

Date assessment began:

Note: This is the first date that evidence was gathered, or observations were made.

Note: This is the last date that evidence was gathered, or observations were made.

Identify the date(s) spent onsite at the assessed entity.

Added p. 19

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

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.

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.

Describe efforts made to ensure no conflict of interest resulted from the above- mentioned products and services provided by the QSA Company.

Added p. 21

Note: The use of subcontractors must conform with the requirements defined in the Qualification Requirements for Qualified Security Assessors (QSA) and Qualified Security Assessor Program Guide.

☐ Yes ☐ No If yes, identify the Assessor Company(s) utilized during the assessment.

Added p. 21

☐ 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 requirements except those noted as Not Tested above.

☐ Non-Compliant: Not all sections of the PCI DSS ROC are complete, or one or more requirements are marked as Not in Place, resulting in an overall NON-COMPLIANT rating; thereby the assessed entity has not demonstrated compliance with PCI DSS requirements.

Compliant but with Legal Exception: One or more assessed requirements …

Added p. 22

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

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 Appendix A1: ☐ ☐ ☐ ☐ ☐ ☐ Appendix A2: ☐ ☐ ☐ ☐ ☐ ☐ Appendix A3: ☐ ☐ ☐ ☐ ☐ ☐ In the sections below identify the sub-requirements with the following results and assessment methods. If there are none, enter “Not Applicable.”

Note: Natural grouping of requirements is allowed (for example, Req. 3, 1.1, 1.1.1, 1.1.2, or 1.2.1 through 1.2.3, etc.) to reduce the number of individual requirements listed.

Not Applicable Not Tested Not in Place Due to a Legal Restriction Not in Place Not Due to a Legal Restriction Compensating Customized

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 …

Added p. 25

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.” 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 evaluation identified areas of …

Added p. 26

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

Note: The only SAQ for service providers is SAQ D for Service Providers. All other SAQs are for merchants only.

Additional information, if applicable:

Added p. 26

Note: An environment with no segmentation is considered a “flat” network where all systems are considered to be in scope.

• If “No,” provide the name of the assessor who attests that the entire network has been included in the scope of the assessment.

• If “Yes,” complete the following:

• Describe how the segmentation is implemented, including the technologies and processes used.

• Describe the environments that were confirmed to be out of scope as a result of the segmentation methods.

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

Added p. 27

☐ 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 solution Version of product or

PCI SSC Standard to which product or solution was validated

PCI SSC listing reference number Expiry date of listing 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.

Any additional comments or findings the assessor would like to include, if applicable.

Added p. 28

 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 all network security controls that are defined for connection points between trusted and untrusted networks.

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

• At the perimeter of the cardholder data environment.

• At critical points in the cardholder data environment.

Added p. 29

 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 account data. Add rows as necessary.

Account data flows (For example, account data flow 1, account data flow 2) Description (Include the type of account data) Insert Diagrams

Added p. 30

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.

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 Logged4 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 Storage of SAD If SAD is stored complete the following:

Note: Anywhere SAD is stored should be documented in the table in 4.3 Indicate whether SAD is stored post authorization: ☐ Yes ☐ No Indicate whether SAD is …

Added p. 31

Refer to PCI DSS v4.x, section 4 Scope of PCI DSS Requirements, subsection Use of Third-Party Service Providers for more information.

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 1 For example, PAN, expiry date, providing support via remote access, and so on. 2 For example, third-party storage, transaction processing, custom software development, and so on.

Added p. 32

Note: This section must align with networks identified on the network diagram.

Describe all networks that store, process, and/or transmit Account Data:

Network Name (In scope) Type of Network Function/ Purpose of Network 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.:

Network Name (In Scope) Type of Network Function/Purpose of Network

Added p. 33

Facility Type (Datacenters, corporate office, call center, mail processing facility, etc.) Total Number of Locations (How many locations of this type are in scope) Location(s) of Facility (for example, city, country) Example 1: Data center 1 Los Angeles, California, United States Example 2: retail locations 132 92 locations in the United States and 40 in Canada 4.7 In-Scope System Component Types Identify all types of system components in scope. Refer to PCI DSS v4.x section 4 Scope of PCI DSS Requirements for examples, that include but are not limited to, of system component types that are in scope for PCI DSS requirements.

For each item, even if they reside with other system components, list them below with each component with different roles, vendors, or make/model/version on separate rows. Add rows as needed.

Type of System Component1 Total Number of System Components2 Vendor Product Name and Version Role/Function Description 1 For example, application, …

Added p. 34

Date of the Scan(s) Name of ASV that Performed the 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 Indicate whether this is the assessed entity’s initial PCI DSS assessment against the ASV scan requirements.

☐ Yes ☐ No If yes, Identify the name of the document the assessor verified to include the entity’s documented policies and procedures requiring scanning at least once every three months going forward.

Assessor comments, if applicable:

Added p. 34

Indicate whether the ASV and the assessed entity 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.

Added p. 35

☐ Yes ☐ No If yes, Identify the name of the document the assessor verified to include the entity’s documented policies and procedures requiring scanning at least once every three months going forward.

Assessor comments, if applicable:

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 Indicate if this is the assessed entity’s initial PCI DSS assessment against the internal scan requirements.

Added p. 36

Identify the entity or entities who controls the evidence repositories.

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 Identify the assessor who attests that all evidence, including interview notes, system configuration evidence, documentation, and observation notes has been gathered and stored as per the QSA Company’s evidence retention policy.

Added p. 37

• If “Yes,” complete the following:

• If “No,” provide the name of the assessor who attests that every item in each population has been assessed.

Note: If multiple sampling methodologies are used, clearly respond for each methodology.

• Describe the sampling rationale(s) used for selecting sample sizes (for people, process evidence, technologies, devices, locations/sites, etc.).

• Describe how the samples are appropriate and representative of the overall populations.

• Indicate whether standardized processes and controls are in place that provide consistency between each item in the samples

•for example, automated system build processes, configuration change detection, etc.

☐ Yes ☐ No o If “Yes,” describe how the processes and controls were validated by the assessor to be in place and effective.

Added p. 38

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. 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 Sample Type/ Description1 Identify All Items in the Sample Set2 Selection Method3 Total Sampled Total Population 1 For example, firewalls, datacenters, change records, User IDs, and so on. 2 For example, unique system identifiers, location addresses/identifiers, change record numbers/identifiers, personnel identifier, and so on. 3 Describe the method for selecting individual items in the sample sets.

Added p. 39

Information Security Manager

Added p. 41

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

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.

PCI DSS Requirement 1.2.1 Configuration standards for NSC rulesets are:

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.1.a Examine the configuration standards for NSC rulesets to verify the standards are in accordance with all elements specified in this requirement.

Added p. 43

1.2.1.b Examine configuration settings for NSC rulesets to verify that rulesets are implemented according to the configuration standards.

Added p. 44

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.

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

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.

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.

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

Added p. 46

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.

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.

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

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.4.a Examine data-flow diagram(s) and …

Added p. 51

PCI DSS Requirement 1.2.8 Configuration files for NSCs are:

• Secured from unauthorized access.

• Kept consistent with active network configurations.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.2.8 Examine configuration files for NSCs to verify they are in accordance with all elements specified in this requirement.

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

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.

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.

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.

Added p. 53

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.3.2.a Examine configuration standards for NSCs to verify that they define restricting outbound traffic from the CDE in accordance with all elements specified in this requirement.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.3.3 Examine configuration settings and network diagrams to verify that NSCs are …

Added p. 55

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

PCI DSS Requirement 1.4.1 NSCs are implemented between trusted and untrusted networks.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.4.1.a Examine configuration standards and network diagrams to verify that NSCs are defined between trusted and untrusted networks.

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.

Added p. 56

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.

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

PCI DSS Requirement 1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.4.3 Examine vendor documentation and configurations for NSCs to verify that anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

PCI DSS Requirement 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.

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.

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

1.4.4.b Examine configurations of NSCs to verify that controls are implemented such …

Added p. 61

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 1.5.1.b Examine configuration settings on computing devices that connect to both untrusted networks and the CDE to verify settings are implemented in accordance with all elements specified in this requirement.

Added p. 62

Requirement 2: Apply Secure Configurations to All System Components Requirement Description 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.

Added p. 64

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.

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

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.

Added p. 66

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

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.

Added p. 66

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.

Added p. 67

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,

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

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.2.3.a Examine system configuration standards to verify they include managing primary functions requiring different security levels as specified in this requirement.

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.

Added p. 68

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

PCI DSS Requirement 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.2.4.a Examine system configuration standards to verify necessary services, protocols, daemons and functions are identified and documented.

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.

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.

2.2.5.b If any insecure services, protocols, or …

Added p. 74

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.

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.

Added p. 75

• SNMP defaults are not used.

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

Identify the evidence reference number(s) from Section 6 for the observations of administrator log in(s) for this testing procedure.

2.3.1.c Examine vendor documentation and wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

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

Added p. 76

PCI DSS Requirement 2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows:

• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.

• Whenever a key is suspected of or known to be compromised.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 2.3.2 Interview responsible personnel and examine key-management documentation to verify that wireless encryption keys are changed in accordance with all elements specified in this requirement.

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.

Added p. 78

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.

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:

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

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

• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.

• Processes for secure deletion …

Added p. 80

Identify the evidence reference number(s) from Section 6 for all data retention and disposal policies, procedures, and processes examined for this testing procedure.

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.

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

3.2.1.c Observe the mechanisms used to render account data unrecoverable to verify data cannot be recovered.

Identify the evidence reference number(s) from Section 6 for the observations of the mechanisms used for this testing procedure.

Added p. 81

PCI DSS Requirement 3.3.1 SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.

Added p. 81

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.1.a If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not stored after authorization.

Added p. 81

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.

Identify the evidence reference number(s) from Section 6 for the observations of the secure data deletion processes for this testing procedure.

Added p. 82

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

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

PCI DSS Requirement 3.3.1.2 The card verification code is not stored upon completion of the authorization process.

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.3.2 Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

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

Added p. 85

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

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:

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

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.

Identify the evidence reference number(s) from Section 6 for all documented policies examined for …

Added p. 87

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

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

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.

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.

Added p. 88

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.4.2.a Examine documented policies and procedures and documented evidence for technical controls that prevent copy and/or relocation of PAN when using remote-access technologies onto local hard drives or removable electronic media to verify the following:

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

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

3.4.2.c Observe processes and interview personnel to verify that only personnel with documented, explicit authorization and a legitimate, defined business need …

Added p. 90

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.5.1.a Examine documentation about the system used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the methods specified in this requirement.

3.5.1.b Examine data repositories and audit logs, including payment application logs, to verify the PAN is rendered unreadable using any of the methods specified in this requirement.

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

Added p. 90

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.

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

Added p. 91

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. This requirement will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date is reached.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures.

3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic …

Added p. 93

• On removable electronic media,

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

3.5.1.2.b Examine configurations and/or vendor documentation and observe encryption processes to verify the system is configured according to vendor documentation the result is that the disk or the partition is rendered unreadable.

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

Added p. 94

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.

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.

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

3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that …

Added p. 96

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.

• Description of the key usage for each key.

• 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, to support meeting Requirement 12.3.4.

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 …

Added p. 98

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

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

Added p. 99

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

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 all user access lists examined for this testing procedure.

PCI DSS Requirement 3.6.1.4 Cryptographic keys are stored in the fewest possible locations.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.6.1.4 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations.

Added p. 101

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.

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 documented key-management policies and procedures examined for this testing procedure.

3.7.1.b Observe the method for generating keys to verify that strong keys are generated.

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

Added p. 102

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.

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

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

3.7.2.b Observe the method for distributing keys to verify that keys are distributed securely.

Identify the evidence reference number(s) from Section 6 for all observations 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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.3.a Examine the documented key- management policies and procedures for …

Added p. 103

3.7.3.b Observe the method for storing keys to verify that keys are stored securely.

Identify the evidence reference number(s) from Section 6 for all observations 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 application vendor or key owner, and based on industry best practices and guidelines, including the following:

• A defined cryptoperiod for each key type in use.

• A process for key changes at the end of the defined cryptoperiod.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.4.a Examine the documented key- management policies and procedures for keys used for protection of stored account data to verify that they define changes to cryptographic keys that have reached the end of their cryptoperiod and include all elements specified in this requirement.

3.7.4.b …

Added p. 106

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.

• The key is suspected of or known to be compromised.

• Retired or replaced keys are not used for encryption operations.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 3.7.5.a Examine the documented key- management policies and procedures for keys used for protection of stored account data and verify that they define retirement, replacement, or destruction of keys in accordance with all elements specified in this requirement.

3.7.5.b Interview personnel to verify that processes are implemented in accordance with all elements specified in …

Added p. 114

4.2.1.c Examine cardholder data transmissions to verify that all PAN is encrypted with strong cryptography when it is transmitted over open, public networks.

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

4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected.

PCI DSS Requirement 4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.

Added p. 115

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

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.

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.

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.

Added p. 116

PCI DSS Requirement 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.

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.

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.

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

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.2.1.a Examine system components to verify that an anti- malware solution(s) is deployed on all system components, except for those determined to not be at risk from malware based on periodic evaluations per Requirement 5.2.3.

Added p. 119

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.

Added p. 120

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

• Detects all known types of malware.

• Detects all known types of malware.

• Removes, blocks, or contains all known types of malware.

• Removes, blocks, or contains all known types of malware.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.2.3.a Examine documented policies and procedures to verify that a process is defined for periodic evaluations of any system components that are not at risk for malware that includes …

Added p. 123

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.2.3.1.a Examine the entity’s targeted risk analysis for the frequency of periodic evaluations of system components identified as not at risk for malware to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

Identify the evidence reference number(s) from Section 6 for the targeted risk analysis examined for this testing procedure.

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 …

Added p. 124

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.

Added p. 125

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

• Performs periodic scans and active or real-time scans.

• Performs continuous behavioral analysis of systems or processes.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.3.2.a Examine anti-malware solution(s) configurations, including any master installation of the software, to verify the solution(s) is configured to perform at least one of the elements specified in this requirement.

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 scan results examined for this testing procedure.

Added p. 127

Identify the evidence reference number(s) from Section 6 for the targeted risk analysis 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 12.3.1.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.3.2.1.a Examine the entity’s targeted risk analysis for the frequency of periodic malware scans to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1.

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

• …

Added p. 130

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.3.5.a Examine anti-malware configurations, to verify that the anti-malware mechanisms cannot be disabled or altered by users.

Identify the evidence reference number(s) from Section 6 for all anti- malware solution configurations examined for this testing procedure.

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.

PCI DSS Requirement 5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 5.4.1 Observe implemented processes and examine mechanisms to verify controls are in place to detect and protect personnel against phishing attacks.

Identify …

Added p. 132

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.

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.

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.

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

• Incorporating consideration of information security issues during each stage of the software development lifecycle.

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

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.2.2.a Examine software development procedures to verify that processes are defined for training of software development personnel developing bespoke and custom software that includes all elements specified in this requirement.

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

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 …

Added p. 141

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.

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.

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 for all software documentation examined for this testing procedure.

PCI DSS Requirement 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

• Patches/updates for critical vulnerabilities (identified according …

Added p. 144

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

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

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

Added p. 145

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

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.

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.

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 place in accordance with …

Added p. 148

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.

• Documentation of security impact.

• Documented change approval by authorized parties.

• Testing to verify that the change does not adversely impact system security.

• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.

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

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.

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

Added p. 149

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

Added p. 150

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.5.2 Examine documentation for significant changes, interview personnel, and observe the affected systems/networks to verify that the entity confirmed applicable PCI DSS requirements were in place on all new or changed systems and networks and that documentation was updated as applicable.

Identify the evidence reference number(s) from Section 6 for all observations 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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 6.5.3.a Examine policies and procedures to verify that processes are defined for separating the pre-production environment from the production environment via access controls that …

Added p. 155

Identify the evidence reference number(s) from Section 6 for all observations of the testing processes 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.

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.

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.

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 or test accounts on systems in production.

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

Identify the evidence reference number(s) from Section …

Added p. 157

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.

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.

• Access to system components and data resources that is based on users' job classification and functions.

• The least privileges required (for example, user, administrator) to perform a job function.

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.

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.

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

Added p. 159

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

• Job classification and function.

• Least privileges necessary to perform job responsibilities.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.2.a Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement.

7.2.2.b Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement.

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

7.2.2.c Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement.

PCI DSS Requirement 7.2.3 Required privileges are approved by authorized personnel.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.3.a Examine policies and procedures to verify they define processes for …

Added p. 163

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.5.a Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement.

7.2.5.b Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement.

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

• Any inappropriate access is addressed.

• Management acknowledges that …

Added p. 165

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

Added p. 166

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.2.6.a Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement.

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.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.3.1 Examine vendor documentation and system …

Added p. 168

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.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 7.3.3 Examine vendor documentation and system settings to verify that the access control system(s) is set to “deny all” by default.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.1.1 Examine documentation and interview personnel to verify that security …

Added p. 173

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

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

• Use is limited to the time needed for the exceptional circumstance.

• Business justification for use is documented.

• Use is explicitly approved by management.

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

• Every action taken is attributable to an individual user.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.2.a Examine user account lists on system components and applicable documentation 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.

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

Added p. 174

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.

Added p. 175

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.2.3 Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that service providers with remote access to customer premises use unique authentication factors for remote access to each customer premises.

PCI DSS Requirement 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:

• Authorized with the appropriate approval.

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

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 …

Added p. 182

PCI DSS Requirement 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.2.a Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage.

8.3.2.b Examine repositories of authentication factors to verify that they are unreadable during storage.

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

8.3.2.c Examine data transmissions to verify that authentication factors are unreadable during transmission.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.3 Examine procedures for modifying authentication factors and observe security personnel to verify that when a user requests a modification …

Added p. 183

Identify the evidence reference number(s) from Section 6 for all observations 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.

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.

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.

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

PCI DSS Requirement 8.3.5 If passwords/passphrases are …

Added p. 186

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.3.7 Examine system configuration settings to verify that password parameters are set to require that new passwords/passphrases cannot be the same as the four previously used passwords/passphrases.

PCI DSS Requirement 8.3.8 Authentication policies and procedures are documented and communicated to all users including:

• Guidance on selecting strong authentication factors.

• Guidance for how users should protect their authentication factors.

• Instructions not to reuse previously used passwords/passphrases.

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

Testing Procedures …

Added p. 190

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 for customers to change their user passwords/passphrases periodically.

• 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 once 8.3.10.1 becomes effective.

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.

• Passwords/passphrases are changed at …

Added p. 194

PCI DSS Requirement 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.4.1.a Examine network and/or system configurations to verify MFA is required for all non-console into the CDE for personnel with administrative access.

Added p. 194

8.4.1.b Observe administrator personnel logging into the CDE and verify that MFA is required.

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

Added p. 195

PCI DSS Requirement 8.4.2 MFA is implemented for all non-console access into the CDE.

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 non-console access into the CDE.

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 observations of personnel logging into the CDE for this testing procedure.

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 all remote access originating from outside the entity’s network that could access or impact the CDE.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.4.3.a Examine network and/or system configurations for remote access servers and systems to verify MFA is required in accordance with all elements specified in this requirement.

8.4.3.b Observe personnel (for …

Added p. 198

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 observations of personnel logging into system components in the CDE for this testing procedure.

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 reference number(s) from Section 6 for all observations of personnel connecting remotely from outside the entity’s network for this testing procedure.

Added p. 199

• Every action taken is attributable to an individual user.

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.

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 reference number(s) from Section 6 for all application and system accounts examined for this testing procedure.

Added p. 200

PCI DSS Requirement 8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 8.6.2.a Interview personnel and examine system development procedures to verify that processes are defined for application and system accounts that can be used for interactive login, specifying that passwords/passphrases are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

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

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 …

Added p. 203

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.

PCI DSS Requirement 9.2.1 Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.2.1 Observe entry controls and interview responsible personnel to verify that physical security controls are in place to restrict access to systems in the CDE.

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

Added p. 206

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.

• Monitoring devices or mechanisms are protected from tampering or disabling.

• Collected data is reviewed and correlated with other entries.

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

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 observations of locations where individual physical access to sensitive areas within the CDE occurs for this testing procedure.

9.2.1.1.b Observe locations where individual physical access …

Added p. 208

PCI DSS Requirement 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.2.2 Interview responsible personnel and observe locations of publicly accessible network jacks to verify that physical and/or logical controls are in place to restrict access to publicly accessible network jacks within the facility.

Identify the evidence reference number(s) from Section 6 for all observations 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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.2.3 Interview responsible personnel and observe locations of hardware and lines to verify that physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted.

Identify the evidence reference number(s) from Section 6 for all …

Added p. 212

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

• Access is authorized and based on individual job function.

• Access is revoked immediately upon termination.

• All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.

Added p. 213

• Access is required for the individual’s job function.

Identify the evidence reference number(s) from Section 6 for all observations of personnel in sensitive areas for this testing procedure.

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

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

9.3.1.1.b Observe processes and interview personnel to verify that access of all personnel is revoked immediately upon termination.

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.

Added p. 214

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

• Visitor badges or other identification visibly distinguishes visitors from personnel.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.3.2.a Examine documented procedures and interview personnel to verify procedures are defined for authorizing and managing visitor access to the CDE in accordance with all elements specified in this requirement.

• Authorized before entering the CDE.

• Escorted at all times within the CDE.

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

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.

Identify the evidence …

Added p. 216

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.

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 observations of visitors leaving the facility for this testing procedure.

PCI DSS Requirement 9.3.4 Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas, including:

• The visitor’s name and the organization represented.

• The date and time of the visit.

• The name of the personnel authorizing physical access.

• Retaining the log for at least three months, unless otherwise restricted by law.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response …

Added p. 219

PCI DSS Requirement 9.4.1 All media with cardholder data is physically secured.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.1 Examine documentation to verify that procedures defined for protecting cardholder data include controls for physically securing all media.

Added p. 220

PCI DSS Requirement 9.4.1.1 Offline media backups with cardholder data are stored in a secure location.

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.

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.

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 media backup location(s) with cardholder data at least once every 12 months.

9.4.1.2.b Examine documented procedures, logs, or …

Added p. 229

Identify the evidence reference number(s) from Section 6 for the periodic media destruction policy examined for this testing procedure.

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.4.7.a Examine the media destruction policy to verify that procedures are defined to destroy electronic media when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

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 observations of the media destruction process for this testing procedure.

PCI DSS Requirement …

Added p. 231

PCI DSS Requirement 9.5.1.1 An up-to-date list of POI devices is maintained, including:

• Make and model of the device.

• Location of device.

• Device serial number or other methods of unique identification.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 9.5.1.1.a Examine the list of POI devices to verify it includes all elements specified in this requirement.

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

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.

Identify the evidence reference number(s) from Section 6 for all observations of the POI devices and device locations for this testing procedure.

9.5.1.1.c Interview personnel to verify the list of POI devices is updated when devices are added, relocated, decommissioned, etc.

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

Added p. 236

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.

PCI DSS Requirement 10.2.1 Audit logs are enabled and active for all system components and cardholder data.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 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. 238

PCI DSS Requirement 10.2.1.1 Audit logs capture all individual user access to cardholder data.

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

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.2 Examine audit log configurations and log data to verify that all actions taken by any individual with administrative access, including any interactive use of application or system accounts, are logged.

PCI DSS Requirement 10.2.1.3 Audit logs capture all access to audit logs.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.2.1.3 Examine audit log configurations and log data to verify that access to all audit logs is captured.

PCI DSS Requirement 10.2.1.4 Audit logs capture all invalid logical access attempts.

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 …

Added p. 247

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.

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.

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.

Assessment Findings (select one) Select If Below Method(s) Was Used In Place Not Applicable Not Tested Not in Place Compensating Control* Customized ☐ ☐ ☐ ☐ ☐ ☐ Describe why the assessment finding was selected.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.3.3 Examine backup configurations or log files to …

Added p. 250

PCI DSS Requirement 10.4.1 The following audit logs are reviewed at least once daily:

• All security events.

• Logs of all system components that store, process, or transmit CHD and/or SAD.

• Logs of all critical system components.

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

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

PCI DSS Requirement 10.4.1.1 Automated mechanisms are used to perform audit log reviews.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.4.1.1 Examine log review mechanisms and interview personnel to verify that automated mechanisms are used to perform log reviews.

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

Added p. 252

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

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.

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.4.2.1.a Examine the entity’s targeted risk analysis for the frequency of periodic log reviews for all other system components (not defined in …

Added p. 256

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.

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

Added p. 257

PCI DSS Requirement 10.6.1 System clocks and time are synchronized using time-synchronization technology.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 10.6.1 Examine system configuration settings to verify that time-synchronization technology is implemented and kept current.

Added p. 258

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.

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

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

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.

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

PCI DSS Requirement 10.6.3 Time …

Added p. 260

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

Added p. 261

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 observations of detection and alerting processes conducted for this testing procedure.

Added p. 262

• Anti-malware solutions.

• Physical access controls.

• Logical access controls.

• Audit logging mechanisms.

• Segmentation controls (if used).

PCI DSS Requirement 10.7.2 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:

• Change-detection mechanisms.

• Audit log review mechanisms.

• Automated security testing tools (if used).

Note: This requirement applies to all entities, including service providers, and will supersede Requirements 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1. 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 and will supersede Requirement 10.7.1.

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

10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures …

Added p. 264

PCI DSS Requirement 10.7.3 Failures of any critical security control systems are responded to promptly, including but not limited to:

• Restoring security functions.

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

• Identifying and documenting the cause(s) of failure and documenting required remediation.

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

• Determining whether further actions are required as a result of the security failure.

• Implementing controls to prevent the cause of failure from reoccurring.

• Resuming monitoring of security controls.

Added p. 264

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.

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

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

Added p. 266

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.1.1 Examine documentation and interview personnel to verify that security policies and operational procedures are managed in accordance with all elements specified in this requirement.

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,

• All authorized and unauthorized wireless access points are detected and identified,

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

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

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.

Added p. 269

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

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.

11.2.1.d If automated monitoring is used, examine configuration settings to verify the configuration will generate alerts to notify personnel.

Added p. 270

PCI DSS Requirement 11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.2.2 Examine documentation to verify that an inventory of authorized wireless access points is maintained, and a business justification is documented for all authorized wireless access points.

PCI DSS Requirement 11.3.1 Internal vulnerability scans are performed as follows:

• At least once every three months.

• Vulnerabilities that are either high-risk or critical (according to the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

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

• Scans are performed by qualified personnel and organizational independence of the tester exists.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.3.1.a Examine internal scan report results from the last 12 months to verify that internal …

Added p. 272

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

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.

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.

Added p. 273

PCI DSS Requirement 11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:

• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

Added p. 273

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.3.1.1.a Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.

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.

Added p. 275

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

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

11.3.1.2.b Examine scan report results and interview personnel to verify that authenticated scans are performed.

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

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.

11.3.1.2.d Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined.

Added p. 276

• Vulnerabilities that are either high-risk or critical (according to the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

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

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.3.1.3.a Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes.

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

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 all high-risk vulnerabilities and all critical vulnerabilities (defined in Requirement 6.3.1) were resolved.

Identify the evidence reference number(s) from Section 6 for all internal scan and rescan reports examined for …

Added p. 278

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

• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.3.2.a Examine ASV scan reports from the last 12 months to verify that external vulnerability scans occurred at least once every three months in the most recent 12-month period.

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

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

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 …

Added p. 281

PCI DSS Requirement 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity and includes:

• Industry-accepted penetration testing approaches.

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

• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.

• Network-layer penetration tests that encompass all components that support network functions as well as operating systems.

• Review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.

• Retention of penetration testing results and remediation activities results for at least 12 months.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.4.1 Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes …

Added p. 282

PCI DSS Requirement 11.4.2 Internal penetration testing is performed:

• Per the entity's defined methodology

• At least once every 12 months

• After any significant infrastructure or application upgrade or change

• By a qualified internal resource or qualified external third-party

Added p. 282

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.

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

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

• Per the entity's defined methodology

• 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

Added p. 284

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

Identify the evidence reference number(s) from Section 6 for the results from the most recent external penetration test examined for this testing procedure.

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

Added p. 285

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.

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:

• At least once every 12 months and after any changes to segmentation controls/methods

• Covering all segmentation controls/methods in use

• According to the entity's defined penetration testing methodology

• Confirming that the segmentation controls/methods are operational …

Added p. 288

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

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

Added p. 289

PCI DSS Requirement 11.4.7 Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.4.7 Additional testing procedure for multi-tenant providers only: Examine evidence to verify that multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

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

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.

• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.5.1.a Examine system configurations and network diagrams to verify …

Added p. 291

11.5.1.c Examine system configurations and vendor documentation to verify intrusion- detection and/or intrusion- prevention techniques are configured to keep all engines, baselines, and signatures up to date.

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.

Added p. 292

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 number(s) from Section 6 for the entity’s incident-response plan examined for this testing procedure.

11.5.1.1.c Additional testing procedure for service provider assessments only: Interview responsible personnel and observe processes to verify that personnel maintain knowledge of covert malware communication and control techniques and are knowledgeable about how to respond when malware is suspected.

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

Added p. 293

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

PCI DSS Requirement 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:

• To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.

• To perform critical file comparisons at least once weekly.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 11.5.2.a Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism.

11.5.2.b Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement.

Identify the evidence reference number(s) from Section 6 for all settings for the change-detection mechanism examined for this testing procedure.

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

PCI DSS Requirement 11.6.1 A change- and tamper-detection …

Added p. 295

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

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

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.

11.6.1.d Examine configuration settings and interview personnel to verify the mechanism functions are performed either:

• At least once weekly OR

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

Added p. 296

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.

PCI DSS Requirement 12.1.1 An overall information security policy is:

• Disseminated to all relevant personnel, as well as to relevant vendors and business partners.

Assessment Findings (select one) Select If Below Method(s) Was Used In Place Not Applicable Not Tested Not in Place Compensating Control* Customized Approach* ☐ ☐ ☐ ☐ ☐ ☐ 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. *As applicable, complete and attach the corresponding documentation (Appendix C, Appendix E, or both) to support the method(s) used.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.1.1 Examine the information security policy and interview personnel to …

Added p. 297

PCI DSS Requirement 12.1.2 The information security policy is:

• Reviewed at least once every 12 months.

• Updated as needed to reflect changes to business objectives or risks to the environment.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.1.2 Examine the information security policy and interview responsible personnel to verify the policy is managed in accordance with all elements specified in this requirement.

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.

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.

12.1.3.b Interview personnel in various roles to verify they understand their information security responsibilities.

12.1.3.c Examine documented evidence …

Added p. 301

PCI DSS Requirement 12.3.1 For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis 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 the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact 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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses …

Added p. 302

PCI DSS Requirement 12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include:

• Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis).

• Approval of documented evidence by senior management.

• Performance of the targeted analysis of risk at least once every 12 months.

Assessment Findings (select one) Select If Below Method(s) Was Used In Place Not Applicable Not Tested Not in Place Compensating Control* Customized Approach* ☐ ☐ ☐ ☐ ☐ N/A Describe why the assessment finding was selected.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.3.2 Examine the documented targeted risk-analysis for each PCI DSS requirement that the entity meets with the customized approach to verify that documentation for each requirement exists and is in accordance with all elements specified in this requirement.

PCI DSS Requirement 12.3.3 Cryptographic …

Added p. 306

PCI DSS Requirement 12.4.2 Additional requirement for service providers only: Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks:

• Configuration reviews for network security controls.

• Applying configuration standards to new systems.

• Responding to security alerts.

• Change-management processes.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.4.2.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined for conducting reviews to confirm that personnel are performing their tasks in accordance with all security policies and all operational procedures, including but not limited to the tasks specified in this requirement.

• By personnel other than those responsible for performing the given task.

Identify the evidence reference …

Added p. 308

PCI DSS Requirement 12.4.2.1 Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented to include:

• Results of the reviews.

• Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.4.2.1 Additional testing procedure for service provider assessments only: Examine documentation from the reviews conducted in accordance with PCI DSS Requirement 12.4.2 to verify the documentation includes all elements specified in this requirement.

PCI DSS Requirement 12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.5.1.a Examine the inventory to verify it includes all in-scope system components and a description of function/use for each.

Identify the evidence …

Added p. 310

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 security of the CDE.

• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.

• …

Added p. 312

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.3 Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.5.3.a Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined such that a significant change to organizational structure results in documented review of the impact to PCI DSS scope and applicability of controls.

Added p. 314

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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.6.1 Examine the security awareness program to verify it provides awareness to all personnel about the entity’s information security policy and procedures, and personnel’s role in protecting the cardholder data.

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

Added p. 315

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 cardholder data and/or sensitive authentication data, or the information provided to personnel about their role in protecting cardholder data.

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.

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

PCI DSS Requirement 12.6.3 Personnel receive security awareness training as follows:

• Upon hire and at least once every 12 months.

• Multiple methods of communication are used.

• …

Added p. 318

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

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.

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.

Added p. 319

PCI DSS Requirement 12.7.1 Potential personnel who will have access to the CDE are screened, within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.7.1 Interview responsible Human Resource department management to verify that screening is conducted, within the constraints of local laws, prior to hiring potential personnel who will have access to the CDE.

Added p. 320

PCI DSS Requirement 12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.8.1.a Examine policies and procedures to verify that processes are defined to maintain a list of TPSPs, including a description for each of the services provided, for all TPSPs with whom account data is shared or that could affect the security of account data.

12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided.

Added p. 321

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 TPSPs 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 the TPSP could impact the security of the entity's cardholder data and/or sensitive authentication data.

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.

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

PCI DSS Requirement 12.9.2 Additional requirement for service providers only: TPSPs support their customers' requests for information to meet Requirements 12.8.4 and 12.8.5 by providing the following upon customer request:

• PCI DSS compliance status information (Requirement 12.8.4).

• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement 12.8.5), for any service the TPSP provides that meets a PCI DSS requirement(s) on behalf of customers or that can impact security of customers’ cardholder data and/or sensitive authentication data.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.9.2 Additional testing procedure for service provider assessments only: Examine policies and procedures to verify processes are defined for the TPSPs to support customers’ request for information to meet Requirements 12.8.4 and 12.8.5 in accordance with all elements specified in this requirement.

PCI DSS Requirement 12.10.1 An incident response plan exists and …

Added p. 328

PCI DSS Requirement 12.10.2 At least once every 12 months, the security incident response plan is:

• Reviewed and the content is updated as needed.

• Tested, including all elements listed in Requirement 12.10.1.

Added p. 329

• Tested, including all elements listed in Requirement 12.10.1.

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

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response 12.10.3 Examine documentation and interview responsible personnel occupying designated roles to verify that specific personnel are designated to be available on a 24/7 basis to respond to security incidents.

Added p. 330

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.

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.

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 with all elements specified in Requirement 12.3.1.

12.10.4.1.b Examine documented results of periodic training of incident response personnel and interview personnel to verify training is performed at the frequency defined in the entity’s targeted …

Added p. 336

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.

Added p. 337

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

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

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.

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.

Added p. 339

Identify the evidence reference number(s) from Section 6 for the results from the most recent penetration test 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.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.1.4 Examine the results from the most recent penetration test to verify that testing confirmed the effectiveness of logical separation controls used to separate customer environments.

PCI DSS Requirement A1.2.1 Audit log capability is enabled for each customer's environment that is consistent with PCI DSS Requirement 10, including:

• Logs are enabled for common third-party applications.

• Logs are active by default.

• Logs are available for review only by the owning customer.

• Log locations are clearly communicated to the owning customer.

• Log data and availability is consistent with PCI DSS Requirement 10.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response …

Added p. 341

PCI DSS Requirement A1.2.2 Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer.

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A1.2.2 Examine documented procedures to verify that the provider has processes or mechanisms to support and/or facilitate a prompt forensic investigation of related servers in the event of a suspected or confirmed security incident for any customer.

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

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 …

Added p. 343

Testing Procedures Reporting Instructions Reporting Details: Assessor’s Response A2.1.1 For POS POI terminals using SSL and/or early TLS, confirm the entity has documentation (for example, vendor documentation, system/network configuration details) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

Added p. 344

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:

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

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

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 …

Added p. 347

Compensating controls must satisfy the following criteria:

1. Meet the intent and rigor of the original PCI DSS requirement.

2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. 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.

3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

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 …

Added p. 348

5. Address the additional risk imposed by not adhering to the PCI DSS requirement.

6. Address the requirement currently and in the future. A compensating control cannot address a requirement that was missed in the past (for example, where the performance of a task was required two quarters ago, but that task was not performed).

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.

To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete. Additionally, compensating control results must be documented in the applicable report for the assessment (for example, a Report on Compliance or a Self-Assessment Questionnaire) in the corresponding PCI DSS requirement section, and included when the applicable report is …

Added p. 350

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 PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website.

 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 PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website.

 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 of customized controls must …

Added p. 351

Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach; however, these entities may elect to have a QSA or ISA perform their assessment and document it in a ROC Template.

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

Requirement Number and Definition:

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) 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) Describe how the control(s) meet the Customized Approach Objective.

Identify the Controls Matrix documentation reviewed that supports a customized approach for this requirement.

Identify the Targeted Risk Analysis documentation reviewed that supports the customized approach for this requirement.

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 PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website, and the results of the Controls Matrix support the customized approach for this requirement.

• The entity …

Added p. 353

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.

Enter assessor-derived testing procedure here:

Identify what was tested (for example, individuals interviewed, system components reviewed, processes observed, etc.)

Note: all items tested must be uniquely identified.

Identify all evidence examined for this testing procedure.

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.

Added p. 354

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.

Enter assessor-derived testing procedure here:

Identify what was tested (for example, individuals interviewed, system components reviewed, processes observed, etc.)

Note: all items tested must be uniquely identified.

Identify all evidence examined for this testing procedure.

Describe the results of the testing performed by the assessor for this testing procedure and how these results verify the implemented controls are maintained to ensure ongoing effectiveness.

Modified p. 1 → 2

~~PCI DSS ROC Template~~ Summary of Changes from ROC Template v4.0 to v4.0.1

• Summary of Changes from ROC Template v4.0 to v4.0.1 for details of changes to the ROC Template.

Removed p. 4

This summary is organized as follows:

 Summary of General Changes to ROC Template - includes descriptions of general changes made throughout.

 Summary of Specific Changes to ROC Template - includes descriptions of changes made for ROC Template Instructions, Part 1 Assessment Overview, and Part II Findings and Observations.

Removed p. 4

Update language throughout to align with PCI DSS v4.0.1 Remove all pre-formatted text input fields.

Removed p. 4

- Method(s) Used Add section to describe how to report the use of a compensating control or the customized approach.

Figure 1 Replace figure to reflect new requirement layout.

What is the Difference between Not Applicable and Not Tested? Clarify that both the ROC and AOC(s) must indicate which if any requirements were Not Applicable or Not Tested (formerly only the AOC(s) were cited).

Removed p. 5

- Remove section and figure to reflect new reporting approach for compensating controls and customized approach.

Do’s and Don’ts: Reporting Expectations Add “Do” section bullets to:

PCI DSS v4.0.1 Report on Compliance Template Clarify that all instructional content from “this page and all preceding pages” may be deleted prior to finalizing the report.

PCI DSS Customizable cover page Update “Assessment End Date” to “Date Assessment Ended” to align with Section 1.2 Date and Timeframe of Assessment.

Part 1 Assessment Overview 1.1 Contact Information Under “Lead Qualified Security Assessor,” update “Assessor PCI credentials and certificate number (QSA, Secure Software Assessor, etc.” to “Assessor certificate number.” Under “Additional Assessors,” update “Assessor PCI credentials" to “Assessor certificate number.” Under “Assessor Quality Assurance Primary Reviewer,” update “QA Reviewer’s PCI Credentials” to “QA Reviewer’s PCI credentials or certificate number.” 1.3 Remote Assessment Activities Add a reference to PCI SSC Remote Assessment Guidelines and Procedures.

Remove Remote Assessment Activities subsections 1.3.2- …

Removed p. 5

- Remove section Optional: Additional Assessor comments.

Removed p. 5

- Remove section Attestation Signatures.

Modified p. 5 → 1

PCI DSS ~~v4.0~~ Report on Compliance Template

PCI DSS v4.0.1 Report on Compliance Template Revision 3

Modified p. 5 → 15

• Provide a completed Appendix C for any ~~requirements~~ met with a compensating control.

• Provide a completed Appendix C Compensating Control Worksheet for any requirement met with a compensating control.

Modified p. 5 → 15

• Provide a completed Appendix E for any ~~requirements~~ met with a customized approach.

• Provide a completed Appendix E Customized Approach Template for any requirement met with a customized approach.

Modified p. 5 → 15

• Read the PCI DSS Applicability Notes and Guidance for each ~~requirement. Update a “Don’t” section bullet to clarify that, before copying responses from one~~ requirement ~~to another,~~ the ~~assessor confirms the response is fully applicable to each requirement.~~

• Read the PCI DSS Applicability Notes and Guidance column for each requirement (in the Standard).

Removed p. 6

Consolidate information about excluded business functions and services into section 3.1.

Update “entity” to “merchant” to clarify that using SAQ eligibility criteria to determine applicability of PCI DSS requirements reported in a ROC is only applicable to merchants.

Removed p. 6

- Remove section In Scope Business Functions.

Removed p. 6

- Move section 6 Sampling (Assessment Workpapers) to Part II (see Part II below for details)

Modified p. 6 → 24

~~Add a section to separate~~ the ~~description of businesses,~~ services, or functions that ~~store~~ process, or transmit account ~~data from those that could impact the security of account~~ data.

Describe the entity’s business, services, or functions that store, process, or transmit account data.

Removed p. 7

Remove column to identify all sub-requirements where the sample set was used.

Removed p. 7

- 7 Findings and Observations Add header for section 7 Findings and Observations to account for move of section 6 into Part II.

Requirement Layout Remove Validation Method- Customized Approach reporting rows and add checkbox to note the use of the customized approach.

Remove Validation Method

• Defined Approach reporting rows and add checkbox to note the use of a compensating control.

Modified p. 7 → 11

~~Add an instruction that any use of a compensating control or the customized approach must include~~ the corresponding documentation to support the method(s) used.

*As applicable, complete and attach the corresponding documentation (Appendix C, Appendix E, or both) to support the method(s) used.

Document Comparison

From Revision History

Content Changes