Payment Card Industry  
Data Security Standard  
 
PCI DSS v4.0 Supplemental Attestation of 
Compliance for Report on Compliance   
Designated Entities  Supplemental Validation  
Revision 1  
Publication Date: December  2022

PCI DSS v4.0 Supplemental AOC for ROC –  Designated Entities Supplemental Validation r1 December  2022  
© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 1 
Section 1  Assessment Information  
Instructions for Submission 
** Complete this Attestation of Compliance only if required by a Payment Brand or Acquirer to 
complete the requirements specified in the PCI DSS v4.0 Appendix A3: Designated Entities 
Supplemental Validation ** 
This Supplemental Attestation of Compliance (S-AOC)  must be completed as a declaration of the results of the 
Designated E ntity’s  assessment with PCI DSS v4.0 Appendix A3:  PCI DSS Designated Entities  Supplemental 
Validation  (DESV).  The S-AOC is an addendum to the PCI DSS Attestation of Compliance (AOC)  and is not intended 
to stand alone. Because of this, details about the environment reviewed for the S -AOC must be included in Part 2:

to stand alone. Because of this, details about the environment reviewed for the S -AOC must be included in Part 2: 
Executive Summary of the AOC for that entity. T he Designated Entity is responsible for ensuring that all section s, in 
both the S -AOC and the AOC , are completed by the relevant parties, as applicable. Contact the entit y(ies) to which 
this S-AOC will be submitted for  reporting and submission procedures . 
Part 1. Contact Information  
Part 1a. Assessed Entity  
(ROC Section 1.1)  
Company name:        
DBA (doing business as):        
Company mailing address:        
Company  main website :       
Company contact name :

Company contact name :       
Company contact title:        
Contact phone number:        
Contact e -mail address:        
Part 1b. Assessor  
(ROC Section 1.1) 
Provide the following information for all assessors involved in the Assessment. If there was no assessor for a 
given assessor type , enter  Not Applicable.  
PCI SSC Internal Security Assessor(s)  
ISA name (s):       
Qualified Security Assessor   
Company website:        
Lead Assessor name:        
Assessor phone number:        
Assessor e -mail address:        
Assessor certificate number:

Assessor certificate number:        
Note: Section titles and numbers correspond to similar sections within the PCI DSS Attestation of 
Compliance (AOC). Section numbering was kept intact for clarification purposes.

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 2 
Part 2g. Summary of Assessment   
(S-ROC Summary of  DESV Results ) 
Indicate below all responses provided within each principal DESV requirement .  
DESV 
Requirement  Requirement Finding  
More than one response may be selected for a given requirement. 
Indicate all responses that apply.  Select If Below 
Method Was Used  
In Place  Not Applicable  Not In Place Compensating 
Controls  
Requirement 
A3.1      
A3.2      
A3.3      
A3.4      
A3.5

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 3 
Section 2  Supplemental Report on Compliance  
This Supplemental Attestation of Compliance reflects the results of an assessment  that is documented in 
an accompanying Supplemental Report on Compliance S -ROC for Designated Entities . 
The assessment documented in this attestation and in the S -ROC for Designated 
Entities was completed on:  YYYY- MM-DD 
Were any requirements in the S -ROC  for Designated Entities  unable to be met 
due to a legal constraint?   Yes     No 
Were any testing activities performed remotely?  
If yes, for each testing activity below, indicate whether remote assessment 
activities were performed:    Yes     No 
• Examine documentation                  Yes  No 
• Interview personnel                           Yes  No 
• Examine/observe  live data   Yes  No

• Examine/observe  live data   Yes  No 
• Observe process being performed   Yes  No 
• Observe physical environment          Yes  No 
• Interactive testing                             Yes  No 
• Other:        Yes  No

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 4 
Section 3  Validation and Attestation Details  
Part 3. PCI DSS Designated Entities Supplemental Validation  
This S -AOC is based on results noted in the S-ROC dated (S-ROC completion date YYYY -MM-DD). 
 
Based on the results documented in the S-ROC  for Designated Entities  noted above,  each signator y 
identified in any of Parts 3b-3d, as applicable, assert(s) the following compliance status for the entity 
identified in Part 2  of this document (select  one): 
 Compliant:  All sections of the S-ROC  for Designated Entities  are complete, and all requirements are 
marked as being either In Place or Not Applicable,  resulting in an overall COMPLIANT  rating; thereby 
(Designated Entity Company Name)  has demonstrated compliance with all PCI DSS Designated 
Entities  Supplemental Validation requirements .

Entities  Supplemental Validation requirements . 
 Non- Compliant: Not all sections of the S-ROC  for Designated Entities  are complete, or one or more 
requirements are marked as Not in Place, resulting in an overall NON -COMPLIANT  rating, thereby 
(Designated Entity Company Name)  has not demonstrated compliance with PCI DSS Designated 
Target Date for Compliance: YYYY- MM-DD 
An entity submitting this form with a status of Non- Compliant status may be required to complete the

Non- Compliant: Not all sections of the S-ROC  for Designated Entities  are complete, or one or more 
An entity submitting this form with a status of Non- Compliant status may be required to complete the 
Action Plan in Part 4 of this document. Confirm  with the entity  to which this S -AOC will be submitted 
before completing Part 4.  
 Compliant but with Legal exception:  One or more requirements of the S -ROC  for Designated Entities 
are marked “Not in Place” due to a legal restriction that prevents the requirement from being met  and all 
other requirements are marked as being either In Place or Not Applicable, resulting in an overall 
COMPLIANT BUT WITH LEGAL EXCEPTION rating; thereby  has demonstrated compliance with all

COMPLIANT BUT WITH LEGAL EXCEPTION rating; thereby  has demonstrated compliance with all 
PCI DSS Designated Entit ies Supplemental Validation requirem ents except those noted as Not in Place 
due to a legal restriction.  
This option requires additional review from the entity to which this S -AOC  will be submitted. If selected, 
complete the following:  
 Affected Requirement  Details of how legal constraint prevents requirement from 
being met

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 5 
Part 3a. Designated Entit y Acknowledgement  
Signatory(s) confirms:  
(Select  all that apply)  
 The S -ROC  for Designated Entities  was completed according to PCI DSS Version 4.0  Appendix A3: 
Designated Entities  Supplemental Validation and was completed according to the instructions 
therein.  
 All information within the above- referenced S -ROC  for Designated Entities  and in this attestation 
fairly represents the results of  the assessment in all material respects.  
 PCI DSS Appendix A3: Designated Entities Supplemental Validation ( DESV)  controls will be 
maintained at all times,  as applicable to the entity’s  environment.  
 
Part 3b. Designated Entity  Attestation  
 
Signature of Designated Entity  Executive Officer  Date:        
Designated Entity Executive Officer Name:        Title:

Designated Entity Executive Officer Name:        Title:        
 
Part 3c. Qualified Security Assessor (QSA)  Acknowledgement  
If a QSA was involved or assisted with this 
Assessment, indicate the role performed:   QSA performed testing procedures.  
 QSA provided other assistance.  
If selected, describe all role(s) performed:       
 
Signature of Lead QSA  Date: YYYY -MM-DD 
Lead QSA Name:       
 
Signature of Duly Authorized Officer of QSA Company  Date:  YYYY -MM-DD 
Duly Authorized Officer Name:       QSA Company:       
 
Part 3d. Internal Security Assessor (ISA)  Involvement  
If an ISA(s) was involved or assisted with this

If an ISA(s) was involved or assisted with this 
Assessment , indicate the role performed:   ISA(s) performed testing procedures.  
  ISA(s) provided other assistance.  
If selected, describe all role(s) performed:

© 2006-2022 PCI Security Standards Council, LLC. All Rights Reserved.  Page 6 
Part 4. Action Plan for Non- Compliant Requirements  
Only complete Part 4 upon request of the entity to which this S -AOC will be submitted, and only if the 
Assessment has Non- Compliant results noted in Section 3.  
If asked to complete this section, select the appropriate response for “Compliant to DESV 
Requirements” for each requirement below. For any “No” responses, include the date the entity expects 
to be compliant with the requirement and provide a brief description of the actions being taken to meet 
the requirement.  
DESV 
Requirement  Description of Requirement  Compliant to DESV 
Requirements  
(Select One)  Remediation Date and Actions  
(If “NO”  selected for any 
Requirement ) 
YES NO 
A3.1 PCI DSS compliance program is 
implemented.          
A3.2 PCI DSS scope is documented and 
validated.

DESV 
YES NO 
validated.          
A3.3 PCI DSS is incorporated into business -as-usual (BAU) activities.          
A3.4 Logical access to the cardholder 
data environment is controlled and managed.          
A3.5 Suspicious events are identified and responded to.

Data Security Standard 
PCI DSS v4.x Report on Compliance Template - 
Frequently Asked Questions  
Revision 1  
December 2022

PCI DSS v4. x ROC Template – Frequently Asked Questions  r1  December  2022  
©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 1 
Purpose of document  
This document addresses questions around the use of the Report on Compliance ( ROC)  Template for PCI DSS v4. x.  
1. Overview of PCI DSS v4. x Reporting 
1.  What has changed in the PCI DSS v4. x ROC Template?  
 
ROC Section  Description of Change  
Throughout  Updates to reflect changes in PCI DSS v4.x  
Updates to improve clarity and reduce redundancy  
Separated the ROC into three parts:  
• ROC Template Instructions –  instructional content that is used to complete the ROC. This part can 
optionally be deleted prior to releasing the final report  
• Part I: Assessment Overview  
• Part II: Findings and Observations  and Appendices  
In parts I and II  minor modifications are allowed, such as increasing/decreasing the number of rows or to 
change the column width; however, deletion of content is not allowed.

change the column width; however, deletion of content is not allowed.  
Use of reference numbers in the Summary Overview/ Findings and Observations is no longer optional. There is 
also the option to identify items in the response in the Findings and Observations section in addition to the 
reference number . 
Updated Summary of Assessment Findings (aligns with new checkboxes w ithin the Findings and 
Observations)  
• Added “In Place with Remediation”  
• Deleted “In Place w/ CCW” (instead, reporting for Compensating Controls is captured in the 
“Validation Method” section for each sub- requirement)

“Validation Method” section for each sub- requirement)  
PCI DSS v4.0 ROC Template Revision 1  
• Removed “In Place with Remediation” as a reporting option from the Summary of Assessment Findings .

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 2 
ROC Template Instructions  Added Assessment Findings table indicating when each finding is to be used and what reporting is required  
• Removed “In Place with Remediation” as an  Assessment Finding.  
Added Instructions for Assessment Approach Reporting Options  
Aligned the Reporting Instruction Terms for consistency with other PCI standards : 
• Indicate  
• Identify  
• Describe  
• Attest  
Part I: Assessment Overview  Added a customizable title page 
Updated the Overall Assessment Results to align with the AOC  
• Full/Partial Assessment  
1. Indicate whether a Full Assessment or a Partial Assessment was completed.  
• Overall Assessment Result  descriptions  (Same three options exist in the AOC of PCI DSS v3.2.1)  
1. Compliant  
2. Compliant but with Legal Exception

• Indicate  
• Identify  
• Describe  
• Attest  
2. Compliant but with Legal Exception 
3. Non- Compliant  
• Removed “In Place with Remediation” from Overall Assessment Results.  
Added following sections:  
• Remote Assessment Activities  
• Use of Subcontractors  
• Additional Information/ Reporting 
• Overall Assessment Result  
• Attestation Signatures  
• Storage of SAD  
• Quarterly Internal S can R esults  
Added Section 6 Evidence (Assessment Workpapers)  
• Added a column for assessor documentation to tables 6.3 and 6.4.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 3 
Removed sections including:  
• PCI DSS version  
• Connected entities for payment processing and transmission  
• Other business entities that require compliance with the PCI DSS  
• Wireless summary  
• Managed service providers  
Updated, merged, and/or moved sections to reduce redundancy, add clarity, and/or improve readabil ity 
Part II: Findings and Observations  Reporting updated to facilitate reporting for defined approach, customized approach, or a combination of the 
two 
Updated the reporting to focus more on referencing evidence for the defined approach  
Added a narrative for each requirement to explain why the assessment finding was selected. Specific 
instructions for each assessment finding are found in the “Required Reporting” column in the Assessment Findings section in ROC Template Instructions

two 
instructions for each assessment finding are found in the “Required Reporting” column in the Assessment Findings section in ROC Template Instructions  
• Removed “In Place with Remediation” as a reporting option from each r equirement in Part II: Findings 
and Observations.  
Appendices  Minor updates to Compensating Controls Worksheet  
• Clarified instructions at the start of Appendix C . 
Addition of Customized Approach Template  
• Clarified instructions at the start of Appendix D .

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 4 
1.2 What are the options for implementing and validating requirements?  
PCI DSS v4. x includes the following options for implementing and validating PCI DSS requirements:  
ASSESSMENT APPROACH  WHEN TO USE THIS APPROACH  
Customized Approach  
(New option)  Focuses on the Customized Approach Objective of each PCI DSS Requirement  (if applicable) , allowing entities to implement 
controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined 
requirement. The customized approach supports innovation in security practices, allowing entities greater flexibility to show 
how their current security controls meet PCI DSS requirements.  
Refer to the PCI DSS Requirements and Testing Procedures v4.0 for the Customized Approach Objectives , included with 
each applicable requirement .

each applicable requirement . 
Note:  Compensating Controls are not an option for the Customized Approach  
Defined Approach  
(Existing approach)  The traditional method for implementing and validating PCI DSS and uses the Requirements and Testing Procedures 
defined within the standard. The entity implements security controls to meet the stated requirements, and the assessor 
follows the defined testing procedures to verify that the requirement has been met.  
Note on using Compensating Control(s) : As part of the defined approach, entities that cannot meet a PCI DSS

Note on using Compensating Control(s) : As part of the defined approach, entities that cannot meet a PCI DSS 
requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other or 
compensating controls that sufficiently mitigate the risk associated with the requirem ent. On an annual basis, any 
compensating controls must be documented by the entity and reviewed and validated by the assessor and included with the 
Report on Compliance submission.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 5 
 
2. New ROC Reporting Features for PCI DSS v4. x 
2.1 What is the purpose of  Section 1. 7: Overall Assessment Result?  
Overall Assessment Result  is a new ROC section to provide the overall status of a PCI DSS assessment, based on findings noted in the 
Assessment Findings  for each PCI DSS requirement. The Overall Assessment Result  table below is excerpted from the PCI DSS v4. x ROC 
Template:

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 6 
 
2.2 In Part II: Findings and Observations, what is the purpose of the Assessment Findings columns?  
The Assessment Findings  columns categorize the results of the assessment for each individual PCI DSS requirement.  
These results are summarized in new Section 1. 8 Summary of Assessment . 
Here is an excerpt from Part II: Findings and Observations  that shows the headings and reporting options:

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 7 
2.3 What is the difference between the Overall Assessment Result in Section 1. 7 and the Assessment Findings in 
Part II: Findings and Observations?  
The Overall Assessment Result  in Section 1. 7 of the ROC is a cumulative summary of all assessment findings, and is one of the following:  
Overall Assessment Result  
• Compliant  
• Compliant but with Legal Exception  
• Non-Compliant  
The Assessment Findings in Part II shows the results for each individual PCI DSS requirement, and is one of the following:  
Assessment Findings  
• In Place  
• Not Applicable  
• Not Tested  
• Not in Place  
 
2.4 What is the purpose of section 1.9 Attestation  Signatures ? 
The attestation signatures section is intended to emphasize to the assessor the importance of conducting an independent, fact-based assessment

• In Place  
 
The attestation signatures section is intended to emphasize to the assessor the importance of conducting an independent, fact-based assessment 
that is complete and accurate to the best of the assessor’s knowledge and to capture such acknowledgement by the assessor for PCI SSC quality 
assurance purposes . This s ection does not change the intended audience or distribution methods for the ROC.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 8 
3. New ROC Reporting Options for PCI DSS v4. x Explained 
3.1 Why have  Full Assessment and Partial Assessment been added  to the ROC Template ?  
These reporting options  have been added to provide better transparency in reporting. When an entity undergoes a Full Assessment , all PCI DSS 
requirements have been considered and no r equirements are marked as Not Tested. When an entity undergoes a Partial Assessment , only a 
subset of PCI DSS requirements has  been considered and one or more requirements are marked as Not Tested. Refer to question 4 .2 below 
“What is the difference between Not Applicable and Not Tested?”  for more information.   
4. Assessment Findings  
4.1 When determining which  one of the  summary findings  is appropriate for a sub- requirement, is there any more

4.1 When determining which  one of the  summary findings  is appropriate for a sub- requirement, is there any more 
guidance available on those options beyond what is in the “Introduction to the ROC Template” section of the 
ROC Template for PCI DSS v 4.x?  
The following table is a supplement  to the explanation provided within the ROC Template for PCI DSS v 4.x. Only one response should be selected 
at the sub- requirement.  
 
Response  When to use this response:  
In Place  The expected testing has been performed, and all elements of the requirement have been met.

In Place  The expected testing has been performed, and all elements of the requirement have been met.  
Not Applicable  (N/A)  The requirement does not apply to the organization’s environment.  
Not Applicable responses require reporting on testing performed to confirm the Not Applicable status including a detailed 
description explaining how it was determined that the requirement does not apply.  
Note that reporting instructions that start with “If Yes” or “If No” do not require additional testing to confirm the Not App licable

Note that reporting instructions that start with “If Yes” or “If No” do not require additional testing to confirm the Not App licable 
status. For example, if the Reporting Instruction was “If Yes, complete the following” and the response was  “No” then the assessor 
would simply mark that section as Not Applicable or N/A and no further testing is required.  
Not Tested  The requirement (or any single aspect of the requirement) was not included for consideration in the assessment and was not 
teste d in any way.  
(See “What is the difference between “Not Applicable” and “Not Tested”?” below at 4.2 for examples of when this option should be 
used.)

used.)  
Note : Where Not Tested is used, the assessment is considered a Partial 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.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 9 
This response is also used if a requirement cannot be met due to a legal restriction, me aning 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 pr ohibits 
the requirement from being met.  
Note:  Contractual obligations or legal advice are not legal restrictions . 
 
4.2 What is the difference between “Not Applicable” and “Not Tested?”  
Requirements that are Not Applicable to an environment must be verified as such. Using the example of wireless and an organiz ation that does 
not use wireless technology in any capacity, an assessor could select Not Applicable for Requirements 1.3.3, 2.3.1 -  2.3.3, and 4.2.1.2 after the

not use wireless technology in any capacity, an assessor could select Not Applicable for Requirements 1.3.3, 2.3.1 -  2.3.3, and 4.2.1.2 after the 
assessor confirms through testing that there are no wireless technologies used in the organization’s  CDE or that connect to their CDE. Once this 
has been confirmed, the assessor may select Not Applicable for those specific requirements, and the accompanying reporting must reflect the 
testing performed to confirm the Not Applicable status.  
If a requirement is completely excluded from review without any consideration as to whether it could apply, the Not Tested option must be

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 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 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 only to validate the physical security controls per PCI DSS Requirement 9 for their storag e facility.  
In these scenarios, the organiz ation wants only to validate certain PCI DSS requirements, even though other requirements might also apply to 
their environment. The resulting AOC(s) must be clear in what was tested and not tested.

their environment. The resulting AOC(s) must be clear in what was tested and not tested.  
Items marked as Not Applicable require that the assessor  render an opinion that the item is not applicable; however, with Not Tested, the assessor 
is simply following the entity’s instructions to not test something with no opinion needed from the assessor.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 10 
The example below illustrates the difference between Not Applicable and Not Tested using different scenarios  
 Not Applicable  Not Tested  
Scenario  • A listed PCI SSC Validated P2PE solution 
is in place, and the entity fully meets all 
the eligibility criteria defined in SAQ P2PE  
• No C HD in the environment . • A service provider organization offer s a 
service that covers only a limited number of 
PCI DSS requirements -for example, a 
physical storage provider that only wish es 
to validate the physical security controls per 
PCI DSS Requirement 9 for their storage facility.  
• Acquirer  asking for a report on a subset of 
requirements (for example, the prioritized 
approach) .  
Testing  Assessor performs the appropriate testing and 
validation on all requirements. Any PCI DSS 
requirement where testing verifies the non-

applicability of that requirement is marked as 
Not Applicable , which would result in a Full 
Assessment *. 
 
*By definition, no requirements are marked as 
“Not Tested ”. Assessor only validates the physical security 
controls per PCI DSS Requirement 9. The 
remaining requirements are marked as Not 
Tested  which would result in a Partial 
Assessment .

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 11 
 
5. General Questions  
5.1 Is use of the ROC Template for PCI DSS v4 .x mandatory?  
The PCI DSS ROC Template is mandatory for QSAs to use for official reporting  of a PCI DSS assessment . Requirements for ISAs and reporting 
should be discussed with the brands and/or acquirers accepting the  Report on Compliance. For official reporting of a PCI DSS v4.0 assessment 
by a QSA , the ROC Template must be completed, with all response sections completed (even if to note that sections or requirements are not 
applicable).  
5.2 Where can I find the unlocked Microsoft Word version of the ROC Template for PCI DSS v4 .x? 
The most up- to-date unlocked Microsoft Word version of the ROC Template for PCI DSS v4. x is available on the Assessor Portal

The most up- to-date unlocked Microsoft Word version of the ROC Template for PCI DSS v4. x is available on the Assessor Portal 
(www.programs.pcissc.org) for assessors to download. Please b e sure to download a clean copy before each assessment, as there may be 
subsequent changes to the ROC Template for PCI DSS v4. x during the PCI DSS v4 lifecycle.  
Contact your Program Manager directly if you cannot access the Assessor Portal. A PDF version of the ROC Template for PCI DSS v 4.x is 
available on the PCI SSC website for non- assessor inquiries.  
5.3 How should a QSA Company report typos or other errors in the ROC Template for PCI DSS v4.x ?

5.3 How should a QSA Company report typos or other errors in the ROC Template for PCI DSS v4.x ? 
Errors in the ROC Template for PCI DSS v4.x should be repor ted to the Program Manager. Please include all relevant details regarding the error  
such as operating system and word processor used when experiencing the error . 
5.4 Can a QSA company make personalization -type changes to the ROC Template for PCI DSS v4. x and, if so, 
what are the limitations?  
PCI SSC recognizes the need for personalization changes by the QSA to the ROC Template for PCI DSS v4. x, such as the addition of company

PCI SSC recognizes the need for personalization changes by the QSA to the ROC Template for PCI DSS v4. x, such as the addition of company 
logos and addition of legal verbiage. Therefore, a customizable title page has been added to the ROC Template for PCI DSS v4.x . Personalization 
must be limited to the customizable title page and the headers of the remainder of the document. The addition of table rows is perm itted as 
needed throughout the document . The assessor may opt ionally delete ROC Template Instructions  prior to submitting the final report to the

needed throughout the document . The assessor may opt ionally delete ROC Template Instructions  prior to submitting the final report to the 
customer.  The addition of content, such as legal verbiage, is allowed and must be limited to the customizable title page.  
Other changes must be minimal and the format of t he ROC Template for PCI DSS v4. x must remain unchanged. This includes reordering of 
sections, which is NOT allowed. Nothing is permitted to be removed from Part s I and II of the document , including sections or requirements

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 12 
determined to be not applicable. Those sections and/or requirements shall remain in the completed ROC Template with the “ Not Applicable” result 
documented instead.  Edits to the footers are explicitly not allowed.  
The fo llowing changes are permitted : 
• Addition of Company logos and legal verbiage  
• Changes to the customizable title page  
• Changes to the page headers  
• Additions of table rows  
• Removal of ROC Template Instructions  
The following changes are prohibited : 
• Edits to the footers  
• Changes to the format of the ROC Template for PCI DSS  v4.x 
• Reorder ing or removal of sections  or requirements  
• Removal of any content from Parts I and II including reporting instructions  in those sections  
The following should be considered  when making changes:

The following should be considered  when making changes:  
• QSAs must ensure there is reasonable distinction between the content has been added by the QSA and is not part of the published PCI 
SSC document.  
• All additions should be considered carefully,  and such content should be added only to the customizable title page of the document.  
• Accepting entities (Payment Brands and/or Acquirers) may choose not to accept any report that has changes to the ROC Template they 
believe are unacceptable.

believe are unacceptable.  
5.5 Can our company use our reporting tool to generate the report (such as a PDF generated from HTML), 
provided that the look and the content closely follow the original?  
PCI SSC will allow this, but with the understanding that  what your reporting tool produces must include all content from the Reporting Template 
and look just like the PCI SSC Reporting Template. If it cannot do that, do not use the tool and report directly into the Wor d file.

and look just like the PCI SSC Reporting Template. If it cannot do that, do not use the tool and report directly into the Wor d file.  
5.6 Do ROCs and ROVs need to be com piled only in English or may they be produced in the local language? 
There is not a PCI SSC requirement that the ROC be compiled in English; however, the QSA will be required to translate to Eng lish at their own 
expense if PCI SSC requests reports, work pa pers, etc. at any point. Check with the accepting brands/acquirers as to their language 
requirements.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 13 
5.7 Will PCI SSC be translating the PCI DSS v4.x ROC Template into other languages ? May I translate the 
document myself? 
PCI SSC only provides  the PCI DSS v4.x ROC Template in  English. However, it is recognized that not all work is done in English and that 
translations may be necessary. If a QSA translates this document, PCI SSC requires the following:  
• QSA must provide both PCI SSC's English version and QSA’s translated version to customers/end- users, noting that the English version 
from PCI SSC governs in the event of any conflict.  
• After the table of contents at the beginning of the document, the following disclaimer must be included in both in Engli sh and the translated 
language: "Note – This document (the "Translation") is an unofficial, <<final language>> language translation of the original English

language: "Note – This document (the "Translation") is an unofficial, <<final language>> language translation of the original English 
language version provided herewith ("Official Version"). The Translation has been prepared by <<QSA C ompany>>, and PCI SSC has not 
had any involvement in and does not endorse the Translation. <QSA Company> hereby certifies that it has made all attempts to ensure 
that the Translation accurately, completely, and truly reflects the Official Version in form a nd substance. <<QSA Company>> is and shall 
be solely responsible for any and all liability resulting from any error in translation or inconsistency between the Official  Version and the

be solely responsible for any and all liability resulting from any error in translation or inconsistency between the Official  Version and the 
Translation."  
5.8 Have requirements for work papers and retention of wo rk papers changed?  
Requirements for work papers and retention of work papers have not changed; however, please review the current version of QSA Program Guide 
for expectations regarding evidence. Assessors are expected to collect evidence to support the c ontents of the ROC from end- to-end. As 
explained in the “ROC Template Instructions” section of the ROC Template for PCI DSS v4. x, work papers contain comprehensive records of the

explained in the “ROC Template Instructions” section of the ROC Template for PCI DSS v4. x, work papers contain comprehensive records of the 
assessment activities including observations, results of system testing, conf iguration data, file lists, interview notes, documentation excerpts, 
references, screenshots, and other evidence collected during the course of the assessment to support the assessor’s findings.  
5.9 When a QSA company is audited, are the audit s conducted using reports from only the most recent 
standard?

standard?   
Any audits will continue to employ a sampling of completed reports, which could include v3.2.1 and v4. x reporting. It is important to continue to 
strive for quality reporting when assessing against either  standard, and the expectations around 3.2.1 have not changed. Assessors should be 
prepared to be audited for any work they’ve completed, including reporting, work papers, and similar. The company will receiv e feedback no 
matter what version of reporting is used.  
5.10 Are requirements noted as best practice until 31 March 2025 considered “Not Applicable” or “Not Tested”?

5.10 Are requirements noted as best practice until 31 March 2025 considered “Not Applicable” or “Not Tested”? 
Requirements noted as best practices  until 31 March 2025 are not required to be tested until that  date has passed. As such, a “Not Applicable” 
response to future- dated requirements is accurate.

©2006 - 2022 PCI Security Standards Council, LLC. All Rights Reserved.   Page 14 
Once the future date has passed, responses to those requirements should be consistent with instructions for all requirements.  
Note – Requirements that are future- dated are considered as best practices until the future date is reached. During this time, organizations are not 
required to validate to future- dated requirements. While validation is not required, organizations that  have implemented controls to meet the new 
requirements and are ready to have the controls assessed prior to the stated future date are encouraged to do so. Once the designated future 
date is reached, all future- dated requirements become effective and appl icable.  
6. Cardholder data storage  
6.1 My client feels that inclusion of  the cardholder data storage table in the completed ROC  puts too much

6.1 My client feels that inclusion of  the cardholder data storage table in the completed ROC  puts too much 
sensitive data into one document. How can I address their concerns, but complete the ROC Template 
appropriately?  
In this case, it may make sense to put a document reference in the ROC Template at 4.3 for the QSA to attest that the cardhol der data storage 
has been d ocumented according to 4.3 and identify where in the work papers it can be found. PCI SSC reserves the right to request any w ork 
papers, and may request this to ensure that the required details are recorded. Like all work papers, this would need to be reta ined by the QSA 
pursuant to the QSA Agreement.  
7. AOC

7. AOC 
7.1 Regarding the AOC for S ervice Providers,  v4.x, are you planning to issue definitions for the services listed or 
similar guidance?  
PCI SSC does not plan to provide formal definitions for these services. As noted in Part 2 of the AOC for Service Providers, v 4.x: “Note: These 
categories are provided for assistance only and are not intended to limit or predetermine an entity’s service description. If  you feel these

7. AOC 
categories are provided for assistance only and are not intended to limit or predetermine an entity’s service description. If  you feel these 
categories don’t apply to your service, complete “Others.” If you’re unsure whether a category could apply to your service, consult with the applicable payment brand.”

This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
PCI DSS v4.0 Quick Reference Guide
Understanding the Payment Card Industry 
Data Security Standard version 4.0
For merchants and other entities involved in payment account data processing
Contents

PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard 
version 4.0.
Copyright 2009-2022 PCI Security Standards Council, LLC. All Rights Reserved. 
This Quick Reference Guide to the PCI Data Security Standard (PCI DSS) is provided by the PCI Security 
Standards Council (PCI SSC) to inform and educate merchants and other entities involved in payment 
card processing. For more information about the PCI SSC and the standards we manage, please visit 
https://pcisecuritystandards.org.
The intent of this document is to provide supplemental information, which does not replace or supersede 
PCI Standards or their supporting documents.
August 2022

3
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Contents
Importance of Protecting Payment Account Data with the PCI Data Security Standard ....... 4
Overview of PCI SSC Standards ............................................................................................ 6
Introduction to PCI DSS ......................................................................................................... 8
PCI DSS Applicability Information  ................................................................................................... 9
The Role of PCI SSC and Participating Payment Brands .............................................................. 11
Professionals to Assist with PCI DSS Assessments ....................................................................... 11
Reporting Results of PCI DSS Assessments ................................................................................... 12

Choosing a Qualified Security Assessor ........................................................................................ 13
Choosing an Approved Scanning Vendor .................................................................................... 14
The PCI DSS Assessment Process ................................................................................................... 14

Scope of PCI DSS Requirements .................................................................................................... 15
Use of Third-Party Service Providers (TPSP) ................................................................................... 16
Implementing PCI DSS into BAU Processes .................................................................................. 18
Understanding PCI DSS v4.0 ............................................................................................... 20
Approaches for Implementing and Validating PCI DSS .............................................................. 20

Understanding the Layout and Content in PCI DSS Requirements ........................................... 23
Summary of PCI DSS v4.0 Requirements 1–12 ............................................................................. 23
Resources ............................................................................................................................ 35
About the PCI Security Standards Council .......................................................................... 37
Importance of 
PCI DSS

4
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Importance of Protecting Payment Account Data with the 
PCI Data Security Standard
The global acceleration of cashless transactions puts payment systems in the crosshairs of criminals 
looking for easy money. Payment account data is their Number One attraction – 84 percent of data breach 
caseloads entailed payment card data, according to Verizon. They all seek the simplest path to steal 
payment account data used by payment cards and related electronic payment systems.
As a payment system stakeholder, your company is on the front line of a high-stakes battle for keeping 
payment data safe from theft and exploitation. Occasional lax security enables criminals to easily steal and 
use personal consumer financial information from payment transactions and processing systems.
Vulnerabilities may appear anywhere in the card-processing ecosystem, including but not limited to:

• point-of-sale devices;
• cloud-based systems;
• mobile devices, personal computers, or servers;
• wireless hotspots;
• web shopping applications;
• paper-based storage systems;
• the transmission of cardholder data to service providers;
• remote access connections.
Vulnerabilities may also extend to systems operated by service providers and acquirers, which are the 
financial institutions that initiate and maintain the relationships with merchants that accept payment cards 
(see diagram on page 5).

Compliance with PCI DSS helps to alleviate these vulnerabilities and protect payment account data.#1 ATTRACTION IS PAYMENT 
ACCOUNT DATA
84% of data breach caseloads 
entailed payment account data
93% of data breaches had financial 
motive by actors
Source: Verizon 2022 Data Breach 
Investigations Report, pp. 18 and 25 
https://www.verizon.com/business/resources/
reports/dbir/

5
POS Merchant
 Acquirer
 Service Provider
INTERNET  
PUBLIC NETWORKS 
WIRELESS
INTERNET  
WIRELESS
INTERNET  
WIRELESS
The intent of this PCI DSS v4.0 Quick Reference Guide is to help you understand how PCI DSS can help 
protect your payment processing environment and how to apply the standard.
There are four ongoing steps to protecting payment account data with PCI DSS:
Assess — identifying all locations of payment account data, taking an inventory of all IT assets and 
business processes associated with payment processing, analyzing them for vulnerabilities that could 
expose payment account data, implementing or updating necessary controls, and undergoing a formal 
PCI DSS assessment.
Remediate — identifying and addressing any gaps in security controls, fixing identified vulnerabilities,

Remediate — identifying and addressing any gaps in security controls, fixing identified vulnerabilities, 
securely removing any unnecessary payment data storage, and implementing secure business processes.
Report — documenting assessment and remediation details, and submitting compliance reports to the 
compliance-accepting entity (typically, an acquiring bank or payment brands).
Monitor and Maintain — confirming that security controls put in place to secure the payment account 
data and environment continue to function effectively and properly throughout the year. These “business

data and environment continue to function effectively and properly throughout the year. These “business 
as usual” processes should be implemented as part of an entity’s overall security strategy to help ensure 
protection on an ongoing basis.PCI DSS IS A CONTINUOUS 
PROCESS
Overview of 
PCI SSC Standards

6
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Overview of PCI SSC Standards
PCI Security Standards enhance payment security with robust, comprehensive security control 
requirements, assessment procedures, and supporting materials. The standards define security 
controls and processes for entities involved in the payment ecosystem, as well as requirements for 
developers and solution providers to build and securely manage payment devices, software, and 
solutions for the payment industry. 
Descriptions of PCI Standards are provided below. Some of these standards result in validated PCI-
listed payment devices, software, and/or solutions that can be used alongside PCI DSS to help secure 
payment data environments.
PCI Data Security Standard – An actionable framework for developing a robust payment account 
data security process, including prevention, detection, and appropriate reaction to security incidents.

data security process, including prevention, detection, and appropriate reaction to security incidents. 
PIN Transaction Security (PTS) – Security requirements focused on characteristics and management 
of devices used in the protection of cardholder PINs (personal identification numbers) and other 
sensitive payment data. The PTS Point of Interaction (POI) standard covers devices including PIN 
terminals, POS (point of sale) devices, encrypting PIN pads, and unattended payment terminals. The 
PTS Hardware Security Module (HSM) standard defines security requirements for HSMs, to ensure

PTS Hardware Security Module (HSM) standard defines security requirements for HSMs, to ensure 
confidentiality and data integrity during activities such as financial transactions and payment card 
personalization.
Software Security Framework – A collection of standards and programs for the secure design, 
development, and maintenance of existing and future payment software. Includes the Secure 
Software Lifecycle (Secure SLC) Standard and Secure Software Standard.
Point-to-Point Encryption (P2PE) – A comprehensive set of security requirements for validation

Point-to-Point Encryption (P2PE) – A comprehensive set of security requirements for validation 
of P2PE solutions, to protect payment account data via encryption from where it is captured in the 
payment terminal until it is decrypted in the solution provider’s environment.
PCI Security Standards are 
developed and maintained by the 
PCI Security Standards Council 
and global payment card industry 
stakeholders.

7
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Mobile Standards – Includes the Contactless Payments on COTS (CPoC) and Software-based PIN Entry 
on COTS (SPoC) standards for mobile payment-acceptance solutions on commercial-off-the-shelf (COTS) 
devices (e.g., smartphone or tablet) in a merchant-attended environment.
Other Standards – Other PCI Standards define controls and testing requirements for PIN security, 
physical and logical card production and provisioning, token service providers, and access security 
(3-D Secure).
The PCI Standards can all be downloaded from the PCI SSC Document Library: 
https://pcisecuritystandards.org/document_library
Introduction to 
PCI DSS

8
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Introduction to PCI DSS
PCI DSS was developed to encourage and enhance payment account data security and facilitate the 
broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical 
and operational requirements designed to protect payment account data. 
Goals PCI DSS Requirements
Build and Maintain a 
Secure Network and 
Systems1. Install and maintain network security controls  
2. Apply secure configurations to all system components
Protect Account Data 3. Protect stored account data
4. Protect cardholder data with strong cryptography during 
transmission over open, public networks
Maintain a Vulnerability 
Management Program5. Protect all systems and networks from malicious software
6. Develop and maintain secure systems and software
Implement Strong Access

Implement Strong Access 
Control Measures7. Restrict access to system components and cardholder data by 
business need to know
8. Identify users and authenticate access to system components
9. Restrict physical access to cardholder data
Regularly Monitor and Test 
Networks10. Log and monitor all access to system components and 
cardholder data
11. Test security of systems and networks regularly
Maintain an Information 
Security Policy12. Support information security with organizational policies and 
programsPCI DSS PROTECTS MORE THAN

programsPCI DSS PROTECTS MORE THAN 
PAYMENT ACCOUNT DATA
While specifically designed to focus 
on environments with payment 
card account data, PCI DSS can also 
be used to protect against threats 
and secure other elements in the 
payment ecosystem.

9
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.PCI DSS Applicability Information 
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive 
authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This 
includes all entities involved in payment account processing – merchants, processors, acquirers, issuers, 
and other service providers. Cardholder data and sensitive authentication data are considered account 
data and are defined as follows:
Account Data
Cardholder Data Includes: Sensitive Authentication Data Includes:
• Primary Account Number (PAN)
• Cardholder Name
• Expiration Date
• Service Code• Full track data (magnetic stripe data or 
equivalent on a chip)
• Card verification code
• PINs/PIN blocks
PCI DSS requirements apply to entities with environments where account data (cardholder data and/or

PCI DSS requirements apply to entities with environments where account data (cardholder data and/or 
sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can 
impact the security of the CDE. Some PCI DSS requirements may also apply to entities with environments 
that do not store, process, or transmit account data – for example, entities that outsource payment 
operations or management of their CDE.
The primary account number (PAN) is the defining factor for cardholder data. The term account data

The primary account number (PAN) is the defining factor for cardholder data. The term account data 
includes: the full PAN, any other elements of cardholder data that are present with the PAN, and any 
elements of sensitive authentication data. 
If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with 
the PAN, or are otherwise present in the CDE, they must be protected in accordance with the PCI DSS 
requirements applicable to cardholder data. OUTSOURCING PROTECTION OF 
Entities that outsource their payment 
environments or payment operations 
to third parties remain responsible

to third parties remain responsible 
for ensuring that the account data 
is protected by the third party per 
applicable PCI DSS requirements.

10
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.If an entity stores, processes, or transmits PAN, then a CDE exists to which PCI DSS requirements will 
apply. Some requirements may not be applicable, for example, if the entity does not store PAN, then 
the requirements relating to the protection of stored PAN in Requirement 3 will not be applicable to the 
entity.
The following diagram shows where the data illustrated in the table above can be found on a payment 
card. These account data elements on physical payment cards also exist in devices with functionality that 
emulates a payment card, such as a payment token on a mobile device or smart watch.
CID
(American Express)
Expiration Date Magnetic Stripe
(data on tracks 1 & 2)PANChipCAV2/CID/CVC2/CVN2/CVV2
(all other payment card brands)Types of Data on a Payment Card
Cardholder 
Name

11
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.The Role of PCI SSC and Participating Payment Brands
PCI SSC is responsible for developing and managing the PCI Security Standards and related qualification 
and listing programs; however, each Participating Payment Brand maintains its own separate compliance 
enforcement programs, including which entities need to validate compliance, validation levels, whether 
an entity is eligible to complete a Self-Assessment Questionnaire (SAQ) or must complete a Report on 
Compliance (ROC), and any fines or penalties. 
Questions? Questions about payment brand compliance programs, including how to report the results 
of PCI DSS assessments and to understand any additional requirements payment brands may specify, 
should be directed to your acquirer or the payment brands directly. Contact details for the payment

should be directed to your acquirer or the payment brands directly. Contact details for the payment 
brands can be found in FAQ 1142 “How do I contact the payment card brands?” on the PCI SSC website.
Professionals to Assist with PCI DSS Assessments
The PCI SSC manages several programs to qualify industry professionals to facilitate the PCI DSS 
assessment process. 
Qualified Security Assessors.  Qualified Security Assessors (QSAs) are independent security organizations 
that have been qualified by the PCI SSC to assess and validate an entity’s adherence to PCI DSS.
Internal Security Assessors. The Internal Security Assessor (ISA) program provides an opportunity for

Internal Security Assessors. The Internal Security Assessor (ISA) program provides an opportunity for 
employees of PCI-qualified ISA sponsor companies to receive training and qualification to improve the 
employees’ understanding of PCI DSS, facilitate the entity’s interactions with QSAs, enhance the quality, 
reliability, and consistency of the entity’s self-assessments, and support consistent and proper application 
of PCI DSS measures and controls. 
Approved Scanning Vendors. Approved Scanning Vendors (ASVs) are qualified by the PCI SSC to

Approved Scanning Vendors. Approved Scanning Vendors (ASVs) are qualified by the PCI SSC to 
provide a set of security services and tools (the “ASV scan solution”) to conduct external vulnerability 
scanning services to validate adherence to the PCI DSS external vulnerability scan requirements. 
Payment Card Industry Professionals. The Payment Card Industry Professional (PCIP) program provides 
a foundational credential for industry practitioners that demonstrate their professional knowledge and 
understanding of PCI SSC standards and supporting materials.QUALIFIED INTEGRATORS AND 
RESELLERS (QIRs)
Qualified Integrators and Resellers

Qualified Integrators and Resellers 
(QIRs) are integrators and resellers 
specially trained by PCI Security 
Standards Council to address critical 
security controls while installing 
merchant payment systems. QIRs 
reduce merchant risk and mitigate 
the most common causes of 
payment data breaches by focusing 
on critical security controls.FAQ 1142 is available at:  
https://pcisecuritystandards.org/
faq/articles/Frequently_Asked_
Question/How-do-I-contact-the-
payment-card-brands/
Additional details and listings for 
assessors and solutions can be 
found on the PCI SSC website at:

found on the PCI SSC website at: 
https://www.pcisecuritystandards.
org/program-listings-overview/

12
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Reporting Results of PCI DSS Assessments
Validation documents are the official mechanism by which entities convey their PCI DSS compliance 
status to their acquirer or payment brands. Depending on payment brand compliance programs, entities 
may be required to undergo a detailed PCI DSS assessment and submit a Report on Compliance or may 
be eligible to conduct a self-assessment and submit a Self-Assessment Questionnaire. An Attestation 
of Compliance, signed by the entity and the QSA (if involved) accompanies the validation document. 
Quarterly submission of an ASV scan report for network vulnerability scanning may also be required.
Report on Compliance. The Report on Compliance (ROC) is a detailed report for assessors to 
document the results of a PCI DSS assessment. The ROC contains more detailed information than the

document the results of a PCI DSS assessment. The ROC contains more detailed information than the 
Self-Assessment Questionnaires, including information about the entity’s environment, the samples 
the assessor selected, and how each requirement was assessed and validated. The ROC Template 
provides detailed reporting instructions for assessors and is mandatory for QSAs to use for any PCI DSS 
assessment that is documented in a ROC.
Self-Assessment Questionnaires. Self-Assessment Questionnaires (SAQs) provide alternate validation

Self-Assessment Questionnaires. Self-Assessment Questionnaires (SAQs) provide alternate validation 
tools for entities that, according to payment brand compliance programs, are eligible to conduct self-
assessments to validate their PCI DSS compliance and that meet the SAQ Eligibility Criteria specified 
in each SAQ. Different SAQs are available for various merchant environments, including e-commerce 
environments and environments with PCI-listed Point-to-Point Encryption (P2PE) solutions. Most SAQs 
include a sub-set of only those PCI DSS requirements that are applicable for a given environment. More

include a sub-set of only those PCI DSS requirements that are applicable for a given environment. More 
details can be found in the SAQ Instructions and Guidelines document and the SAQ section on the 
PCI SSC website. To determine whether you are eligible to complete an SAQ, and if so, which SAQ is 
appropriate, contact the payment brands or your acquiring bank.
Attestations of Compliance. An Attestation of Compliance (AOC) is a declaration of the results of a 
PCI DSS assessment, completed and signed by the entity that underwent the assessment and the QSA

PCI DSS assessment, completed and signed by the entity that underwent the assessment and the QSA 
company (if involved). The AOC reflects the results of a PCI DSS assessment documented in an associated 
ROC or SAQ. PRIORITIZED APPROACH
PCI SSC also provides the PCI 
DSS Prioritized Approach to help 
stakeholders understand how to 
reduce risk earlier in their PCI DSS 
journey. The Prioritized Approach 
maps all PCI DSS requirements into 
six risk-based security milestones 
and provides a tool that entities can 
use to map their progress as they 
meet PCI DSS requirements. This 
helps them to incrementally protect 
against the highest risk factors

against the highest risk factors 
first while on the road to PCI DSS 
compliance.
SERVICE PROVIDER SAQ
Self-Assessment Questionnaire D for 
Service Providers is the ONLY SAQ 
option for service providers.
SERVICE PROVIDER AOC
If a service provider has an 
Attestation of Compliance (AOC), it 
is expected to provide the AOC to 
customers upon request.

13
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Choosing a Qualified Security Assessor
The QSA’s role during a PCI DSS assessment is to:
• Verify all technical information given by merchant or service provider
• Use independent judgment to confirm whether the standard has been met
• Provide support and guidance during the compliance process
• Adhere to the PCI DSS Requirements and Testing Procedures
• Validate the scope of the assessment
• Evaluate compensating controls and any customized approach implementations
• Produce the final report
The QSA you select should have a solid understanding of your business and have experience in assessing 
the security of similar types of businesses. That knowledge helps the QSA to understand nuances 
specific to your business sector when securing payment data under PCI DSS. Also, look for a good fit

specific to your business sector when securing payment data under PCI DSS. Also, look for a good fit 
with your company’s culture. While the assessment will conclude whether PCI DSS requirements have 
been met, QSAs can provide support beyond the assessment, working with your organization to help you 
understand how to achieve and maintain compliance on an ongoing basis. Many QSAs can also provide 
additional security-related services such as ongoing vulnerability assessment and remediation. A list of 
QSAs is available at https://listings.pcisecuritystandards.org/assessors_and_solutions/qualified_security_

assessors.

14
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Choosing an Approved Scanning Vendor
The ASV’s role is to determine whether the customer meets the PCI DSS external vulnerability scanning 
requirements. ASVs and their ASV scan solutions are qualified by the PCI Security Standards Council to 
perform external network and system scans as required by PCI DSS. An ASV may use its own software 
or a commercial or open-source solution that is PCI-approved as part of the ASV qualification process. 
An ASV scan solution includes the scanning procedures and tool(s), the associated scanning reports, 
and the process for exchanging information between the scanning vendor and the scan customer. ASVs 
may submit ASV scan reports to the acquiring institution on behalf of a merchant or service provider 
customer, if agreed between the ASV and its customer. More information about ASVs and their scan

customer, if agreed between the ASV and its customer. More information about ASVs and their scan 
solutions, responsibilities of scan customers, and PCI DSS external vulnerability scan requirements can 
be found in the ASV Program Guide on the PCI SSC website. A list of ASVs is available at https://listings.
pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors
The PCI DSS Assessment Process
The PCI DSS assessment process includes the following high-level steps:
1. Scope – determine where payment account data is stored, processed, and transmitted, and which

1. Scope – determine where payment account data is stored, processed, and transmitted, and which 
systems and networks are in scope for PCI DSS, and confirm the scope of the assessment.
2. Assess – perform the assessment on all in-scope system components to determine whether PCI DSS 
requirements have been met, by following the testing procedures for each PCI DSS requirement.
3. Report – complete the required documentation (for example, Self-Assessment Questionnaire (SAQ) 
or Report on Compliance (ROC)), including documentation of all compensating controls and any 
requirements met with the customized approach.

4. Attest – complete the appropriate Attestation of Compliance (AOC) in its entirety. Official AOCs are 
only available on the PCI SSC website.PREPARING FOR A PCI DSS 
ASSESSMENT
Gather Documentation: Security 
policies, change control records, 
network diagrams, scan reports, system 
documentation, training records, and 
so on.
Schedule Resources: Ensure 
participation of senior management, 
as well as a project manager and key 
people from IT, security, applications, 
human resources, and legal.
Describe the Environment: Organize 
information about the cardholder data

so on.
information about the cardholder data 
environment, including account data 
flows and locations of account data 
repositories.
Photo: Wikimedia Commons

15
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.5. Submit – submit the applicable PCI SSC documentation (SAQ or ROC) and AOC, along with other 
requested supporting documentation such as ASV scan reports to the requesting entity (those that 
manage compliance programs such as payment brands and acquirers (for merchants) or other 
requestors (for service providers)).
6. Remediate – if required, perform remediation to address requirements that are not in place, and 
provide an updated report.
Scope of PCI DSS Requirements
PCI DSS requirements apply to:
• The cardholder data environment (CDE), which is comprised of:
 –System components, people, and processes that store, process, and transmit cardholder data and/or 
sensitive authentication data, and,
 –System components that may not store, process, or transmit CHD/SAD but have unrestricted 
connectivity to system components that store, process, or transmit CHD/SAD.
AND

AND
• System components, people, and processes that could impact the security of the CDE.
“System components” include network devices, servers, computing devices, virtual components, cloud 
components, and software. See PCI DSS “Scope of PCI DSS Requirements” section for examples of 
“system components.”
Annual PCI DSS Scope Confirmation 
The first step in preparing for a PCI DSS assessment is for the assessed entity to accurately determine 
the scope of the review. The assessed entity must confirm the accuracy of their PCI DSS scope according

the scope of the review. The assessed entity must confirm the accuracy of their PCI DSS scope according 
to PCI DSS Requirement 12.5.2 by identifying all locations and flows of account data, and identifying all 
systems that are connected to or, if compromised, could impact the CDE (for example, authentication 
servers, remote access servers, logging servers) to ensure they are included in the PCI DSS scope. All 
systems and locations should be considered during the scoping process, including backup/recovery sites 
and fail-over systems.ANNUAL CONFIRMATION OF 
PCI DSS SCOPE
The annual confirmation of PCI DSS 
scope is defined at PCI DSS

scope is defined at PCI DSS 
Requirement 12.5.2 and is expected 
to be performed by the entity. This 
activity is not the same as, nor is 
it intended to be replaced by, the 
scoping confirmation performed 
by the entity’s assessor during the 
assessment.

16
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.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 entity 
accurately defined and documented the scope of the assessment.
Segmentation
The scope of a PCI DSS assessment can be reduced with the use of segmentation, which isolates the 
cardholder data environment from the remainder of an entity’s network. Reduction of scope can lower the 
cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS

cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS 
controls, and reduce risk for the entity. To be considered out of scope for PCI DSS, a system component 
must be properly isolated (segmented) from the CDE, such that the out-of-scope system component 
could not impact the security of the CDE even if it was compromised.  For more information on scoping, 
see the PCI DSS “Segmentation” section.
Refer to the Information Supplement: Guidance for PCI DSS Scoping and Segmentation for more 
information.
Use of Third-Party Service Providers (TPSP)

An entity (“customer” in this section) may use a TPSP to store, process, or transmit account data, or to 
manage in-scope system components on their behalf. 
Using TPSPs and meeting PCI DSS Requirement 12.8
Customers must manage and oversee all their TPSP relationships and monitor the PCI DSS compliance 
status of all their TPSPs in accordance with Requirement 12.8, including TPSPs that have access to the 
customer’s CDE, manage in-scope system components on the customer’s behalf, and/or can impact the

customer’s CDE, manage in-scope system components on the customer’s behalf, and/or can impact the 
security of the customer’s CDE.
Managing TPSPs according to Requirement 12.8 includes performing due diligence, having appropriate 
agreements in place, identifying which requirements apply to the customer and which apply to the TPSP , 
and monitoring the compliance status of TPSPs at least annually. Use of a PCI DSS compliant TPSP 
does not make a customer PCI DSS 
compliant, nor does it remove the 
customer’s responsibility for its own 
PCI DSS compliance.

17
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that 
the customer monitors their TPSPs’ compliance status. Therefore, a TPSP does not need to be PCI DSS 
compliant for its customer to meet Requirement 12.8.
Using TPSPs for services that meet customer’s PCI DSS requirements
When the TPSP provides a service that meets PCI DSS requirements on the customer’s behalf or where 
that service may impact the security of the customer’s CDE, then those requirements are in scope for the 
customer’s assessment and the compliance of that service will impact the customer’s PCI DSS compliance. 
The TPSP must demonstrate it meets applicable PCI DSS requirements for those requirements to be in 
place for its customer.
Understanding responsibilities between customers and TPSPs

Customers and TPSPs should clearly identify and understand the services and system components 
included in the scope of the TPSP’s PCI DSS assessment, the specific PCI DSS requirements and sub-
requirements covered by the TPSP’s PCI DSS assessment, and any requirements that are the responsibility 
of the TPSP’s customers to include in their own PCI DSS assessments, and any requirements for which 
responsibility is shared between the TPSP and its customers.

Refer to the Information Supplement: Third-Party Security Assurance on the PCI SSC website for a sample 
responsibility matrix template that may be used for documenting and clarifying how responsibilities are 
shared between TPSPs and customers.
TPSPs and PCI DSS compliance evidence provided to customers
If a TPSP undergoes its own PCI DSS assessment, it is expected to provide sufficient evidence to its 
customers to verify that the scope of the TPSP’s PCI DSS assessment covered the services applicable

customers to verify that the scope of the TPSP’s PCI DSS assessment covered the services applicable 
to the customers, and that the relevant PCI DSS requirements were examined and determined to be in 
place. If the TPSP has an Attestation of Compliance (AOC), it is expected that the TPSP will provide it to 

18
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.If a TPSP does not undergo its own PCI DSS assessment and therefore does not have an AOC, the TPSP is 
expected to provide specific evidence related to the applicable PCI DSS requirements, so that customers 
(or their assessor) are able to confirm the TPSP is meeting those PCI DSS requirements.
Implementing PCI DSS into BAU Processes
To ensure that security controls continue to be properly implemented, entities should implement PCI 
DSS into business-as-usual (BAU) processes as part of their overall security strategy. This enables an 
entity to ensure that the security controls implemented to secure data and the environment continue to 
be implemented correctly and are functioning properly. Some BAU requirements are defined within the 
standard to help entities monitor the effectiveness of their security controls on an ongoing basis and

standard to help entities monitor the effectiveness of their security controls on an ongoing basis and 
provide assurance that compliance is maintained between PCI DSS assessments. Entities should also 
adopt additional BAU practices specific to their organizations and environments wherever possible.
Examples of best practices for how PCI DSS should be incorporated into BAU activities include, but are 
not limited to:
1. Monitoring of security controls to ensure they are operating effectively and as intended.
2. Ensuring that all failures in security controls are detected and responded to in a timely manner.

3. Reviewing changes to the environment (for example, addition of new systems, changes in system or 
network configurations) prior to completion of the change to ensure PCI DSS scope is updated and 
controls are applied as appropriate.
4. Formally reviewing the impact to PCI DSS scope and requirements after changes to organization 
structure (for example, a company merger or acquisition).
5. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to

5. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to 
be in place and personnel are following secure processes.
6. Reviewing hardware and software technologies at least annually to confirm that they continue to be 
supported by the vendor and can meet the entity’s security requirements, including PCI DSS, and 
remediating shortcomings as appropriate.

19
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Note: Some best practices in this section are also included as PCI DSS requirements for certain entities. 
For example, those undergoing a full PCI DSS assessment, service providers validating to the additional 
“service provider only” requirements, and designated entities that are required to validate according to PCI 
DSS Appendix A3. 
Each entity should consider implementing these best practices into their environment, even where the 
entity is not required to validate to them (for example, merchants undergoing self-assessment).
Understanding 
PCI DSS v4.0

20
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Understanding PCI DSS v4.0
Approaches for Implementing and Validating PCI DSS
To provide flexibility for different ways entities may use to meet security objectives, PCI DSS v4.0 includes 
two approaches for implementing controls and validating to PCI DSS. Entities should identify the 
approach, or combination of approaches, best suited to their needs.
Defined Approach – The traditional approach for implementing and validating PCI DSS; it is what entities 
have been doing all along to meet PCI DSS. This approach uses the Requirements and Testing Procedures 
defined in PCI DSS. The entity implements security controls that meet the stated requirements, and the 
assessor follows the defined testing procedures to verify requirements are met. If an entity already has 
controls in place that meet PCI DSS requirements and is comfortable with its current approach, there is

controls in place that meet PCI DSS requirements and is comfortable with its current approach, there is 
no need to change. The Defined Approach is also useful for those wanting more direction about how to 
meet security objectives or those new to information security or PCI DSS.
Compensating Controls – Compensating Controls are still an option within the Defined Approach 
for entities with legitimate and documented technical or business constraints that prevent 
them from meeting the Defined Approach Requirement as stated. The entity implements other, 
or compensating, controls, that sufficiently mitigate the risk associated with not meeting the

or compensating, controls, that sufficiently mitigate the risk associated with not meeting the 
requirement. Compensating Controls are often used in situations where there is a legacy system or 
process that cannot be updated to meet the requirement. 
Customized Approach – This approach allows entities to implement controls that meet the requirements 
stated in the Customized Approach Objective in a way that does not strictly follow the defined 
requirement, providing greater flexibility to entities that choose to implement innovative approaches or 
new technologies to meet PCI DSS objectives. For example, some entities may wish to supplement legacy

new technologies to meet PCI DSS objectives. For example, some entities may wish to supplement legacy 
scanning for internal vulnerabilities with modern machine learning techniques such as User and Entity 
Behavior Analytics (UEBA), or other AI-based probabilistic approaches for detecting advanced threats to 
the CDE. Emerging modern security solutions may be candidates for a Customized Approach.COMPENSATING CONTROLS VS. 
CUSTOMIZED APPROACH
Compensating Controls serve 
a different purpose than the 
Customized Approach. Unlike 
compensating controls, where 
entities have a constraint and are 
unable to meet the requirement

unable to meet the requirement 
as stated, with the customized 
approach organizations choose to 
meet the requirement differently 
than is stated. 
Compensating Controls are not 
an option with the Customized 
Approach.

21
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Because each customized implementation is different, there are no defined testing procedures. Instead, 
the entity’s assessor develops unique testing procedures to verify the implemented control meets the 
stated Customized Approach Objective. 
Because entities develop their own security controls, the Customized Approach requires substantial pre-
planning and advance documentation. The Customized Approach is intended for risk-mature entities that 
demonstrate robust security and risk-management practices, and can effectively design, document, test, 
and maintain rigorous security controls that meet the objective. 
Entities can use both the defined and customized approaches within their environment, using the Defined 
Approach to meet some requirements and the Customized Approach to meet other requirements, or the

Approach to meet some requirements and the Customized Approach to meet other requirements, or the 
Defined Approach to meet a requirement for one system component or environment and the Customized 
Approach to meet that same requirement for a different system component or environment.

22
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.PCI DSS Validation Approaches
Entity identifies validation path
Entity designs and implements control(s) that 
meets the Objective of the PCI DSS requirementEntity implements control(s) per
the PCI DSS requirement
Entity documents their customized control(s) and 
how it meets the requirement’s Objective
Assessor derives testing procedure(s), including 
what is to be reviewed, evidence to be examined 
and observed, interviews, etc.
Assessor performs the assessment per the 
assessor-derived testing procedure(s)Assessor performs assessment 
as stated in the PCI DSS Testing 
Procedure(s)
Assessor documents results of the assessment per instructions 
in the ROC TemplateCustomized 
ValidationDefined 
Validation
If entity has a legitimate 
and documented technical 
or business constraint that 
prevents it from meeting a PCI 
DSS requirement as written, it

DSS requirement as written, it 
implements and documents 
a compensating control for 
assessor review

23
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Understanding the Layout and Content in PCI DSS Requirements
The column headings and content for the PCI DSS v4.0 requirements are described on page 37 of the 
standard (see adjacent pop-up image and URL). Each requirement includes the following elements:
• Requirement Description organizes and describes associated requirements.
• Defined Approach and associated Defined Approach Testing Procedures. These procedures are 
the traditional method for implementing and validating PCI DSS using the Requirements and Testing 
Procedures defined in the standard.
• Customized Approach Objective is the intended goal or outcome for the requirement. It must be met 
by entities using a Customized Approach.
• Applicability Notes apply to both the Defined and Customized Approach. It includes information that

• Applicability Notes apply to both the Defined and Customized Approach. It includes information that 
affects how the requirement is interpreted in the context of the entity or in scoping. Applicability Notes 
also indicate the new PCI DSS v4.0 requirements that are best practices until 31 March 2025, after 
which they become formal requirements.
• Guidance provides information, categorized into sections, to understand how to meet a requirement. 
Guidance is not required to be followed – it does not replace or extend any PCI DSS requirement.
Summary of PCI DSS v4.0 Requirements 1–12
Build and Maintain a Secure Network and Systems

In the past, theft of financial records required a criminal to physically enter an entity’s business site. 
Now, payment transactions occur with many different electronic devices, including traditional payment 
terminals, mobile devices, and other Internet connected computer systems. By using network security 
controls, entities can prevent criminals from virtually accessing payment system networks and stealing 
payment account data.
Click to see the full image 
of annotated details on 
“Understanding Information in 
PCI DSS Requirements”

org/understanding-information-in-
pci-dss-requirements_/

24
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 1: Install and maintain network security controls
Network security controls (NSCs), such as firewalls and other network security technologies, are network 
policy enforcement points that typically control network traffic between two or more logical or physical 
network segments (or subnets) based on pre-defined policies or rules. Traditionally this function has been 
provided by physical firewalls; however, now this functionality may be provided by virtual devices, cloud 
access controls, virtualization/container systems, and other software-defined networking technology.
1.1 Processes and mechanisms for installing and maintaining network security controls are defined and 
understood. 
1.2 Network security controls (NSCs) are configured and maintained.
1.3 Network access to and from the cardholder data environment is restricted.

1.4 Network connections between trusted and untrusted networks are controlled.
1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and 
the CDE are mitigated.
Requirement 2: Apply secure configurations to all system components
Malicious individuals, both external and internal to an entity, often use default passwords and other 
vendor default settings to compromise systems. These passwords and settings are well known and are 
easily determined via public information.

Applying secure configurations to system components reduces the means available to an attacker to 
compromise systems. Changing default passwords, removing unnecessary software, functions, and 
accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.
2.1 Processes and mechanisms for applying secure configurations to all system components are 
defined and understood.
2.2 System components are configured and managed securely.
2.3 Wireless environments are configured and managed securely.

25
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Protect Account Data
Payment account data refers to any information printed, processed, transmitted, or stored in any form 
on a payment card. Account data refers to both cardholder data and sensitive authentication data, and 
protection of the account data is required where account data is stored, processed, or transmitted. 
Entities accepting payment cards are expected to protect account data and to prevent its unauthorized 
use – whether the data is printed or stored locally, or transmitted over an internal or public network to a 
remote server or service provider.
Requirement 3: Protect stored account data
Payment account data should not be stored unless it is necessary to meet the needs of the business. 
Sensitive authentication data must never be stored after authorization. If your organization stores PAN, it

Sensitive authentication data must never be stored after authorization. If your organization stores PAN, it 
is crucial to render it unreadable. If your company stores sensitive authentication data prior to completion 
of authorization, that data must also be protected1. 
3.1 Processes and mechanisms for protecting stored account data are defined and understood.
3.2 Storage of account data is kept to a minimum.
3.3 Sensitive authentication data (SAD) is not stored after authorization. 
3.4 Access to displays of full PAN and ability to copy cardholder data are restricted.

3.5 Primary account number (PAN) is secured wherever it is stored.
3.6 Cryptographic keys used to protect stored account data are secured.
3.7 Where cryptography is used to protect stored account data, key management processes and 
procedures covering all aspects of the key lifecycle are defined and implemented.
1 This requirement is a best practice until 31 March 2025, after which it must be fully considered as part of a 
PCI DSS assessment.ENCRYPTION PRIMER
Cryptography uses a mathematical 
formula to render plaintext data

formula to render plaintext data 
unreadable to people without 
special knowledge (called a “key”). 
Cryptography is applied to stored 
data as well as data transmitted over 
a network. 
Encryption changes plaintext into 
ciphertext.
Decryption changes ciphertext back 
into plaintext.
This is secret stuff, please do not…
Illustration: Wikimedia Commons

26
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Elements of Account Data and Storage Requirements
Table 3 in PCI DSS (see below) identifies the elements of cardholder and sensitive authentication data, 
whether storage of each data element is permitted or prohibited, and whether each data element 
must be rendered unreadable – for example, with strong cryptography – when stored. This table is not 
exhaustive and is presented to illustrate only how the stated requirements apply to the different data 
elements.
Data Elements Storage Restrictions Required to Render 
Stored Data 
UnreadableAccount DataCardholder Data Primary Account Number 
(PAN)Storage is kept to a 
minimum as defined in 
Requirement 3.2Yes, as defined in 
Requirement 3.5
Cardholder Name Storage is kept to a 
Requirement 3.22 No
Service Code
Expiration Date
Sensitive 
Authentication 
DataFull Track Data Cannot be stored after

elements.
Sensitive 
DataFull Track Data Cannot be stored after 
authorization as defined 
in Requirement 3.3.13 Yes, data stored until 
authorization is complete 
must be protected with 
strong cryptography as 
defined in Requirement 
3.3.2Card verification code
PIN/PIN Block
2 Where data exists in the same environment as PAN.
3 Except as permitted for issuers and companies that support issuing services. Requirements for issuers and 
issuing services are separately defined in Requirement 3.3.3.

27
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 4: Protect cardholder data with strong cryptography during transmission over 
open, public networks
To protect against compromise, primary account numbers (PANs) must be encrypted during transmission 
over networks that are easily accessed by malicious individuals, including untrusted and public networks. 
Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols 
continue to be targeted by malicious individuals aiming to exploit these vulnerabilities to gain privileged 
access to cardholder data environments (CDE). PAN transmissions can be protected by encrypting the 
data before it is transmitted, or by encrypting the session over which the data is transmitted, or both.
4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during

4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during 
transmission over open, public networks are defined and documented.
4.2 PAN is protected with strong cryptography during transmission.
Maintain a Vulnerability Management Program
Vulnerability management is the process of systematically and continuously finding and mitigating 
weaknesses in an entity’s payment card environment. This includes addressing threats from malicious 
software, routinely identifying and patching vulnerabilities, and ensuring that software is developed

software, routinely identifying and patching vulnerabilities, and ensuring that software is developed 
securely and without known coding vulnerabilities.
Requirement 5: Protect all systems and networks from malicious software 
Malicious software (malware) is software or firmware designed to infiltrate or damage a computer system 
without the owner’s knowledge or consent, with the intent of compromising the confidentiality, integrity, 
or availability of the owner’s data, applications, or operating system. Examples include viruses, worms,

or availability of the owner’s data, applications, or operating system. Examples include viruses, worms, 
Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links. Malware can enter 
the network during many business-approved activities, including employee e-mail (for example, via 
phishing) and use of the internet, mobile computers, and storage devices, resulting in the exploitation of 
system vulnerabilities.
5.1 Processes and mechanisms for protecting all systems and networks from malicious software are 
defined and understood.VULNERABILITY MANAGEMENT
Create a policy governing security 
controls according to industry 
standards and best practices.

Regularly scan systems for 
vulnerabilities.
Create a remediation schedule 
based on risk and priority.
Pre-test and deploy patches. 
Rescan to verify vulnerabilities are 
addressed.
Update all software with the most 
current signatures and technology.
Use only software or systems that 
are securely developed following 
industry standard best practices.

28
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.5.2 Malicious software (malware) is prevented, or detected and addressed.
5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.
5.4 Anti-phishing mechanisms protect users against phishing attacks.
Requirement 6: Develop and maintain secure systems and software
Security vulnerabilities in systems and applications may allow criminals to access payment data. Many 
of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform 
a quick-repair job for a specific piece of programming code. All system components must have the 
most recently released critical security patches installed to prevent exploitation. Entities must also apply 
patches to less-critical systems in an appropriate timeframe, based on a formal risk analysis. Applications

patches to less-critical systems in an appropriate timeframe, based on a formal risk analysis. Applications 
must be developed according to secure development and coding practices, and changes to systems in 
the cardholder data environment must follow change control procedures.
6.1 Processes and mechanisms for developing and maintaining secure systems and software are 
6.2 Bespoke and custom software are developed securely. 
6.3 Security vulnerabilities are identified and addressed.
6.4 Public-facing web applications are protected against attacks.
6.5 Changes to all system components are managed securely.Typically, bespoke software is 
developed by a third party on the

developed by a third party on the 
entity’s behalf, while custom software 
is developed internally by the entity.

29
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Implement Strong Access Control Measures
Access to payment account data must be granted only on a business need-to-know basis. Logical access 
controls are technical means used to permit or deny access to data on computer systems.  Physical access 
controls entail the use of locks or other physical means to restrict access to computer media, paper-based 
records, and computer systems.
Requirement 7: Restrict access to cardholder data by business need-to-know
Unauthorized individuals may gain access to critical data or systems due to ineffective access control 
rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and 
processes must be in place to limit access based on need to know and according to job responsibilities. 
“Need to know” refers to providing access to only the least amount of data needed to perform a job.

“Need to know” refers to providing access to only the least amount of data needed to perform a job. 
“Least privileges” refers to providing only the minimum level of privileges needed to perform a job. 
7.1 Processes and mechanisms for restricting access to system components and cardholder data by 
business need to know are defined and understood
7.2 Access to system components and data is appropriately defined and assigned.
7.3 Access to system components and data is managed via an access control system(s).RESTRICTING ACCESS  
IS CRUCIAL!
Restrict access to cardholder data 
environments by employing physical

environments by employing physical 
and logical access controls.
Limit access to only those 
individuals whose job requires such 
access.
Formalize an access control policy 
that includes a list of who gets 
access to specific account data and 
systems.
Deny all access to anyone who is 
not specifically allowed to access 
cardholder data and systems.

30
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 8: Identify users and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that actions taken on critical 
data and systems are performed by, and can be traced to, known and authorized users. Unless otherwise 
stated in the requirement, these requirements apply to all accounts, including point-of-sale accounts, 
those with administrative capabilities, and all accounts used to view or access payment account data or 
systems with those data. These requirements do not apply to accounts used by consumers (cardholders).
8.1 Processes and mechanisms for identifying users and authenticating access to system components 
are defined and understood.
8.2 User identification and related accounts for users and administrators are strictly managed 
throughout an account’s lifecycle.

8.3 Strong authentication for users and administrators is established and managed.
8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.
8.6 Use of application and system accounts and associated authentication factors is strictly managed.IDENTIFY AND AUTHENTICATE 
ALL USERS 
Every user with access to the 
cardholder data environment 
must have a unique ID. This 
allows a business to trace every 
action to a specific individual.

ALL USERS 
action to a specific individual. 
Every user should have a strong 
authentication mechanism — such 
as a strong password, biometric, or 
access token — and use multi-factor 
authentication for all access into 
the CDE4.
4 The requirement for use of multi-factor authentication for all access into the CDE is a best practice until 
31 March 2025, after which it must be fully considered as part of a PCI DSS assessment.

31
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 9: Restrict physical access to cardholder data
Physical access to cardholder data or systems that store, process, or transmit cardholder data should be 
restricted so that unauthorized individuals cannot access or remove systems or hardcopies containing 
this data. 
9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and 
understood.
9.2 Physical access controls manage entry into facilities and systems containing cardholder data.
9.3 Physical access for personnel and visitors is authorized and managed.
9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.
9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution. MERCHANTS MUST INSPECT 
PAYMENT DEVICES
Criminals can steal payment 
account data by replacing and/
or manipulating card-reading

or manipulating card-reading 
devices and terminals. Merchants 
must periodically inspect payment 
devices for “skimming” components 
or other tampering (see PCI DSS 
Requirement 9.5.1). 
• Maintain a list of point of 
interaction (POI) devices. 
• Periodically inspect POI devices to 
look for tampering or unauthorized 
substitution. 
• Train personnel to be aware 
of suspicious behavior and to 
report tampering or unauthorized 
substitution of devices.

32
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Regularly Monitor and Test Networks
Physical, virtual, and wireless networks are the glue connecting all endpoints and servers in the payment 
infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain 
unauthorized access to payment applications and payment account data. To prevent exploitation, entities 
must regularly monitor and test networks to find and address unexpected access and activities, security 
system failures, and vulnerabilities.
Requirement 10: Log and monitor all access to system components and cardholder data
Logging mechanisms and the ability to track user activities are critical for detection of anomalies and 
suspicious activities, and for effective forensic analysis. The presence of logs in all environments allows

suspicious activities, and for effective forensic analysis. The presence of logs in all environments allows 
thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is 
difficult, if not impossible, without system activity logs.
10.1 Processes and mechanisms for logging and monitoring all access to system components and 
cardholder data are defined and documented.
10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the 
forensic analysis of events.
10.3 Audit logs are protected from destruction and unauthorized modifications.
10.4 Audit logs are reviewed to identify anomalies or suspicious activity.

10.5 Audit log history is retained and available for analysis.
10.6 Time-synchronization mechanisms support consistent time settings across all systems.
10.7 Failures of critical security control systems are detected, reported, and responded to promptly.MONITOR ALL ACTIVITIES
10.2.2 Audit logs record the 
following details for each auditable 
event: 
• User identification
• Type of event
• Date and time
• Success and failure indication
• Origination of event
• Identity or name of affected data, 
system component, resource, or

event: 
system component, resource, or 
service (for example, name and 
protocol). 

33
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Requirement 11: Test security of systems and networks regularly
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being 
introduced by new software. System components, processes, and bespoke and custom software should 
be tested frequently to ensure security controls continue to reflect a changing environment.
11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and 
11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are 
11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and 
security weaknesses are corrected.

11.5 Network intrusions and unexpected file changes are detected and responded to.
11.6 Unauthorized changes on payment pages are detected and responded to.
TIPS FOR SCANNING
Get Advice. Ask your acquiring bank about any partnerships they may have with PCI Approved 
Scanning Vendors (ASVs).
Talk to a PCI ASV. See PCI Council website for the list of PCI ASVs.
Select an ASV. Contact several PCI ASVs and select a suitable program.
Address Vulnerabilities. Ask your PCI ASV for help correcting issues found by scanning.SEVERITY LEVELS FOR

Address Vulnerabilities. Ask your PCI ASV for help correcting issues found by scanning.SEVERITY LEVELS FOR 
VULNERABILITY SCANNING
CVSS 
ScoreSeverity 
LevelScan 
Results
7.0 
through 
10.0High 
SeverityFail
4.0 
through 
6.9Medium 
0.0 
through 
3.9Low 
SeverityPass
Note that external vulnerability 
scanning must be performed at 
least once every three months by 
a PCI Approved Scanning Vendor. 
To receive a “pass,” external 
scan reports must not include 
any vulnerability that has been 
assigned a Common Vulnerability 
Scoring System (CVSS) base score 
equal to or higher than 4.0 or any 
vulnerability that indicates features

LevelScan 
Results
7.0 
through 
10.0High 
4.0 
through 
6.9Medium 
0.0 
through 
3.9Low 
vulnerability that indicates features 
or configurations that are in violation 
of PCI DSS.

34
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.Maintain an Information Security Policy
A strong security policy sets the tone for security affecting an entity’s entire company, and it informs 
employees of their expected duties related to security. All employees should be aware of the sensitivity of 
payment account data and their responsibilities for protecting it.
Requirement 12: Support information security with organizational policies and programs
12.1 A comprehensive information security policy that governs and provides direction for protection of 
the entity’s information assets is known and current.
12.2 Acceptable use policies for end-user technologies are defined and implemented.
12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed.
12.4 PCI DSS compliance is managed.
12.5 PCI DSS scope is documented and validated.

12.6 Security awareness education is an ongoing activity.
12.7 Personnel are screened to reduce risks from insider threats.
12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is 
managed.
12.9 Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.
12.10 Suspected and confirmed security incidents that could impact the CDE are responded to 
immediately.

Resources
WebsiteFrequently Asked Questions 
(FAQs)PCI SSC Blog Subscribe to the 
PCI Perspectives Blog
Membership Information Merchant Resources Training Qualified PCI Products & Solutions
Qualified PCI Professionals PCI Data Security Standard 
(PCI DSS)Glossary Threat Center
Resources

37
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.About the PCI Security Standards Council
The PCI Security Standards Council (PCI SSC) is a global forum for the industry to come together to 
develop, enhance, disseminate, and assist with the understanding of security standards for payment 
account security. 
The PCI SSC maintains, evolves, and promotes the Payment Card Industry Security Standards. It also 
provides critical tools needed for implementation of the standards, such as assessment and scanning 
qualifications, self-assessment questionnaires, training and education, and product certification programs.
The PCI SSC is led by a policy-setting Executive Committee composed of representatives from 
the Founding Members and Strategic Members: American Express, Discover Financial Services, 
JCB International, Mastercard, UnionPay, and Visa Inc.

JCB International, Mastercard, UnionPay, and Visa Inc. 
Participating Organization membership in the PCI SSC is open globally to those affiliated with the 
payments industry, including merchants, banks, processors, hardware and software developers, and 
point-of-sale vendors.
Industry stakeholders are encouraged to join the PCI SSC as Strategic or Affiliate members and 
Participating Organizations to review proposed additions or modifications to the standards.PCI SSC PARTICIPATING 
PAYMENT BRANDS
PARTICIPATING ORGANIZATIONS
Merchants, Banks, Processors, Hardware 
and Software Developers, and 
Point-of- Sale Vendors.

About the PCI 
Security Standards 
Council

PCI Data Security Standard
PCI DSS provides a baseline of technical and operational requirements designed to protect payment account data. Learn more about its 
requirements, security controls and processes, and steps to assess compliance inside this PCI DSS Quick Reference Guide.
Build and Maintain a Secure Network 
and Systems1. Install and maintain network security controls  
4. Protect cardholder data with strong cryptography during transmission over open, public 
networks
Maintain a Vulnerability Management 
Program5. Protect all systems and networks from malicious software
Implement Strong Access Control 
Measures7. Restrict access to system components and cardholder data by business need to know

networks
Regularly Monitor and Test Networks 10. Log and monitor all access to system components and cardholder data
Maintain an Information Security 
Policy12. Support information security with organizational policies and programs

©2016 – 2022 PCI Securit y Standar ds Counc il LLC. The intent of this document is to provide 
supplemental information, which does  not replace or supersede requirements in any PCI SSC Standard.
 August 2022 1 
The Prioritized 
Approach to Pursue PCI DSS Compliance 
The Payment Card Industry Data Security Standard (PCI  DSS) provides a baseline of technical and operational requirements, 
organized into  12 principal requirement s and detailed security requirements . PCI DSS has been developed to  secur e payment account 
data that is stored, processed , and/or transmitted by merchants , service providers, and other organizations  (referred to, collectively,  as 
“organizations ” hereafter) . By its compre hensive nature, PCI DSS provides a large amount of security information – so much 
information that some people responsible for security of payment account data may wonder where to start. Toward this end, the PCI

information that some people responsible for security of payment account data may wonder where to start. Toward this end, the PCI 
Security Standards Council provides the Prioritized Approach to help organizations understand how they can reduce risk earlier in the ir 
PCI DSS  journey .  
What Is the Prioritized Approach? 
The Prioritized Approach maps all PCI DSS requirements into six risk-based security 
milestones that are intended to  help organizations  incrementally protect against the highest 
risk factors and escalating threats while on the road to PCI DSS compliance. No single 
milestone in the Prioritized Approach provides compr ehensive security but following its

milestone in the Prioritized Approach provides compr ehensive security but following its 
guidelines will help organizations  to secure payment account data more quickly.  
The Prioritized Approach and its milestones (described on page 2) are intended to provide 
the following benefits:  
•Provides a r oadmap that an organization can use to address its risks in
priority  order
•Allows for “quick wins” using a pragmatic approach
•Support s financial and operational planning
•Promotes objective and measurable progress indicators
•Helps promote consistency among assesso rs
Objectives of the Prioritized Approach

Objectives of the Prioritized Approach 
The Prioritized Approach provides a roadmap of PCI DSS requirements based on the risk 
associat ed with storing, processing, and/or transmitti ng payment account data. The roadmap 
helps organizations  to prioritize e fforts to a chieve c ompliance, establish m ilestones , and 
lower the risk of payment account data breaches sooner in the complianc e process . 
Additionally, the r oadmap helps acquirers objectively  m easur e complianc e activities and risk 
reduction by organizations . The P rioritized A pproach w as devel oped after reviewing data

reduction by organizations . The P rioritized A pproach w as devel oped after reviewing data 
from a ctual b reaches a nd fe edback fr om Q ualified S ecurity A ssessors, forensic 
investigators, and the PCI Security Standards C ouncil Board of Advisors. The roadmap is 
not intended as a substitute, shortcut , or stop- gap approac h to PCI DSS compliance, nor i s it 
a one-size-fits-all framework applicabl e to every or ganization.  
Questions about using the Prioritized Approach and how use of the Prioritized Approach 
may impact an organization’s compliance obligations should be directed to the acquirer or

may impact an organization’s compliance obligations should be directed to the acquirer or 
payment brands to  which  an organization reports compliance.  
HIGHLIGHTS  
•Helps organizations identify
the highest risk targets.
•Creates a common languagearound PCI DSSimplementation andassessment efforts.
•Enables organizations todemonstrate complianceprogress.

The Prioritized Approach to Pursue PCI DSS Compliance  
supplemental information, which does not replace or supersede requirements in any PCI SSC Standard. 
August 2022 2 Milestones for Prioritizing PCI DSS Compliance Efforts 
The Prioritized Approach includes six milestones. The following table  summarizes the high -
level goals  of each milestone .  
Milestone  Goals  
1 Do not store sensitive authentication data and limit cardholder data 
retention. This milestone targets a key area of risk for entities that have 
been compromised. Remember – if sensitive authentication data and other 
account data are not stored, the effects of a compromise will be greatly reduced. If you don’t need it, don’t store it.  
2 Protect systems and networks and be prepared to respond to a 
system breach.  This milestone targets controls for points of access to 
most compromises a nd the response processes.

most compromises a nd the response processes.  
3 Secure payment applications.  This milestone targets controls for 
applications, application processes, and application servers. Weaknesses 
in these areas are easy prey for compromising systems and obtaining access to cardholder  data.  
4 Monitor and control access to your systems.  Controls for this milestone 
allow you to detect the who, what, when, and how concerning access to 
your network and cardholder data environment.  
5 Protect stored cardholder data. For those organizations that have

5 Protect stored cardholder data. For those organizations that have 
analyzed their business processes and determined that they must store 
Primary Account Numbers, this milestone targets key protection mechanisms for the stored data.  
6 Complete remaining compliance efforts, and ensure all  controls are in 
place.  This milestone completes PCI DSS requirements and finishes all 
remaining related policies, procedures, and processes needed to protect 
the cardholder data environment.  
Disclaimer

Disclaimer 
This document does not modify or abridge the PCI DSS or any of its requirements and may 
be changed without notice. 
PCI SSC is not responsible for errors  or damages of any kind resulting from the use of the 
information contained herein. PCI SSC makes no warranty, guarantee, or representation 
whatsoever regar ding the informati on provi ded herein, and assumes no responsibility or 
lia
bility regarding the use or misuse of such information. 
Mapping the Prioritized Approach Milestones to PCI DSS v4.0

lia
Mapping the Prioritized Approach Milestones to PCI DSS v4.0 
Requirements 
The rest of this document maps the m ilestone s to each PCI DSS v4.0 requirement and sub-
requirement . Note that the PCI DSS v4.0 requirements in the fo llowing section do not 
include the Applicability Notes and other important information found in PCI DSS. 
Applicability Notes include information that can affect how a requirement is interpreted and 
are consider ed an integral part of PCI DSS that must be fully c onsider ed during an 

assessment.  
Applicability Notes also indicate the new PCI DSS v4.0 requirements that are best practices 
until 31 March 2025. These new requirements are denoted with the following note: “This 
requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS 
for details” i n the table below.  
Organizations are urged to refer to PCI DSS v4.0 to see the Applicability Notes and 
other important information in cluded t herein . 
PARTICIPATING 
ORGANIZATIONS  
Merchants, service providers,

Merchants, service providers, 
banks, processors, developers, and point of sale vendors. 
PCI DSS COMPLIANCE IS A 
CONTINUOUS PROCESS  
PCI SSC PARTICIPATING 
PAYMENT BRANDS

August 2022 3 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
Requirement 1: Install and Maintain Network Security Controls  
1.1 Processes and mechanisms for installing and maintaining network security 
controls are defined and understood . 
1.1.1 All security policies and operational procedures that are identified in 
Requirement 1 are:  
•Documented .
•Kept up to date.
•In use .
•Known to all affected parties.6 
1.1.2 Roles and responsibilities for performing activities in Requirement 1 
are documented, assigned, and understood.  6 
1.2 Network security controls (NSCs) are configured and maintained.  
1.2.1 Configuration standards for NSC rulesets are:  
•Defined .
•Implemented .
•Maintained .2

•In use .
•Defined .
•Maintained .2 
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.  6 
1.2.3 An accurate network diagram(s) is maintained that shows all 
connections between the CDE and other networks, including any wireless 
networks.  1 
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.1 
1.2.5 All services, protocols , and ports allowed  are identified, approved, and 
have a defined business need.  2 
1.2.6 Security features are defined and implemented for all services, 
protocols, and ports that are in use and considered to be insecure, such that 
the risk is mitigated.  2

©2016 – 2022 PCI Securit y Standar ds Council LLC. The intent of this document is to provide 
August 2022 4 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
1.2.7 Configurations of NSCs are reviewed at least once every six months 
to confirm they are relevant and effective.  6 
1.2.8 Configuration files for NSCs are: 
•Secured from unauthorized access.
•Kept consistent with active network configurations.2 
1.3 Network access to and from the cardholder data environment is restricted.  
1.3.1 Inbound traffic to the CDE is restricted as follows: 
•To only traffic that is necessary .
•All other traffic is specifically denied.2 
1.3.2 Outbound traffic from the CDE is restricted as follows: 
•To only traffic that is necessary.
1.3.3 NSCs are installed between all wireless networks and the CDE,

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 pur pose is allowed int o
the CDE.2 
1.4 Network connections between trusted and untrusted networks are controlled.  
1.4.1 NSCs are implemented between trusted and untrusted networks.  2 
1.4.2 Inbound traffic from untrusted networks to trusted networks is 
restricted to:

default.
the CDE.2 
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 i n
a trusted network.
•All other traffic is denied.2 
1.4.3 Anti-spoofing measures are implemented to detect  and block forged 
source IP addresses from entering the trusted network.  2 
1.4.4 System components that store cardholder data are not directly 
accessible from untrusted networks.  2

Augus t 2022 5 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
1.4.5 The disclosure of internal IP addresses and routing information is 
limited to only authorized parties.  2 
1.5 Risks to the CDE from computing devices that are able to  connect to both 
untrusted networks and the CDE are mitigated. 
1.5.1 Security controls are implemented on any computing devices, 
including company-  and employee- owned devices, that connect to both 
untrusted networks (including the Internet) and the CDE as follows :  
•Specific configuration settings are defined to prevent thr eats bei ng
introduced into the entity’s network.
•Security controls are actively running.
•Security controls are not alterable by users of the computing devices

unless specifically documented and authorized by management on a
case -by-case basis for a limite d period.2 
Requirement 2:  Apply Secure Configurations to All System Components  
2.1 Processes and mechanisms for applying secure configurations to all system 
components are defined and understood.  
2.1.1 All security policies and operational procedures that are identified in 
Requirement 2 are:  
•Kept up to date .
•In use .
•Known to all affected parties.6

•In use .
2.1.2 Roles and responsibilities for performing activities in Requirement 2 

August 2022 6 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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 updat ed as new vulnerability issues are identified, as defined i n
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 .2 
2.2.2 Vendor default accounts  are managed as follows:  
•If the vendor default account(s) will be used, the default password i s
changed  per Requirement 8.3.6.

•If the vendor default account(s) will not be used, the account is removed
or disabled.2 
2.2.3 Primary functions requiring different security levels are managed as 
follows:  
•Only one primary  function exists on a system component,
OR
•Primary functions with differing security levels that exist on the same
system component are isolated from each other,
OR 
•Primary functions with differing security levels on the same systemcomponent are all secured to the level required by the function with t
he
highest security need.2

follows:  
OR
OR 
he
highest security need.2 
2.2.4 Only necessary services, protocols, daemons, and functions are 
enabled, and all unnecessary functionality is removed or disabled.  2 
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.2 
2.2.6 System security parameters are configured to prevent misuse.  2 
2.2.7 All non- console administrative access  is encrypted using strong 
cryptography. 2

August 2022 7 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
2.3 Wireless environments are configured and managed securely.  
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 o n wireless access  points.
•SNMP defaults.
•Any other security -related wireless vendor defaults .2 
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.2 
Requirement 3: Protect Stored Account Data 
3.1 Processes and mechanisms for protecting stored account data  are defined 
and understood.  
3.1.1 All security policies and operational procedures that are identified in 
Requirement 3 are:  
•In use .
3.1.2 Roles and responsibilities for performing activities in Requirement 3 
3.2 Storage of account data  is kept to a minimum.

Augus t 2022 8 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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 a ny sensitive authentication data ( SAD) stored prior t o
completion of authorization. This bullet is a best practice until 31 Mar ch
2025; refer to Applicability Notes in PCI DSS for  details.
•Limiting data storage amount and retention time to that which is requir ed
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 or rendering account data unrecovera ble
when no longer needed per the retention policy.
•A process for verifying, at least once every three months, that stored
account data exceeding the defined retention period has been securel y
deleted or rendered unrecoverable.1 
3.3 Sensitive authentication data (SAD) is not stored after authorization.  
3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive 
authentication data received is rendered unrecoverable upon completion of

authentication data received is rendered unrecoverable upon completion of 
the authorization process.  1 
3.3.1.1 The full contents of any track are not retained upon completion 
of the authorization process.  1 
3.3.1.2 The card verification code is not retained upon completion of the 
authorization process.  1 
3.3.1.3 The personal identification number (PIN) and the PIN block are 
not retained upon completion of the authorization process.  1 
3.3.2 SAD that is stored electronically prior to completion of authorization is 
encrypted using strong cryptography.

encrypted using strong cryptography.  
This re quirement is a best practice until 31 March 2025; refer to Applicability 
Notes in PCI DSS for details.  1

August 2022 9 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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; refer to Applicability Notes in PCI DSS  for details.1 
3.4 Access to displays of full PAN and ability to copy PAN is restricted.  
3.4.1 PAN is masked when displayed (the BIN and last four digits are the 
maximum number  of digits to be displayed), such that only personnel with

maximum number  of digits to be displayed), such that only personnel with 
a legitimate business need can see more than  the BIN and last four digits 
of the PAN.  5 
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.  
This requirement is a best practice until 31 March 2025; refer to Applicability 
Notes in PCI DSS for details.  5 
3.5 Primary account number ( PAN)  is secured wherever it is stored.

3.5 Primary account number ( PAN)  is secured wherever it is stored.  
3.5.1 PAN is rendered unreadable anywhere it is stored by using any of the 
following approaches:  
•One-way hashes based on strong cryptography of the entire PAN.
•Truncation (hashing cannot be used to replace the truncated segment o f
PAN).
–If hashed and truncate d versions of the same PAN , or different
truncation formats of the same PAN,  are present in an environment,
additional controls are in place such that the different  versions cannot
be correlated to reconstruct the original PAN.
•Index tokens.

PAN).
•Strong cryptog raphy with associated key -management processes and
procedures.5 
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.   
This requirement is a best practice until 31 March 2025; refer to 
Applicability Notes in PCI DSS for details. 5

August 2022 10 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
3.5.1.2 If disk -level or partition- level encryption (rather than file -, 
column- , or field -level database encryption) is used to render PAN 
unreadable, it is implemented only as follows: 
•On removable electronic media
OR
•If used for non -removable electronic media, PAN is also rendered
unreadable via another mechanism that meets Requirement 3.5.1.
Applicability Notes in PCI DSS for details. 5 
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:

OR
it is managed as follows:  
•Logical access is managed separately and independently of nati ve
operating system authentication and access control mechanisms.
•Decryption keys are not associated with user accounts .
•Authentication factors (passwords, passphrases, or cryptographi c
keys)  that allow access to unencrypted data are stored securely .5 
3.6 Cryptographic keys used to protect stored account data  are secured.  
3.6.1 Procedures are defined and implemented to protect cryptographic 
keys used to protect stored account data against disclosure and misuse that 
include:

include:  
•Access to keys is restricted to the fewest number of custodians
necessary.
•Key-encrypting keys are at least as strong as the data -encrypting keys
they protec t.
•Key-encrypting keys are stored separately from data- encrypting keys.
•Keys are stored securely in the fewest possible locations and forms.5

August 2022 11 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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 producti on
and test environments.  This bullet is a best practice until 31 March
2025; refer to Applicability Notes in PCI DSS for details.
•Description of the key usage for each key.
•Inventory of any hardware security modules (HSMs), key
management systems (KMS), and other secure cryptographicdevices (SCDs) used for key management, including type 
and

and
location of devices, as outlined in Requirement 12.3. 4.5 
3.6.1.2 Secret and private keys used to encrypt/decrypt stored 
account data  are stored in one (or more) of the following forms at all 
times:  
•Encrypted with a key -encrypting key that is at least as strong as t he
data- encrypting key, and that is stored separately from the data -
encrypting key.
•Within a secure cryptographic device (SCD), such as a hardware
security module (HSM) or PTS -approved point -of-interaction
device.

and
times:  
device.
•As at least two full -length key components or key shares , in
accordance with an industry- accepted method.5 
3.6.1.3 Access to cleartext cryptographic key components is restricted 
to the fewest number of custodians necessary.  5 
3.6.1.4 Cryptographic keys are stored in the fewest possible locations. 5 
3.7 Where cryptography is used to protect stored account data , key management 
processes and procedures covering all aspects of the key lifecycle are defined 
and implemented.

device.
and implemented.  
3.7.1 Key-management policies and procedures are implemented to include 
generation of strong cryptographic keys used to protect stored account 
data.  5 
3.7.2 Key-management policies and procedures are implemented to include 
secure distribution of cryptographic keys used to protect stored account 
data.  5 
3.7.3 Key-management policies and procedures are implemented to include 
secure storage of cryptograph ic keys used to protect stored account data . 5

August 2022 12 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.5 
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 f or encryption operations .5 
3.7.6 Where manual cleartext cryptographic key -management operations 
are performed by personnel, key- management policies and procedures are 
implemented include managing these operations using split knowledge and 
dual control.  5

dual control.  5 
3.7.7 Key management policies and procedures are implemented to include 
the prevention of unauthorized substitution of cryptographic keys.  5 
3.7.8 Key management policies and procedures are implemented to include 
that cryptographic key custodians formall y acknowledge (in writing or 
electronically) that they understand and accept their key- custodian 
responsibilities.  5 
3.7.9 Additional requirement for service providers only:  Where a 
service provider shares cryptographic keys with its customers for

service provider shares cryptographic keys with its customers for 
transmission or storage of account data , guidance on secure transmission, 
storage and updating of such keys is documented and distributed to the service provider ’s customers.  5 
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission 
Over Open, Public Networks  
4.1 Processes and mechanisms for protecting cardholder data with strong 
cryptography during transmission over open, public networks  are defined and 
documented.

August 2022 13 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
4.1.1 All security policies and operational procedures that are identified in 
Requirement 4 are:  
•In use .
•Known to all  affected parties.6 
4.1.2 Roles and responsibilities for performing activities in Requirement 4 
4.2 PAN is protected with strong cryptography during transmission.  
4.2.1 Strong cryptography and security protocols are implemented as 
follows to safeguard PAN during transmission over open, public networks:  
•Only trusted keys and certificates are accepted.
•Certificates used to safeguard PAN during transmission over open,
publi c networks are confirmed as valid and are not expired or revoked.

This bullet is a best practice until 31 March 2025; refer to Applicability
Notes in PCI DSS for details.
•The protocol in use supports only secure versions or configurations and
does not supp ort fallback to, or use of insecure versions, algorithms, key
sizes, or implementations.
•The encryption strength is appropriate for the encryption  methodology in
use.2 
4.2.1.1 An inventory of the entity’s  trusted keys and certificates used 
to protect PAN during transmission is maintained. 
This requirement is a best practice until 31 March 2025; refer to

use.2 
Applicability Notes in PCI DSS for details. 2 
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.  2 
4.2.2 PAN is secured with strong cryptography whenever it is sent via end-
user messaging technologies.  2 
Requirement 5:  Protect All Systems and Networks from Malicious Software  
5.1 Processes and mechanisms for protecting all systems and networks from 
malicious software are defined and understood.

August 2022 14 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
5.1.1 All security policies and operational procedures that are identified in 
Requirement 5 are:  
•In use .
5.1.2 Roles and responsibilities for performing activities in Requirement 5 
5.2 Malicious software (malware) is prevented , or detected and addressed.  
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.  2 
5.2.2 The deployed anti-malware  solution(s):  
•Detects all known types of malware.

•Removes, blocks, or contains all known types of malware.2 
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.2 
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

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.   
This requirement is a best p ractice until 31 March 2025; refer to 
5.3 Anti-malware  mechanisms and processes are active, maintained, and 
monitored.  
5.3.1 The anti -malware solution(s) is kept current via automatic updates.  2

August 2022 15 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
5.3.2 The anti-malware  solution(s):  
•Performs periodic scans and active or real -time scans .
OR
•Performs continuous behavioral  analysis of systems or processes.2 
5.3.2.1 If periodic malware scans are performed to meet Requirement 
5.3.2, t he 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.  
This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details. 2 
5.3.3 For removable electronic media, the anti -malware  solution (s): 
•Performs automatic scans of when the media is inserted, connected, or
logically mounted,
OR

OR
•Performs continuous behavioral analysis of systems or processes when
the media is inserted, connected , or logically mounted.
Notes in PCI DSS for details.  2 
5.3.4 Audit logs for the anti-malware  solution (s) are enabled and retained in 
accordance with Requirement 10.5.1.  2 
5.3.5 Anti-malware  mechanisms cannot be disabled or altered by users, 
unless specifically documented, and authorized by management on a case -

OR
by-case basis for a limited time period.  2 
5.4 Anti-phishing mechanisms protect users against phishing attacks.  
5.4.1 Processes and automated mechanisms are in place to detect and 
protect personnel against phishing attacks.   
Requirement 6:  Develop and Maintain Secure Systems and Software  
6.1 Processes and mechanisms for developing and maintaining secure systems

6.1 Processes and mechanisms for developing and maintaining secure systems 
and software are defined and understood.

August 2022 16 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
6.1.1 All security policies and operational procedures that are identified in 
Requirement 6 are:  
•In use .
6.1.2 Roles and responsibilities for performing activities in Requirement 6 
6.2 Bespoke and custom software are developed securely.  
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 informat ion security issues during each
stage of the software development lifecycle.3

logging).
stage of the software development lifecycle.3 
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 fo r
detecting vulnerabilities in software.3 
6.2.3 Bespoke and custom software is reviewed prior to being released into 
production or to customers, to identify and correct potential coding 
vulnerabilities, as follows:

vulnerabilities, as follows:  
•Code reviews ensure code is developed according to secure coding
guidelines.
•Code review s look for both existing and emerging softwar e
•Appropriate corrections are implemented prior to release.3 
6.2.3.1 If manual code reviews are performed for bespoke and custom 
software prior to release to production, code changes are:  
•Reviewed by individuals other than the originating code author, and
who are knowledgeable about code -review techniques and secure
coding  practices.

•Reviewed and approved by management prior to release.3

August 2022 17 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
6.2.4 Software engineering techniques or other methods are defined and in 
use by software development personnel to prevent or mitigate common 
software attacks and related vulnerabilities  in bespoke and custom 
software, including but not limited to the following : 
•Injection attacks, including SQL, LDAP, XPath, or other command ,
parameter, object, fault, or injection -type flaws.
•Attacks on data and data structures, including attempts to manipulate
buffers, pointers, input data, or shared data.
•Attacks on cryptograp hy usage, including attempts to exploit weak,
insecure, or inappropriate cryptographic implementations, algorithms,cipher suites, or modes of operation.

•Attacks on business logic, including attempts to abuse or bypassapplication features and functionalit ies through the manipulation of APIs,
communication protocols and channels, client -side functionality, or other
system/application functions and resources. This includes cross -sit
e
scripting (XSS) and cross -site request forgery (CSRF).
•Attacks on access co ntrol mechanisms, including attempts to bypass or
abuse identification, authentication, or authorization mechanisms, o r
attempts to exploit weaknesses in the implementation of such

e
mechanisms.
•Attacks via any “high -risk” vulnerabilities identified in the v ulnerabilit y
identification process, as defined in Requirement 6.3.1.3 
6.3 Security vulnerabilities are identified and addressed.  
6.3.1 Security vulnerabilities are identified and managed as follows: 
•New security vulnerabilities are identified using industry -recognized
sources for security vulnerability information, including alerts from
international and national computer emergency response teams
(CERTs) .
•Vulnerabilities are assigned a risk ranking based on industry best
practices and consideration of potential impact.

(CERTs) .
•Risk rankings  identify , at a minimum, all vulnerabilities considered to be
a high- risk or critical to the environment .
•Vulnerabilities for bespoke and custom, and third -party software (for
example operating systems and databases) are covered.3 
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.  
This requirement is a best practice until 31 March 2025; refer t o Applicability

This requirement is a best practice until 31 March 2025; refer t o Applicability 
Notes in PCI DSS for details.  3

August 2022 18 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
6.3.3 All system components are protected from known vulnerabilities by 
installing applicable security patches/updates  as follows:  
•Critical or high -security patches /updates (identified according to the ri sk
ranking process at Requirement 6.3.1 ) are installed within one month o f
release .
•All other applicable security patches/updates are installed within an
appropriate time frame as determined by the entity (for example, withi n
three month s of release).3 
6.4 Public -facing web applications are protected against attacks.  
6.4.1 For public -facing web applications, new threats and vulnerabilities are 
addressed on an ongoing basis and these applications are protected

release .
addressed on an ongoing basis and these applications are protected 
against known attacks as follows:  
•Reviewing public -facing web applications via manual or automated
application vulnerability security assessment tools or methods as follows:
–At least once every 12 months and after significant changes.
–By an entity that specializes in application security.
–Including, at a minimum, all common software attacks in Requiremen t
6.2.4.
–All vul nerabilities are ranked in accordance with requirement 6.3.1.
–All vulnerabilities are corrected.
–The application is re -evaluated after the corrections
OR

6.2.4.
OR 
•Installing an automated technical solution(s) that continually detects and
prevents web- based attacks as follows:
–Installed in front of public -facing web applications to detect and
prevent web- based attacks.
–Actively running and up to date as applicable.
–Generating audit logs .
–Configured to either block web -based attacks or generate an alert
that is immediately investigated.3

August 2022 19 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.
•Actively running and up to date as applicable.
•Generating audit logs.
•Configured to either block web -based attacks or generate an alert that i s
immediately investiga ted.
Notes in PCI DSS for details.  3 
6.4.3 All payment page scripts that are loaded and executed in the 
consumer’s browser are managed as follows:

consumer’s browser are managed as follows:  
•A method is implemented to confirm that each script is authorized.
•A method is implemented to assure the integrity of each script.
•An inventory of all  scripts is maintained with written justification as  to why
each is necessary.
6.5 Changes to all system components are managed securely.  
6.5.1 Changes to all system components in the production environment are 
made according to established procedures that include:

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 int o
production.
•Procedures to address failures and return to a secure state.6 
6.5.2 Upon completion of a significant change, all applicable PCI DSS

security.
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.  6 
6.5.3 Pre-production environments are separated from production 
environments and the separation is enforced with access controls.  3

August 2022 20 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
6.5.4 Roles and functions are separated between production and pre -
production environments to provide accountability such that only reviewed 
and approved changes are deployed.  3 
6.5.5 Live PANs are not used in pre -production environments, except where 
those environments are included in the CDE and protected in accordance 
with all applicable PCI DSS requirements.  3 
6.5.6 Test data and test accounts  are removed from system components 
before the system goes into production.  3 
Requirement 7: Restrict Access to System Components and Cardholder Data by Business 
Need to Know  
7.1 Processes and mechanisms for restricting access to system components and

7.1 Processes and mechanisms for restricting access to system components and 
cardholder data by business need to know are defined and understood.  
7.1.1 All security policies and operational procedures that are identified in 
Requirement 7 are:  
•In use .
7.1.2 Roles and responsibilities for performing activities in Requirement 7 
7.2 Access to system components and data is appropriately defined and 
assigned.  
7.2.1 An access control model is defined and includes granting access as

•In use .
assigned.  
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.4 
7.2.2 Access is assigned to users, including privileged users, based on: 
•Job classification and function.
•Least privileges necessary to perform job responsibilities .4

August 2022 21 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
7.2.3 Required privileges are approved by authorized personnel.  4 
7.2.4 All user accounts  and related access privileges, including third -
party/vendor accounts, are reviewed as follows:  
•At least once every six months .
•To ensure user accounts and access remain appropriate based on j ob
function .
•Any inappropriate access is addressed.
•Management acknowledges that access remains appropriate.
Notes in PCI DSS for details.  4 
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

function .
or application.
•Access is limited to the systems, applications, or processes that
specifically require their use.
7.2.5.1 All access by application and system accounts  and related 
access privileges are reviewed as follows:  
•Periodically (at the frequency defined in the entity’s targeted risk
analysis, which is performed according to all elements specified i n
Requirement 12.3.1).

•The application /system access remains appr opriate for the functi on
being performed.
Applicability Notes in PCI DSS for details. 4 
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 quer y
repositories of stored CHD.4 
7.3 Access to system components and data is managed via an access control 
system(s).

August 2022 22 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.  4 
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.  4 
7.3.3 The access control system(s) is set to “deny all” by default.  4 
Requirement 8: 
8.1 Processes and mechanisms for identifying users and authenticating access to 
system components are defined and understood.  
8.1.1 All security policies and operational procedures that are identified in 
Requirement 8 are:  
•In use .

•In use .
8.1.2 Roles and responsibilities for performing activities in Requirement 8 
8.2 User identification and related accounts  for users and administrators are 
strictly managed throughout an account’s lifecycle.  
8.2.1 All users are assigned a unique ID before access to system 
components or cardholder data is allowed.  2 
8.2.2 Group, shared, or generic accounts , or other shared authentication 
credentials  are only used when necessary  on an exception basis, and are

credentials  are only used when necessary  on an exception basis, and are 
managed as follows:  
•Account use is prevented unless needed for an exceptional
circumstance.
•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 i s
granted.
•Every action taken is attributable to an individual user.2

August 2022 23 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.  2 
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.2 
8.2.5 Access for terminated users is immediately revoked.  2 
8.2.6 Inactive user accounts  are removed or disabled within 90 days of 
inactivity.  2 
8.2.7 Accounts  used by third parties to access, support, or maintain system

8.2.7 Accounts  used by third parties to access, support, or maintain system 
components via remote access are managed as follows:  
•Enabled only during the time period needed and disabled when not in
use.
•Use is  monitored for unexpected activity.2 
8.2.8 If a user session has been idle for more than 15 minutes, the user is 
required to re -authenticate to re- activate the terminal or session.  2 
8.3 Strong authentication for users and administrators is established and 
managed.  
8.3.1 All user access to system components for users and administrators is

use.
managed.  
8.3.1 All user access to system components for users and administrators is 
authenticated via at least one of the following authentication factors:  
•Something you know, such as a password or passphrase.
•Something you have, such as a token device or smart card.
•Something you are, such as a biometric element.2 
8.3.2 Strong cryptography is used to render all authentication factors 
unreadable during transmission and storage on all system components.  2 
8.3.3 User identity is verified before modifying any authentication factor . 2 
8.3.4 Invalid authentication attempts are limited by:

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 t he
user’s identity is confirmed.2

August 2022 24 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
8.3.5 If passwords /passphrases are used as authentication factors to meet 
Requirement 8.3.1, they are set and reset for each user as follows:  
•Set to a unique value for first -time use and upon reset.
•Forced to be changed  immediately after the first use.2 
8.3.6 If passwords /passphrases are used as authentication factors to meet 
Requirement 8.3.1, they meet the following minimum level of complexity:  
•A minimum length of 12 characters (or IF the system does not support 12
characters, a minimum length of eight characters).
•Contain both numeric and alphabetic characters.

Notes in PCI DSS for details.  
Until 31 March 2025, passwords must be a minimum length of seven 
characters in accordance with PCI  DSS v3.2.1 Requirement 8.2.3.  2 
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.  2 
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 suspici on
or knowledge that the password /passphrases ha ve been compromi sed
and how to report the incident.4 
8.3.9 If passwords /passphrases are used as the only authentication factor  
for user access (i.e., in any single -factor authentication implementation) 
then either: 
•Passwords/passphrases are changed at least once every 90 days,
OR

OR
•The security posture of accounts  is dynamically analyzed, and real -time
access to resources is automatically determined accordingly.2

August 2022 25 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
8.3.10 Additional requirement for service providers only:  If 
passwords /passphrases are used as the only authentication factor  for 
customer user ac cess 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 /passphr ases
periodically.
•Guidance as to when, and under what circumstances,
passwords /passphrases are to be changed.2 
8.3.10.1 Additional requirement for service providers only:  If 
customer user access (i.e., in any single -factor auth entication

customer user access (i.e., in any single -factor auth entication 
implementation) then either:  
•Passwords /passphrases  are changed at least once every 90 days,
OR
•The security posture of accounts  is dynamically analyzed, and real -
time access to resources is automatically determined accordingly .
8.3.11 Where authentication factors such as physical or logical security 
tokens, smart cards, or certificates are used:  
•Factors are assigned to an individual user and not shared among

OR
multiple users.
•Physical and/or logical controls ensure only the intended user can use
that factor to gain access.4 
8.4 Multi -factor authentication (MFA) is implemented to secure access into the 
CDE.  
8.4.1 MFA is implemented for all non -console access into the CDE for 
personnel with administrative access .  2 
8.4.2 MFA is implemented for all access into the CDE.  
Notes in PCI DSS for details.  2

CDE.  
8.4.3 MFA is implemented for all remote network access originating from 
outside the entity’s network that could access or impact the CDE as follows:  
•All remote access by all personnel, both users and adm inistrators,
originating from outside the entity’s network.
•All remote access by third parties and vendors.2

August 2022 26 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
8.5 Multi -factor authentication (MFA) systems are configured to prevent misuse.  
8.5.1 MFA systems are implemented as follows:  
•The MFA system is not susceptible to replay attacks.
•MFA systems cannot be bypassed by any users, including administrative
users unless specifically documented, and authorized by management
on an exception basis, fo r a limited time period .
•At least two different types of authentication factors are used.
•Success of all authentication factors is required before access is  granted.

8.6 Use of application and system accounts  and associated authentication factors 
is strictly managed.  
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
•Interactive use is limited to the time needed for the exceptional
•Business justification for interactive use is documented.
•Interactive use is explicitly approved by managemen t.

•Individual user identity is confirmed before access to account is granted.
•Every action taken is attributable to an individual user.
This requirement is a best practice until 3 1 March 2025; refer to Applicability 
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.

configuration/property files, or bespoke and custom source code.  
Notes in PCI DSS for details.  4

August 2022 27 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
8.6.3 Passwords/passphrases for any application and system accounts  are 
protected against misuse as follows:  
•Passwords/passphrases are changed periodically (at the fr equency
defined in the entity’s targeted risk analysis, which is perform ed
according to all elements specified in Requirement 12.3.1) and upon
suspicion or confirmation of compromise.
•Passwords/passphrases are constructed with sufficient  complexit y
appropriate for how frequently the entity changes t he
passwords/passphrases.
This requirement i s a best practice until 31 March 2025; refer to Applicability 
Requirement 9:  Restrict Physical Access to Cardholder Data

Requirement 9:  Restrict Physical Access to Cardholder Data  
9.1 Processes and mechanisms for restricting physical access to cardholder data 
are defined and understood.  
9.1.1 All security policies and operational procedures that are identified in 
Requirement 9 are:  
•In use .
9.1.2 Roles and responsibilities for performing activities in Requirement 9 
9.2 Physical access controls manage entry into facilities and systems containing 
cardholder data.

•In use .
cardholder data. 
9.2.1 Appropriate facility entry controls are in place to restrict physical 
access to systems in the CDE.  2 
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.2

August 2022 28 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
9.2.2 Physical and/or logical controls are implemented to restrict use of 
publicly accessible network jacks within the facility.  2 
9.2.3 Physical access  to wireless access points, gateways, 
networking/communications hardware, and telecommunication lines within 
the facility is restricted.  2 
9.2.4 Access to consoles in sensitive areas is restricted via locking when 
not in use.  2 
9.3 Physical access for personnel and visitors is authorized and managed.  
9.3.1 Procedures are implemented for authorizing and managing physical 
access of personnel to the CDE, including:  
•Identifying personnel.
•Managing changes to an individual’s physical access requirements.

•Revoking or terminating personnel identification.
•Limiting access to the identification process or system to authorized
personnel.5 
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.2 
9.3.2 Procedures are implemented for authorizing and managing visitor

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 identificati on
that expires.
•Visitor badges or other identification visibly distinguishes visitors from
9.3.3 Visitor badges or identification are surrendered or deactivated before 
visitors leave the facility or at the date of expiration.  5

August 2022 29 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
9.3.4 A visitor log is used to maintain a physical record of visitor activity 
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.5 
9.4 Media with cardholder data is securely stored, accessed, distributed, and 
destroyed.  
9.4.1 All media with cardholder data is physically secured.  5 
9.4.1.1  Offline media backups with cardholder data are stored in a 
secure location. 5 
9.4.1.2 The security of the offline media backup location(s) with

law.5 
9.4.1.2 The security of the offline media backup location(s) with 
cardholder data is reviewed at least once every 12 months.  5 
9.4.2 All media with cardholder data is classified in accordance with the 
sensitivity of the data.  5 
9.4.3 Media with cardholder data sent outside the facility is secured as 
follows: 
•Media sent outside the facility is logged.
•Media is sent by secured courier or other delivery method that can be
accurately tracked.
•Offsite tracking logs include details about media location.5 
9.4.4 Management approves all media with cardholder data that is moved

follows: 
9.4.4 Management approves all media with cardholder data that is moved 
outside the facility (including when media is distributed to individuals).  5 
9.4.5 Inventory logs of all electronic media with cardholder data are 
maintained.  5 
9.4.5.1 Inventories of electronic media with cardholder data are 
conducted at least once every 12 months.  5 
9.4.6 Hard -copy materials with cardholder data are destroyed when no 
longer needed for business or legal reasons, as follows:  
•Materials are cross -cut shredded, incinerated, or pulped so that
cardholder data cannot be reconstructed.

•Materials are stored in secu re storage containers prior to destruction.1

August 2022 30 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.1 
9.5 Point -of-interaction (POI) devices are protected from tampering and 
unauthorized substitution.  
9.5.1 POI devices that capture payment card data via direct physical 
interaction with the payment card form factor are protected from tampering 
and unauthorized substitution, including the following: 
•Maintaining a list of POI devices.
•Periodically inspecting P OI devices to look for tampering or
unauthorized substitution.

•Training personnel to be aware of suspicious behavior and to report
tampering or unauthorized substitution of devices.2 
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 method s of unique identification.2 
9.5.1.2 POI device surfaces are periodically inspected to detect 
tampering and unauthorized substitution.  2 
9.5.1.2.1 The frequency of periodic POI device inspections and the 
type of inspections performed is defined in the entity’s targeted risk

type of inspections performed is defined in the entity’s targeted risk 
This requirement is a best practice unt il 31 March 2025; refer to 
Applicability Notes in PCI DSS for details. 2

August 2022 31 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
9.5.1.3 Training is provided for personnel in POI environments to be 
aware of attempted tampering or replacement of POI devices, and 
includes: 
•Verifying the identity of any third -party persons claiming to be repair
or maintenance personnel, before granting them a ccess to modify or
troubleshoot devices.
•Procedures to ensure devices are not installed, replaced, or returnedwithout verification.
•Being aware of suspicious behavior around devices.
•Reporting suspicious behavior and indications of device tampering
or substitution to appropriate personnel.2 
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data  
10.1 Processes and mechanisms for logging and monitoring all access to system 
components and cardholder data are defined and documented.  
10.1.1 All security policies and operational procedures that are identified in 
Requirement 10 are:  
•In use .
10.1.2 Roles and responsibilities for performing activities in Requirement 10 
are documented, assigned, and understood.  6

•In use .
10.2 Audit logs  are implemented to support the detection of anomalies and 
suspicious activity, and the forensic analysis of events.  4 
10.2.1 Audit logs are enabled and active for all system components and 
cardholder data. 4 
10.2.1.1 Audit logs  capture all individual user access to cardholder 
data.  4 
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 . 4 
10.2.1.3 Audit logs  capture all access to audit logs.  4

data.  4 
10.2.1.3 Audit logs  capture all access to audit logs.  4 
10.2.1.4 Audit logs  capture all invalid logical access attempts.  4

August 2022 32 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
10.2.1.5 Audit logs capture all changes to identification and 
authentication credentials including, but not limited to:  
•Creation of new accounts .
•Elevation of privileges.
•All changes, additions, or deletions to accounts with administrati ve
access .4 
10.2.1.6 Audit logs  capture the following: 
•All initialization of new audit logs, and
•All starting, stopping, or pausing of the existing audit logs.4 
10.2.1.7 Audit logs  capture all creation and deletion of system -level 
objects.  4 
10.2.2 Audit logs  record the following details for each auditable event:  
•User identification.
•Type of event.
•Date and time.
•Success and failure indication.
•Origination of event.

access .4 
objects.  4 
•Identity or name of affected data, system component, resource, o r
service (for example, name and protocol).4 
10.3 Audit logs  are protected from destruction and unauthorized modifications. 
10.3.1 Read access to audit logs files is limited to those with a job -related 
need.  4 
10.3.2 Audit log files are protected to prevent modifications by individuals.  4 
10.3.3 Audit log files, including those for external -facing technologies, are

need.  4 
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.  4 
10.3.4 File integrity monitoring or change -detection mechanisms is used on 
audit logs to ensure that existing log data cannot be changed without 
generating alerts.  4

August 2022 33 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
10.4 Audit logs  are reviewed to identify anomalies or suspicious activity.  
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 securit y
functions (for example, network security controls, intrusion -detecti on
systems/intrusion -prevention systems (IDS/IPS), authentication servers).4 
10.4.1.1 Automated mechanisms are used to perform audit log reviews.  
Applicability Notes in PCI DSS for details. 4

10.4.2 Logs of all other system components (those not specified in 
Requirement 10.4.1) are reviewed periodically . 4 
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 . 
10.4.3 Exceptions and anomalies identified during the review process are 
addressed.  4

addressed.  4 
10.5 Audit log history is retained and available for analysis.  
10.5.1 Retain audit log history for at least 12 months, with at least the most 
recent three months immediately available for analysis.  4

August 2022 34 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
10.6 Time -synchronization mechanisms support consistent time settings across 
all systems.  
10.6.1 System clocks and time are synchronized using time -synchronization 
technology.  4 
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 so urces.

sources.
•Where there is more than one designated time server, the time serverspeer with one another to keep accurate time.
•Internal systems receive time information only from designated central
time server(s).4 
10.6.3 Time synchronization settings and data are protected as follows: 
•Access to time data is restricted to only personnel with a business need.
•Any changes to time settings on critical systems are logged, monitored,
and reviewed.4 
10.7 Failures of critical security control systems are detected, reported, and 
responded to promptly.

responded to promptly.  
10.7.1 Additional requirement for service providers only:  Failures of 
critical security control systems are detected, alerted, and addressed 
promptly, including but not limited to failure of the following critical security 
control systems:  
•Network security controls .
•IDS/IPS .
•FIM.
•Anti-malware  solutions .
•Physical access controls .
•Logical access controls .
•Audit logging mechanisms.
•Segmentation controls (if used) .4

August 2022 35 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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:  
•IDS/IPS .
•Change -detection mechanisms.
•Segmentation controls (if used) .
•Audit log review mechanisms.
•Automated security testing  tools (if used) .
10.7.3 Failures of any critical security controls systems are responded to

•IDS/IPS .
10.7.3 Failures of any critical security controls systems are responded to 
promptly, including but not limited to:  
•Restoring security functions.
•Identifying and documenting the duration (date and time from start t o
end) of the security failure.
•Identifying an d documenting the cause(s) of failure and documenti ng
required remediation .
•Identifying and addressing any security issues that arose during the
failure .
•Determining whether further actions are required as a result of thesecurity failure.
•Implementing controls to prevent the cause of failure from reoccurring.

failure .
•Resuming monitoring of security controls.
This is a PCI DSS v3.2.1 requirement that applies to service providers only. 
This requirement is a best practice for all other entities until 31 March 202 5; 
refer to Applicability Notes in PCI DSS for details.  4 
Requirement 11:  Test Security of Systems and Networks Regularly  
11.1 Processes and mechanisms for regularly testing security of systems and 
networks are defined and understood.

August 2022 36 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
11.1.1 All security policies and operational procedures that are identified in 
Requirement 11 are:  
•In use .
11.1.2 Roles and responsibilities for performing activities in Requirement 11 
11.2 Wireless access points are identified and monitored, and unauthorized 
wireless access points are addressed.  
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,

follows: 
•Testing, detection, and identifi cation occurs at least once every thr ee
months.
•If automated monitoring is used, personnel are notified via generated
alerts.4 
11.2.2 An inventory of authorized wireless access points is maintained, 
including a documented business justification.  4 
11.3 External and internal vulnerabilities are regularly identified, prioritized, and 
addressed.  
11.3.1 Internal vulnerability scans are performed as follows: 
•At least once every three months.

months.
alerts.4 
•High-risk and critical vulnerabilities (per the entity’s vulnerability risk
rankings defined at Requirement 6.3.1) are resolved.
•Rescans are performed that confirm a ll 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.2

August 2022 37 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
11.3.1.1 All other applicable vulnerabilities (those not ranked as high -
risk or critical per 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
Requirement 12.3.1.
•Rescans are conducted as needed.
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 accep t
credentials for scannin g.
•If accounts  used for authenticated scanning can be used for
interactive login, they are managed in accordance withRequirement 8.2.2.
11.3.1.3 Internal vulnerability scans are performed after any significant 
change as follows: 

rankings defined at Requirement 6.3.1 ) are resolved.
•Rescans are conducted as needed .
independence of the tester exists (not required to be a QSA or
ASV).2 
11.3.2 External vulnerability scans are performed as follows:  
•By a PCI SSC Approved Scanning Vendor ( ASV).
•Vulnerabilities are resolved and ASV Program Guide requirements for a
passing scan are met.

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

August 2022 38 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
11.3.2.1 External  vulnerability scans are performed after any significant 
•Vulnerabilities that are scored 4.0 or higher by the CVSS are
resolved.
independence of the tester exists (not required to be a QSA or ASV).2 
11.4 External and internal penetration testing is regularly performed, and 
exploitable vulnerabilities and security weaknesses are corrected.  
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 secu rity weaknesses found during
penetration testing.
•Retention of penetration testing results and remediation activities resultsfor at least 12 months.2 
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

•Organizational independence of the tester exists (not required to be a
QSA or ASV).2

August 2022 39 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
11.4.3 External  penetration testing is performed: 
•Per the entity’s defined methodology
•By a qualified internal resource or qualified external third party
QSA or ASV).2 
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.2

•Penetration testing is repeated to verify the corrections.2 
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 and
effective, and isolate the CDE from all out -of-scope systems.

•Confirming effectiveness of any use of isolation to separate systems withdiffering security levels (see Requirement 2.2.3).
•Performed by a qualified internal resource or qualified external third
party.

August 2022 40 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
11.4.6 Additional requirement for service providers only:  If 
segmentation is used to isolate the CDE from other networks, penetration 
tests are performed on segmentation controls as follows:  
•At least once every six months and after any changes to segmentation
controls/methods.
effective, and isolate the CDE from all out- of-scope systems.

•Performed by a qualified internal resource or qua lified external third
party.
•Organizational independence of the tester exists (not required to be aQSA or ASV).2 
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. 
11.5 Network intrusions and unexpected file changes are detected and

party.
11.5 Network intrusions and unexpected file changes are detected and 
responded to.  
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 signatur es
are kept up to date.2 
11.5.1.1 Additional requirement for service providers only:

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.  

August 2022 41 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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 l east once weekly .4 
11.6 Unauthorized changes on payment pages are detected and responded to.  
11.6.1 A change - and tamper -detection mechanism is deployed as follows:  
•To alert personnel to unauthorized modification (including indicators of
compromise, changes, additions, and deletions) to the HTTP header s
and the contents of payment pages as received by the consumer
browser.

browser.
•The mechanism is configured to evaluate the received HTTP header and
payment page.
•The mechanism functi ons are performed as follows:
–At least once every seven days
OR
–Periodically (at the frequency defined in the entity’s targeted risk
Requirement 12.3.1) .
This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.  2 
Requirement 12: Support Information Security with Organizational Policies and Programs

OR
Requirement 12: Support Information Security with Organizational Policies and Programs  
12.1 A comprehensive information security policy that governs and provides 
direction for protection of the entity’s information assets is known and current. 
12.1.1 An overall information security policy is: 
•Established .
•Published .
•Maintained .
•Disseminated to all relevant personnel, as well as to relevant vendors
and business partners.6 
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.6

August 2022 42 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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. 6 
12.1.4 Responsibility for information security is f ormally assigned to a Chief 
Information Security Officer or other information security knowledgeable 
member of executive management.  6 
12.2 Acceptable use policies for end -user technologies are defined and 
implemented.  
12.2.1 Acceptable use policies for end -user technologies are documented 
and implemented, including: 
•Explicit approval by authorized parties.
•Acceptable uses of the technology.

•List of products approved by the company for employee use, includi ng
hardware and soft ware.6 
12.3 Risks to the cardholder data environment are formally identified, evaluated, 
and managed.  
12.3.1 Each PCI DSS requirement that provides flexibility for how frequently 
it is performed (for example, requirements to be performed periodically) is 
supported by a targeted risk analysis that is documented and includes:  
•Identification of the assets being pr otected.
•Identification of the threat(s) that the requirement is protecting against.

•Identification of factors that contribute to the likelihood and/or impact of a
threat being realized .
•Resulting analysis that determines, and includes justification for,  how
frequently the requirement must be performed to minimize the likelihood
of the threat being realized.
•Review of each targeted risk analysis at least once every 12 months to
determine whether the results are still valid or if an updated risk analysi s
is needed.
•Performance of updated risk analyses when needed, as determined bythe annual review.

is needed.

August 2022 43 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.2 
12.3.3 Cryptographic cipher suites and protocols in use are documented 
and reviewed at least once every 12 months, including at least the following: 
•An up -to-date inventory of all cryptographic cipher suites and protocols in
use, including purpose and where used.

months.2 
•Active monitoring of industry trends regarding continued viability of all
cryptographic cipher suites and protocols in use.
•A documented strategy to respond to anticipated changes i n
cryptographic vulnerabilities.
This requirement is a best practice unti l 31 March 2025; refer to Applicability 
Notes in PCI DSS for details.  6 
12.3.4 Hardware and software technologies in use are reviewed at least 
once every 12 months, including at least the following:  
•Analysis that the technologies continue to receive security fixes from

vendors promptly.
•Analysis that the technologies continue to sup port (and do not preclude)
the entity’s PCI DSS compliance.
•Documentation of any industry announcements or trends related to a
technology, such as when a vendor has announced “end of life” plans fo r
a technology.
•Documentation of a plan, approved by senior management, to remediat e
outdated technologies, including those for which vendors have
announced “end of life” plans .
This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.  6

This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.  6 
12.4 PCI DSS compliance is managed.  
12.4.1 Additional requirement for service providers only:  Responsibility 
is established by executive management for the protection of cardholder 
data and a PCI DSS compliance program to include:  
•Overall accountability for maintaining PCI DSS compliance.
•Defining a charter for a PCI DSS compliance program and
communication to executive management.6

August 2022 44 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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:  
•Daily log reviews.
•Configuration reviews for network security controls.
•Applying configuration standards to new systems.
•Responding to security alerts.
•Change -management process es.6 
12.4.2.1 Additional requirement for service providers only:  Reviews

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 responsibilit y
for the PCI DSS compliance program.6 
12.5 PCI DSS scope is documented and validated.  
12.5.1 An inventory of system components that are in scope for PCI DSS,

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

August 2022 45 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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 ex ample,
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 t he
currently defined CDE, 2) applications that process  CHD, 3)

transmissions between systems and networks , and 4) file backups.
•Identifying all system componen ts in the CDE, connected to the CDE, o r
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.
•Identifying all  connections from third -party entities with access to t he
CDE.
•Confirming that all identified data flows, account data, system

CDE.
components, segmentation controls, and connections from third parti es
with access to the  CDE are included in scope.1 
12.5.2.1 Additional requirement for service providers only:  PCI 
DSS scope is documented and confirmed by the entity at least once 
every six months and upon significant change  to the in -scope 
environment . At a minimum, the scoping validation includes all the 
elements specified in Requirement 12.5.2 . 

Applicability Notes in PCI DSS for details. 1 
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.  
This requirement is a best practice until 31 March 202 5; refer to Applicability 
Notes in PCI DSS for details.  6

August 2022 46 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
12.6 Security awareness education is an ongoing activity . 
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. 6 
12.6.2 The security awareness program is: 
•Reviewed at least once every 12 months, and
•Updated as needed to address any new threats and vulnerabilities that
may impact the security of the entity’s CDE, or the information provided
to personnel about their role i n protecting cardholder data.

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.
•Personnel acknowledge at least once every 12 months that  they have
read and understood the information secu rity policy and procedures .6 
12.6.3.1 Security awareness training includes awareness of threats and 
vulnerabilities that could impact the security of the CDE, including but 
not limited to:  
•Phishing and related attacks.
•Social  engineering.

Applicability Notes in PCI DSS for details. 6 
12.6.3.2 Security awareness training includes awareness about the 
acceptable use of end -user technologies in accordance with 
Requirement 12.2.1 . 
12.7 Personnel are screened to reduce risks from insider threats.  
12.7.1 Potential personnel who will have access to the CDE are screened,

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.  6 
12.8 Risk to information assets associated with third -party service provider 
(TPSP) relationships is managed.

August 2022 47 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
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.  2 
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 acknowledgment s from TPSPs that they ar e
responsible for the security of account data the TPSPs possess o r
otherwise store, process, or transmit on behalf of the entity, or to the
extent that they could impact the security of the entity’s CDE.2

extent that they could impact the security of the entity’s CDE.2 
12.8.3 An established process is implemented for engaging TPSPs, 
including proper due diligence prior to engagement.  2 
12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance 
status at least once every 12 months.  2 
12.8.5 Information is maintained about which PCI DSS requirements are 
managed by each TPSP, which are managed by the entity, and any that are 
shared between the TPSP and the entity.  2 
12.9 Third -party service providers (TPSPs) support their customers’ PCI DSS 

compliance.  
12.9.1 Additional requirement for service providers only:  TPSPs 
acknowledge in writing to customers that they are responsible for the 
security of account data  the TPSP possesses or otherwise stores, 
processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the cus tomer’s CDE.  2 
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:

12.8.4 and 12.8.5 by providing the following upon customer request:  
•PCI DSS compliance status information for any service the TPSP
performs on behalf of customers (Requirement 12 .8.4).
•Information about which PCI DSS requirements are the responsibility o f
the TPSP and which are the responsibility  of the customer, including any
shared responsibilities  (Requirement 12.8.5 ).2

August 2022 48 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
12.10 Suspected and confirmed security incidents that could impact the CDE are 
responded to immediately.  
12.10.1 An incident response plan exists and is ready to be activated in the 
event of a suspected or confirmed security incident. The plan includes, but 
is not limited to:  
•Roles, responsibilities, and communication and contact strategies in the
event of a suspected or confirmed security incident, including notificati on
of payment brands and acquirers, at a minimum.
•Incident response procedures with specific containment and mitigati on
activities for different types of incidents.
•Business recovery and  continuity proced ures.
•Data backup processes.

•Analysis of legal requirements for reporting compromises.
•Coverage and responses of all critical system components.
•Reference or inclusion of incident response procedures from thepayment brands.2 
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.2 
12.10.3 Specific personnel are designated to be available on a 24/7 basis to 
respond to suspected or confirmed security incidents.  2

is:  
respond to suspected or confirmed security incidents.  2 
12.10.4 Personnel responsible for responding to suspected and confirmed 
security incidents are appropriately and periodically trained on their incident 
response responsibilities.  2 
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.  
This requirement is a best practice until 31 March 2025; re fer to 

August 2022 49 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
12.10.5 The security incident response plan includes monitoring and 
responding to alerts from security monitoring systems, including but not 
limited to:  
•Intrusion -detection and intrusion- prevention systems.
•Network security controls.
•Change -detection mechanisms for critical files .
•The change -and tamper -detection mechanism for payment pages.  This
bullet is a best practice until 31 March 2025; refer to App licability Notes
in PCI DSS for details.
•Detection of unauthorized wireless access points.2 
12.10.6 The security incident response plan is modified and evolved 
according to lessons learned and to incorporate industry developments.  2

according to lessons learned and to incorporate industry developments.  2 
12.10.7 Incident response procedures are in place, to be initiated upon the 
detection of stored PAN anywhere it is not expected, and include:  
•Determining what to do if PAN is discovered outside the CDE, including
its retrieval, secure deletion, and/or migration into the currently defined
CDE, as applicable.
•Identifying whether sensitive authentication data is stored wi th PAN .
•Determining where the account data  came from and how it ended up
where it was not expected.

•Remediating data leaks or process gaps that resulted in the account databeing where it was not expected
.
Appendix A1: Additional PCI DSS Requirements for Multi -Tenant Service Providers  
A1.1 Multi -tenant service providers protect and separate  all customer 
environments and data.  
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
A1.1.2  Controls are implemented such that each customer only has 
permission to access its own cardholder data and CDE.  4

August 2022 50 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
A1.1.3  Controls are implemented such that each customer can only access 
resources allocated to them.  4 
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.  
Notes in PCI DSS for details. 2 
A1.2 Multi -tenant service providers facilitate logging and incident response for all 
customers.  
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.4 
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.  2 
A1.2.3  Processes or mechanisms are implemented for reporting and

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 provide r.
•The provider addresses and remediates suspected or  confirmed securit y
incidents and vulnerabilities according to Requirement 6.3.1 .
Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card-

Present POS POI Terminal Connections  
A2.1 POI terminals using SSL and/or early TLS are confirmed as not susceptible 
to known SSL/TLS exploits.  
A2.1.1  Where POS POI terminals at the merchant or payment acceptance 
location use SSL and/or early TLS, the entity confirms the devices are not 
susceptible to any known exploits for those protocols . 2

August 2022 51 PCI DSS Requirements v4.0 Milestone  
1 2 3 4 5 6 
A2.1.2  Additional r equirement 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 ofenvironment.
•Risk-assessment results and risk -reduction controls in place.
•Description of processes to monitor for new vulnerabilities associated
with SSL/e arly 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 futur
e
date.2 
A2.1.3  Additional r equirement for service providers only: All service 
providers provide a secure service offering.  2

Attestation of Compliance for Report 
on Compliance − Merchants  
Version 4.0  
Revision 1  

PCI DSS v4.0  Attestation of Compliance for Report on Compliance - Merchants  r1 December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 1 
PCI DSS v4.0 Attestation of Compliance for Report on 
Compliance -  Merchants  
Entity Name:       
Assessment End Date:       
Date of Report as noted in the Report on Compliance:

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 2 
This Attestation of Compliance  (AOC) must be completed as a declaration of the results of the merchant’s 
assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing  
Procedures  (“Assessment”). Complete all sections. The merchant is responsible for ensuring that each section is 
completed by the relevant parties, as applicable. Contact the entity(ies) to which this AOC will be submitted for 
reporting and submission procedures.   
This AOC reflects the results documented in an associated Report on Compliance (ROC). Associated ROC sections 
are noted in each AOC Part/Section below.   
Capitalized terms used but not otherwise defined in this document have the meanings set forth in the PCI DSS

Capitalized terms used but not otherwise defined in this document have the meanings set forth in the PCI DSS 
Report on Compliance Template.  
Provide the following information for all assessors involved in the Assessment. If there was no assessor for a given 
assessor type, enter  Not Applicable.  
PCI SSC Internal Security Assessor(s)

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 3 
Part 2. Executive Summary  
Part 2a. Merchant Business Payment Channels (select  all that apply) : 
(ROC Section 2.1)  
Indicate all  payment channels used by the  business  that are included in this Assessment.  
 Mail order  / telephone order (MOTO)  
 E-Commerce  
 Card-present  
Are any payment channels not included in  this 
Assessment?  
If yes, indicate which channel (s) is  not included  in 
the Assessment  and provide a brief explanation 
about why the channel was excluded.    Yes     No 
 
Note:  If the merchant has a payment channel that is not covered by this Assessment , consult with the entity(ies) to 
which this AOC will be submitted about validation for the other channels.  
 
Part 2b. Description of Role with Payment Card s 
(ROC Section 2.1)

Card-present  
 
For each payment channel included in this Assessment as selected in Part 2a above, describe how the business 
store s, process es, and/or transmit s account  data.  
Channel  How Business Stores, Processes, and/or Transmits Account Data  
            
Part 2c . Description of Payment Card Environment  
Provide a high -level description of the environment covered by 
this Assessment.  
For example:  
• Connections into and out of the cardholder data 
environment (CDE).

environment (CDE).  
• Critical system components within the CDE, such as POI 
devices, databases, web servers, etc., and any other 
necessary payment components, as applicable.  
• System components that could impact the security of 
account data.        
Indicate whether the environment includes segmentation to reduce the scope of the 
Assessment.  
Refer to “Segmentation” section of PCI DSS for guidance on segmentation.   Yes     No

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 4 
Part 2d. In -Scope Locations/Facilities  
(ROC Section 4.6)  
List all types of physical locations/ facilities  (for example, retail locations , corporate offices, data centers, call 
centers, and mail rooms ) in scope  for th is Assessment .  
Facility Type  Total Number of 
Locations  
(How many locations of 
this type are in scope)  Location(s) of Facility  
(city, country)  
Example: Retail locations  3 Boston, MA, USA  
                  
Part 2 e. PCI SSC Validated Products  and Solutions  
(ROC Section 3.3)  
Does the entity  use any item identified on any PCI SSC Lists of Validated Products and Solutions* ? 
 Yes     No

Locations  
                  
 Yes     No 
Provide the following information regarding each item the entity uses from PCI SSC 's Lists of V alidated Products 
and Solutions : 
Name of PCI SSC -
Validated Product or 
Solution  Version of 
Product or 
Solution  PCI SSC Standard to 
which Product or 
Solution Was Validated  PCI SSC L isting 
Reference 
Number  Expiry Date of 
Listing  
                        YYYY -MM-DD 
                        YYYY -MM-DD

Product or 
Reference 
Listing  
* For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, 
and/or components, appearing on the PCI SSC website ( www.pcisecuritystandards.org) (for example,  3DS Software 
Development Kits, Approved PTS Devices, Validated Payment Software,  Payment Applications  (PA-DSS) , Point to Point 
Encryption (P2PE)  solutions , Software -Based PIN Entry on COTS (SPoC)  solutions , and Contactless Payments on COTS 
(CPoC)  solutions) .

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 5 
Part 2f. Third -Party Service Providers  
(ROC Section 4.4)  
Does the entity have relationships with one or more third -party service providers that:   
• Store, process, or transmit account data on the entity’s behalf (for example, payment 
gateways, payment processors, payment service providers (PSPs), and off -site 
storage)   Yes    No  
• Manage system components included in the scope of the Assessment (for example, via 
network security control services, anti -malware services, security incident and event 
management (SIEM), contact and call centers, web- hosting services, and IaaS, PaaS, 
SaaS , and FaaS cloud providers)   Yes    No  
• Could impact the security of the entity’s CDE (for example, vendors providing support 
via remote access, and/or  bespoke software developers).   Yes    No  
If Yes:

If Yes:  
Name of Service Provider:   Description of Service(s ) Provided:   
            
Note: Requirement 12.8 applies to all entities in this list.

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 6 
Part 2g.  Summary of  Assessment  
(ROC Section 1.8.1)  
Indicate below all responses provided within each principal PCI DSS requirement.  
PCI DSS 
More than one response may be selected for a given 
requirement. Indicate all responses that apply.  Select If Below Method(s) 
Was Used  
In Place  Not 
Applicable  Not Tested  Not In 
Place  Customized 
Approach  Compensating 
Controls  
Requirement 1:        
Requirement 2:        
Requirement 3:        
Requirement 4:        
Requirement 5:        
Requirement 6:        
Requirement 7:        
Requirement 8:        
Requirement 9:        
Requirement 10:        
Requirement 11:        
Requirement 12:        
Appendix A2:

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 7 
Section 2  Report on Compliance  
(ROC Sections 1.2 and 1.3.2)  
Date Assessment began : 
Note:  This is the first date that evidence was gathered, or observations were made.  YYYY -MM-DD 
Date Assessment ended:  
Note:  This is the last date that evidence was gathered, or obser vations were made.  YYYY -MM-DD 
Were any requirements in the ROC unable to be met due to a legal constraint?   Yes   No 
If yes, for each testing activity below, indicate whether remote assessment activities were 
performed:   Yes   No 
• Observe physical environment          Yes  No

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 8 
Part 3. PCI DSS Validation  
(ROC Section 1.7)  
This AOC is based on results noted in the ROC dated  (Date of Report as noted in the ROC YYYY-MM- DD).  
Indicate below whether a full or partial PCI DSS assessment was completed:  
 Full Assessment  – All requirements have been assessed and therefore no requirements were marked as Not 
Tested in the ROC.  
 Partial  Assessment  – One or more requirements have not been assessed and were therefore marked as Not 
Tested in the ROC. Any requirement not assessed is noted as Not Tested in Part 2g above.  
Based on the results documented in the ROC noted above, each  signator y identified in any of Parts 3b-3d, as 
applicable, assert(s) the following compliance status for the entity identified in Part 2  of this document (select  one):

applicable, assert(s) the following compliance status for the entity identified in Part 2  of this document (select  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 
(Merchant Company Name)  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  (Merchant Company

marked as Not in Place, resulting in an overall NON -COMPLIANT  rating; thereby  (Merchant Company 
Name)  has not demonstrated compliance with  PCI DSS  requirements . 
Target Date  for Compliance: YYYY-MM-DD  
An entity submitting this form with a Non-Compliant status may be required to complete the Action 
Plan in Part 4 of this document. Confirm with the entity to which this AOC will be submitted before 
completing Part 4.  
 Compliant but with Legal exception:   One or more assessed requirements in the  ROC are  marked 
as Not in Place due to a legal restriction that prevents the requirement from being met and all other

as Not in Place due to a legal restriction that prevents the requirement from being met and all other 
assessed requirements are marked as being either In Place or Not Applicable, resulting in an overall 
COMPLIANT BUT WITH LEGAL EXCEPTION rating;  thereby (Merchant Company Name)  has 
demonstrated compliance with all PCI DSS requirements except those noted as Not Tested above or as Not in Place due to a legal restricti on.   
This option requires additional review from the entity to which this AOC will be submitted.  
If selected, complete the following:   
Affected Requirement  Details of how legal constraint prevents requirement from being met

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 9 
 
Part 3a. Merchant Acknowledgement  
(Select all that apply)  
 The ROC was completed according to PCI DSS , Version 4.0 and was completed according to the 
instructions therein.  
 All information within the above -referenced ROC and in this attestation fairly represents the results of the 
Assessment in all material respects.  
 PCI DSS controls will be maintained at all times , as applicable to the entity’s  environment.  
 
Part 3b. Merchant Attestation  
 
Signature of Merchant Executive Officer  Date:  YYYY -MM-DD 
Merchant Executive Officer Name:       Title:        
 
 QSA provided other assistance.

PCI DSS controls will be maintained at all times , as applicable to the entity’s  environment.  
 
Part 3d. PCI SSC Internal Security Assessor ( ISA) Involvement  
 ISA(s) provided other assistance.  

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 10 
Part 4. Action Plan for Non -Compliant Requirements  
Only complete Part 4 upon request of the entity to which this AOC will be submitted , and only if the Assessment 
has Non-Compliant results noted in Section 3.  
If asked to complete this section, select the appropriate response for “Compliant to PCI DSS Requirements” for 
each requirement  below . For any “No” responses, include the  date the entity  expects to be compliant with the 
requirement and provide a brief description of the actions being taken to meet the requirement . 
PCI DSS 
Requirement  Description of Requirement  Compliant to PCI 
DSS Requirements  
(Select One)  Remediation  
Date and Actions  
 (If “NO” selected for any 
Requirement)  YES NO 
1 Install and maintain network security 
controls          
2 Apply secure configurations to all system

PCI DSS 
controls          
2 Apply secure configurations to all system 
components          
3 Protect stored account  data         
4 Protect cardholder data with strong 
cryptography during transmission over 
open, public networks          
5 Protect all systems and networks from 
malicious software          
6 Develop and maintain secure systems 
and software          
7 Restrict access to system components 
and cardholder data by business need to 
know          
8 Identify users and authenticate access to 
system components          
9 Restrict physical access to cardholder

know          
9 Restrict physical access to cardholder 
data         
10 Log and monitor all access to system 
components and cardholder data          
11 Test security systems and networks 
regularly          
12 Support information security with 
organizational policies and programs           
Appendix A2  Additional PCI DSS Requirements for 
Entities using SSL/early TLS  for Card -
Present POS POI T erminal Connections

AT A GLANCE: PCI DSS v4.0
© 2022 PCI Security Standards Council LLC.  The intent of this document is to provide supplemental 
information, which does not replace or supersede PCI SSC Security Standards or their supporting documents.
December 20221
What is the PCI Data Security Standard?
The PCI Data Security Standard (PCI DSS) is a global standard that provides a baseline of technical and operational 
requirements designated to protect payment data. PCI DSS v4.0 is the next evolution of the standard.PCI DSS v4.0
Developed with Global Industry Collaboration
Development of PCI DSS v4.0 was driven by industry feedback. This version furthers the protection of payment data 
with new controls to address sophisticated cyber attacks.
Implementation Timeline
PCI DSS v3.2.1 will remain active for two years after v4.0 is published. This provides organizations time to become 
familiar with the new version, and plan for and implement the changes needed.Continue to Meet the 
Security Needs of the 
Payment Industry

Request for Comment (RFCs) 
On Draft ContentItems of Feedback 
ReceivedCompanies Provided 
FeedbackPromote Security as 
Continuous ProcessAdd Flexibility for 
Different MethodologiesEnhance Validation 
MethodsGoals for PCI DSS v4.0
2022Q1Q2Q3Q431March 2024
PCIDSSv3.2.1
retired31March 2025
Future-datednew
requirements
becomeeffective
2024 2025
Transitionperi odfromPCIDSS v3.2.1tov4.0OfficialRelease:
PCIDSSv4.0with
validation
documentsISA/QSA
trainingand
supporting
documents
2023
Transitionpe riodfromPCIDSS v3.2.1tov4.0

2024 2025
documents
2023
Implementationoffuture-datednewrequirementsQ1Q2Q3Q4 Q1Q2Q3Q4 Q1Q233 6,000+6,000+ 200+200+

December 20222
What is New in PCI DSS v4.0?
There were many changes incorporated into the latest version of the Standard. Below are examples of some 
of those changes. For a comprehensive view, please refer to the Summary of Changes from PCI DSS v3.2.1 
to v4.0, found in the PCI SSC Document Library.
Subscribe to the PCI Perspectives BlogContinue to meet the security needs of the payments industry.
Why it is important: Security practices must evolve as threats change.
Examples:
• Expanded multi-factor authentication requirements. 
• Updated password requirements.
• New e-commerce and phishing requirements to address ongoing threats.
Promote security as a continuous process.
Why it is important: Criminals never sleep. Ongoing security is crucial to 
protect payment data.
Examples:

Examples:
Examples:
• Clearly assigned roles and responsibilities for each requirement.
• Added guidance to help people better understand how to implement and 
maintain security.
Increase flexibility for organizations using different methods to 
achieve security objectives.
Why it is important: Increased flexibility allows more options to achieve a 
requirement’s objective and supports payment technology innovation.
Examples:
• Allowance of group, shared, and generic accounts.

Examples:
Examples:
• Targeted risk analyses empower organizations to establish frequencies for 
performing certain activities.
• Customized approach, a new method to implement and validate PCI DSS 
requirements, provides another option for organizations using innovative methods to 
Enhance validation methods and procedures.
Why it is important: Clear validation and reporting options support 
transparency and granularity.
Example:
• Increased alignment between information reported in a Report on Compliance or

Example:
• Increased alignment between information reported in a Report on Compliance or 
Self-Assessment Questionnaire and information summarized in an Attestation of 
Compliance.

PCI DSS v4.0  Designated Entities Supplemental Validation  
June 2022

PCI DSS FAQs for Designated Entities Supplemental Validation  Page 2  
© 2015 -2022 PCI Security Standards Council, LLC. All Rights Reserved  June 20 22 
FAQs  for Designated Entities Supplemental Validation  
Q1: What is a Designated Entity?  
A:   A Designated Entity is determined by an Acquirer or Payment Brand as an organization that 
requires additional validation to existing PCI DSS requirements.  
Q2: How will I know if my organization has been deemed a Designated Entity?  
A:   Your Acquirer and/or Payment Brand(s) will manage communications about which 
organizations are a Designated Entity as part of their compliance programs.  
Q3: What are some examples of Designated Entities?  
A:  Examples of Designated Entities could include organizations that store, process, or transmit 
large volumes of account  data; organizations that provide aggregation points for account  data; 
or organizations  that may have suffered a security breach of account  data.  Whether a

or organizations  that may have suffered a security breach of account  data.  Whether a 
particular entity is deemed a Designated Entity is determined by Payment Brand compliance 
programs.  
Q4: Why was the Designated Entities Supplemental Validation (DESV) created?  
A:   Analys is of recent account  data breaches and PCI DSS compliance trends  has revealed that 
many organizations view PCI DSS compliance as a periodic exercise and do not have processes 
in place to ensure that PCI DSS security controls are continuously enforced. This can result in

programs.  
in place to ensure that PCI DSS security controls are continuously enforced. This can result in 
lapse s in security controls between validation assessments. PCI DSS compliance is an ongoing 
process that must be incorporated into an entity’s overall security strategy, and the DESV was 
created to provide a means for entities to assess and document how they a re maintaining PCI 
DSS controls on a continual basis.  
Q5: What are the requirements within the Designated Entities Supplemental Validation (DESV) ? 
A:   The DESV is a series of additional validation procedures to provide greater insight into and

A:   The DESV is a series of additional validation procedures to provide greater insight into and 
assurance t hat an organization’s PCI DSS controls are being effectively maintained  through 
validation of Business -as-Usual (BAU) processes, and increased validation and scoping 
consideration .  
Q6: Can I use the DESV even if I’m not a Designated Entity ? 
A:   Yes. The DESV can be used to complement any entity’s  PCI DSS compliance efforts, and a ll 
entities are encouraged to follow the DESV  as a best practice , even if not required to validate.  
Q7: If my organization has been defined as a Designated Entity, is that designa tion permanent?

Q7: If my organization has been defined as a Designated Entity, is that designa tion permanent?  
A:   The duration for which an entity is deemed a Designated Entity is defined by each Payment 
Brand as part of their compliance program s.

PCI DSS FAQs for Designated Entities Supplemental Validation  Page 3  
Q8: Is it possible to be deemed a Designated Entity by one payment brand but not the others? If so,  
how would my organization report PCI DSS compliance?  
A:   Yes. As each Payment B rand manages their own compliance program, it is possible that one 
Brand may deem an organization a Designated Entity while the others may not. It is important 
that a Designat ed Entity work with each of their compliance -accepting entities ( that is,  their 
Acquirers and/or Payment Brands) to determine specific compliance reporting requirements.  
Q9: As a Designated Entity, am I expected to  comply with  all requirements in the DESV ? 
A:   Yes, it is the intent that a Designated Entity comply with all requirements in the DESV . However, 
entities should check with their Acquirer and/or the Payment Brands directly as they may have

entities should check with their Acquirer and/or the Payment Brands directly as they may have 
different compliance validation expectations as part of their individual compliance programs.  
Q10: How does the DESV impact my PCI DSS assessment?  
A:   Typically, the supplemental validation woul d be performed in conjunction with a full PCI DSS 
assessment. Designated Entities should contact their Acquirer and/or Payment Brand(s) with 
any questions about completing and submitting reports on compliance.  
Q11: How do I report my DESV assessment?

Q11: How do I report my DESV assessment?  
A:   As mentioned previously, a supplemental validation would typically be performed in conjunction 
with a full PCI DSS assessment. The PCI DSS ROC Reporting T emplate and AOC cover aspects of 
the supplemental validation (for example, in the Scope of Work and D etails of Reviewed 
Environment sections ). However , there  is also a supplemental ROC Template (S -ROC) and a 
supplemental Attestation of Compliance (S -AOC) that are specific to supplemental validations , 
and these need to be completed in addition to the PCI DSS ROC and AOC respectively.

and these need to be completed in addition to the PCI DSS ROC and AOC respectively.  
Designated Entities should  contact their Acquirer and/or the Payment Brand(s) directly with any 
questions about how to complete and submit these documents.

Summary of Changes from 
PCI DSS Version 3.2.1 to 4.0   
Revision 2 

PCI DSS v3.2.1 to v.4.0 Summary of Changes  r2 December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page i 
 
Document Changes  
Date  Revision  Description 
March 2022   Initial release of the PCI DSS v3.2.1 to v4.0 Summary of Changes.  
May 2022  1 Errata update t o correct  the change description for PCI DSS v4.0 
Requirement 8.3.9. 
December 
2022  2 Errata update to  add a description of the change made to Requirement 
6.3.3 and to correct the entry in the Summary of New Requirements  table 
for Requirement 3.6.1.1.

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page ii 
Table of Contents  
Document Changes  ..................................................................................................................................... i 
1 Introduction  ........................................................................................................................................... 1 
2 Change Types  ....................................................................................................................................... 2 
3 Summary of Changes to PCI DSS Introductory Sections  ................................................................ 2 
4 Summary of General Changes to PCI DSS Requirements  ............................................................... 5 
5 Additional Changes per Requirement ................................................................................................ 6

5 Additional Changes per Requirement ................................................................................................ 6 
6 Summary of New Requirements  ....................................................................................................... 28

1 Introduction  
This document provides a high- level summary and description of the changes from PCI DSS v3.2.1 to 
PCI DSS v4.0  and does not detail all document revisi ons. Due to the extent of the changes, the 
standard should be reviewed in its entirety rather than focusing solely on this summary document.  
This Summary of Changes is organized as follows:  
 Change Types  - provides an overview of the types of changes   
 Summary of Changes to PCI DSS Introductory Sections  - summarizes  changes made for 
each affected section.  
 Summary of General Changes to PCI DSS Requirements  - summarizes  changes made 
throughout the requirements, testing procedures, and guidance.  
 Additional Changes per Requirement  - summarizes  additional changes made in 
requirements 1- 12 and the appendices.

requirements 1- 12 and the appendices.  
 Summary of New Requirements  - lists all new requirements, the entity to which the new 
requirement applies (that is, all entities or service providers only), and the effective date 
of the new requirement.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 2 
2 Change Types 
Change Type  Definition  
Evolving requirement  Changes to ensure that the standard is up to date with emerging threats and 
technologies, and changes in the payment industry. Examples include new or 
modified requirements or testing procedures, or the removal of a requirement.  
Clarification or guidance  Update s to wording, explanation, definition, additional guidance, and/or instruction 
to increase  understanding or provide further information or guidance on a 
particular topic.  
Structure or format  Reorganization of content, including combining, separating, and renu mbering of 
requirements to align content.  
3 Summary of Changes to PCI DSS Introductory Sections  
Section  
Description of Change  Change Type  
PCI DSS v3.2.1  PCI DSS  v4.0  
Introduction and 
PCI Data Security Standard Overview  Introduction and

Section  
PCI Data Security Standard Overview  Introduction and 
PCI Data Security Standard Overview  Added “Limitations” sub -heading and clarified that 
PCI DSS does not supersede county, state, or local laws.  
Expanded list of PCI DSS resources.  Clarification or 
guidance  
PCI DSS 
Applicability 
Information  PCI DSS 
Applicability Information  Added sub -headings to increase readability.  
Clarified that some PCI DSS requirements may apply for entities that do not store, process, or transmit 
primary account number (PAN).  
Clarified that terms account data, sensitive 
authentication data (SAD), cardholder data, and PAN

guidance  
PCI DSS 
authentication data (SAD), cardholder data, and PAN 
are not interchangeable and are used intentionally in 
PCI DSS.  
Clarified table with commonly used elements of cardholder data and SAD, whether storage is 
permitted, and whether data must be rendered 
unreadable.   Clarification or 
guidance  
Relationship 
between PCI DSS and PA -DSS  Relationship 
between PCI DSS and PCI SSC Software Standards  Refocused section on relationship between PCI DSS 
and PCI SSC software standards, with mention of PA-DSS (retiring in October 2022).  Evolving 
requirement  
Scope of PCI 
DSS

PCI DSS.  
guidance  
DSS 
Requirements  Scope of PCI 
DSS Requirements  Clarified applicability of PCI DSS requirements and 
the definition of cardholder data environment (CDE).  
Expanded examples of system components to which 
PCI DSS applies; added cloud and other system components.  
Added “Understanding PCI DSS Scoping” diagram.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 3 
Section  
DSS 
DSS Requirements: 
Annual PCI DSS Scope Confirmation  Added sub -heading and clarified ex isting content.  Clarification or 
guidance  
Appendix D: 
Segmentation and 
Sampling of 
Business Facilities/System Components  Scope of PCI 
DSS 
Requirements: 
Segmentation  Moved segmentation diagram formerly in Appendix 
D, with minor edits.  
Retitled sub-section and updated references from 
‘network segmentation’ to ‘segmentation’ to support a broader range of segmentation controls.  Clarification or 
guidance  
DSS 
Wireless  Scope of PCI 
DSS 
Wireless  Clarified that rogue wireless detection (Requirement 
11.2.1) must be performed even if wireless is not

DSS 
guidance  
DSS 
DSS 
11.2.1) must be performed even if wireless is not 
used in the CDE and even if the entity has a policy 
that prohibits its use.  Clarification or 
guidance  
 Scope of PCI 
DSS Requirements: Encrypted Cardholder Data 
and Impact on 
PCI DSS Scope  Added sub -section and related content.  Clarification or 
guidance  
DSS Requirements: Encrypted 
Cardholder Data 
and Impact to PCI DSS Scope for Third-Party 
Service Providers  Added new sub -section and related content.  Clarification or 
guidance  
DSS 
Requirements: Use of Third -party 
Service 
Providers /Outsour

guidance  
guidance  
guidance  
DSS 
Service 
cing Scope of PCI 
DSS 
Service Providers  Retitled sub -section, added new content, and 
reorganized existing content under new sub-headings.  Clarification or 
guidance  
Best Practices for 
Implementing PCI DSS into Business -as-
Usual Processes  Best Practices for 
Usual Processes  Added guidance and clarifications throughout.  Clarification or 
guidance  
For Assessors: 
Sampling of Business Facilities/System Components  For Assessors:

DSS 
guidance  
guidance  
Sampling of Business Facilities/System Components  For Assessors: 
Sampling for PCI DSS Assessments  Retitled section and updated throughout with 
additional guidance and clarifications . 
Clarified that sampling references were removed from Testing Procedures to support assessors in selecting samples that are  appropriate to the population being 
tested.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 4 
Section  
Business Facilities/System Components  For Assessors: 
Sampling for PCI 
DSS 
Assessments  Moved sampling diagram formerly in Appendix D, 
with minor edit s. Clarification or 
guidance  
 Description of 
Timeframes Used 
in PCI DSS 
Requirements  New section to clarify frequencies and timeframes 
specified in PCI DSS and related expectations.  
Added explanation of “significant change.”  Clarification or 
guidance  
 Approaches for 
Implementing and Validating PCI DSS New section to explain and illustrate the two 
approaches, defined and customized, for implementing and validating PCI DSS.  Evolving 
Compensating 
Controls  Approaches for 
Implementin g and

guidance  
in PCI DSS 
guidance  
Implementin g and 
Validating PCI DSS Moved content to this section , at a sub -heading under 
“Defined Approach.”  Structure or 
format  
 Protecting 
Information About Entity’s Security Posture  New section to describe how entities may handle 
sensitive artifacts from their PCI DSS assessment.  Clarification or 
guidance  
 Testing Methods 
for PCI DSS Requirements  New section to describe the testing methods used in 
each PCI DSS Testing Procedures and corresponding expected activities to be performed by

format  
guidance  
each PCI DSS Testing Procedures and corresponding expected activities to be performed by 
the assessor.  Clarification or 
guidance  
PCI DSS 
Assessment 
Process  PCI DSS 
Assessment Process Includes minor clarifications.  
Moved note that starts “PCI DSS requirements are not considered to be in place…” here, formerly in Detailed PCI DSS Requirements and Security Assessment Procedures.  Clarification or 
guidance  
 Additional 
References  New section that lists external organizations 
referenced within PCI DSS requirements or guidance.  Clarification or 
guidance  
Detailed PCI DSS 
Requirements and

guidance  
PCI DSS 
guidance  
guidance  
Requirements and 
Security 
Assessment Procedures  Detailed PCI DSS 
Testing 
Procedures  Replaced content on first page of section with an 
illustration that explains all elements of the 
Requirements column, Testing Procedures column, 
and Guidance column.  
To first page of section, added description for Requirements noted with “Additional requirements for 
service providers only.”  
To first page of section, added summary of

guidance  
Security 
Testing 
To first page of section, added summary of 
appendices that include additional PCI DSS requirements for different types of entities.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 5 
4 Summary of General Changes to PCI DSS 
General Changes Implemented Throughout PCI DSS Requirements  Change Type  
Reformatted overview sections and added a summary of the sections to the beginning of each 
principal requirement.  Structure or 
format  
Updated overview sections and added guidance at the start of each requirement section.  Clarification or 
guidance  
Added numbered requirement description headings throughout each requirement to organize 
and describe the requirements that fall under it.  Structure or 
format  
Renumbered requirements and testing procedures and reorganized requirements due to the 
addition of numbered requirement description headings.  Structure or format  
Rephrased directive requirements to be objective.  Evolving 
requirement

guidance  
format  
Moved examples from requirements or testing procedures into the guidance column.  Structure or 
format  
Removed references to sampling from testing procedures.  Clarification or 
guidance  
Shortened testing procedures by clarifying testing is to be done “in accordance with all 
elements specified in this requirement” to minimize redundancy between requirements and testing procedures.  Clarification or guidance  
Updated language in requirements and/or corresponding testing procedures for alignment and 
consistency.  Clarification or 
guidance

format  
guidance  
guidance  
Enhanced testing procedures to clarify level of validation expected for each requirement.  Clarification or 
guidance  
Reformatted requirements and testing procedures and made minor wording changes for 
readability – for example, content from paragraphs reformatted to bullet points.  Structure or 
format  
Combined requirements that support the same intent and separated requirements that support 
different intents.  Structure or 
format  
Separated complex requirements / testing procedures and removed redundant or overlapping

guidance  
format  
format  
Separated complex requirements / testing procedures and removed redundant or overlapping 
testing procedures.  Structure or 
format  
Moved required elements that were included only in testing procedures to requirements , to 
clarify the requirement and to facilitate shortening of the testing procedures.  Clarification or 
guidance  
Moved  and reworded policies and procedures requirements from the end to the beginning of 
each principal requirement.  Structure or 
format  
Removed notes about SSL/Early TLS from the guidance columns for requirements that 
referenced those specific protocols.  Clarification or 
guidance

format  
guidance  
format  
guidance  
Changed “cardholder data” to “account data” as needed to align with usage and intent.  Clarification or 
guidance  
Changed terminology used to refer to frequency throughout the requirements in accordance 
with Description of Timeframes Used in PCI DSS Requirements.  Clarification or 
guidance  
Added titles and reorganized content of the guidance column to aid understanding and merge 
similar information.  Structure or 
format

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 6 
5 Additional Changes per Requirement  
Section  
PCI DSS v3.2.1  PCI DSS v4.0  
Requirement 1  
Requirement 1 - General  Updated principal requirement title to reflect the focus 
on “network security controls.”  
Replaced “firewalls” and “routers” with “network 
security controls” to support a broader range of 
technologies used to meet the security objectives 
traditionally met by firewalls.  Evolving 
1.1.5  1.1.2  Replaced requirement for “Description of groups, 
roles, and responsibilities for management of network components” with general requirement for roles and 
responsibilities for Requirement 1.  Evolving 
1.1 1.2.1  Refocused former “null” requirement (all content 
pointed to other requirements) on defining,

pointed to other requirements) on defining, 
implementing, and maintaining configuration standards for network security control rulesets.  Clarification or guidance  
1.1.1  1.2.2  Clarified that changes are managed in accordance 
with the change control process defined at Requirement 6.5.1.  Clarification or guidance  
1.1.4   Removed redundant requirement.  Clarification or 
guidance  
1.1.6  1.2.5  
1.2.6  Separated into two requirements to clarify intent of 
each.  Clarification or 
guidance  
1.1.7  1.2.7  Clarified the intent of reviewing configurations of

guidance  
guidance  
1.1.7  1.2.7  Clarified the intent of reviewing configurations of 
network security controls at least once every six months.  Clarification or 
guidance  
1.2  Removed “null” requirement (all content pointed to 
other requirement s). Structure or 
format  
1.2.2  1.2.8  Clarified the intent of securing configuration files.  Clarification or 
guidance  
1.2.1 
1.3.4  1.3.1  
1.3.2  Separated Requirement 1.2.1. into two requirements 
to clarify intent of each.  
Removed redundant Requirement 1.3.4.  Clarification or 
guidance  
1.2.3  1.3.3  Clarified the intent of implementing network security 
controls between wireless networks and the CDE.  Clarification or 
guidance

format  
guidance  
1.2.1 
guidance  
guidance  
1.3 1.4.1  Refocused a former null requirement (all content 
pointed to other requirements).  
Clarified that the intent is to implement controls between trusted and untrusted networks.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 7 
Section  
1.3.1  
1.3.2  
1.3.5  1.4.2  Merged requirements to clarify that the intent is to 
restrict inbound traffic from untrusted networks.  Clarification or 
guidance  
1.3.6  1.4.4  Clarified the intent is that system components storing 
cardholder data are not directly accessible from 
untrusted networks.  Clarification or 
guidance  
1.4 1.5.1  Clarified that the intent is to implement security 
controls on any computing device that connects to both untrusted networks and the CDE.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 8 
Section  
Requirement 2 
Requirement 2 - General  Updated principal requirement title to reflect that the 
focus is on secure configurations in general, and not 
just on vendor -supplied defaults.  Clarification or 
guidance  
 2.1.2  New requirement  for roles and responsibilities.  
This requirement is effective immediately for all v4.0 
assessments  Evolving 
2.1 2.2.2  Clarified that the intent is to understand whether 
vendor default accounts are in use and to manage them accordingly.  Clarification or 
guidance  
2.2.1  2.2.3  Clarified the intent of the requirement for managing 
primary functions that require different security levels.  Clarification or 
guidance  
2.2.2  
2.2.5  2.2.4  Combined requirements to align similar topics.  Structure or 
format

guidance  
guidance  
2.2.2  
format  
2.2.3  2.2.5  Clarified that the intent of the requirement is if any 
insecure services, protocols, or daemons are present.  Clarification or 
guidance  
2.1.1  2.3.1  
2.3.2  Split requirement for changing all wireless vendor 
defaults into two requirements to clarify the focus of 
guidance  
2.4 12.5.1  Moved requirement to align related content.  Structure or 
format  
2.6  Removed “null” requirement (all content pointed to 
other requirements).  Structure or 
format  
Requirement 3

guidance  
guidance  
format  
format  
Requirement 3 
Requirement 3 - General  Updated principal requirement title to reflect the focus 
on account data.  Clarification or 
guidance  
 3.1.2  New requirement  for roles and responsibilities.  
This requirement is effective immediately for all v4.0 assessments.  Evolving 
3.1 3.2.1  New requirement  bullet  to address SAD stored prior 
to completion of authorization through implementation 
of data retention and disposal policies, procedures, and processes.  
This bullet is a best practice until 31 March 2025.  Evolving 

guidance  
 3.3.2  New requirement  to encr ypt SAD that is stored 
electronically prior to completion of authorization.  
This requirement is a best practice until 31 March 2025.  Evolving 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 9 
Section  
3.2.a  
3.2.b  3.3.3  Added a requirement to address former testing 
procedures that any storage of SAD by issuers is 
limited to that which is needed for a legitimate issuing 
business need and is secured.  Clarification or 
guidance  
3.3 3.4.1  Clarified that PAN is masked when displayed such 
that only personnel with a business need can see more than the BI N/last four digits of the PAN.  Evolving 
12.3.10  3.4.2  New requirement for technical controls to prevent 
copy and/or relocation of PAN when using remote-access technologies. Expanded from former 
Requirement 12.3.10.  
3.4 3.5.1  Removed pads from the “Index tokens and pads” 
bullet for rendering PAN unreadable.  Evolving

bullet for rendering PAN unreadable.  Evolving 
 3.5.1.1  New requirement for keyed cryptographic hashes 
when hashing is used to render PAN unreadable.  
 3.5.1.2  New requirement  that disk -level or partition -level 
encryption is used only to render PAN unreadable on 
removable electronic media or, if used on non-removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement  3.5.1.

removable electronic media or, if used on non-removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement  3.5.1.  
3.5.1  3.6.1.1  New requirement  bullet  for service providers only 
to include  in the documented description of the 
cryptographic architecture that use of  the same 
cryptographic keys in production and test 
environments is prevented.  
This bullet is a best  practice until 31 March 2025.  Evolving 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 10 
Section  
Requirement 4 
Requirement 4 - General  Updated principal requirement title to reflect the focus 
on “strong cryptography” to protect transmissions of 
cardholder data.  Clarification or 
guidance  
 4.1.2  New requirement for roles and responsibilities.  
assessments.  Evolving 
4.1 4.2.1  New requirement  bullet  to confirm certificates used 
for PAN transmissions over open, public networks are valid and not expired or revoked.  
 4.2.1. 1 New requirement to maintain an inventory of trusted 
keys and certif icates.  
This requirement is a best practice until 31 March 
2025.  Evolving 
Requirement 5

Requirement 5 
Requirement 5 - General  Updated principal requirement title to reflect the focus 
on protecting all systems and networks from malicious software.  Clarification or 
guidance  
Replaced “anti -virus” with “anti -malware” throughout 
to support a broader range of technologies used to 
meet the security objectives traditionally met by anti-
virus software.  Evolving 
 5.1.2  New requirement  for roles and responsibilities.  

guidance  
5.1.2  5.2.3  Clarified requirement by changing focus to “system 
components that are not at risk for malware.”  Clarificatio n or 
guidance  
 5.2.3.1  New requirement  to define the frequency of periodic 
evaluations of system components not at risk for malware in the entity’s targeted risk analysis.  
5.2 5.3.1  
5.3.2  
5.3.4  Split one requirement into three to focus each 
requirement on one area:  
• Keeping the malware solution current via 
automatic updates,

guidance  
5.2 5.3.1  
5.3.2  
automatic updates,  
• Performing periodic scans and active or real -time 
scans (with a new option for continuous behavioral  analysis),  
• Generation of audit logs by the malware solution.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 11 
Section  
 5.3.2.1  New requirement to define the frequency of periodic 
malware scans in the entity’s targeted risk analysis.   
 5.3.3  New requirement for a malware solution for 
removable electronic media.   
 5.4.1  New requirement to detect and protect personnel 
against phishing attacks.  
Requirement 6 
Requirement 6 - General  Updated principal requirement title to include 
“software” rather than “applications.”  
Clarified that Requirement 6 applies to all system components, except for Requirement  6.2, which

Clarified that Requirement 6 applies to all system components, except for Requirement  6.2, which 
applies only to bespoke and custom software.  Clarification or 
guidance  
 6.1.2  New requirement  for roles and responsibilities.  
6.3 6.2.1  Moved requirement for developing software securely 
to align all software development content under 
Requirement 6.2.  Structure or 
format  
Replaced “internal and external” with “bespoke and 
custom” software.  
Clarified that this requirement applies to software

guidance  
format  
Clarified that this requirement applies to software 
developed for or by the entity for the entity’s own use and does not apply to third-party software.  Clarification or 
guidance  
6.5 6.2.2  Moved the elements of Requirement 6.5 for training 
of software developers to align all software 
development content under Requirement 6.2.  
Clarified training requirements for software 
development personnel.  Clarification or 
guidance  
6.3.2  6.2.3  
6.2.3.1  Moved requirement for reviewing custom software

guidance  
guidance  
6.2.3.1  Moved requirement for reviewing custom software 
prior to release to align all software development content under Requirement  6.2. 
Split requirement to separate general code review 
practices from those needed if manual code reviews are performed.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 12 
Section  
6.5.1  – 6.5.10  6.2.4  Moved requirements for addressing common coding 
vulnerabilities to align all software development 
content under Requirement  6.2. 
Combined methods to prevent or mitigate common 
software attacks into a single requirement and generalized the language describing each type of 
attack.  Clarification or 
guidance  
6.1 
6.2 6.3 Moved requirements for identifying security 
vulnerabilities and protecting system components 
from vulnerabilities via patching under Requirement  
6.3. Structure or 
format  
6.1 6.3.1  Added a bullet to clarify applicability to  vulnerabilities 
for bespoke and custom and third-party software . Clarification or 
guidance  
 6.3.2  New requirement to maintain an inventory of 
bespoke and custom software.

guidance  
6.1 
format  
guidance  
bespoke and custom software.  
6.2 6.3.3  Changed the applicable security patches to be 
installed within one month of release from “critical security patches” to “critical or high- security 
patches/updates.”  Evolving 
6.6 6.4.1  Moved requirement for addressing new threats and 
vulnerabilities for p ublic-facing web applications 
under Requirement  6.4. Structure or 
format  
 6.4.2  New requirement to deploy an automated technical 
solution for public -facing web applications that

format  
solution for public -facing web applications that 
continually detects and prevents web- based attacks. 
This new requirement removes the option in 
Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods.  
 6.4.3  New requirement for management of all payment 
page scripts that are loaded and executed in the consumer’s browser.   

6.3.1  
6.4 
6.4.1 – 6.4.6  6.5.1 – 6.5.6  Moved and combined requ irements for changes to 
system components under Requirement  6.5. Structure or 
format  
6.4 6.5.3  
6.5.4  
6.5.5  
6.5.6  Removed requirement for specific documented 
procedures and added testing procedures to verify 
policies and procedures to each related requirement.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 13 
Section  
6.4.1  6.5.3  Changed term from “development/test and 
production” to “production and pre-production” 
environments.  Clarification or 
guidance  
6.4.2  6.5.4  Changed term from “development/test and 
environments.  
Changed term “separation of duties” and clarified that separation of roles and functions between production 
and pre-production is intended to provide 
accountability so that only approved changes are deployed.  Clarification or 
guidance  
6.4.3  6.5.5  Changed term from “testing or development” to “pre -
production” environments.  
Clarified that live PANs  are not used in pre-
production environments except where all applicable PCI DSS requirements are in place.  Clarific ation or 
guidance  
Requirement 7

guidance  
guidance  
Requirement 7 
Requirement 7 - General  Updated principal requirement title to include system 
components and cardholder data.  Clarification or 
guidance  
 7.1.2  New requirement  for roles and responsibilities.  
7.1 7.2.1  
7.2.2  
7.2.3  Removed requirement for specific documented 
guidance  
7.1.1  7.2.1  Clarified requirement is about defining an access 
control model.  Clarification or 
guidance

guidance  
7.1 7.2.1  
7.2.2  
guidance  
guidance  
7.1.2  
7.1.3  7.2.2  Combined requirements for assigning access based 
on job classification and function, and least privileges.  Structure or 
format  
7.1.4  7.2.3  Clarified requirement is about approval of required 
privileges by authorized personnel.  Clarification or 
guidance  
 7.2.4  New requirement  for review of all user accounts an d 
related access privileges.  
 7.2.5  New requirement  for assignment and management

format  
guidance  
 7.2.5  New requirement  for assignment and management 
of all application and system accounts and related 
access privileges.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 14 
Section  
 7.2.5.1  New requirement  for review of all access by 
application and system  accounts and related access 
privileges.  
8.7 7.2.6  Moved requirement since it aligns better with the 
content in Requirement 7.  Structure or 
format  
7.2   Removed “null” requirement (all content pointed to 
format  
Requirement 8 
Requirement 8 - General  Standardized on terms “authentication factor” and 
“authentication credentials.”  
Removed “non- consumer users” and clarified in the 
overview that requirements do not apply to accounts used by consumers (cardholders).  Clarification or 
guidance  
Removed note in overview that listed requirements

format  
format  
guidance  
Removed note in overview that listed requirements 
that do not apply to user accounts with access to only 
one card number at a time to facilitate a single 
transaction and added that note to each related requirement.  Structure or 
format  
 8.1.2  New requirement  for roles and responsibilities.  
8.1.1  8.2.1  Added a note that this requirement is not intended to 
apply to user accounts on point -of-sale terminals that

format  
apply to user accounts on point -of-sale terminals that 
have access to only one card number at a time to facilitate a single transaction.  Clarification or 
guidance  
8.5 8.2.2  Changed focus of  requirement to allow use of shared 
authentication credentials , but only on an exception 
basis.  Evolving 
Added a note that this requirement is not intended to 
have access to only one card number at a time to 
facilitate a single transaction.  Clarification or 
guidance  
8.5 
8.5.1  8.2.2

guidance  
guidance  
8.5 
8.5.1  8.2.2  
8.2.3  Moved requirements for group, shared, or generic 
accounts and for service providers with remote access to customer premises under Requirement 8.2.  Structure or 
format  
8.1.8  8.2.8  Added a note that this requirement is not intended to 
have access to only one card number at a time to facilitate a single transaction.  Structure or 
format  
8.2 8.3.1  Added a note that this requirement is not intended to

guidance  
8.5 
format  
format  
8.2 8.3.1  Added a note that this requirement is not intended to 
facilitate a single transaction.  Structure or 
format

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 15 
Section  
8.1.6  
8.1.7  8.3.4 Merged requirements and moved under Requirement 
8.3 
format  
Increased the number of invalid authentication 
attempts before locking out a user ID  from six to 10 
attempts.  Evolving 
8.2.6  8.3.5  Clarified that this requirement applies only if 
passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1.  Clarification or 
guidance  
8.2.3  8.3.6  New requirement  to increase password length from 
a minimum length of seven characters to minimum

format  
guidance  
a minimum length of seven characters to minimum 
length of 12 characters (or if the system does not support 12 characters, a minimum length of eight 
characters).  
2025.  
Clarified that, until 31 March 2025, passwords must 
be a minimum length of at least seven characters in 
accordance with v3.2.1 Requirement 8.2.3.  
Clarified that this requirement applies only if 
passwords/passphrases are used as an 
authentication factor to meet Requirement 8.3.1.  
Added a note that this requirement is not intended to apply to user accounts on point -of-sale terminals that

2025.  
Added a note that this requirement is not intended to apply to user accounts on point -of-sale terminals that 
have access to only one card number at a time to facilitate a single transaction.  Evolving 
8.2.5  8.3.7  Added a n ote that this requirement is not intended to 
format  
8.4 8.3.8  Moved content about communicating user 
authentication policies and procedures under Requirement 8.3.  Structure or 
format  
8.2.4  8.3.9  Clarified that this requirement applies if

format  
format  
8.2.4  8.3.9  Clarified that this requirement applies if 
passwords/passphrases are used as the only 
authentication factor for user access (i.e., in any 
single-factor authentication implementation) .  
facilitate a single transaction.  
Added a note that thi s requirement does not apply to 
service providers’ customer accounts, but does apply 
to accounts for service provider personnel.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 16 
Section  
8.2.4  8.3.9  Added the option to determine access to resources 
automatically by dynamically analyzing the security 
posture of accounts, instead of changing 
passwords/passphrases at least once every 90 days.  Evolving 
8.2.4.b  8.3.10  Moved content from a former testing procedure to a 
requirement for service providers to provide guidance to customers about changing passwords/ passphrases.  
Added a note that this requirement will be superseded by Requirement 8.3.10.1 once Requirement 8.3.10.1 becomes effectiv e. Structure or 
format  
 8.3.10.1  New requirement for service providers only – if 
passwords/passphrases are the only authentication factor for customer user access, then 
passwords/passphrases are either changed at least

format  
passwords/passphrases are either changed at least 
once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts.  
2025.  
Added a note that this requirement does not apply to 
accounts of consumer users accessing their payme nt 
card information.  
Added a note that this requirement will supersede Requirement 8.3.10 once it becomes effective, and until that date, service providers may meet either Requirement  8.3.10 or 8.3.10.1.  Evolving 

2025.  
8.6 8.3.11  Moved requirement about authentication factors such 
as physical or logical security tokens, smart cards, 
and certificates under Requirement 8.3.  Structure or 
format  
8.3  Removed “null” requirement (all content pointed to 
format  
 8.4.2  New requirement  to implement multi -factor 
authentication (MFA) for all access into the CDE.  
2025.  
Added a note to clarify that MFA is required for both 
types of access specified in Requirements 8.4.2 and

format  
format  
2025.  
types of access specified in Requirements 8.4.2 and 
8.4.3; and that applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access.  Evolving 
 8.5.1  New requirement  for secure implementation of multi -
factor authentication systems.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 17 
Section  
 8.6.1  New requirement  for management of system or 
application accounts that can be used for interactive 
login.  
 8.6.2  New requirement  for not hard -coding 
passwords/passphrases into files or scripts for any application and system accounts that can be used for 
interactive login.  
 8.6.3  New requirement  for protecting 
passwords/passphrases for application and system accounts against misuse.  
format  
Requirement 9

format  
Requirement 9 
Requirement 9 - General  In the overview, clarified the three different areas 
covered in Requirement 9 (sensitive areas, CDE, and 
facilities).  
Throughout, clarified whether each requirement 
applies to the CDE, sensitive areas, or facilities.  Clarification or 
guidance  
 9.1.2  New requirement for roles and responsibilities.  
9.1 9.2.4  Added a requirement to address a former testing 
procedure bullet to restrict access to consoles in

guidance  
procedure bullet to restrict access to consoles in 
sensitive areas via locking when not in use.  Clarification or 
guidance  
9.2 9.3.1  
9.3.2  Split requirement for identifying personnel and visitors 
into separate requirements, Requirements 9.3. 1 and 
9.3.2 respectively.  Structure or 
format  
9.4 
9.4.1  
9.4.2  9.3.2  Combined requirements for authorizing and 
managing visitor access together in Requirement 
9.3.2.  Structure or 
format  
9.5 
9.5.1  9.4.1  
9.4.1.1  
9.4.1.2  Removed requirement for procedures to physically

guidance  
9.2 9.3.1  
format  
9.4 
9.4.1  
format  
9.5 
9.4.1.1  
9.4.1.2  Removed requirement for procedures to physically 
secure media (9.5) and merged the procedures into the related requirements.  
Split requirement for storing media backups in a 
secure location and reviewing the security of the 
offline backup location at least every 12 months into 2 requirements.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 18 
Section  
9.6 
9.6.1  
9.6.2  
9.6.3  9.4.2  
9.4.3  
9.4.4  Removed requirement for procedures for internal and 
external distribution of media (9.6) and merged the 
procedures into the related requirements.  Clarification or 
guidance  
9.7 
9.7.1  9.4.5  
9.4.5.1  Removed requirement for procedures for strict control  
over storage and accessibility of media (9.7) and 
merged the procedures into the related requirements.  
Split requirement for maintaining media inventory 
logs and conducting media inventories annually into 2 
requirements.  Clarification or 
guidance  
9.8 
9.8.1  
9.8.2  9.4.6  
9.4.7  Removed requirement for procedures for media 
destruction when media is no longer needed (9.8) and merged the procedures into the related requirements.

guidance  
9.8 
9.8.1  
destruction when media is no longer needed (9.8) and merged the procedures into the related requirements.  
Clarified options for destroying media when no longer needed includes either dest ruction of electronic 
media or rendering cardholder data unrecoverable.  Clarification or 
guidance  
9.9 9.5.1  Clarified the focus of the requirement is on “Point -of-
interaction (PO I) devices that capture payment card 
data via direct physical interaction wit h the payment 
card form factor .”  
Clarified that this requirement applies to deployed 
POI devices used in card-present transactions.  Clarification or

guidance  
POI devices used in card-present transactions.  Clarification or 
guidance  
 9.5.1.2.1  New requirement to define the frequency of periodic 
POI device inspections based on the entity’s targeted risk analysis.  
Requirement 10 
Requirement 10 - General  Updated principal requirement title to reflect focus on 
audit logs, system components, and cardholder data.  
Clarified that these requirements do not apply to user 
activity of consumers (cardholders).

guidance  
activity of consumers (cardholders).  
Replaced “Audit trails” with “Audit logs” throughout.  Clarification or 
guidance  
 10.1.2  New requirement  for roles and responsibilities.  
10.2  Removed “null” requirement (all content pointed to 
format  
10.5  Removed “null” requirement (all content pointed to 
format  
10.5.1 – 10.5.5  10.3.1  – 10.3.4  Moved audit log protection requirements under

guidance  
format  
format  
10.5.1 – 10.5.5  10.3.1  – 10.3.4  Moved audit log protection requirements under 
Requirement 10.3.  Structure or 
format

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 19 
Section  
10.5.3  
10.5.4  10.3.3  Combined requirements to align similar topics.  Structure or 
format  
10.6  Removed “null” requirement (all content pointed to 
format  
10.6.1 – 10.6.3  10.4.1  – 10.4.3  Moved requirements for audit log reviews under 
Requirement 10.4.  Structure or 
format  
 10.4.1.1  New requirement  for the use of automated 
mechanisms to perform audit log reviews.  
 10.4.2.1  New requirement  for a targeted risk  analysis to 
define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1)  

format  
10.7 10.5.1  Moved requirement for audit log history to 10.5.1.  Structure or 
format  
10.4 
10.4.1  – 10.4.3  10.6.1  – 10.6.3  Moved and reorganized requirements for time 
synchronization under 10.6.  Structure or 
format  
10.8 10.7.1  Moved requirement for service providers  to detect, 
alert, and promptly address failures of critical control systems to Requirement  10.7.1.  Structure or 
format  
 10.7.2  New requirement  for all entities to detect, alert, and 
promptly address failures of critical security control systems.

format  
10.4 
format  
format  
promptly address failures of critical security control systems.  
2025.  
This new requirement applies to all entities - it 
includes two additional critical security controls not 
included in Requirement 10.7.1 for service providers.  Evolving 
10.8.1  10.7.3  New requirement  to respond promptly to failures of 
any critical security controls.  
For service providers: this is current PCI DSS v3.2.1 requirement.  
For all other (non-service provider) entities: this is a new requirement.  
This requirement is a best practice (for non- service

2025.  
This requirement is a best practice (for non- service 
providers) until 31 March 2025.  Evolving 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 20 
Section  
Requirement 11  
Requirement 11 - General  Minor update to principal requirement title.  Clarification or 
guidance  
 11.1.2  New requirement  for roles and responsibilities.  
11.1 11.2.1  Clarified the intent of the requirement is to manage 
both authorized and unauthorized wireless access points.  
Clarified that this requirement applies even when a policy exists to prohibit the use of wireless technology.  Clarification or 
guidance  
 11.3.1.1  New requirement  to manage a ll other applicable 
vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans.  

guidance  
 11.3.1.2  New requirement  to perform internal vulnerability 
scans via authenticated scanning.  
11.2.3  11.3.1.3  
11.3.2.1  Separated requirement to perform internal and 
external vulnerability scans and resc ans after any 
significant changes into a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1).  Structure or 
format  
11.3 11.4.1  Clarified the following:  
• The methodology is defined, documented, and implemented by the entity.

format  
• The methodology is defined, documented, and implemented by the entity.  
• Penetration testing results are retained for at 
least 12 months.  
• The methodology includes a documented 
approach to assessing and addressing risk posed by exploitable vulnerabilities a nd security 
weaknesses found during penetration testing.  
• The meaning of testing from inside the network (internal penetration testing) and from outside the network (external penetration testing).  Clarification or 
guidance  
11.3.3  11.4.4  Clarified that pene tration test findings are corrected in

guidance  
11.3.3  11.4.4  Clarified that pene tration test findings are corrected in 
accordance with the entity’s assessment of the risk 
posed by the security issue.  Clarification or 
guidance  
 11.4.7  New requirement for multi -tenant  service 
providers  to support their customers for external 
penetrati on testing.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 21 
Section  
 11.5.1.1  New requirement for service providers  to use 
intrusion -detection and or intrusion- prevention 
techniques to detect, alert on/prevent, and address 
covert malware communication channels.  
 11.6.1  New requirement  to deploy a change -and-tamper -
detection mechanism to alert for unauthorized 
modifications to the HTTP headers and contents of 
payment pages as received by the consumer browser.  
11.2  Removed “null” requirement (all content pointed to 
format  
11.1.2  12.10.5  Moved requirement for incident response procedures

format  
11.1.2  12.10.5  Moved requirement for incident response procedures 
if unauthorized wireless access points are detected to 
align with other incident response items.  Structure or 
format  
11.5.1  12.10.5  Moved requirement to respond to alerts generated by 
the change-detectio n solution to align with other the 
incident response items.  Structure or 
format  
Requirement 12  
Requirement 12 - General  Updated principal requirement title to reflect that the 
focus is on organizational policies and programs that support information security.  Clarification or 
guidance

format  
format  
guidance  
12.2  Removed requirement for a formal organization -wide 
risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).  Evolving 
12.4 12.1.3  Added formal acknowledgment by personnel of their 
responsibilities.  Evolving 
12.5 
12.5.1 – 12.5.5  12.1.4  Clarified that responsibilities are formally assigned to 
a Chief Information Security Officer or other knowledgeable member of executive management.  
Merged requirements for formally assigning

12.5 
Merged requirements for formally assigning 
responsibility for information security.  Clarification or 
guidance  
12.3 
12.3.1 – 12.3.9  12.2.1  Clarified the intent of the requirement is for 
acceptable use policies for end-user technologies.  
Merged and removed requirements to focus on explicit management approval, acceptable uses of technologies, and a list of hardware and software 
products approved by the company for employee 
use. Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 22 
Section  
12.3.10  3.4.2  Removed requirement and added new Requirement 
3.4.2 for technical controls to prevent copy and/or 
relocation of PAN when using remote-access 
technologies.  Evolving 
 12.3.1  New requirement  to perform a targeted risk analysis 
for any PCI DSS requirement that provides flexibility for how frequently it is performed.  
 12.3.2  New requirement for entities using a Customized 
Approach  to perform a targeted risk analysis for 
each PCI DSS requirement that the entity meets with 
the customized approach.  
This requirement is effective immediately for all 
entities undergoing a v4.0 assessment and using a 
customized approach.  Evolving 

 12.3.3  New requirement  to document and review 
cryptographic cipher suites and protocols in use at least once every 12 months.  
 12.3.4  New requirement  to review hardware and software 
technologies in use at least once every 12 months.  
12.11  
12.11.1  12.4.2  
12.4.2.1  Moved requirements for reviews to confirm that

12.11  
12.4.2.1  Moved requirements for reviews to confirm that 
personnel are performing PCI DSS tasks in accordance with policies and procedures under Requirement  12.4, to align with other requirements 
for managing PCI DSS compliance activities.  Structure or 
format  
2.4 12.5.1  Moved under Requirement  12.5 to align with other 
requirements for documenting and validating PCI DSS scope.  Structure or 
format  
 12.5.2  New requirement to document and confirm PCI DSS 
scope at least every 12 months and upon significant change to the in- scope environment.

format  
format  
scope at least every 12 months and upon significant change to the in- scope environment.  
 12.5.2.1  New requirement for service provide rs to 
document and confirm PCI DSS scope at least once 
every six months and upon significant change to the in-scope environment.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 23 
Section  
 12.5.3  New requirement for service providers  for a 
documented review of the impact to PCI DSS scope 
and applicability of controls upon significant changes 
to organizational structure.  
12.6 12.6.1  Clarified that the intent is that all personnel are aware 
of the entity’s information security policy and their role 
in protecting cardholder data.  Clarification or 
guidance  
 12.6.2  New requirement to review and update (as needed) 
the security awareness program at least once every 
12 months.  
12.6.1  
12.6.2  12.6.3  Merged requirements for security awareness training.  Structure or 
format

guidance  
12 months.  
12.6.1  
format  
 12.6.3.1  New requirement for security awareness training to 
include awareness of threats and vulnerabilities that could impact the security of the CDE.  
 12.6.3.2  New requirement  for security awareness training to 
include awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1.  

format  
12.8  Removed “null” requirement (all content pointed to 
format  
12.8.1 – 12.8.5  12.8.1 – 12.8.5  Replaced “Service Provider” with Third -Party Service 
Provider (TPSP).  
Clarified that the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor 
does it remove the entity’s responsibility for its own 
PCI DSS compliance.  Clarification or 
guidance  
12.8.2  12.8.2  Replaced “Service Provider” with Third -Party Service

format  
guidance  
12.8.2  12.8.2  Replaced “Service Provider” with Third -Party Service 
Provider (TPSP).  Clarification or 
guidance  
12.8.3  12.8.3  Replaced “Service Provider” with Third -Party Service 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 24 
Section  
12.8.4  12.8.4  Replaced “Service Provider” with Third -Party Service 
Clarified that where an entity has an agreement with 
a TPSP for meeting PCI  DSS requirements on behalf 
of the entity, the entity must work with the TPSP to make sure the applicable PCI DSS requirements are 
met. If the TPSP does not meet those applicable PCI 
DSS requirements, then those requirements are also “not in place” for the entity. Clarification or 
guidance  
12.8.5  12.8.5  Replaced “Service Provider” with Third -Party Service 
Clarified that the information about PCI DSS 
requirements managed by the TPSP and the entity 
should include any that are shared between the TPSP and the entity.  Clarification or 
guidance

guidance  
guidance  
 12.9.2  New requirement for service providers  to support 
their cust omers’ requests for information to meet 
Requirements 12.8.4 and 12.8.5.  
12.10   Removed “null” requirement (all content pointed to 
format 
12.10.1  12.10.1  Replaced “system breach” and “compromise” with 
“suspected or confirmed security incident.”  Clarification or 
guidance  
12.10.3  12.10.3  Replaced “alerts” with “suspected or confirmed

format 
guidance  
12.10.3  12.10.3  Replaced “alerts” with “suspected or confirmed 
security incidents.”  Clarification or 
guidance  
12.10.4  12.10.4  Replaced “system breach” with “suspected or 
confirmed security incidents.”  Clarification or 
guidance  
 12.10.4.1  New requirement  to perform a targeted risk analysis 
to define the frequency of periodic training for incident 
response personnel.  
12.10.5  
11.1.2  
11.5.1  12.10.5  Merged requirements and updated the security

guidance  
guidance  
12.10.5  
11.1.2  
11.5.1  12.10.5  Merged requirements and updated the security 
monitoring systems to be monitored and responded 
to as part of the incident response plan to include the 
following:  
• Detection of unauthorized wireless access points (former 11.1.2),  
• Change- detection mechanism for critical files 
(former 11.5.1),  
• New requirement bullet  for use of a change- 
and tamper -detection mechanism for payment 
pages (relates to new requirement 11.6.1).  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 25 
Section  
 12.10.7  New requirement  for incident response procedures 
to be in place and initiated upon detection of stored 
PAN anywhere it is not expected.  
Appendix A1  
Appendix A1 - General  Updated principal requirements title to reflect focus 
on multi -tenant service providers.  
Updated requirement overview to describe multi -
tenant service providers and their environments, and to clarify responsibilities between multi -tenant service 
providers  and their customers.  
Updated “shared hosting provider” to “multi -tenant 
hosting provider” throughout.  Clarification or 
guidance  
A1  Removed “null” requirement (all content pointed to 
format

guidance  
format  
 A1.1.1  New requirement  for to implement logical separation 
between providers’ environments and customers’ environments.  
 A1.1.4  New requirement to confirm, via penetration testing, 
the ef fectiveness of logical separation controls used 
to separate customer environments .  
 A1.2.3  New requirement for the implementation of 
processes and mechanisms for reporting and

processes and mechanisms for reporting and 
addressing suspected or confirmed security incidents and vulnerabilities.  
A1.4 A1.2.2  Replaced “compromise” with “suspected or confirmed 
security incident”  Clarifi cation or 
guidance  
Appendix A2  
The only changes made to Appendix A2 were to add the requirement description heading at 
A2.1 and to renumber the three requirements as A2.1.1, A2.1.2, and A2.1.3.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 26 
Section  
Appendix A3  
Appendix A3 - General  Clarified that other PCI standards may reference 
completion of this Appendix.  
Clarified that not all PCI DSS requirements apply to 
all entities that undergo a PCI DSS assessment, 
which is why some PCI DSS requirements are duplicated in this Appendix. Any questions about this Appendix should be addressed to acquirers or payment brands.  Clarification or 
guidance  
A3.2.1  A3.2.1  Updated the elements included for PCI DSS scope 
documentation and confirmation to align with new 
PCI DSS Requirement 12.5.2.  Evolving 
 A3.3.1  New requirement  bullet  to detect, alert, and report 
failures of automated log review mechanisms.  
New requirement bullet  to detect, alert, and report 
failures of automated code review tools.

guidance  
failures of automated code review tools.  
These bullets are best practices until 31 March 2025.  Evolving 
Appendix B: 
Compensating Controls  Appendix B: 
Compensating Controls  Clarified that compensating controls may  be 
considered when an entity cannot meet a PCI DSS requirement explicitly as written, due to “legitimate 
and documented technical or business constraints.”  
Updated item 2 to mention the Customized Approach Objective and its use to understand the intent of  most 
PCI DSS requirements.  
Clarified the intent of item 4 is to address the risk imposed by not adhering to the PCI DSS requirement.

Clarified the intent of item 4 is to address the risk imposed by not adhering to the PCI DSS requirement.  
Added item  6 to clarify that compensating controls 
are used to address requirements currently and in the future, and they cannot be used to address a requirement missed in the past.  Clarification or 
guidance  
Appendix C: 
Controls 
Worksheet  Appendix C: 
Controls 
Worksheet  Clarified that the intent is for the entity to use the 
worksheet to define its compensating controls.

guidance  
Controls 
Controls 
worksheet to define its compensating controls.  
Updated item 1 to “Document the legitimate technical or business constraints precluding compliance with the original requirement.”  
Reordered the worksheet items to move item 4 to 
item 2.  
Updated item 3 to mention the Customized Appr oach 
Objective, and split item into two parts to “Define the 
objective of the original control” and to “Identify the objective met by the compensating control.”  
Removed the Compensating Control Worksheet - 
Completed Example. An updated completed example will be included in a separate guidance document.  Clarification or 
guidance  
 Appendix D:

item 2.  
guidance  
 Appendix D: 
Customized Approach  New Appendix  to explain and provide instructions for 
the Customized Approach.  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 27 
Section  
 Appendix E: 
Sample 
Templates to 
Support Customized Approach  New Appendix  for example templates for the 
controls  matrix and targeted risk analysis, to be 
documented by the entity as part of the customized approach.  
Clarified that entities are not required to follow the specific template formats , but must provide all 
information as defined in each template.  
Includes two templates:  
• E1 Sample Controls Matrix Template  
• E2 Sample Targeted Risk Analysis Template.  Clarification or 
guidance  
 Appendix F: 
Leveraging the 
PCI Software 
Security Framework to Support 
Requirement 6  New Appendix  to describe how an entity can meet 
several requirements in Requirement 6 by use of 
bespoke or custom software that is developed and

guidance  
bespoke or custom software that is developed and 
maintained in accordance with one of PCI SSC’s Secure Software Standards.  Clarification or 
guidance  
 Appendix G: PCI 
DSS Glossary of Terms, Abbreviations, and A cronyms  New Appendix  for the PCI DSS v4.0 Glossary.  
General updates to the Glossary include:  
• Added new terms based on updated requirements or based on feedback,  
• Removed common terms that can be readily 
found with other sources,  
• Removed terms not used in PCI DSS v4.0,  
• Shortened acronym definitions.  Clarification or 
guidance  
Segmentation and Sampling of

guidance  
guidance  
Segmentation and Sampling of 
Business Facilities/ System Components   Removed Appendix and moved former content to 
sections titled “Segmentation” and “For Assessors: 
Sampling for PCI DSS Assessments.”  Clarification or 
guidance

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 28 
6 Summary of New Requirements  
As noted in the table below, t he new requirements included in PCI DSS v4.0 are either:  
 Effective immediately for all PCI DSS v4.0 assessments.  
OR  
 Best practices until 31 March 2025, after which they become effective.  
New Requirement  Applicable to Effective Date  
All 
Entities  Service 
Providers 
Only  Immediately 
for all v4.0 
Assessments  31 March 
2025  
2.1.2  Roles and responsibilities for performing 
activities in Requirement 2 are 
documented, assigned, and understood.      
3.1.2  Roles and responsibilities for performing 
activities in Requirement 3 are documented, assigned, and understood.      
3.2.1  Any SAD stored prior to completion of 
authorization is kept to a minimum through implementation of data retention 
and disposal policies, procedures, and 
processes.     

2025  
processes.      
3.3.2  SAD stored electronically prior to 
completion of authorization is encrypted using strong cryptography.      
3.3.3  SAD stored by issuers is encrypted 
using strong cryptography .  1   
3.4.2  Technical controls to prevent copy  
and/or relocation of PAN when using 
remote-access technologies except with  
explicit authorization.      
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 .     
3.5.1.2  Implementation of disk -level or partition -
level encryption when used to render 
PAN unreadable.      
3.6.1.1  A documented description of the 
cryptographic architecture includes 
prevention of the use of the same 
cryptographic keys in production and test environments .     
 
1 Applicable only to issuers and companies that support issuing services and store sensitive authentication data.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 29 
New Requirement  Applicable to  Effective Date  
All 
Providers 
2025  
4.1.2  Roles and responsibilities for performing 
activities in Requirement 4 are 
4.2.1  Certificates used to safeguard PAN 
during transmission over open, public networks are confirmed as valid and are 
not expired or revoked.      
4.2.1.1  An inventory of the entity’s trusted keys 
and certificates is maintained.      
5.1.2  Roles and responsibilities for performing 
activities in Requirement 5 are 
5.2.3.1  A targeted risk analysis is performed to 
determine frequency of periodic evaluations of system components identified as not at risk for malware.      
5.3.2.1  A targeted risk analysis is performed to

5.3.2.1  A targeted risk analysis is performed to 
determine frequency of periodic malware 
scans.      
5.3.3  Anti-malware scans are performed when 
removable electronic media is in use.      
5.4.1  Mechanisms are in place to detect and 
protect personnel against phishing 
attacks.      
6.1.2  Roles and responsibilities for performing 
activities in Requirement 6 are documented, assigned, and understood.      
6.3.2  Maintain an inventory of bespoke and 
custom software to facilitate vulnerability and patch management.      
6.4.2  Deploy an automated technical solution

scans.      
6.4.2  Deploy an automated technical solution 
for public -facing web applications that 
continually detects and prevents web-based attacks.      
6.4.3  Manage all payment page scripts that 
are loaded and executed in the consumer’s browser.      
7.1.2  Roles and responsibilities for performing 
activities in Requirement 7 are documented, assigned, and understood.      
7.2.4  Review all user accounts and related 
access privileges appropriately.     

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 30 
All 
Providers 
2025  
7.2.5  Assign and manage all application and 
system accounts and related access 
privileges appropriately.      
7.2.5.1  Review all access by application and 
system accounts and related access privileges.      
8.1.2  Roles and responsibilities for performing 
activities in Requirement 8 are 
8.3.6  Minimum level of complexity for 
passwords when used as an 
authentication factor.      
8.3.10.1  If passwords/passphrases are the only 
authentication factor for customer user access, p assword s/passphrases are 
changed at least every 90 days or the 
security posture of accounts is 
dynamically analyzed to determine real-time access to resources.      

dynamically analyzed to determine real-time access to resources.       
8.4.2  Multi -factor authentication for all access 
into the CDE.      
8.5.1  Multi -factor authentication systems are 
implemented appropriately.      
8.6.1  Manage i nteractive login for accounts 
used by systems or applications.      
8.6.2  Passwords/passphrases used for 
interactive login for application and system accounts are protected against 
misuse.      
8.6.3  Passwords/passphrases for any 
application and system accounts are 
protected against misuse.     

misuse.      
protected against misuse.      
9.1.2  Roles and responsibilities for performing 
activities in Requirement 9 are documented, assigned, and understood.      
9.5.1.2.1  A targeted risk analysis is performed to 
determine frequency of periodic POI device inspections.      
10.1.2  Roles and responsibilities for performing 
activities in Requirement 10 are documented, assigned, and understood.      
10.4.1.1  Audit log reviews are automated .    

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 31 
All 
Providers 
2025  
10.4.2.1  A targeted risk analysis is performed to 
determine frequency of log reviews for 
all other system components.      
10.7.2  Failures of c ritical security control 
systems are detected, alerted, and addressed promptly.      
10.7.3  Failures of c ritical security control 
systems are responded to promptly.      
11.1.2  Roles and responsibilities for performing 
activities in Requirement 11 are 
11.3.1.1  Manage all other a pplicable 
vulnerabilities (those not ranked as high-
risk or critical ).     
11.3.1.2  Internal vulnerability scans are 
performed via authenticated scanning.      
11.4.7  Multi -tenant  service providers support

11.4.7  Multi -tenant  service providers support 
their customers for external penetration 
testing.      
11.5.1.1  Covert malware communication 
channels detect, alert and/or prevent, 
and address via intrusion-detection 
and/or intrusion-prevention techniques.      
11.6.1  A change -and-tamper -detection 
mechanism is deployed for payment 
pages .      
12.3.1  A targeted risk analysis is documented 
to support  each PCI DSS requirement 
that provides flexibility for how frequently it is performed.      
12.3.2  A targeted risk analysis is performed for

pages .      
12.3.2  A targeted risk analysis is performed for 
each PCI DSS requirement that is met 
with the customized approach.      
12.3.3  Cryptographic cipher suites and 
protocols in use are documented and 
reviewed.      
12.3.4  Hardware and software technologies are 
12.5.2  PCI DSS scope is documented and 
confirmed at least once every 12 months.    

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 32 
All 
Providers 
2025  
12.5.2.1  PCI DSS scope is documented and 
confirmed at least once every six months 
and upon significant changes.      
12.5.3  The impact of significant organizational 
changes on PCI DSS scope is documented and reviewed and results 
are communicated to executive 
management.      
12.6.2  The security awareness program is 
reviewed at least once every 12 months 
and updated as needed .      
12.6.3.1  Security awareness training includes 
awareness of threats that could impact 
the security of the CDE, to include 
phishing and related attacks and social 
engineering.      
12.6.3.2  Security awareness training includes 
awareness about acceptable use of end-user technologies.     

awareness about acceptable use of end-user technologies.      
12.9.2  TPSPs support customers’ requests to 
provide PCI DSS compliance status and information about PCI DSS requirements 
that are the responsibility of the TPSP.      
12.10.4.1  A targeted risk analysis is performed to 
determine frequency of periodic training 
for incident response personnel.      
12.10.5  The security incident response plan 
includes alerts from the c hange- and 
tamper -detection mechanism for 
payment pages .     
12.10.7  Incident response procedures are in 
place and initiated upon detection of 
PAN.    

PAN.     
A1.1.1  The multi -tenant service provider 
confirms access to and from customer 
environment is logically separated to prevent unauthorized access.      
A1.1.4  The multi -tenant service provider 
confirms effectiveness of logical separation controls used to separate customer environments at leave once 
every six months via penetration testing.     

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page 33 
All 
Providers 
2025  
A1.2.3  The multi -tenant service provider 
implements processes or mechanisms 
for reporting and addressing suspected 
or confirmed security incidents and 
vulnerabilities.      
A3.3.1  Failures of the following are detected, 
alerted, and reported in a timely manner:  
Automated log review mechanisms  
Automated code review tools.      
Totals:   53 11 13 51 
Grand Total:  64

Payment Card Industry (PCI)  
Data Security Standard (DSS)  
and Payment Application  
Data Security Standard (PA -DSS)  
 
Glossary of Terms, Abbreviations, and 
Acronyms  
 
Version 3.2 
 April 2016

PCI DSS and PA -DSS Glossary of Terms, Abbreviations, and Acronyms  v3.2    April 2016  
© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 2  
Term  Definition  
AAA  Acronym for “authentication, authorization, and accounting.” Protocol for 
authenticating a user based on their verifiable identity, authorizing a user 
based on their user rights, and accounting for a user’s consumption of 
network resources.  
Access Control  Mechanisms that limit availability of information or information -processing 
resources only to authorized persons or applications.  
Account Data  Account data consists of cardholder data and/or  sensitive authentication 
data. See Cardholder Data  and Sensitive Authentication Data . 
Account Number  See Primary Account Number (PAN).  
Acquirer  Also referred to as “merchant bank,” “acquiring bank,” or “acquiring financial 
institution” . Entity, typically a financial institution, that processes payment

institution” . Entity, typically a financial institution, that processes payment 
card transactions for merchant s and is defined by a payment brand as an 
acquirer . Acquirers are subject to payment brand rules and procedures 
regarding merchant compliance . See also Payment Processor.   
Administrative Access  Elevated or increased privileges  granted to a n account in order for that 
account to manage systems, networks and/or applications .  
Administrative access can be assigned to an individual’s account or a built-
in system account. Accounts with administrative access are often  referred to

in system account. Accounts with administrative access are often  referred to 
as “superuser ”, “root”, “admin istrator ”, “admin ”, “sysadmin”  or “supervisor -
state ”, depending on the particular operating system  and organizational 
structure . 
Adware  Type of malicious software that, when installed, forces a computer to 
automatically display or download advertisements.  
AES Abbreviation for “Advanced Encryption Standard.” Block cipher used in 
symmetric key cryptography adopted by NIST in November 2001 as U.S. 
FIPS PUB 197 (or “FIPS 197”). See Strong Cryptography.

FIPS PUB 197 (or “FIPS 197”). See Strong Cryptography.  
ANSI  Acronym for “American National Standards Institute.” Private, non -profit 
organization that administers and coordinates the U.S. voluntary 
standardization and conformity assessment system.  
Anti-Virus  Program or software capable of detecting, removing, and protecting against 
various forms of malicious software (also called “malware”) including 
viruses, worms, Trojans or Trojan horses, spyware, adware, and rootkits.  
AOC  Acronym for “attestation of compliance.” The AOC is a form for merchants

AOC  Acronym for “attestation of compliance.” The AOC is a form for merchants 
and service providers to attest to the results of a PCI DSS assessment, as 
documented in the Self -Assessment Questionnaire or Report on 
Compliance.  
AOV  Acronym for “attestation of validation.” The AOV is a form for PA -QSAs to 
attest to the results of a PA-DSS assessment, as documented in the PA -
DSS Report on Validation.  
Application  Includes all purchased and custom software programs or groups of 
programs, including both internal and external (for example, web) 
applications.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 3  
ASV Acronym for “Approved Scanning Vendor.” Company approved by the PCI 
SSC to conduct external vulnerability scanning services.  
Audit Log  Also referred to as “audit trail.” Chronological record of system activities. 
Provides an independently verifiable trail sufficient to permit reconstruction, 
review, and examination of sequence o f environments and activities 
surrounding or leading to operation, procedure, or event in a transaction 
from inception to final results.   
Audit Trail  See Audit Log.  
Authentication  Process of verifying identity of an individual, device, or process . 
Authentication typically occurs through the use of one or more 
authentication factors such as:  
 Something you know, such as a password or passphrase  
 Something you have, such as a token device or smart card

 Something you have, such as a token device or smart card  
 Something you are, such as a biometric  
Credentials  Combination of the user ID or account ID plus the authentication factor(s) 
used to authenticate an individual, device, or process,  
Authorization  In the context of access control, authorization is the g ranting  of access or 
other rights to a user, program, or process. Authorization defines what an 
individual or program can do after successful authentication .

individual or program can do after successful authentication .  
In the context of a payment card transaction , authorization occurs when a 
merchant receives transaction approval after the a cquirer validates the 
transaction with the issuer/processor.  
Backup  Duplicate copy of data made for archiving purposes or for protecting against 
damage or loss.  
BAU  An acronym for “business as usual.” BAU is an organization’s normal daily 
business operations.  
Bluetooth  Wireless protocol using short -range communications technology to facilitate

Bluetooth  Wireless protocol using short -range communications technology to facilitate 
transmission of data over short distances.  
Buffer Overflow  Vulnerability that is created from insecure coding methods, where a program 
overruns the buffer’s boundary and writes data to adjacent memory space. 
Buffer overflows are used by attackers to gain unauthorized access to 
systems or data.  
Card Skimmer  A physical device, often attached to a legitimate card -reading device,  
designed to illegitimately capture and /or store the information from a 
payment card.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 4  
Card Verification  
Code or Value  
 Also known as Card Validation Code or Value, or Card Security Code.  
Refers to either: (1) magnetic -stripe data, or (2) printed security features.  
(1) Data element on a card's magnetic stripe that uses secure 
cryptographic process es to protect data integrity on the stripe, and 
reveals any alteration or counterfeiting. Referred  to as CAV, CVC, 
CVV, or CSC depending on payment card brand. The following list 
provides the terms for each card brand:  
 CAV – Card Authentication Value (JCB payment cards)  
 PAN CVC – Card Validation Code (MasterCard payment cards)  
 CVV – Card Verification V alue (Visa and Discover payment cards)  
 CSC – Card Security Code (American Express)  
(2) For Discover, JCB, MasterCard, and Visa payment cards, the second

(2) For Discover, JCB, MasterCard, and Visa payment cards, the second 
type of card verification value or code is the rightmost three -digit value 
printed in the signature panel area on the back of the card. For 
American Express payment cards, the code is a four -digit unembossed 
number printed above the PAN on the face of the payment cards. The 
code is uniquely associated with each individual piece of plastic and 
ties the PAN to the plastic. The following list provides the terms for 
each card brand:  
 CID – Card Id entification Number (American Express and Discover 
payment cards)

payment cards)  
 CAV2 – Card Authentication Value 2 (JCB payment cards)   
 PAN CVC2 – Card Validation Code 2 (MasterCard payment cards)  
 CVV2 – Card Verification Value 2 (Visa payment cards)  
Cardholder  Non-consumer or consumer customer to whom a payment card is issued to 
or any individual authorized to use the payment card.  
Cardholder Data  At a minimum, cardholder data consists of the full PAN. Cardholder data 
may also appear in the form of the full PAN  plus any of the following: 
cardholder name, expiration date and/or service code

cardholder name, expiration date and/or service code    
See Sensitive Authentication Data  for additional data elements that may be 
transmitted or processed (but not stored) as part of a payment transaction.  
CDE  
 Acronym for “cardholder data environment.” The people, processes and 
technology that store, process , or transmit cardholder data or sensitive 
authentication data.  
Cellular Technologies  Mobile communications through wireless telephone networks, including b ut 
not limited to Global System for Mobile communications (GSM) , code

CDE  
not limited to Global System for Mobile communications (GSM) , code 
division multiple access (CDMA) , and General Packet Radio Service 
(GPRS).  
CERT  Acronym for Carnegie Mellon University's “Computer Emergency Response 
Team.” The CERT Program develops and  promotes the use of appropriate 
technology and systems management practices to resist attacks on 
networked systems, to limit damage, and to ensure continuity of critical 
services.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 5  
Change Control  Processes and procedures to review, test, and approve chang es to systems 
and software for impact before implementation.  
CIS Acronym for “Center for Internet Security.” Non -profit enterprise with mission 
to help organizations reduce the risk of business and e -commerce 
disruptions resulting from inadequate technica l security controls.  
Column -Level 
Database Encryption  Technique or technology (either software or hardware) for encrypting 
contents of a specific column in a database versus the full contents of the 
entire database. Alternatively, see Disk Encryption or File-Level Encryption.  
Controls  Compensating controls may be considered when an entity cannot meet a 
requirement explicitly as stated, due to legitimate technical or documented

requirement explicitly as stated, due to legitimate technical or documented 
business constraints, but has sufficiently mitigated the risk as sociated with 
the requirement through implementation of other controls. Compensating 
controls must:  
(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;  
(3) Be “above and beyond” other PCI DSS requirements (not simply in 
compliance with other PCI DSS requirements); and  
(4) Be commensurate with the additional risk imposed by not adhering to

(4) Be commensurate with the additional risk imposed by not adhering to 
the PCI DSS requirement.  
See “Compensating Controls ” Appendices B and C i n PCI DSS 
Requirements and Security Assessment Procedures  for guidance on the 
use of compensating controls.  
Compromise  Also referred to as “data compromise,” or “data breach.” Intrusion into a 
computer system where unauthorized disclosure/theft, modifica tion, or 
destruction of cardholder data is suspected.  
Console  Screen and keyboard which permits access and control of a server,

Console  Screen and keyboard which permits access and control of a server, 
mainframe computer or other system type in a networked environment.  
Consumer  Individual purchasing goods, services, or both.  
Critical systems / 
critical technologies  A system or technology that is deemed by the entity to be of particular 
importance. For example, a critical system may be essential  for the 
performance of a business operation  or for a security function to be 
maintained .  Examples of critical systems often  include security systems, 
public -facing devices and systems, databases, and systems that store,

public -facing devices and systems, databases, and systems that store, 
process, or transmit cardholder data.  Considerations for determining which 
specific system s and technolog ies are critical will depend on an 
organization’s environment and risk-assessment strategy.  
Cross -Site Request 
Forgery (CSRF)  Vulnerability that is created from insecure coding methods that allows for the 
execution of unwanted actions through an authenticated session. Often 
used in conjunction with XSS and/or SQL injection.  
Cross -Site Scripting 
(XSS)  Vulnerability that is created from insecure coding techniques, resulting in

(XSS)  Vulnerability that is created from insecure coding techniques, resulting in 
improper input validation. Often used in conjunction with CSRF and/or SQL 
injection.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 6  
Cryptographic Key A value that determines the output of an encryption algorithm when 
transforming plain text to ciphertext. The length of the key generally 
determines how difficult it will be to decrypt the ciphertext  in a given 
message.  See Strong Cryptography.  
Cryptographic Key 
Generation  Key generation is one of the functions within key management.  The 
following documents provide recognized guid ance on proper key generation : 
 NIST Special Publication 800 -133: Recommendation for Cryptographic 
Key Generation  
 ISO 11568 -2 Financial services — Key management (retail) — Part 2: 
Symmetric ciphers, their key management and life cycle  
o 4.3 Key generation  
 ISO 11568 -4 Financial services — Key management (retail) — Part 4: 
Asymmetric cryptosystems — Key management and life cycle

Asymmetric cryptosystems — Key management and life cycle  
o 6.2 Key life cycle stages — Generation  
 European Payments Council EPC 34 2-08 Guidelines on Algorithms 
Usage and Key Management  
o 6.1.1 Key generation [for symmetric al gorithms]  
o 6.2.1 Key generation [for asymmetric algorithms]  
Management  The set of processes and mechanisms which support cryptographic key 
establishment and maintenance, including replacing older keys with new 
keys as necessary.  
Cryptography  Discipline of mathematics and computer science concerned with information

Cryptography  Discipline of mathematics and computer science concerned with information 
security, particularly encryption and authentication. In applications and 
network security, it is a tool for access control, information confidentiality, 
and integrity.  
Cryptoperiod  The time span during which a specific cryptographic key can be used for its 
defined purpose based on, for example, a defined period of time and/or the 
amount of cipher -text that has been produced, and according to industry 
best practices and guidelines (for example, NIST Special Publication 800 -
57).

57). 
CVSS  Acronym for “ Common Vulnerability Scoring System .” A vendor agnostic, 
industry open standard designed to convey the severity of computer system 
security vulnerabilities  and help determine urgency and priority of response . 
Refer to ASV Program Guide  for more information.  
Data -Flow Diagram  A diagram showing how data flows through an application, system, or 
network.  
Database  Structured format for organizing and maintaining easily retrievable

57). 
network.  
Database  Structured format for organizing and maintaining easily retrievable 
information. Simple database examples are tables and spreadsheets.  
Database 
Administrator  Also referred to as “DBA.” Individual responsible for managing and 
administering databases.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 7  
Default Accounts  Login account predefined  in a system, application, or device to permit initial 
access when system is first put into service. Additional default accounts may 
also be generated by the system as part of the installation process.  
Default Password  Password on system administration, u ser, or service accounts predefined in 
a system, application, or device; usually associated with default account. 
Default accounts and passwords are published and well known, and 
therefore easily guessed.  
Degaussing  Also called “disk degaussing.” Process or technique that demagnetizes the 
disk such that all data stored on the disk is permanently destroyed.  
Dependency  In the context of PA -DSS, a dependency is a specific software or hardware

Dependency  In the context of PA -DSS, a dependency is a specific software or hardware 
component (such as a hardware terminal, database, operating system, API, 
code library, etc.) that is necessary for the payment application to meet PA-
DSS requirements.  
Disk Encryption  Technique or technology (either software or hardware) for encrypting all 
stored data on a device (for example, a hard disk or flash drive). 
Alternatively, File-Level Encryption  or Column -Level Database Encryption  is 
used to encrypt contents of specific fil es or columns.

used to encrypt contents of specific fil es or columns.  
DMZ  Abbreviation for “demilitarized zone.” Physical or logical sub -network that 
provides an additional layer of security to an organization’s internal private 
network. The DMZ adds an additional layer of network security between the 
Intern et and an organization’s internal network so that external parties only 
have direct connections to devices in the DMZ rather than the entire internal 
network.  
DNS  Acronym for “ domain name system ” or “domain name server.” A system  that

network.  
DNS  Acronym for “ domain name system ” or “domain name server.” A system  that 
stores information associated with domain names in a distributed database 
to provide name -resolution services to users on networks such as the 
Internet.  
DSS Acronym for “Data Security Standard .”  See PA-DSS and PCI DSS.  
Dual Control  Process of using two or more separate entities (usually persons) operating 
in concert to protect sensitive functions or information. Both entities are 
equally responsible for the physical protection of materials involved in

Internet.  
equally responsible for the physical protection of materials involved in 
vulnerable transactions. No sing le person is permitted to access or use the 
materials (for example, the cryptographic key). For manual key generation, 
conveyance, loading, storage, and retrieval, dual control requires dividing 
knowledge of the key among the entities. (See also Split Know ledge. ) 
Dynamic Packet 
Filtering  See Stateful Inspection.  
ECC  Acronym for “Elliptic Curve Cryptography.” Approach to public -key 
cryptography based on elliptic curves over finite fields. See Strong 
Cryptography.

Cryptography.  
Egress Filtering  Method of filtering outbound network traffic such that only explicitly allowed 
traffic is permitted to leave the network.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 8  
Encryption  Process of converting information into an unintelligible form except to 
holders of a specific cryptographic key. Use of encryption protects 
information between the encryption process and the decryption process (the 
inverse of encryption) against unauthorized disclosure . See Strong 
Encryption Algorithm  Also called “cryptographic algorithm.” A sequence of mathematical 
instructions  used for transforming unencrypted text or data to encrypted text 
or data, and back again. See Strong Cryptography.  
Entity  Term used to represent the corporation, organization or business which is 
undergoing a PCI DSS review.  
File Integrity 
Monitoring  Technique or technology under which certain files or logs are monitored to 
detect if they are modified. When critical files or logs are modified, alerts

detect if they are modified. When critical files or logs are modified, alerts 
should be sent to appropriate security personnel.  
File-Level Encryption  Technique or technology (eithe r software or hardware) for encrypting the full 
contents of specific files. Alternatively, see  Disk Encryption or Column -Level 
Database Encryption.  
FIPS  Acronym for “Federal Information Processing Standards.” Standards that 
are publicly recognized by the  U.S. Federal Government; also for use by 
non-government agencies and contractors.  
Firewall  Hardware and/or software technology that protects network resources from

Firewall  Hardware and/or software technology that protects network resources from 
unauthorized access. A firewall permits or denies computer traffic between 
networks with d ifferent security levels based upon a set of rules and other 
criteria.  
Forensics  Also referred to as “computer forensics.” As it relates to information security, 
the application of investigative tools and analysis techniques to gather 
evidence from comput er resources to determine the cause of data 
compromises.  
FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data

criteria.  
FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data 
from one computer to another through a public network such as the Internet. 
FTP is widely viewed as an insecure protocol because passwords and file 
contents are sent unprotected and in clear text. FTP can be implemented 
securely via SSH or other technology . See S-FTP. 
GPRS  Acronym for “General Packet Radio Service.” Mobile data service available 
to users of GSM mobile phones. Recognized for efficient use of limited 
bandwidth. Particularly suited for sending and receiving small bursts of data,

bandwidth. Particularly suited for sending and receiving small bursts of data, 
such as e -mail and web browsing.  
GSM  Acronym for “Global System for Mobile Communications.” Popular standard 
for mobile p hones and networks. Ubiquity of GSM standard makes 
international roaming very common between mobile phone operators, 
enabling subscribers to use their phones in many parts of the world.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 9  
Hashing  Process of rendering cardholder data unreadable by converting  data into a 
fixed -length message digest . Hashing is a  one-way (mathematical) function 
in which a non -secret algorithm takes any arbitrary length message as input 
and produces a fixed length output (usually called a “hash code” or 
“message digest”). A hash function should have the following properties:  
(1) It is computationally infeasible to determine the original input given only 
the hash code,  
(2) It is computationally infeasible to find two inputs that give the same 
hash code .  
In the context of PCI DSS, hashing must be applied to the entire PAN for the 
hash code t o be considered rendered unreadable. It is recommended that 
hashed cardholder data include a n input variable (for example, a “salt”) to

hash code .  
hashed cardholder data include a n input variable (for example, a “salt”) to 
the hashing function  to reduce or defeat the effectiveness of pre-computed 
rainbow table attacks  (see Input Variable ). 
For further guidance, refer to industry standards, such as current versions of 
NIST Special Publications 800 -107 and 800 -106, Federal Information 
Processing Standard (FIPS) 180 -4 Secure Hash Standard (SHS ), and FIPS 
202 SHA -3 Standard: Permutation -Based Ha sh and Extendable -Output 
Functions .  
Host  Main computer hardware on which computer software is resident.

Host  Main computer hardware on which computer software is resident.  
Hosting Provider  Offers various services to merchants and other service providers. Services 
range from simple to complex; from shared space on a server to a whole 
range of “shopping cart” options; from payment applications to connections 
to payment gateways and processors; and for hosting dedicated to just one 
customer per server. A hosting provider may be a shared hosting provider, 
who hosts multi ple entities on a single server.  
HSM  Acronym for “hardware security module” or “host security module.” A

HSM  Acronym for “hardware security module” or “host security module.” A 
physically and logically protected hardware device that provides a secure 
set of cryptographic services, used for cryptographic key -management 
functions and/or the decryption of account data.  
HTTP  Acronym for “hypertext transfer protocol.” Open internet protocol to transfer 
or convey information on the World Wide Web.  
HTTPS  Acronym for “hypertext transfer protocol over secure socket layer.” Sec ure 
HTTP that provides authentication and encrypted communication on the 
World Wide Web designed for security -sensitive communication such as 
web-based logins.

web-based logins.  
Hypervisor  Software or firmware responsible for hosting and managing virtual 
machines. For the purposes of PCI DSS, the hypervisor system component 
also includes the virtual machine monitor (VMM).  
ID Identifier for a particular user or application.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 10  
IDS Acronym for “intrusion -detection system.” Software or hardware used to 
identify and alert on network or system anomalies or intrusion attempts. 
Composed of : sensors that generate security events; a console to monitor 
events and alerts and control the sensors; and a central engin e that records 
events logged by the sensors in a database. Uses system of rules to 
generate alerts in response to detected security events.  See IPS 
IETF  Acronym for “Internet Engineering Task Force.” Large, open international 
community of network designer s, operators, vendors, and researchers 
concerned with evolution of Internet architecture and smooth operation of 
Internet. The IETF has no formal membership and is open to any interested 
individual.

individual.  
IMAP  Acronym for “Internet Message Access Protocol .” An application -layer 
Internet protocol that allows an e -mail client to access e -mail on a remote 
mail server.  
Index Token  A cryptographic token that replaces the PAN, based on a given index for an 
unpredictable value.  
Information Security  Protection of info rmation to ensure confidentiality, integrity, and availability.  
Information System  Discrete set of structured data resources organized for collection, 
processing, maintenance, use, sharing, dissemination, or disposition of 

information.  
Ingress Filtering  Method of filtering inbound network traffic such that only explicitly allowed 
traffic is permitted to enter the network.  
Injection Flaws  Vulnerability that is created from insecure coding techniques resulting in 
improper input validation, which allows att ackers to relay malicious code 
through a web application to the underlying system. This class of 
vulnerabilities includes SQL injection, LDAP injection, and XPath injection.

vulnerabilities includes SQL injection, LDAP injection, and XPath injection.  
Input Variable  Random data string that is concatenated with source data  before  a one-way 
hash function  is applied . Input variables can help reduce the effectiveness of 
rainbow table attacks. See also Hash ing and Rainbow Tables . 
Insecure 
Protocol/Service/Port  A protocol, service, or port that introduces security concerns due to the lack 
of controls over confidentiality and/or integrity. These security concerns 
include services, protocols, or ports that transmit data or authentication

Insecure 
include services, protocols, or ports that transmit data or authentication 
credentials ( for example,  password/passphrase ) in clear -text over the 
Internet, or that easily allow for exploitation by default or if misconfigured . 
Examples of insecure services, protocols, or ports include but are not limited 
to FTP, Telnet, POP3, IMAP, and SNMP  v1 and v2 . 
IP Acronym for “internet protocol.” Network -layer protocol containing address 
information and some control information that enables packets to be routed

information and some control information that enables packets to be routed  
and delivered from the source host to the destination host . IP is the primary 
network -layer protocol in the Internet protocol suite . See TCP. 
IP Address  Also referred to as “internet protocol address.” Numeric code that uniquely 
identifies a particular computer (host)  on the Internet.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 11  
IP Address Spoofing  Attack technique used to gain unauthorized access to networks or 
computers. The malicious individual sends deceptive messages to a 
computer with an IP address indicating that the message is coming from a 
trusted host.  
IPS Acronym for “intrusion prevention system.” Beyond an IDS, an IPS takes the 
additional ste p of blocking the attempted intrusion.  
IPSEC  Abbreviation for “Internet Protocol Security.” Standard for securing IP 
communications at the network layer by encrypting and/or authenticating all 
IP packets  in a communication session.  
ISO In the context of  industry standards and best practices, ISO, b etter known 
as “International Organization for Standardization”  is a non-governmental 
organization consisting of a network of the national standards institutes.

organization consisting of a network of the national standards institutes.  
Issuer  Entity that issues payment cards or perfo rms, facilitates, or supports issuing 
services including but not limited to issuing banks and issuing processors. 
Also referred to as “issuing bank” or “issuing financial institution.”  
Issuing services  
 Examples of issuing services may include but are not  limited to authorization 
and card personalization.  
LAN Acronym for “local area network.” A group of computers and/or other 
devices that share a common communications line, often in a building or

devices that share a common communications line, often in a building or 
group of buildings.  
LDAP  Acronym for “Lightweight Directory Access Protocol.” Authentication and 
authorization data repository utilized for querying and modifying user 
permissions and granting access to protected resources.  
Least Privilege  Having the minimum access and/or privileges necessary to perform the 
roles and responsibilities of the job function.  
Log See Audit Log.  
LPAR  Abbreviation for “logical partition.” A system of subdividing, or partitioning, a 
computer's total resources —processors, memory and storage —into smaller

computer's total resources —processors, memory and storage —into smaller 
units that can run with t heir own, distinct copy of the operating system and 
applications. Logical partitioning is typically used to allow the use of different 
operating systems and applications on a single device. The partitions may 
or may not be configured to communicate with ea ch other or share some 
resources of the server, such as network interfaces.  
MAC  In cryptography, an a cronym for “message authentication code.” A small 
piece of information used to authenticate a message. See Strong 

MAC Address  Abbreviation for “media access control address.” Unique identifying value 
assigned by manufacturers to network adapters and network interface 
cards.  
Magnetic -Stripe Data  See Track Data.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 12  
Mainframe  Computers that are designed to handle very large volumes of data input and 
output and emphasize throughput computing. Mainframes are capable of 
running multiple operating systems, making it appear like it is operating as 
multiple computers. Many legacy systems have a mainframe design.  
Malicious Software / 
Malware  Software  or firmware  designed to infiltrate or damage a computer system 
without the owner's knowledge or consent , with the intent of compromising 
the confidentiality, integrity, or availability of the owner’s  data, applications, 
or operating system . Such software typ ically enters a network during many 
business -approved activities, which results in the exploitation of system 
vulnerabilities. Examples include viruses, worms, Trojans (or Trojan horses),

vulnerabilities. Examples include viruses, worms, Trojans (or Trojan horses), 
spyware, adware, and rootkits.  
Masking  In the context of PCI DSS, i t is a method of concealing a segment of data 
when displayed or printed . Masking is used when there is no business 
requirement to view the entire PAN. Masking relates to protection of PAN 
when displayed or printed. See Truncation  for protection of PAN when 
stored in files, databases, etc.  
Memory -Scraping 
Attacks  Malware activity that examines and extracts data that resides in memory as

Attacks  Malware activity that examines and extracts data that resides in memory as 
it is being processed or which has not been properly flushed or overwritten.  
Merchant  For the purposes of the PCI DSS, a merchant is defined as any entity that 
accepts payment cards bearing the logos of any of the five members of PCI 
SSC (American Express, Discover, JCB, MasterCard or Visa) as payment 
for goods and/or services. Note that a merchant  that accepts payment cards 
as payment for goods and/or services can also be a service provider, if the 
services sold result in storing, processing, or transmitting cardholder data on

services sold result in storing, processing, or transmitting cardholder data on 
behalf of other merchants or service providers. For example, an ISP is a  
merchant that accepts payment cards for monthly billing, but also is a 
service provider if it hosts merchants as customers.  
MO/TO  Acronym for “ Mail-Order/Telephone -Order.”  
Monitoring  Use of systems or processes that constantly oversee computer or networ k 
resources for the purpose of alerting personnel in case of outages, alarms, 
or other predefined events.  
MPLS  Acronym for “multi -protocol label switching.” Network or telecommunications

MPLS  Acronym for “multi -protocol label switching.” Network or telecommunications 
mechanism designed for connecting a group of packet -switched networks.  
Multi -Factor 
Authentication  Method of authenticating a user whereby  at least  two factors are verified. 
These factors include something the user has (such as a smart card or 
dongle), something the user knows (such as a password, passphrase, or 
PIN) or something the user is or does (such as fingerprints, other forms of 
biometrics, etc.).  
NAC  Acronym for “n etwork access control ” or “network admission control .” A

NAC  Acronym for “n etwork access control ” or “network admission control .” A 
method of implementing security at the network  layer by restricting the 
availability of network resources to endpoint devices according to a defined 
security polic y.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 13  
NAT Acronym for “network address translation.” Also k nown  as network 
masquerading or IP masquerading. Change of an IP address used within 
one network to a different IP address known within another network , 
allowing  an organization to have internal addresses that are visible 
internally, and external addresses that are only visible externally.  
Network  Two or more computers connected together via physical or wireless means.  
Network Administrator  Personnel responsible for managing the network within an entity . 
Responsibilities typically include but are not limited to network security, 
installations, upgrades, maintenance and activity m onitoring.  
Network Components  Include, but are not limited to firewalls, switches, routers, wireless access 
points, network appliances, and other security appliances.

points, network appliances, and other security appliances.  
Network Diagram  A diagram showing  system components and connections within a networked 
environment.  
Network Security 
Scan  Process by which an entity’s systems are remotely checked for 
vulnerabilities through use of manual or automated tools. Security scans 
that include probing internal and external systems and reporting on services 
exposed to the network. Scans may identify vulnerabilities in operating 
systems, services, and devices that could be used by malicious individuals.  
Network

Network 
Segmentation  Also referred to as “segmentation” or “isolation.” Network segmentation 
isolates system compon ents that store, process, or transmit cardholder data 
from systems that do not . Adequate network segmentation may reduce the 
scope of the cardholder data environment and thus reduce the scope of the 
PCI DSS assessment. See the Network Segmentation section in the PCI 
DSS Requirements and Security Assessment Procedures for guidance on 
using network segmentation. Network segmentation is not a PCI DSS

using network segmentation. Network segmentation is not a PCI DSS 
requirement.  
Network Sniffing  Also referred to as “packet sniffing” or “sniffing.” A technique that passive ly 
monitors or collects network communication s, decodes protocols, and 
examines contents for information of interest . 
NIST  Acronym for “National Institute of Standards and Technology.” Non -
regulatory federal agency within U.S. Commerce Department's Technolo gy 
Administration.  
NMAP  Security -scanning software that maps networks and identifies open ports in 
network resources.

Non-Console Access  Refers to logical access to a system component that occurs over a network 
interface rather than via a direct , physical connection to the system 
component . Non -console access includes access from within local/internal 
network s as well as access from external, or remote, networks.   
Non-Consumer Users  Individuals, excluding cardholders, who access system components , 
including but not limited to employees, administrators, and third parties.

including but not limited to employees, administrators, and third parties.  
NTP Acronym for “Network Time Protocol.” Protocol for synchronizing the clocks 
of computer systems, network devices and other system components.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 14  
NVD  Acronym for “National Vulnerability Database.” T he U.S. government 
repository of standards -based vulnerability management data. NVD includes 
databases of security checklists, security -related software flaws, 
misconfigurations, product names, and impact metrics . 
OCTAVE® Acronym  for “Operationally Critical Threat, Asset, and Vulnerability 
Evaluation .” A suite of tools, techniques, and methods for risk -based 
information security strategic assessment and planning.  
Off-the-Shelf  Description of products that are stock items not spec ifically customized or 
designed for a specific customer or user and are readily available for use.  
Operating System / 
OS Software of a computer system that is responsible for the management and 
coordination of all activities and the sharing of computer re sources.

coordination of all activities and the sharing of computer re sources. 
Examples of operating systems include Microsoft Windows, Mac OS, Linux 
and Unix.  
Organizational 
Independence  An organizational structure that ensures there is no conflict of interest 
between the person or department performing the activity and the person or 
department assessing the activity. For example,  individuals performing 
assessments  are organizationally separate from the management of the 
environment being assessed . 
OWASP  Acronym for “Open Web Application Security Project.” A non -profit

and Unix.  
OWASP  Acronym for “Open Web Application Security Project.” A non -profit 
organization focused on improving the security of application software. 
OWASP maintains a list of critical vulnerabilities for web applications. (See 
http://www.owasp.org ). 
PA-DSS Acronym for “ Payment Application Data Security Standard .” 
PA-QSA  Acronym for “Payment Application Qualified Security Assessor .” PA-QSAs 
are qualified by PCI SSC to assess payment applications against the PA -
DSS. Refer to the PA-DSS Program Guide  and PA-QSA Qualification 
Requirements  for details about requirements for PA -QSA Companies and 
Employees.

Employees.  
Pad In cryptography, the one -time pad is an encryption algorithm with text 
combined with a random key or "pad"  that is as long as the plain -text and 
used only once. Additionally, if key i s truly random, never reused, and, kept 
secret, the one -time pad is unbreakable  
PAN  Acronym for “primary account number” and also referred to as “account 
number.” Unique payment card number (typically for credit or debit cards) 
that identifies the issuer and the particular cardholder account.  
Parameterized

Parameterized 
Queries  A means of structuring SQL queries to limit escaping and thus prevent 
injection attacks.  
Password / 
Passphrase  A string of characters that serve as an authenticator of the user.  
PAT Acronym for “port address translation” and also referred to as “network 
address port translation.” Type of NAT that also translates the port numbers.  
Patch  Update to existing software to add functionality or to correct a defect.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 15  
Payment Application  In the context of PA-DSS, a  software application that stores, processes, or 
transmits cardholder data as part of authorization or settlement , where the 
payment application is sold, distributed, or licensed to third parties.  Refer to 
PA-DSS Program Guide  for details.  
Payment Cards  For purposes of PCI DSS, any payment card/device that bears the logo of 
the founding members of PCI SSC, which are American Express, Discover 
Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc.  
Payment Processor  Sometimes  referred to as “payment gateway ” or “payment service provider 
(PSP) ”.  
Entity  engaged  by a merchant or other entity to handle payment  card 
transactions on their behalf. While p ayment processor s typically provide

(PSP) ”.  
transactions on their behalf. While p ayment processor s typically provide 
acquiring  services , payment processors are not considered acquirers unless 
defined as such by a payment card brand. See also  Acquirer.   
PCI  Acronym for “Payment Card Industry.”  
PCI DSS  Acronym for “Payment Card Industry  Data Security Standard .” 
PDA  Acronym for “personal  data assistant” or “personal digital assistant.” 
Handheld mobile devices with capabilities such as mobile phones, e -mail, or 
web browser.  
PED PIN entry device .

PED PIN entry device . 
Penetration Test  Penetration tests attempt  to identify ways to exploit vulnerabilities to 
circumvent or defeat the security features of system components . 
Penetration testing includes network and application testing as well as 
controls and processes around the networks and applications, and occurs 
from both outside the environment  (external testing) and from inside the 
environment .  
Personal Firewall 
Software  A software firewall product installed on a single computer.  
Personally Identifiable

Personally Identifiable 
Information  Information that can be utilized to identify or trace an individual ’s identity  
including but not limited to name, address, social security number, biometric 
data, date of birth , etc.  
Personnel  Full-time and part -time employees, temporary employees, contractors, and 
consultants who are “resident” on the entity’s site or othe rwise have access 
to the cardholder data environment.  
PIN Acronym for “personal identification number.” Secret numeric password 
known only to the user and a system to authenticate the user to the system.

known only to the user and a system to authenticate the user to the system. 
The user is only granted access if the PIN the user  provided matches the 
PIN in the system. Typical PINs are used for automated teller machines for 
cash advance transactions. Another type of PIN is one used in EMV chip 
cards where the PIN replaces the cardholder’s signature.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 16  
PIN Block  A block of data used  to encapsulate a PIN during processing. The PIN block 
format defines the content of the PIN block and how it is processed to 
retrieve the PIN. The PIN block is composed of the PIN, the PIN length, and 
may contain subset of the PAN.  
POI Acronym for “Point  of Interaction,” the initial point where data is read from a 
card. An electronic transaction -acceptance product, a POI consists of 
hardware and software and is hosted in acceptance equipment to enable a 
cardholder to perform a card transaction. The POI ma y be attended or 
unattended. POI transactions are typically integrated circuit (chip) and/or 
magnetic -stripe card -based payment transactions.  
Policy  Organization -wide rules governing acceptable use of computing resources,

Policy  Organization -wide rules governing acceptable use of computing resources, 
security practices, and guiding development of operational procedures  
POP3  Acronym for “Post Office Protocol  v3.” Application -layer protocol used by e -
mail clients to retrieve e -mail from a remote server over a TCP/IP 
connection.  
Port Logical  (virtual) connection points  associated with  a particular 
communication protocol to facilitate communications across networks.  
POS  Acronym for “point of sale.” Hardware and/or software used to process 
payment card transactions at merchant locations.

payment card transactions at merchant locations.  
Private Network  Network established by an organization that uses private IP address space. 
Private networks are commonly designed as local area networks. Private 
network access from public networks should be properly protected with the 
use of firewalls and routers.  See also Public Network . 
Privil eged User  Any user account with greater than basic access privileges. Typically, these 
accounts have elevated or increased privileges with more rights than a 
standard user account. However, the extent of privileges across different

standard user account. However, the extent of privileges across different 
privileged accounts can vary greatly depending on the organization, job 
function or role, and the technology in use.  
Procedure  Descriptive narrative for a policy. Procedure is the “how to” for a policy and 
describes how the policy is to be implemented.  
Protocol  Agreed -upon meth od of communication used within networks. Specification 
describing rules and procedures that computer products should follow to 
perform activities on a network.  
Proxy Server  A server  that acts as an int ermediary between an internal network  and the

Proxy Server  A server  that acts as an int ermediary between an internal network  and the  
Internet. For example, one function of a proxy server is to terminate or 
negotiate connections between internal and external connections such that 
each only communicates with the proxy server . 
PTS Acronym for “PIN Transaction Security,”  PTS is a set of m odular evaluation 
requirements managed by PCI Security Standards Council, for PIN 
acceptance POI terminals. Please refer to www.pcisecuritystandards.org.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 17  
Public Network  Network established and operated by a third party telecommunications 
provider for spec ific purpose of providing data transmission services for the 
public. Data over public networks can be intercepted, modified, and/or 
diverted while in transit. Examples of public networks include, but are not 
limited to, the Internet, wireless, and mobile t echnologies.  See also Private 
Network . 
PVV Acronym for “PIN verification value.” Discretionary value encoded in 
magnetic stripe of payment card.  
QIR Acronym for “ Qualified Integrator or Reseller.”  Refer to  the QIR Program 
Guide on the PCI SSC website for  more information.  
QSA  Acronym for “Qualified Security Assessor .” QSAs are qualified by PCI SSC 
to perform PCI DSS on -site assessments. Refer to the QSA Qualification

Network . 
to perform PCI DSS on -site assessments. Refer to the QSA Qualification 
Requirements  for details about requirements for QSA Companies and 
RADIUS  Abbreviation for “Remote Authentication Dial -In User Service.” 
Authentication and accounting system. Checks if information such as 
username and password that is passed to the RADIUS server is correct, 
and then authorizes access to the system. This authenti cation method may 
be used with a token, smart card, etc., to provide multi -factor authentication.

be used with a token, smart card, etc., to provide multi -factor authentication.  
Rainbow Table Attack  A method of data attack using a  pre-computed table of hash strings ( fixed -
length message digest ) to identify the original data source , usually for 
cracking password or cardholder data hashes . 
Re-keying  Process of changing cryptographic keys. Periodic re -keying limits the 
amount of data encrypted by a single key.  
Remote Access  Access to computer networks from a location  outside of that network . 
Remote access connections can originat e either from inside the company’s

Remote access connections can originat e either from inside the company’s 
own network or from a remote location outside the company’s network. An 
example of technology for remote access is VPN. 
Remote Lab 
Environment  A lab that is  not maintained by the PA -QSA.  
Removable Electronic 
Media  Media that store digitized data and which can be easily removed and/or 
transported from one computer system to another. Examples of removable 
electronic media include CD -ROM, DVD -ROM, USB flash drives and 
external/ portable  hard drives.

Remote Lab 
external/ portable  hard drives.  
Reseller / Integrat or An entity that sells and/or integrates payment applications but does not 
develop them.  
RFC 1918  The standard identified by the Internet Engineering Task Force (IETF) that 
defines the usage and appropriate address ranges for private (non -internet 
routable) networks.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 18  
Risk Analysis / Risk 
Assessment  Process that identifies valuable system resources and threats; quantifies 
loss exposures (that is, loss potential) based on estimated frequencies and 
costs of occurrence; and (optionally) recommends how to allocate resources 
to countermeasures so as to minimize total exposure.  
Risk Ranking  A defined criterion of measurement based upon the risk assessment and 
risk analysis performed on a given entity.  
ROC  Acronym for  “Report on Compliance .” Report documenting detailed results 
from an entity’s PCI DSS assessment . 
Rootkit  Type of malicious software that when installed without authorization, is able 
to conceal its presence and gain administrative control of a computer 
system.  
Router  Hardware or software that connects two or more networks. Functions as

system.  
Router  Hardware or software that connects two or more networks. Functions as 
sorter and interpreter by looking at addresses and passing bits of 
information to proper destinations. Software routers are sometimes referred 
to as gateways.  
ROV  Acronym for “Report on Validation .” Report documenting detailed results 
from a PA -DSS assessment for purposes of the PA -DSS program . 
RSA  Algorithm for public -key encryption described in 1977 by Ron Rivest, Adi 
Shamir, and Len Adleman  at Massachusetts Institute of Technology (MIT); 
letters RSA are the initials of their surnames.

letters RSA are the initials of their surnames.  
S-FTP Acronym for Secure -FTP. S-FTP has the ability to encrypt authentication 
information and data files in transit . See FTP.  
Sampling  The process of selecting a cross -section of a group that is representative of 
the entire group . Sampling may be used by assessors to reduce overall 
testing efforts, when it is validated that an entity has standard, centralized 
PCI DSS security and operational processes a nd controls in place. 
Sampling is not a PCI DSS requirement.

Sampling is not a PCI DSS requirement.  
SANS  Acronym for “SysAdmin, Audit, Networking and Security,” an institute that 
provides computer security training and professional certification. (See 
www.sans.org .) 
SAQ  Acronym for “Self -Assessment Questionnaire.” Reporting tool used to 
document self -assessment results from an entity’s PCI DSS assessment.  
Schema  Formal description of how a database is constructed  including the 
organization of data elements.  
Scoping  Process of identifying all system components, people, and processes to be

Scoping  Process of identifying all system components, people, and processes to be 
included in a PCI DSS assessment. The first step of a PCI DSS assessment 
is to accurately determine the scope of the review.  
SDLC Acronym for “system development life cycle”  or “software development 
lifecycle.” Phases of the development of a software or computer system that 
includes planning, analysis, design, testing, and implementation.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 19  
Secure Coding  The process of creating and implementing applications that are resistant to 
tampering and/or compromise.  
Secure Cryptographic 
Device  A set of hardware, software and firmware that implements cryptographic 
processes (including cryptographic algorithms and key generation) and is 
contained within a defined cryptographic boundary. Examples of secure 
cryptographic devices include host/hardwar e security modules (HSMs) and 
point -of-interaction devices (POIs) that have been validated to PCI PTS.  
Secure Wipe  Also called “secure delete,”  a method o f overwriting data residing on a hard 
disk drive or other digital media, rendering the data irretrie vable .  
Security Event  An occurrence considered by an organization to have potential security

Security Event  An occurrence considered by an organization to have potential security 
implications to a system or its environment . In the context of PCI DSS, 
security events identify suspicious or anomalous activity.  
Security Officer  Primary person responsible for an entity’s security -related matters . 
Security Policy  Set of laws, rules, and practices that regulate how an organization 
manages, protects, and distributes sensitive information  
Security Protocols  Network communications protocols designed to secure the transmission of 
data. Examples of security protocols include, but are not limited to TLS,

data. Examples of security protocols include, but are not limited to TLS, 
IPSEC, SSH, HTTPS, etc. 
Sensitive Area  Any data center, server room or any area that houses systems that store, 
process, or transmit cardholder data. This excludes the areas where only 
point -of-sale terminals are present such as the cashier areas in a retail 
store.  
Sensitive 
Authentication Data  Security -related information (including but not limited to card validation 
codes/values, full track data (from the magnetic stripe or equivalent on a 
chip) , PINs, and PIN blocks) used to authenticate cardholders and/or

store.  
Sensitive 
chip) , PINs, and PIN blocks) used to authenticate cardholders and/or 
authorize payment card transactions.  
Separation of Duties  Practice of dividing steps in a function among different individuals, so as to 
keep a single individual from being able to subvert the process.  
Server  Computer that provides a service to other computers, such as processing 
communications, file storage, or accessing a printing facility. Servers 
include, but are not limited to web, database, application, authentication, 
DNS, mail, proxy, and NTP.

DNS, mail, proxy, and NTP.  
Service Code  Three -digit or four -digit value in the magnetic -stripe that follows  the 
expiration date of the payment card on the track data. It is used for various 
things such as defining service attributes, differentiating between 
international and national interchange, or identifying usage restrictions.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 20  
Service Provider  Business ent ity that is not a payment brand, directly involved in the 
processing, storage, or transmission of cardholder data  on behalf of another 
entity . This also includes companies that provide services that control or 
could impact the security of cardholder data. Examples include managed 
service providers that provide managed firewalls, IDS and other services as 
well as hosting providers and other entities.  If an entity provides a service 
that involves only the provision of public network access —such as a 
telecommu nications company  providing just the communication link —the 
entity would  not be considered a service provider for that service (although 
they may be considered a service provider for other services) .

they may be considered a service provider for other services) .  
Session Token  In the context of web session management, a session token (also referred 
to as a “ session identifier ” or “session ID ”), is a unique identifier (such as a 
“cookie”) used to track a particular session between a web browser and a 
webserver.  
SHA -1/SHA -2 Acronym for “Secure Hash Algorithm.” A family or set of related 
cryptographic hash functions including SHA -1 and SHA -2. See Strong 
Smart Card  Also referred to as “chip card” or “IC card (integrated circuit card).” A type of

Smart Card  Also referred to as “chip card” or “IC card (integrated circuit card).” A type of 
payment card that has integrated circuits embedded within. The circuits, 
also referred to as the “chip,” contain payment card data including but not 
limited to data equivalent to the magnetic -stripe data.  
SNMP  Acronym for “Simple Network Management Protocol.” Supports  monitoring 
of network attached devices for any conditions that warrant administrative 
attention.  
Split Knowledge  A method  by which two or more entities separately have key components 
that individually convey no knowledge of the resultant cryptographic ke y.

that individually convey no knowledge of the resultant cryptographic ke y. 
Spyware  Type of malicious software that when installed, intercepts or takes partial 
control of the user’s computer without the user’s consent.  
SQL Acronym for “Structured Query Language.” Computer language used to 
create, modify, and retrieve data from relational database management 
systems.  
SQL Injection  Form of attack on database -driven web site. A malicious individual executes 
unauthorized SQL commands by taking advantage of insecure code on a 
system connected to the Internet. SQL injection atta cks are used to steal

systems.  
system connected to the Internet. SQL injection atta cks are used to steal 
information from a database from which the data would normally not be 
available and/or to gain access to an organization’s host computers through 
the computer that is hosting the database.  
SSH Abbreviation for “Secure Shell.” Protocol suite providing encryption for 
network services like remote login or remote file transfer.  
SSL Acronym for “Secure Sockets Layer.” Industry standard that encrypts the 
channel between a web browser and web server . Now superseded by TLS. 
See TLS.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 21  
Stateful Inspection  Also called “dynamic packet filtering .” Firewall capability that provides 
enhanced security by keeping track of the state of network connections . 
Programmed to distinguish legitimate packets for various connections , only 
packets matching an established connection will be permitted by the firewall; 
all others will be rejected . 
Strong Cryptography  Cryptography based on industry -tested and accepted algorithms, along with 
key lengths that provide a minimum of 112-bits of effective key strength and 
proper key -management practices. Cryptography is a method to protect 
data and includes both encryption (which is reversible) and hashing (which 
is “one way” ; that is, not reversible). See Hashing .  
At the time of publ ication, examples of industry -tested and accepted

At the time of publ ication, examples of industry -tested and accepted 
standards and algorithms include AES (128 bits and higher ), TDES /TDEA  
(triple -length keys), RSA (2048 bits and higher), ECC ( 224 bits and higher), 
and DSA/D -H (2048 /224 bits and higher). See the current version of NIST 
Special Publication 800 -57 Part 1 ( http://csrc.nist.gov/publications/ ) for more 
guidance on cryptographic key strengths and algorithms.  
Note:  The above examples are appropriate for persistent storage of 
cardholder data. The minimum cryptography requirements for transaction -

based operations, as defined in PCI PIN and PTS, are more flexible as there 
are additional controls in place to reduce the level of exposure.  
It is recommende d that all new implementations use a minimum of 128 -bits 
of effective key strength.  
SysAdmin  Abbreviation for “system administrator.” Individual with elevated privileges 
who is responsible for managing a computer system or network.  
System Components  Any network devices , server s, computing devices, or application s included 
in or connected to the cardholder data environment.

in or connected to the cardholder data environment.  
System -level object  Anything on a system component that is required for its operation, including 
but not limited to database tables,  stored procedures, application 
executable s and configuration files, system configuration files, static and 
shared libraries and DLLs, system executables, device drivers and device 
configuration files, and third -party components.  
TACACS  Acronym for  “Terminal Access Controller Access Control System.” Remote 
authentication protocol commonly used in networks that communicates

authentication protocol commonly used in networks that communicates 
between a remote access server and an authentication server to determine 
user access rights to the network. This authentication method may be used 
with a token, smart card, etc., to provide multi -factor authentication.  
TCP Acronym for “Transmission Control Protocol.” One of the core transport -
layer protocols of the Internet Protocol (IP)  suite , and the b asic 
communication language  or protocol of the Internet . See IP. 
TDES  Acronym for “Triple Data Encryption Standard” and also known as “3DES” 
or “Triple DES.” Block cipher formed from the DES cipher by using it three

or “Triple DES.” Block cipher formed from the DES cipher by using it three 
times. See Strong Cryptography.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 22  
TELNET  Abbreviation for “telephone network protocol.” Typically used to provide 
user-oriented command line login sessions to devices on a network. User 
credentials are transmitted in clear text.  
Threat  Condition or activity that has the potential to  cause information or 
information processing resources to be intentionally or accidentally lost, 
modified, exposed, made inaccessible, or otherwise affected to the 
detriment of the organization  
TLS Acronym for “Transport Layer Security.” Designed with goal of pr oviding 
data secrecy and data integrity between two communicating applications. 
TLS is successor of SSL.  
Token  In the context of authentication and access control, a token is a  value 
provided by hardware or software that works with an authentication serve r

provided by hardware or software that works with an authentication serve r 
or VPN to perform dynamic or multi -factor authentication . See RADIUS, 
TACACS, and VPN.   See also Session Token . 
Track Data  Also referred to as “ full track data”  or “magnetic -stripe data .” Data encoded 
in the magnetic stripe or chip used for authentication and/or authorization 
during payment transactions. Can be the magnetic -stripe image on a chip or 
the data on the track 1 and/or track 2 portion of the magnetic stripe.  
Transaction Data  Data related to electronic payment card transaction.

Transaction Data  Data related to electronic payment card transaction.  
Trojan  Also referred to as “Trojan horse.” A type of malicious software that when 
installed, allows a user to perform a normal function while the Trojan 
performs malicious functions to the computer syst em without the user’s 
knowledge.  
Truncation  Method of rendering the full PAN unreadable by permanently removing a 
segment of PAN data. Truncation relates to protection of PAN when stored  
in files, databases, etc. See Masking for protection of PAN when displayed  
on screens, paper receipts, etc.

on screens, paper receipts, etc.  
Trusted Network  Network of an organization that is within the organization’s ability to control 
or manage.  
Untrusted Network  Network that is external to the networks belonging to an organization and 
which is out of  the organization’s ability to control or manage.  
URL Acronym for “ Uniform Resource Locator .” A formatted text string used by 
Web browsers, e -mail clients , and other software to identify a network 
resource  on the Internet . 
Versioning 
Methodology

or manage.  
Methodology  
 A process of assigning version schemes to uniquely identify a particular 
state of an application or software . These schemes follow a version -number 
format, version -number usage, and any wildcard element as defined by the 
software vendor . Version numbers are generally assigned in increasing 
order and correspond to a particular change in the software.

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 23  
Virtual Appliance (VA)  A VA takes the concept of a pre -configured device for performing a specific 
set of functions and run this device as a workload. Often, an existing 
network device is virtualized to run as a virtual appliance, such as a router, 
switch, or firewall .  
Virtual Hypervisor  See Hypervisor .  
Virtual Machine  A self -contained operating environment that behaves like a separate 
computer. It is also known as the “Guest,” and runs on top of a hypervisor.  
Virtual Machine 
Monitor (VMM)  The VMM is included with the hypervisor and is software that implements 
virtual machine hardware abstraction. It manages the system's processor, 
memory, and other resources to allocate what each guest operating system 
requires.  
Virtual Payment

requires.  
Virtual Payment 
Terminal  A virtual  payment  terminal is web -browser -based  access to an acquirer, 
processor or third party service provider website to authorize payment card 
transactions, where the merchant manual ly enters payment card data via a 
securely connected web browser. Unlike physical terminals, virtual payment 
terminals  do not read data directly from a payment card . Because payment 
card transactions are entered manually, virtual payment terminals are

requires.  
card transactions are entered manually, virtual payment terminals are 
typically used instead of physical terminals in merchant environments with 
low transaction volumes.  
Virtual Switch or 
Router A virtual switch or router is a logical entity that presents network 
infrastructure level data routing and switching functionality. A virtual switch 
is an integral part of a virtualized server platform such as a hypervisor 
driver, module, or plug -in.  
Virtualization  Virtualization refers to the logical abstraction of computing resources from

Virtualization  Virtualization refers to the logical abstraction of computing resources from 
physical constraints. One common abstraction is referred to as virtual 
machines or VMs, which takes the content of a physical machine and allows 
it to operate on d ifferent physical hardware and/or along with other virtual 
machines on the same physical hardware. In addition to VMs, virtualization 
can be performed on many other computing resources, including 
applications, desktops, networks, and storage.  
VLAN  Abbrevi ation for “virtual LAN” or “virtual local area network.” Logical local

VLAN  Abbrevi ation for “virtual LAN” or “virtual local area network.” Logical local 
area network that extends beyond a single traditional physical local area 
network.  
VPN Acronym for “virtual private network.” A computer network in which some of 
connections are virtu al circuits within some larger network, such as the 
Internet, instead of direct connections by physical wires. The end points of 
the virtual network are said to be tunneled through the larger network when 
this is the case. While a common application consis ts of secure

network.  
this is the case. While a common application consis ts of secure 
communications through the public Internet, a VPN may or may not have 
strong security features such as authentication or content encryption.  
A VPN may be used with a token, smart card, etc., to provide two -factor 
authentication.  
Vulnerabilit y Flaw or weakness which, if exploited, may result in an intentional or 
unintentional compromise of a system .

© 2006 -2016 PCI Security Standards Council, LLC. All Rights Reserved  Page 24  
WAN  Acronym for “wide area network.” Computer network covering a large ar ea, 
often a regional or company -wide computer system.  
Web Application  An application that is generally accessed via a web browser or through web 
services . Web applications may be available via the Internet or a private, 
internal network.  
Web Server  Computer that contains a program that accepts HTTP requests from web 
clients  and serves the HTTP responses (usually web pages).  
WEP  Acronym for “Wired Equivalent Privacy.” Weak algorithm used to encrypt 
wireless networks. Several serious weaknesses have been identified by 
industry experts such that a WEP connection can be cracked  with readily 
available software within minutes. See WPA.  
Wildcard  A character that may be substituted for a defined subset of possible

Wildcard  A character that may be substituted for a defined subset of possible 
characters in an application version scheme.  In the context of PA -DSS, 
wildcards can optionally be used to represent a non -security impacting 
change. A wildcard is the only variable  element of the vendor’s version 
scheme, and is used to indicate there are only minor, non -security -
impacting changes be tween each version represented by the wildcard 
element .  
Wireless Access Point  Also referred to as “AP.” Device that allows wireless communication devices

element .  
Wireless Access Point  Also referred to as “AP.” Device that allows wireless communication devices 
to connect to a wireless network. Usually connected to a wired network, it 
can relay data between wireless devices and wired devices on the network.  
Wireless Networks  Network that connects computers without a physical connection to wires.  
WLAN  Acronym for “wireless local area network.” Local area network that links two 
or more computers or devices wi thout wires.  
WPA/WPA2  Acronym for “WiFi Protected Access.” Security protocol created to secure 
wireless networks. WPA is the successor to WEP. WPA2 was also released

wireless networks. WPA is the successor to WEP. WPA2 was also released 
as the next generation of WPA.

PCI DSS v4.0 Report on Compliance Template  
Revision 1  

PCI DSS v4.0 ROC Template  r1 December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.  Page ii 
 
Date  Version  Description  
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.  
April 2015  PCI DSS 3.1, 
Revision  1.0 Revision to align with changes from PCI DSS 3.0 to PCI DSS 3.1 (see PCI DSS – Summary of Changes from PCI DSS 
Version 3.0 to 3.1 for details of those changes). Also includes minor edits made for clarification and/or format.  
April 2016  PCI DSS 3.2, 
Revision 1.0  Revision to align with changes from PCI DSS 3.1 to PCI DSS 3.2 (see PCI DSS – Summary of Changes from PCI DSS

Revision 1.0  Revision to align with changes from PCI DSS 3.1 to PCI DSS 3.2 (see PCI DSS – Summary of Changes from PCI DSS 
Version 3.1 to 3.2 for details of those changes). Also includes minor corrections and edits made for clarification and/or 
format.  
June 2018  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.  
March 2022  PCI DSS 4.0  Updates to align with the changes from PCI DSS v3.2.1 to PCI DSS v4.0 (see PCI DSS – Summary of Changes from

format.  
format.  
March 2022  PCI DSS 4.0  Updates to align with the changes from PCI DSS v3.2.1 to PCI DSS v4.0 (see PCI DSS – Summary of Changes from 
PCI DSS Version 3.2.1 to 4.0 for details of changes). Also includes corrections and edits made for clarification and/or 
format.  
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.

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page iii 
 
ROC Template Instructions ...................................................................................................................................................................... 6 
ROC Sections  .......................................................................................................................................................................................................... 6 
Assessment Findings  .............................................................................................................................................................................................. 8 
What Is the Difference between Not Applicable and Not Tested?  ........................................................................................................................ 11

What Is the Difference between Not Applicable and Not Tested?  ........................................................................................................................ 11 
Dependence on Another Service Provider’s Compliance ..................................................................................................................................... 12 
Assessment Approach Reporting Options  ............................................................................................................................................................ 13 
Understanding the Reporting Instructions  ............................................................................................................................................................. 15

Understanding the Reporting Instructions  ............................................................................................................................................................. 15 
Dos and Don’ts: Reporting Expectations  ............................................................................................................................................................... 16 
PCI DSS v4.0 Report on Compliance Template  ................................................................................................................................................... 16 
Part I  Assessment Overview  .................................................................................................................................................................  2

Part I  Assessment Overview  .................................................................................................................................................................  2 
1 Contact Information and Summary of Resu lts .................................................................................................................................  2 
1.1 Contact Information ........................................................................................................................................................................................ 2 
1.2 Date and Timeframe of Assessment  ............................................................................................................................................................. 4

1.2 Date and Timeframe of Assessment  ............................................................................................................................................................. 4 
1.3 Remote Assessment Activities  ...................................................................................................................................................................... 4 
1.4 Additional Services Provided by QSA Company  ........................................................................................................................................... 6 
1.5 Use of Subcontractors  ................................................................................................................................................................................... 7

1.5 Use of Subcontractors  ................................................................................................................................................................................... 7 
1.6 Additional Information/Reporting  ................................................................................................................................................................... 7 
1.7 Overall Assessment Result  ............................................................................................................................................................................ 7 
1.8 Summary of Assessment  ............................................................................................................................................................................... 8

1.8 Summary of Assessment  ............................................................................................................................................................................... 8 
1.9 Attestation Signatures  .................................................................................................................................................................................. 10 
2 Business Overview  ............................................................................................................................................................................ 11 
2.1 Description of the Entity’s Payment Card Business  .................................................................................................................................... 11

2.1 Description of the Entity’s Payment Card Business  .................................................................................................................................... 11 
3 Description of Scope of Work and Approach Taken ..................................................................................................................... 12 
3.1 Assessor’s Validation of Defined Scope Accuracy  ...................................................................................................................................... 12

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page iv 
 
3.2 Segmentation  ............................................................................................................................................................................................... 13 
3.3 PCI SSC Validated Products and Solutions  ................................................................................................................................................ 14 
3.4 Sampling  ...................................................................................................................................................................................................... 15 
4 Details About Reviewed Environments  .......................................................................................................................................... 16

4 Details About Reviewed Environments  .......................................................................................................................................... 16 
4.1 Network Diagrams  ....................................................................................................................................................................................... 16 
4.2 Account Dataflow Diagrams  ........................................................................................................................................................................ 17 
4.3 Storage of Account Data  .............................................................................................................................................................................. 18

4.3 Storage of Account Data  .............................................................................................................................................................................. 18 
4.4 In-scope Third- Party Service Providers (TPSPs)  ........................................................................................................................................ 19 
4.5 In-scope Networks  ....................................................................................................................................................................................... 21

4.5 In-scope Networks  ....................................................................................................................................................................................... 21 
4.6 In-scope Locations/Facilities  ........................................................................................................................................................................ 21 
4.7 In-scope Business Functions  ....................................................................................................................................................................... 22 
4.8 In-scope System Component Types ............................................................................................................................................................ 22

4.8 In-scope System Component Types ............................................................................................................................................................ 22 
4.9 Sample Sets for Reporting  ........................................................................................................................................................................... 25 
5 Quarterly Scan Results  ..................................................................................................................................................................... 26 
5.1 Quarterly External Scan Results  .................................................................................................................................................................. 26

5.1 Quarterly External Scan Results  .................................................................................................................................................................. 26 
5.2 Attestations of Scan Compliance  .................................................................................................................................................................  26 
5.3 Quarterly Internal Scan Results  ................................................................................................................................................................... 27 
6 Evidence (Assessment Workpapers)  .............................................................................................................................................. 28

6 Evidence (Assessment Workpapers)  .............................................................................................................................................. 28 
6.1 Evidence Retention  ...................................................................................................................................................................................... 28 
6.2 Documentation Evidence  ............................................................................................................................................................................. 28 
6.3 Interview Evidence  ....................................................................................................................................................................................... 28

6.3 Interview Evidence  ....................................................................................................................................................................................... 28 
6.4 Observation Evidence  .................................................................................................................................................................................. 29 
6.5 System Evidence  ......................................................................................................................................................................................... 30

6.5 System Evidence  ......................................................................................................................................................................................... 30 
Part II  Findings and Observations ....................................................................................................................................................... 31 
Build and Maintain a Secure Net work and Systems  ........................................................................................................................... 31 
Requirement 1: Install and Maintain Network Security Controls  ........................................................................................................................... 31

Requirement 1: Install and Maintain Network Security Controls  ........................................................................................................................... 31 
Requirement 2: Apply Secure Configurations to All System Components  ........................................................................................................... 62 
Protect Account Data  .............................................................................................................................................................................. 82 
Requirement 3: Protect Stored Account Data  ....................................................................................................................................................... 82

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page v 
 
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks  .................................  129 
Maintain a Vulnerability Management Program  .................................................................................................................................  138 
Requirement 5: Protect All Systems and Networks from Malicious Software  ..................................................................................................... 138 
Requirement 6: Develop and Maintain Secure Systems and Software  .............................................................................................................. 161 
Implement Strong Access Control Measures  .................................................................................................................................... 196

Implement Strong Access Control Measures  .................................................................................................................................... 196 
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know ..................................................... 196 
Requirement 8: Identify Users and Authenticate Access to System Components  ............................................................................................. 216 
Requirement 9: Restrict Physical Access to Cardholder Data  ............................................................................................................................ 265

Requirement 9: Restrict Physical Access to Cardholder Data  ............................................................................................................................ 265 
Regularly Monitor and Test Networks  ................................................................................................................................................. 310 
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data  ............................................................................ 310 
Requirement 11: Test Security of Systems and Networks Regularly  .................................................................................................................. 354

Requirement 11: Test Security of Systems and Networks Regularly  .................................................................................................................. 354 
Maintain an Information Security Policy  ............................................................................................................................................. 392 
Requirement 12: Support Information Security with Organizational Policies and Programs  .............................................................................. 392 
Appendix A  Additional PCI DSS Requirements  ............................................................................................................................. 449

Appendix A  Additional PCI DSS Requirements  ............................................................................................................................. 449 
A1 Additional PCI DSS Requirements for Multi -Tenant Service Providers  ......................................................................................................... 449 
A2 Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card- Present POS POI Terminal Connections  ........................... 459 
A3 Designated Entities Supplemental Validation (DESV)  ................................................................................................................................... 463

A3 Designated Entities Supplemental Validation (DESV)  ................................................................................................................................... 463 
Appendix B  Compensating Controls .............................................................................................................................................. 464 
Appendix C  Compensating Controls Worksheet  ........................................................................................................................... 466 
Appendix D  Customized Approach  ................................................................................................................................................. 467

Appendix D  Customized Approach  ................................................................................................................................................. 467 
Appendix E  Customized Approach Template  ................................................................................................................................ 469

PCI DSS v4.0 ROC Template  r1: ROC Template  Instructions   December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page vi 
ROC Template Instructions  
This document, the PCI DSS v4.0 Report on Compliance Template (“ROC Template”), is the mandatory template for Qualified Secur ity 
Assessors (QSAs) completing a Report on Compliance (ROC) for assessments against the Payment Card Industry Data Security Standard 
(PCI DSS) Requirements and Testing Procedures . The ROC Template provides the reporting instructions and template for QSAs to document 
PCI DSS assessments with the aim of ensuring a consistent level of  reporting among assessors.   
Use of this ROC Template is mandatory for all PCI DSS v4.0 submissions.  
The tables in this template may be modified to increase/decrease the number of rows or to change the column width. Additional appendices

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

Do not delete any content from Part I  or Part II of this document. The Instruction pages  may be deleted; however, the assessor must follow 
these instructions  while documenting the assessment . The addition of text or rows is acceptable, within reason, as noted above. Ref er to the 
PCI DSS v4.x Report on Compliance Template -  Frequently Asked Questions  document on the PCI SSC website for further guidance.  
The ROC is completed during PCI DSS assessments as part of an entity’s validation process. The ROC provides details abou t the entity’s 
environment and assessment methodology and documents the entity’s assessment results for each PCI DSS requirement. A PCI DSS

environment and assessment methodology and documents the entity’s assessment results for each PCI DSS requirement. A PCI DSS 
compliance assessment involves thorough testing and assessment activities, from which the assessor will generate evi dence (assessment 
workpapers). These workpapers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots,  and other evidence collected during the 
assessment. The ROC is effectively a summary of evidence derived from the assessor’s workpapers to document how the assessor

assessment. The ROC is effectively a summary of evidence derived from the assessor’s workpapers to document how the assessor 
performed the validation activities and how the resultant findings were reached. At a high  level, the ROC provides a comprehensive summary 
of testing activities performed and information collected during the assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures . The information contained in a ROC must provide enough information and coverage to 
support the designated assessment findings.  
ROC Sections 
The ROC includes the following sections and appendices:  
 Part I: Assessment Overview

 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

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page vii 
– Section 4: Details about Reviewed Environment  
– Section 5: Quarterly Scan Results  
– Section 6: Evidence (Assessment Workpapers)  
 Part II: Findings and Observations  
– Build and Maintain a Secure Network and Systems  
– Protect Account Data  
– Maintain a Vulnerability Management Program  
– Implement Strong Access Control Measures  
– Regularly Monitor and Test Networks  
– Maintain an Information Security Policy  
– Appendix A: Additional PCI DSS Requirements  
– Appendix B: Compensating Controls  
– Appendix C: Compensating Controls Worksheet  
– Appendix D: Customized Approach  
– Appendix E: Customized Approach Template  
Part I must be thoroughly and accurately completed to provi de proper context for the assessment findings in Part II. The ROC Template

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page viii 
There are four possible assessment f indings : In Place, Not  Applicable, Not Tested, and Not in Place. At each sub- requirement there is a place 
to designate the result (“Assessment Findings”), which can be checked as appropriate. See the example format in Figure 1. 
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.  
Finding  When to Use This Assessment Finding  Using Figure 1  Required Reporting

guidance.  
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 I n Place for 1.1.1.a and 
1.1.1.b or a combination of In Place and N ot 
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 the N ot Applicable status  including a 
detailed description explaining how it was determined that the requirement does not apply.  
Note that r eporting instructions that start with “If Yes” or “If 
No” do not require additional testing to confirm the Not 
Applicable status . For example, if the Reporting 
Instruction was “If Yes, complete the following” and the 
response was “No” then the assessor would simply mark

response was “No” then the assessor would simply mark 
that section as Not Applicable or N/A and no further testing is required.  In Figure 1 , the Assessment Finding at 1.1.1 is Not 
Applicable if both 1.1.1.a and 1.1.1.b are concluded 
to be N ot Applica ble. A requirement is applicable if 
any aspects of the requirement apply to the 
environment being assessed, and a Not Applicable designation in the Assessment Findings should not 
be used in this scenario.  
Note:  Requirements and/or individual bullets within  a

Note:  Requirements and/or individual bullets within  a 
requirement noted as a best practice until its effective 
date are considered Not Applicable until the future 
date has passed. While it is true that the requirement 
is likely not tested (hence the original instructions), it is not required to be tested until the future date has passed, and the requirement is therefore not 
applicable until that date. As such, a Not Applicable 
response to future- dated requirements is accurate, 
whereas a Not Tested response would imply there was not any consideration as to w hether it could 
apply .

apply .  
Once the effective date has passed, responses to those requirements should be consistent with instructions for all requirements.  Describe the testing 
performed and the results 
of the testing that 
demonstrates the requirement is Not Applicable.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page ix 
Finding When to Use This Assessment Finding  Using Figure 1  Required Reporting  
Not Tested  The requirement (or any single aspect of the requirement) 
was not included for consideration in the assessment and 
was not tested in any way.  
(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

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 t hey 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 advice are not legal

being met.  
Note:  Contractual obligations or legal advice are not legal 
restrictions.  In Figure 1 , the Assessment Finding at 1.1.1 is Not in 
Place if either 1.1.1.a or 1.1.1.b are concluded to be Not in Place.  Describe how the testing 
and evidence demonstrates the 
requirement is Not i n 
Place. 
If the requirement is N ot in 
Place due to a legal restriction, the assessor 
must describe the statutory law or regulation that prohibits the 
requirement from being 
met.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page x 
Figure 1. Example Requirement  
Requirement Description  
1.1 Example Requirement Description  
PCI DSS Requirement  
1.1.1  Example Requirement  
(select one)  
In Place  Not Applicable  Not Tested  Not in Place 
☐ ☐ ☐ ☐ 
Describe why the assessment finding was selected.  
Note : Include all details as noted in the “Required Reporting” column of the table in 
Assessment Findings in the ROC Template Instructions.  <Enter Response Here>  
Validation Method – Customized Approach  
Indicate  whether a Customized Approach was used :  ☐ Yes    ☐ No 
If “Yes”, Identify  the aspect(s) of the requirement where the Customized Approach was 
used . 
Note:  The use of Customized Approach must also be documented in Appendix E . <Enter Response Here>  
Validation Method – Defined Approach

used . 
Validation Method – Defined Approach  
Indicate  whether a Compensating Control was used :  ☐ Yes    ☐ No 
If “Yes”, Identify  the aspect(s) of the requirement where the Compensating Control(s) was 
used . 
Note:  The use of Compensating Controls must also be documented in Appendix C . <Enter Response Here>  
Testing Procedures  Reporting Instructions  Reporting Details:  
Assessor’s Response  
1.1.1.a  Example testing procedure  Example reporting instruction  <Enter Response Here>  
1.1.1.b  Example testing procedure  Example reporting instruction  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page xi 
What Is the Difference between Not Applicable and Not Tested ? 
Requirements that are N ot Applicable to an environment must be verified as such. Using the example of wireless and an organization that 
does not use wireless technology in any capacity, an assessor could select Not Applicable for Requirements 1.3.3, 2.3.1 -  2.3.3, and 4.2.1.2 
after the assessor confirms  through testing that there are no wireless technologies used in their CDE or that connect to their CDE. Once this 

 An organization may be asked by their acquirer or brand to validate a subset of requirements —for example, using the prioritized 
approach to vali date certain milestones.  
 An organization may want to validate a new security control that impacts only a subset of requirements —for example, implementation of 

 A service p rovider organization might offer a service that covers only a limited number of PCI DSS requirements —for example, a 
physical storage provider may want only to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.  
In these scenarios, the organization wants only to validate certain PCI DSS requirements , even though other requirements might also apply to 

Items marked as  Not Applicable require that the assessor render an opinion that the item is not applicable; however, with Not Tested,  the 
assessor is simply following the entity’s instructions to no t test something with no opinion needed from the assessor.

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page xii 
Dependence on Another Service Provider’s Compliance  
Generally, when reporting on a requirement where a third- party service provider is responsible for the task (s), the response is minimally 
captured at each requirement in the “Describe why the assessment finding was sel ected” section and the corresponding evidence is identified 
in the evidence section of the requirement. An acceptable response for an I n Place finding for 1.1.1.a would be documented at the 
requirement and may be something like:  
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

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 f or 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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page xiii 
Assessment Approach Reporting Options  
There are two main reporting options for the assessment approach for  PCI DSS.  It is possible for different aspects of a requirement to meet 
any 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 validated by using a compensating control, while system component Y may be validated by using the defined 
approach, and system component Z may be validated by using the customized approach. Therefore, it is important to document the aspects of 
the requirement where Compensating Controls and the Customized Approach are used.  
Approach  When to Use This Approach  Using Figure 2  
Customized Approach  Focuses on the Customized Approach Objective  of each

Customized Approach  Focuses on the Customized Approach Objective  of each 
PCI DSS Requirement  (if applicable) , allowing entities to 
implement controls to meet the requirement’s stated 
Customized Approach Objective in a way that does not strictly follow the defined requirement.  The customized 
approach supports innovation in security practices, allowing 
entities greater flexibility to show how their current security 
controls meet PCI DSS requirements.  
Refer to the Payment Card Industry Data Security Standard 
(PCI DSS) Requirements and Testing Procedures  for the

(PCI DSS) Requirements and Testing Procedures  for the 
Customized Approach Objective. 
Note:  Compensating Controls are not an option for the 
Customized Approach  For “Validation Method – Customized Approach”  
• If the Customized Approach is not used, select “No” for 
Customized Approach acknowledgement check box, and mark 
the relevant reporting instruction as Not Applicable . 
• If the Customized Approach is used, complete the following:  
o Select “Yes”  for Customized Approach acknowledgement 
check box .

check box . 
o Identify the aspects of the requirement where the Customized Approach was used. 
o Complete the Customized Approach Template in Appendix E  (not pictured) . 
Defined Approach  The traditional method for implementing and validating PCI 
DSS and uses the Requirements and Testing Procedures defined within the standard. The entity implements security 
controls to meet the stated requirements, and the assessor 
follows the defined testing procedures to verify that the requirement  has been met.  
Note on using Compensating Control(s) : As part of the

Note on using Compensating Control(s) : As part of the 
defined approach, entities that cannot meet a PCI DSS requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other or compensating controls that sufficiently 
mitigate the risk associated with the requirement. On an 
annual basis, any compensating controls must be documented by the entity and reviewed and validated by the assessor and included with the Report on Compliance 
submissio n. For “Validation Method – Defined Approach”

submissio n. For “Validation Method – Defined Approach”  
• If Compensating Controls are not used, select “No” for 
Compensating Control acknowledgement check box, and mark 
the relevant reporting instruction as Not Applicable. 
• If Compensating Control(s) are used, complet e the following:  
o Select “Yes” for Compensating Control 
acknowledgement check box . 
o Identify the aspects of the requirement where a compensating control(s) is used. 
o Complete the Compensating Controls Worksheet in Appendix C  (not pictured) .

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page xiv 
Figure 2. Assessment Approach Reporting Options  
If “Yes”, Identify  the aspect(s) of the requirement where the Customized Approach 
was used. 
If “Yes”, Identify  the aspect(s) of the requirement where the Compensating Control(s) 
was used. 
1.1.1.a  Example testing procedure  Example reporting instruction  <Enter Response Here>

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page xv 
Understanding the Reporting Instructions  
The reporting instructions in the Reporting Template explain the intent of the response required.  Responses should be specific and relevant to 
the assessed entity. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage and s hould avoid 
generic templated language.  
Assessor responses generally fall into categor ies, 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:  
☐ Yes   ☐ No 
Note : The applicability of some reporting instructions may be dependent on the 
response of a previous reporting instruction. If applicable, the reporting instruction

Reporting 
☐ Yes   ☐ No 
response of a previous reporting instruction. If applicable, the reporting instruction 
will direct the assessor to a subsequent instruction based on the yes/no answer.  
Identify  Identify  the evidence reference number(s) from 
Section 6 for all documentation examined for this 
testing procedure.  The response would include the relevant item(s) requested.  
Example Reporting Instruction: “ Identify  the evidence reference number(s) from 
Section 6 for all documentation examined for this testing procedure. ” 
Example Response: Doc -01  
OR 
Doc-01 (Company  XYZ Information Sec urity Policy )

OR 
Doc-01 (Company  XYZ Information Sec urity Policy ) 
Note:  When a reference number is available, it is required; however, the 
assessor also has the option to list individual items in addition to the reference number.  
Describe  Describe why the assessment finding was 
selected.  The response would include a detailed description of the item or activity in 
question — for example, details of how the evidence examined or individuals 
interviewed demonstrate a requirement was met, or how the assessor concluded 
a control implemented is fit -for-purpose. The response should be of sufficient

a control implemented is fit -for-purpose. The response should be of sufficient 
detail to provide the reader with a comprehensive understanding of the item or 
activity being described.  
Attest  Identify the name of the QSA who attests.  The assessor’s name is simply provided in the response. This “signature” adds 
more weight than a simple “yes” or “checkmark” response and is used when no additional reporting is needed.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page xvi 
Dos and Don’ts: Reporting Expectations  
DO: DON’T:  
• Use this Reporting Template when assessing against v4.0 of the PCI 
DSS. 
• 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.  • Don’t select the In Place response without verification that the

evidence.  
• Provide useful, meaningful diagrams as directed.  • Don’t 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)  
• Don’t copy responses from one Testing Procedure to another.  
• Don’t copy responses from previous assessments.  
• Don’t include information irrelevant to the assessment.  
• Don’t leave any spaces blank. If a section does not apply, annotate it as such.  
PCI DSS v4.0 Report on Compliance Template

PCI DSS v4.0 Report on Compliance Template 
Complete the following ROC Template per these  instructions. The following title page can be populated according to the assessor company’s 
corporate document guidelines (for example, company name, logo, date, version, etc.). All instructional content (this page and pages up to the 
table of contents) may be deleted by the assessor prior to finalizing the report.

PCI DSS v4.0 ROC Template r1  December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 1 
PCI DSS v4.0 Report on Compliance  
Entity Name:     
Date of Report:     
Assessment End Date:

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 2 
Part I  Assessment Overview 
1 Contact Information and Summary of Results  
1.1 Contact Information 
Assessed Entity  
Company name:  <Enter Response Here>  
DBA (doing business as):  <Enter Response Here>  
Mailing address:  <Enter Response Here>  
Company main website:  <Enter Response Here>  
Contact name:  <Enter Response Here>  
Contact title:  <Enter Response Here>  
Contact phone number:  <Enter Response Here>  
Contact e -mail address:  <Enter Response Here>  
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)  
ISA name:  <Enter Response Here>  
Qualified Security Assessor Company  
Company website:  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 3 
Lead Qualified Security Assessor  
Lead Assessor name:  <Enter Response Here>  
Assessor phone number:  <Enter Response Here>  
Assessor e -mail address:  <Enter Response Here>  
Assessor PCI credentials and 
certificate number:  
(QSA, Secure Software Assessor, 
etc.) <Enter Response Here>  
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:  
<Enter Response Here>  <Enter Response Here>  
Identify all other assessors involved in the assessment. If there were none, mark as Not Applicable. ( Add rows as needed)  
Assessor name:  Assessor PCI credentials: (QSA, Secure Software  Assessor, etc.)  
<Enter Response Here>  <Enter Response Here>

Assessor Quality Assurance (QA) Primary Reviewer for this specific report (not the general QA contact for the QSA Company)  
QA reviewer name:  <Enter Response Here>  
QA reviewer phone number:  <Enter Response Here>  
QA reviewer e -mail address:  <Enter Response Here>  
QA Reviewer’s PCI Credentials:  
(See the current QSA Qualification 
Requirements for acceptable 
credentials)  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 4 
1.2 Date and Timeframe of Assessment  
Date of Report:  
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.  <Enter Response Here>  
Date assessment began:  
Note:  This is the first date that evidence was 
gathered, or observations were made.  <Enter Response Here>  
Date assessment ended:  
Note:  This is the last date that evidence was 
Identify the date(s) spent onsite at the assessed 
entity.  <Enter Response Here>  
1.3 Remote Assessment Activities  
 Overview of Remote Testing Activity  
To what extent were remote testing methods used for this 
assessment?  ☐ All testing was performed onsite  
☐ A combination of onsite and remote testing methods was used

☐ 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.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 5 
 Summary of Testing Performed Remotely  
Type of T esting  
Activity  Were remote testing  
methods used to perform  
this testing activity during  
the assessment?  For all testing activities performed using remote methods:  
Describe the methods used to perform 
the remote testing.  Describe any alternative and any  additional 
testing activities that  were performed to confirm  
assurance in the tes t result.  
Examine documentation  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
Interview personnel  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
Examine/observe live data  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
Observe process being 
performed  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
Observe physical environment  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>

Observe physical environment  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
Interactive testing  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
 Assessor Assurance in Assessment Result  
If remote testing methods were used for the assessment, identify whether the assessor was able to:  
Complete a thorough assessment using appropriate remote testing activities as described in QSA Program Guide?  ☐  Yes ☐  No 
Achieve a high degree of confidence that the assessment resulted in a complete evaluation of the entity’s in -scope 
environment for all applicable requirements?  ☐  Yes  ☐  No

Assessor Assurance in Assessment Result  
environment for all applicable requirements?  ☐  Yes  ☐  No 
Achieve a high degree of confidence in the accuracy and integrity of the evidence observed and reviewed?  ☐  Yes ☐  No 
Achieve a level of confidence in the remote testing results that is commensurate to the level of confidence that would have 
been achieved via onsite testing?  ☐  Yes  ☐  No 
Achieve a high degree of assurance in the overall assessment result?  ☐  Yes  ☐  No

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 6 
 Requirements That Could Not be Fully Verified 
Were any requirements unable to be fully tested, or was the assessor otherwise unable to reach a finding for any 
requirement due to an inability to perform onsite testing?  
 
If yes, complete the following table.  ☐  Yes  ☐  No 
 
Requirement number  Was an y testing able to be 
completed for this 
requirement?  Describe what (if any) aspects of 
the requirement could be verified Describe what aspects of the 
requirement could not be verified  
<Enter Response Here>  ☐  Yes  ☐  No <Enter Response Here>  <Enter Response Here>  
<Enter Response Here>  ☐  Yes ☐  No <Enter Response Here>  <Enter Response Here>  
1.4 Additional Services Provided by QSA Company

1.4 Additional Services Provided by QSA Company  
The PCI SSC Qualification Requirements for Qualified Security Assessors (QSA)  includes content on “Independence,” which specifies 
requirements for assessor disclosure of services and/or offerings that could reasonably be viewed to af fect the independence of assessment. 
Complete the section below after review ing the relevant portions of the Qualification Requirements to ensure responses are consistent with 
documented obligations.  
Indicate whether the QSA Company provided any consultation on the

Indicate whether the QSA Company provided any consultation on the 
development or implementation of controls used for the Customized Approach.  
Note : This does not apply to the assessment of the Customized Approach.  ☐ Yes   ☐ No 
 
If “Yes,” describe the nature of the consultation.  <Enter Response Here>  
Disclose all products or services provided to the assessed entity by the QSA 
Company that are not listed above and that were reviewed during this 
assessment or could reasonably be viewed to affect independence of 
assessment.  <Enter Resp onse Here>

assessment.  <Enter Resp onse Here>  
Describe efforts made to ensure no conflict of interest resulted from the above -
mentioned products and services provided by the QSA Company.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 7 
1.5 Use of Subcontractors 
Indicate whether any assessment activities were subcontracted to another 
Assessor Company . 
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 . <Enter Response Here>  
1.6 Additional Information/ Reporting 
Identify the number of consecutive years (including the current year) the QSA 
Company has issued ROCs for this entity.  <Enter Response Here>  
1.7 Overall Assessment Result  
Indicate below whether a full or partial assessment was completed. Select only one.  
☐ Full Assessment : All requirements have been assessed and therefore no requirements were marked as Not Tested.

☐ 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 . 
 
(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.

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 in the ROC are marked as Not in Place due to a legal 
restriction that prevents the requirement from being met and all other assessed requirements are marked as being either  In Place or Not

restriction that prevents the requirement from being met and all other assessed requirements are marked as being either  In Place or Not 
Applicable, resulting in an overall COMPLIANT BUT WITH LEGAL EXCEPTION rating, thereby the assessed entity  has demonstrated 
compliance with all PCI DSS requirements except those noted as Not Tested above or as Not in Place due to a legal restriction.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 8 
1.8 Summary of Assessment  
 Summary of Assessment Findings and Methods  
Indicate all the findings and assessment methods within each PCI DSS principal requirement. Select all that apply.  For example, In Place  and 
Not Applicable  must  both be selected for Requirement 1 if there is at least one sub- requirement marked In Place  and one sub- requirement 
marked Not Applicable . The columns for Compensating Controls and  Customized Approach must be selected if there is at least one sub -
requirement within the principal requirement  that utilizes t he respective method. For example, Compensating Control and Customized 
Approach must both be checked if at least one sub- requirement utilizes Compensating Controls and at least one sub requirement utilizes a 
Customized Approach. If neither Compensating Controls nor Customized Approach are used , then leave both blank.  
PCI DSS

PCI DSS 
Requirement  Asse ssment Finding  
Select all options that apply.  Select I f Below Method(s) W as 
Used  
In Place  Not Applicable  Not Tested  Not in Place  Compensating 
Control  Customized 
Approach  
Requirement 1:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 2:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 3:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 4:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 5:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 6:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 7:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 8:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 9:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 10:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 11:  ☐ ☐ ☐ ☐ ☐ ☐ 
Requirement 12:  ☐ ☐ ☐ ☐ ☐ ☐

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 9 
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 
Approach  
<Enter Response  Here>  
 <Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response 
Here>  <Enter Response 
Here>  
 Optional: Additional Assessor Comments  
This optional field is provided for the assessor to document any

Approach  
Here>  
This optional field is provided for the assessor to document any 
additional information that is relevant to the entity being assessed 
and that may or may not have impacted the findings of this 
assessment.  <Enter Respo nse Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 10 
1.9 Attestation S ignatures  
When a QSA company has performed the assessment, the Lead Assessor thereby confirms the following:  
Attestation of independence  
• This assessment was conducted strictly in accordance with all applicable requirements set forth in the Payment Card Industry Data Security Standard 
Qualification Requirements for Assessors , including but not limited to the requirements therein regarding independence, independent judgment and 
objectivity, disclosure, conflicts of interest, misrepresentations, and instruction of employees;  
• This assessment was conducted in a manner intended to preserve at all times the professional judgment, integrity, impartiality, and professional skepticism 
of the Assessor Company;

of the Assessor Company;  
• This Report on Compliance accurately identifies, describes, represents, and characterizes all factual evidence that the QSA C ompany and its Assessor 
Employees gathered, generated, discovered, reviewed, and/or determined in their sole discretion to be relevant to this assessment in the course of 
performing the assessment; and  
• The judgments, conclusions, and findings contained in this Report on Compliance (a) accurately reflect and are based solely upon the factual evidence

• The judgments, conclusions, and findings contained in this Report on Compliance (a) accurately reflect and are based solely upon the factual evidence 
described immediately above, (b) reflect the independent judgments, findings, and conclusions of the QSA Company and its Assessor Employees only, 
acting in their sole discretion, and (c) were not in any manner influenced, directed,  controlled, modified, provided, or subjected to any prior approval by the 
assessed entity, any contractor, representative, professional advisor, agent or affiliate thereof, or any other person or ent ity other than the QSA Company 
and its Assessor Employee s. 
Attestation of scoping accuracy

Attestation of scoping accuracy  
To the best of my knowledge, the scope of this PCI DSS assessment is complete and accurate and all information pertaining to the scope of this PCI DSS 
Assessment is accurately represented in Section 3, “Description of Scope of Work and Approach Taken,” and Section 4, “Details about Reviewed 
Environment.”  
Attestation of sampling  
To the best of my knowledge, all sample sets used for this PCI DSS Assessment are accurately represented in Section 4.9 , “Sample sets for reporting.”  
Signatures  
Signature of Lead Assessor:  Date: <Enter Response Here>

Signature of Lead Assessor:  Date: <Enter Response Here>  
Lead Assessor Name:  <Enter Response Here>  QSA Company Name:  <Enter Response Here>  
Note:  This section must be printed and signed manually or digitally signed using a PCI SSC -accepted electronic/digital signature.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 11 
2 Business Overview  
2.1 Description of the Entity’s Payment Card Business  
Provide an overview of the entity’s payment card business, including:  
Describe the nature of the entity’s business (what kind of work 
they do, etc.).  
Note : This is not intended to be a cut -and-paste from the entity’s 
website but should be a tailored description that shows the 
assessor understands the business of the entity being assessed.  <Enter Response Here>  
Describe the entit y’s business, services, or functions that store, 
process, or transmit account data or could impact the security of 
account data.  <Enter Response Here>  
Identify any of the entity’s businesses services or functions that 
have been excluded from the scope of this assessment.  <Enter Response Here>  
Identify the card -present payment channels the entity utilizes.  <Enter Response Here>

Identify the card -present payment channels the entity utilizes.  <Enter Response Here>  
Identify the card -not-present payment cha nnels the entity utilizes.  
(For example, mail order/telephone order [ MOTO ], e-commerce)  <Enter Response Here>  
Describe how the entity  stores, processes, and/or transmits 
Describe how any other in -scope services or functions that the 
entity  performs impact the security of account data.   
(For example, if the entity provides managed services)  <Enter Response Here>

(For example, if the entity provides managed services)  <Enter Response Here>  
Indicate whether any payment channels or services that impact 
the security of account data have been excluded from this 
assessment.  ☐ Yes   ☐ No 
If “Yes,” identify any payment channels or services that impact the security of account data that were not included in this assessme nt below . (Add rows as 
necessary)  
<Enter Response Here>  
Other details, if applicable:  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 12 
3 Description of Scope of Work and Approach Taken  
3.1 Assessor’s Validation of Defined Scope Accuracy  
Describe how the assessor validated the accuracy of the defined PCI DSS scope for the assessment:  
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

Describe how the assessor’s evaluation of scope differs from the assessed 
entity’s evaluation of scope as documented in Requirement 12.5. 
If no difference was identified, mark as “Not  Applicable .” <Enter Response Here>  
Provide the name of the assessor who attests that:  
• They have performed an independent evaluation of the scope of the 
assessed entity’s PCI DSS environment.  
• If the assessor’s evaluation identified areas of scope not included in the 
assessed entity’s documented scope, the assessed entity has updated 
their scoping documentation.   
• The scope of the assessment is complete and accurate to the best of the 
assessor’s  knowledge.  <Enter Response Here>

assessor’s  knowledge.  <Enter Response Here>  
Describe any areas of scope that were excluded from the assessment 
including the following:  
• What was excluded.  
• Why was it excluded.  
• If it was included in a separate assessment.  
If none, mark as “Not Applicable.” <Enter Response Here>  
Identify  any factors that resulted in reducing or limiting scope (for example, 
segmentation of the environment, use of a P2PE solution, etc.)  
If none, mark as “Not Applicable.” <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 13 
Describe any use of SAQ eligibility criteria in determining applicability of PCI 
DSS requirements for this assessment , including the following:  
• The type of SAQ applied.  
• The eligibility criteria for the applicable SAQ.  
• How the assessor verified that the assessed entity’s environm ent meets 
the eligibility  criteria.  
If not used mark as “Not Applicable.” <Enter Response Here>  
Additional information, if applicable:  <Enter Response Here>  
3.2 Segmentation 
Indicate whether the assessed entity has used segmentation to reduce the 
scope of the assessment.  
Note:  An environment with no segmentation is considered a “flat” network 
where all systems are considered to be in scope.  ☐ Yes   ☐ No 
• If “No,” provide the name of the assessor who attests that the entire 
network has been included in the scope of the assessment.  <Enter Response Here>

network has been included in the scope of the assessment.  <Enter Response Here>  
• If “Yes,” complete the following:  
– Describe how the segmentation is implemented , including the 
technologies and processes used.  <Enter Response Here>  
– Describe the environments that were confirmed to be out of scope 
as a result of the segmentation methods.  <Enter Response Here>  
– 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

implement segmentation were included in this PCI DSS 
assessment.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 14 
3.3 PCI SSC Validated Products and Solutions  
For purposes of this document, “Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or 
components, appearing on the PCI SSC website (www.pcisecuritystandards.org) ( For example: 3DS Software Development Kits, Approved 
PTS Devices, Validated Payment Software, Payment Applications [PA-DSS], Point to Point E ncryption [ P2PE] solutions, Software- Based PIN 
Entry on COTS [ SPoC ] solutions, and Contactless Payments on COTS [ CPoC ] solutions .) 
Indicate whether the assessed entity uses one or more PCI SSC validated 
products or solutions.  ☐ Yes   ☐ No 
If “Yes,” provide the following information regarding items the organization uses from PCI SSC's Lists of Validated Products and Soluti ons: 
 
Name of PCI SSC 
validated product or 
solution  Version of product or

solution  Version of product or 
solution PCI SSC Standard to 
which product or 
solution  was validated  PCI SSC listing 
reference number  Expiry date of listing  
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>  
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

merchant has implemented the solution per the instructions 
and detail in the instruction manual.  <Enter Response Here>  
Any additional comments or findings the assessor would like 
to include, if applicable.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 15 
3.4 Sampling 
Indicate whether sampling is used.  ☐ Yes   ☐ No 
• If “No,” provide the name of the assessor who attests that every item in 
each population has been assessed.  <Enter Response Here>  
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.).  <Enter Response Here>  
– Describe how the samples are appropriate and representative of 
the overall populations.  <Enter Response Here>  
– Indicat e 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

detection, etc.  ☐ Yes   ☐ No 
o If “Yes,” describe how the processes and controls were validated by 
the assessor to be in place and effective.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 16 
4 Details About Reviewed Environments  
4.1 Network Diagrams  
Provide one or more network diagrams that:  
 Shows all connections between the CDE and other net works, 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.  
 Insert Diagrams

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 17 
4.2 Account Dataflow Diagrams  
Provide one or more dataflow diagrams that:  
 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 stor ed, 
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)

(Include the type of account data) 
<Enter Response Here>  <Enter Response Here>  Insert Diagrams

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 18 
4.3 Storage of Account Data  
Identify all databases, tables , and files storing account data and provide the following details:  
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 
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 19 
 Storage of SAD  
Identify all databases, tables , and files storing Sensitive Account Data (SAD) and provide the following details:  
Note : The list of files and tables that store SAD in the table below must be supported by an inventory created (or obtained from the assessed 
entity) and retained by the assessor in the workpapers.  
Field Names  Is SAD Stored Pre -
authorization?  Is SAD Stored as 
Part of Issuer 
Functions?  How Data Is Secured2 
<Enter Response Here>  <Enter Response Here>  ☐  Yes 
☐  No  ☐  Yes 
☐  No <Enter Response Here>  
☐  No ☐  Yes 
☐  No ☐  Yes 
☐  No ☐  Yes

☐  No  ☐  Yes 
☐  No ☐  Yes 
☐  No ☐  Yes 
☐  No ☐  Yes 
2 For example, what type of encryption and strength, and so on.  
4.4 In-scope Third -Party Service Providers (TPSPs)  
Third -party service providers include, but are not limited to, third parties that:  
 Store, process, or transmit account data on the entity’s behalf (for example, payment gateways, payment processors, payment s ervice 
providers [ PSPs ])

☐  No ☐  Yes 
providers [ PSPs ]) 
 Manage system components included in the entity’s PCI DSS assessment (for example, via network security control services, ant i-
malware services, security incident and event management [SIEM ], web- hosting companies, IaaS, PaaS, SaaS, FaaS, etc.)  
 Could impact the security of the entity’s account data (for example, vendors providing support via remote access, and/or  bespoke 
software developers).  
These entities are subject to PCI DSS Requirement 12.8.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 20 
For each service provider or third party, provide:  
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 
<Enter Response 
Here>  <Enter Response Here>  <Enter Response Here>  
☐ ☐ <Enter 
Response 
Here>  <Enter 
Response Here>  ☐ ☐ 
☐ ☐ <Enter 
Response 
☐ ☐ <Enter 
Response Here>  <Enter

services 
☐ ☐ <Enter 
Response 
☐ ☐ <Enter 
Response 
☐ ☐ <Enter 
Response Here>  <Enter 
☐ ☐ <Enter 
☐ ☐ <Enter 
Response 
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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 21 
4.5 In-scope Networks  
Identify all in -scope networks including the type of network (for example, wired, Wi -Fi, cloud, etc.) . 
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  
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  
 
Describe all networks that do not store, process, and/or transmit Account Data but are still in scope —for example, connected to the CDE or 
provide management functions to the CDE, etc.:  
(In Scope)  Type of Network  Function/Purpose of Network  
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>

4.6 In-scope Locations/Facilities  
Identify and provide details for all types of physical locations/facilities (for example, retail locations, corporate offices, data centers, call centers 
and mail rooms) in scope. Add rows, as needed.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 22 
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 Ang eles,  California,  United States  
Example  2: retail locations  132 92 locations in the United States and 40 in Canada  
4.7 In-scope Business Functions  
Identify and provide details for all business and operational functions in scope. Functions could include telephone transaction handling, mail 
transaction handling, change control, development, system build and hardening, etc. Add rows as needed.

transaction handling, change control, development, system build and hardening, etc. Add rows as needed.  
Function Name  Function Description  
4.8 In-scope System Component Types  
Identify all types of system components in scope.  
“System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples 
of system components include, but are not limited to:

of system components include, but are not limited to:  
 Systems that store, process, or transmit account data (for example, payment terminals, authorization systems, clearing systems, 
payment middleware systems, payment back -office systems, shopping cart and store front systems, payment gateway/switch systems, 
fraud monitoring systems).

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 23 
 Systems that provide security services (for example, authentication servers, access control servers, security information and  event 
management (SIEM) systems, physical security systems (for example, badge access or CCTV), multi -factor authentication systems, 
anti-malware systems).  
 Systems that facilitate segmentation (for example, internal network security controls).  
 Systems that could impact the security of account data or  the CDE (for example, name resolution, or e- commerce [ web] redirection 
servers).  
 Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and 
hypervisors.  
 Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private

servers).  
 Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private 
clouds, cloud- based identity and access management, CDEs residing on premises or in the cloud, service meshes with containerized 
applications, and  container orchestration tools.  
 Network components, including but not limited to network security controls, switches, routers, VoIP network devices, wireless  access 
 Server types, including but not  limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and 
Domain Name System (DNS).

Domain Name System (DNS).  
 End-user devices, such as computers, laptops, workstations, administrative workstations, tablets, and mobile devices.  
 Printers, and multi -function devices that scan, print, and fax.  
 Storage of account data in any format (for example, paper, data files, audio files, images, and video recordings).  
 Applications, software, and software components, serverless applications, including all purchased, subscribed (for example, Software-as-a-Service), bespoke and custom software, including internal and external (for example, Internet) applications.

 Applications, software, and software components, serverless applications, including all purchased, subscribed (for example, Software-as-a-Service), bespoke and custom software, including internal and external (for example, Internet) applications.  
 Tools, code repositories, and systems that implement software configuration management or for deployment of objects to the CDE or to systems that can impact the CDE.  
For each item, even if they reside with other system components, list them below with each component with different roles, ve ndors , 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

Version  Role/Function Description 

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 24 
1 For example, application, firewall, server, IDS, Anti -malware software, database, and so on.  
2 How many system components of this type are in scope.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 25 
4.9 Sample Sets for Reporting 
Identify all sample sets used during testing.  
When sampling is used the assessor must identify the items in the population that were tested (for example, as “Sample Set -1”) as part of the 
sample in the table below and include all of the sub- requirements where that sample set was used. All unique sample sets must be 
documented in this table.  
Note : For items where the total population fluctuates or is difficult to determine, the assessor may work with the assessed entity to provide an 
estimated total population in the total population column below.  
Tested Sample 
Set 
Reference 
Number  Identify All 
Sub-
Where the 
Sample Set is 
Used  Sample Type/ 
Description1 Identify  All Items in the 
Sample Set2 Selection Method3 Total 
Sampled  Total 
Population  
Here>  <Enter Response

Set 
Reference 
Sub-
Where the 
Here>  <Enter Response Here>  <Enter Response 
Response 
Response Here>  
Here>  <Enter Response  Here>  <Enter Response 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 26 
5 Quarterly Scan Results 
5.1 Quarterly External Scan Results  
Identify each quarterly ASV scan performed within the last 12 months in the table below.  
It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:  
 The most recent scan result was a passing scan,  
 The entity has documented policies and procedures requiring quarterly scanning going forward, and  
 Any vulnerabilities noted in the initial scan have been corrected as shown in a re- scan.  
For subsequent years after the initial PCI DSS assessment , four passing quarterly scans must have occurred.  
Date of the Scan(s)  Name of ASV that 
Performed the Scan  Were any vulnerabilities 
found that resulted in a 
failed initial scan?  For all scans resulting in a Fail, provide date(s) of re -
scans showing that the vulnerabilities have been

scans showing that the vulnerabilities have been 
corrected  
Yes No 
<Enter Response Here>  <Enter Response Here>  ☐ ☐ <Enter Response Here>  
Indicate whether this is the assessed entity’s initial PCI DSS compliance validation . ☐ Yes   ☐ No 
If yes, Identify the name of the document the assessor verified to include the entity’s

corrected  
Yes No 
If yes, Identify the name of the document the assessor verified to include the entity’s 
documented policies and procedures requiring quarterly scanning going forward.  <Enter Response Here>  
Assessor comments, if applicable:  <Enter Response Here>  
5.2 Attestations of Scan Compliance  
The s cans must cover all externally accessible (Internet -facing) IP addresses in existence at the entity, in accordance with the PCI DSS 
Approved Scanning Vendors (ASV) Program Guide.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 27 
Indicate whether the ASV and the 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?  ☐ Yes   ☐ No 
5.3 Quarterly Internal Scan Results  
In the table below identify each quarterly internal vulnerability scan performed within the last 12 months.  It is not required that quarterly scans 
are completed for initial PCI DSS compliance if the assessor verified that:  
For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.  
Date of the S can(s)  Was the scan 
performed via 
authenticated

authenticated 
scanning?  Were any high -risk or 
critical vulnerabilities per 
the entity’s vulnerability 
risk rankings at 
Requirement 6.3.1 found? For all scans where high -risk or critical vulnerabilities 
were found, provide date(s) of re -scans showing that the 
vulnerabilities have been corrected.  
Yes No Yes No 
<Enter Response Here>  ☐ ☐ ☐ ☐ <Enter Response Here>  
<Enter Response Here>  ☐ ☐ ☐ ☐ <Enter Response Here>

Indicate if this is the assessed entity’s initial PCI DSS compliance validation  ☐ Yes   ☐ No 
Assessor comments, if applicable:  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 28 
6 Evidence (Assessment Workpapers) 
6.1 Evidence Retention  
Describe the repositories where the evidence collected during this assessment 
is store d including the names of the repositor ies and how the data is secured.  <Enter Response Here>  
Identify the entity  or entities  who controls the evidence repositories . <Enter Response Here>  
Indicate whether the entity or enti ties in control of the evidence repositories  
understands that all evidence from this assessment must be maintained for a 
minimum of 3 years and must be made available to PCI SSC upon request.  ☐ Yes   ☐ No 
6.2 Documentation Evidence  
Identify all evidence for any testing procedure requiring a review of documents such as policies, procedures, standards, records, inventories, 
vendor documentation, and diagrams. Include the following:  (Add rows as needed)  
Reference Number  Document Name

Reference Number  Document Name  
(including version, if applicable)  Brief Description of Document 
Purpose  Document Revision Date  
(if applicable)  
EXAMPLE: Doc -1 Company XPY Information Security 
Policy  Information Security Policy  2021 -02-18 
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>  
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Response Here>

6.3 Interview Evidence  
Identify all evidence for testing procedures requiring an interview, such as interview notes. Include the following:  (Add rows as needed)

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 29 
Reference Number  Title of Workpaper with Interview 
Notes  Brief Description of the Topics 
Covered  Role(s) of Interviewee(s)  
EXAMPLE: Int -01 Assessor notes from interview with 
Information Security  Manager  Information security processes 
including security vulnerability risk 
ranking, anti -malware configurations, 
and cryptographic key management.  Information Security Manager  
6.4 Observation Evidence

6.4 Observation Evidence  
Identify all evidence for testing procedures requiring an observation, such as observation notes for observed processes. Incl ude the following:  
(Add rows as needed)  
Reference Number  Title of Workpaper with 
Observation Notes  Observed Process  Brief Description of the 
Process  
EXAMPLE: Proc -1 Assessor notes from observation of 
visitor badge processes  Visitor Badge Process  Process for allocating and 
collecting/expiring visitor badges

Process  
collecting/expiring visitor badges  
<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Respons e Here>

<Enter Response Here>  <Enter Response Here>  <Enter Response Here>  <Enter Respons e Here>  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 30 
6.5 System Evidence  
Identify all evidence for testing procedures requiring a review of a system component s such as configurations, settings, access control lists, 
user accounts, or audit logs. Include the following:  (Add rows as needed)  
Reference Number  System Components Reviewed  
(Uniquely identify system components or 
reference a sample set)  Brief Description of the Evidence  
EXAMPLE: Conf -1 System1, system2, Sample Set -1 Group Policy settings for Windows servers  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 31 
Part II  Findings and Observations  
Build and Maintain a Secure Network and Systems 
1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.  
1.1.1  All security policies and operational procedures that are identified in Requirement 1 are:  
• Documented.  
• Kept up to date.  
• In use.  
• Known to all affected parties.  
In Place  Not Applicable  Not Tested  Not in Place  
☐ ☐ ☐ ☐ 
Note : Include all details as noted in the “Required Reporting” column of the 
table in Assessment Findings  in the ROC Template Instructions.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 32 
Indicate whether  a Customized Approach was used:  ☐ Yes    ☐ No 
If “Yes”, Identify  the aspect(s) of the requirement where the Customized 
Approach was used.  
Note:  The use of Customized Approach must also be documented in 
Appendix E . <Enter Response Here>  
Indicate whether a Compensating Control was used:  ☐ Yes    ☐ No 
If “Yes”, Identify  the aspect(s) of the requirement where the Compensating 
Control(s) was used. 
Note:  The use of Compensating Controls must also be documented in 
Appendix C . <Enter Response Here>  
1.1.1  Examine documentation 
and interview personnel to verify 
that security policies and 
operational procedures identified 
in Requirement 1 are managed in 
accordance with all elements

accordance with all elements 
specified in this requirement.  Identify the evidence reference 
number(s) from  Section 6  for all 
documentation  examined for this testing 
procedure.  <Enter Response Here>  
Identify the evidence reference 
number(s) from Section 6  for all 
interview(s)  conducted for this testing 
procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 33 
1.1.2 Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 
table in Assessment Findings  in the ROC Template Instruct ions.  <Enter Response Here>  
Indicate whether a Customized Approach was used :  ☐ Yes    ☐ No 
Approach was used. 
Indicate whether a Compensating Control was used :  ☐ Yes    ☐ No

Indicate whether a Compensating Control was used :  ☐ Yes    ☐ No 
Appendix C . <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 34 
1.1.2.a Examine documentation 
to verify that descriptions of roles 
and responsibilities for 
performing activities in 
Requirement 1 are documented 
and assigned.  Identify the evidence reference 
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.  Identify the evidence reference 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 35 
• Defined.  
• Implemented.  
• Maintained.  
(Select one) 
☐ ☐ ☐ ☐ 
was used. 

was used. 
Note:  The use of Compensating Controls must also be documented in Appendix C . <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 36 
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.  Identify the evidence reference number(s) 
from Section 6  for all configuration 
standards examined for this testing 
1.2.1.b  Examine configuration settings 
for NSC rulesets to verify that rulesets 
are implemented according to the 
configuration standards.  Identify the evidence reference number(s) 
settings  examined for this testing 
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

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 37 
was used. 
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

the formal change control process in 
accordance with Requirement 6.5.1.  Identify the evidence reference number(s) 
from Section 6  for all documented 
procedures  examined for this testing 
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 
from Section 6  for all network

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 38 
1.2.2.c Examine network configuration 
settings to identify changes made to 
configurations of NSCs. Interview 
responsible personnel and examine 
change control records to verify that 
identified changes to configurations of 
NSCs were approved and managed in 
accordance with Requirement 6.5.1.  Identify the evidence reference num ber(s) 
from Section 6  for all network 
records  examined for this testing 
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 wir eless networks.  
☐ ☐ ☐ ☐ 
table in Assessment Findings  in the ROC Template Instructions.  <Enter Response Here>  
Indicate whether a Customized Approach was used :  ☐ Yes    ☐ No

☐ ☐ ☐ ☐ 
was used. 
Note:  The use of Customized Approach must also be documented in Appendix E . <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 39 
1.2.3.a Examine diagram(s) and 
network configurations to verify that 
an accurate network diagram(s) exists 
in accordance with all elements 
specified in this requirement.  Identify the evidence reference number(s) 
from Section 6  for all diagrams  examined 
for this testing procedure.  <Enter Response Here>  
configurations  examined for this testing 

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.  Identify the evidence reference number(s) 
from Section 6  for all documentation  
examined for this testing procedure.  <Enter Response Here>  

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 40 
was used. 

was used. 
1.2.4.a Examine data -flow diagram(s) 
and interview personnel to verify the 
diagram(s) show all account data 
flows in accordance with all elements 
from Section 6  for all data-flow 
diagram(s)  examined for this testing 
from Section 6  for all interview(s)

1.2.4.b Examine documentation and 
verify that the data -flow diagram(s) is 

conducted for this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 41 
1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 42 
was used. 
1.2.5.a Examine documentation to 
verify that a list exists of all allowed 
services, protocols, and ports, 
including business justification and

including business justification and 
approval for each.  Identify the evidence reference number(s) 
1.2.5.b Examine configuration settings 
for NSCs to verify that only approved 
services, protocols, and ports are in 
use. Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 43 
1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be ins ecure, such that the risk is 
mitigated.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 44 
1.2.6.a Examine documentation that 
identifies all insecure services, 
protocols, and ports in use to verify 
that for each, security features are 
defined to mitigate the risk.  Identify the evidence reference number(s) 
1.2.6.b Examine configuration settings 
for NSCs to verify that the defined 
security features are implemented for 
each identified insecure service, 
protocol, and port.  Identify the evidence reference number(s) 
1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.  
☐ ☐ ☐ ☐ 
table in Assessment Findings  in the ROC Template Instruct ions.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 45 
was used. 
1.2.7.a Examine documentation to 
verify procedures are defined for 
reviewing configurations of NSCs at 
least once every six months.  Identify the evidence reference number(s)

least once every six months.  Identify the evidence reference number(s) 
from Section 6  for all documentatio n 
1.2.7.b  Examine documentation of 
reviews of configurations for NSCs 
and interview responsible personnel 
to verify that reviews occur at least 
once every six months.  Identify the evidence reference number(s) 

1.2.7.c  Examine configurations for 
NSCs to verify that configurations 
identified as no longer being 
supported by a business justification 
are removed or updated.  Identify the evidence reference number(s) 
from Section 6  for all configurations  
examined for this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 46 
1.2.8 Configuration files for NSCs are:  
• Secured from unauthorized access.  
• Kept consistent with active network configurations.   
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 47 
1.2.8 Examine configuration files for 
NSCs to verify they are in accordance 
with all elements specified in this 
from Section 6  for all configuration files  
 
1.3.1 Inbound traffic to the CDE is restricted as follows:  
• To only traffic that is necessary.  
• All other traffic is specifically denied.  
☐ ☐ ☐ ☐ 
Note : Include all details as noted in the “Required Reporting” column of the

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 48 
was used. 
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 
from Section 6  for all configuration

1.3.1.b  Examine configurations of 
NSCs to verify that inbound traffic to 
the CDE is restricted in accordance 
from Section  6 for all configurations  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 49 
1.3.2 Outbound traffic from the CDE is restricted as follows:  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 50 
1.3.2.a Examine configuration 
define restricting outbound traffic from 
the CDE in accordance with all 
1.3.2.b Examine configurations of 
NSCs to verify that outbound traffic 
from the CDE is restricted in 

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.  
☐ ☐ ☐ ☐ 
Describe why the assessment finding was selected.

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 51 
was used. 
1.3.3 Examine configuration settings 
and network diagrams to verify that 
NSCs are implemented between all 
wireless networks and the CDE, in 

from Section 6  for all network diagrams  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 52 
 
1.4.1 NSCs are implemented between trusted and untrusted networks.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 53 
1.4.1.a Examine configuration 
standards and network diagrams to 
verify that NSCs are defined between 
trusted and untrusted networks.  Identify the evidence reference 
configuration st andards examined 
network diagrams  examined for 
this testing procedure.  <Enter Response Here>  
1.4.1.b Examine network 
configurations to verify that NSCs are 
in place between trusted and 
untrusted networks, in accordance 
with the documented configuration 
standards and network diagrams.  Identify the evidence reference 
network configurations  exami ned 
for this testing procedure.  <Enter Response Here>

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 54 

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 
requirement.  Identify the evidence reference 
vendor documentation  examined 
Identify the evidence reference

configurations  examined for this 
testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 55 
1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 56 
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.  Identify the evidence reference 
vendor documentation examined 
1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 57 
Validation Method – Defined Ap proach  
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

are not directly accessible from the 
untrusted networks.  Identify the evidence reference 
data-flow diagram  examined for 
network diagram  examined for this 
1.4.4.b Examine configurations of 
NSCs to verify that controls are 
implemented such that system 
are not directly accessible from 
untrusted networks.  Identify the evidence reference

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 58 
1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 59 
1.4.5.a  Examine configurations of 
NSCs to verify that the disclosure of 
internal IP addresses and routing 
information is limited to only 
authorized parties.  Identify the evidence reference 
number(s) from Section 6 for all 
1.4.5.b Interview personnel and 
examine documentation to verify that 
controls are implemented such that 
any disclosure of internal IP 
addresses and routing information is 
limited to only authorized parties.  Identify the evidence reference 
interview(s)  conduct ed for this 
documentation  examined for this

documentation  examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 60 
1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.  
1.5.1 Security controls are implemented on any computing devices, including company - and employee -owned devices, that connect to both untrusted networks 
(including the Internet) and the CDE as follows:  
• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.  
• Security controls are actively running.  
• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by manage ment on a case-by -case 
basis for a limited period.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 61 
1.5.1.a Examine policies and 
configuration standards and interview 
personnel to verify security controls 
for computing devices that connect to 
both untrusted networks, and the 
CDE, are implemented in accordance 
from Section 6  for all policies examined 

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 
acco rdance with all elements 
specified in this requirement.  Identify the evidence reference number(s)

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 62 
Requirement 2: Apply Secure Configurations to All System Components  
2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.  
2.1.1  All security policies and operational procedures that are identified in Requirement 2 are:  
• In use.  
☐ ☐ ☐ ☐ 

• In use.  
☐ ☐ ☐ ☐ 
was used. 
Indicate whether  a Compensating Control was used :  ☐ Yes    ☐ No

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 63 
2.1.1 Examine documentation and 
interview personnel to verify that 
security policies and operational 
procedures identified in Requirement 
2 are managed in accordance with all 

2.1.2 Roles and r esponsibilities for performing activities in Requirement 2 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 
Validation Method – Customized Approach

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 64 
was used. 
2.1.2.a Examine documentation to 
verify that descriptions of roles and 
responsibilities for performing 
documented and assigned.  Identify the evidence reference number(s) 
from Section 6  for all documentation

2.1.2.b Interview personnel with 
responsibility for performing activities 
in Requirement 2 to verify that roles 
and responsibilities are assigned as 
documented and are understood.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 65 
2.2 System components are configured and managed securely.  
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 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 66 
2.2.1.a Examine system configuration 
standards to verify they define 
processes that include all elements 
from Section 6  for all system 
configuration standards  examined for 
2.2.1.b  Examine policies and 
procedures and interview personnel to 
verify that system configuration 
standards are updated as new 
vulnerability issues are identified, as

vulnerability issues are identified, as 
defined in Requirement 6.3.1.  Identify the evidence reference number(s) 
from Section 6  for all policies and 
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

configured and verified as being in 
place before or immediately after a 
system component is connected to a 
production env ironment.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 67 
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.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 68 
2.2.2.a Examine system configuration 
standards to verify they include 
managing vendor default accounts in 
accordance with all elements specified 
in this requirement.  Identify the evidence reference number(s) 
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.  Identify the evidence reference number(s) 
from Section 6  for all vendor 
from Section 6  for all observations(s)

from Section 6  for all observations(s)  
2.2.2.c Examine configuration files 
all vendor default accounts that will 
not be used are removed or disabled.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 69 
2.2.3 Primary functions requiring different security levels are managed as follows:  
• Only one primary function exists on a system component,  
OR 
• Primary functions with differing security levels that exist on the same system component are isolated from each other,  
OR 
• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security 
need.   
☐ ☐ ☐ ☐ 

need.   
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 70 
2.2.3.a Examine system configuration 
managing primary functions requiring 
different security levels as specified in 
this requirement.  Identify the evidence reference number(s) 
configuration standards examined for 
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.  Identify the evidence reference number(s) 
2.2.3.c Where virtualization 
technologies are used, examine the 
system configurations to verify that 
system functions requiring different

system functions requiring different 
security levels are managed in one of 
the following ways:  
• Functions with differing security 
needs do not co- exist on the 
same  system component.  
needs that exist on the same 
system component are isolated 
from each other.  
needs on the same system 
component are all secured to the 
level required by the function with 
the highest security need.  Identify the evidence reference number(s) 
configurations  examined for this testing

procedure.  <Enter Response H ere>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 71 
2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disab led.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 72 
2.2.4.a Examine system configuration 
standards to verify necessary system 
services, protocols, and daemons are 
identified and documented.  Identify the evidence reference number(s) 
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.  Identify the evidence reference number(s) 
2.2.5 If any insecure services, protocols, or daemons are present:

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 73 
was used. 
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

verify they are managed and 
2.2.5.b If any insecure services, 
protocols, or daemons, are present, 
examine configuration settings to 
verify that additional security features

verify that additional security features 
are implemented to reduce the risk of 
using insecure services, daemons, 
and protocols.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 74 
2.2.6 System security parameters are configured to prevent misuse.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 75 
2.2.6.a Examine system configuration 
configuring system security 
parameters to prevent misuse.  Identify the evidence reference number(s) 
2.2.6.b  Interview system 
administrators and/or security 
managers to verify they have 
knowledge of common security 
parameter settings for system 
components.  Identify the evidence reference number(s) 
2.2.6.c Examine system 
configurations to verify that common 
security parameters are set 
appropriately and in accordance with

appropriately and in accordance with 
the system configuration standards.  Identify the evidence reference number(s) 
configurations examined for this testing 
procedure.  <Enter Respon se Here>  
2.2.7 All non -console administrative access is encrypted using strong cryptography.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 76 
was used. 
2.2.7.a Examine system configuration 
encrypting all non- console 
administrative access using strong

administrative access using strong 
cryptography.  Identify the evidence reference number(s) 
2.2.7.b Observe an administrator log 
on to system components and 
examine system configurations to 
verify that non-console administrative 
access is managed in accordance 
with this requirement.  Identify the evidence reference number(s) 
from Section 6  for all observation(s) of 
administrator log on(s)  for this testing

administrator log on(s)  for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 77 
2.2.7.c Examine settings for system 
components and authentication 
services to verify that insecure remote 
login services are not available for 
non-console administrative access.  Identify the evidence reference number(s) 
from Section 6  for all settings for  system 
services examined for this testing 
2.2.7.d Examine vendor 
documentation and interview 
personnel to verify that strong 
cryptography for the technology in use 
is implemented according to industry 
best practices and/or vendor 
recommendations.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 78 
2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at inst allation or are confirmed to 
be secure, including but not limited to:  
• Default wireless encryption keys.  
• Passwords on wireless access points.  
• SNMP defaults.  
• Any other security -related wireless vendor defaults.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 79 
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 
procedures  examined f or this testing 
Identify the evidence reference number(s)

2.3.1.b  Examine vendor 
administrator logging into wireless 
devices to verify:  
o SNMP defaults are not used.  
o Default 
passwords/passphrases on 
wireless access points are 
not used.  Identify the evidence reference number(s) 

o Default 
from Section 6  for the observation(s) of 
administrator log in(s)  for this testing 
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

from Section 6  for all wireless 
configuration settings examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 80 
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.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 
Note:  The use of Compensating Controls must also be documented in Appendix C . <Enter Response  Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 81 
2.3.2 Interview responsible personnel 
and examine key -management 
documentation to verify that wireless 
encryption keys are changed in 
conducted for this testing procedure.  <Enter Respon se Here>  
from Section 6  for all key-management 
documentation examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 82 
Protect Account Data  
Requirement 3: Protect Stored Account Data  
3.1 Processes and mechanisms for protecting stored account data are defined and understood.  
3.1.1 All security policies and operational procedures that are identified in Requirement 3 are:  
• In use.  
☐ ☐ ☐ ☐ 

• In use.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 83 
3.1.1 Examine documentation and 
3 are managed in accordance with all 

3.1.2 Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 84 
was used. 
Indicate whether  a Compensating Control was used :  ☐ Yes    ☐ No 
3.1.2.a Examine documentation to 
responsibilities performing activities in 
Requirement 3 are documented and

Requirement 3 are documented and 
assigned.  Identify the evidence reference number(s) 
3.1.2.b Interview personnel with 
in Requirement 3 to verify that roles 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 85 
3.2 Storage of account data is kept to a minimum.  
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 d ocumented business justification.

• Specific retention requirements for stored account data that defines length of retention period and includes a d ocumented business justification.  
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.  
• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or 
rendered unrecoverable.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 86 
3.2.1.a Examine the data retention 
processes and interview personnel to 
verify processes are defined to 
include all elements specified in this 
from Section 6  for all data retention and 
disposal policies, procedures, an d 
processes examined for this testing 

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 
3.2.1.c  Observe the mechanisms 
used to render account data

used to render account data 
unrecoverable to verify data cannot be 
recovered.  Identify the evidence reference number(s) 
from Section 6  for the ob servation(s) of 
the mechanisms used  for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 87 
3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the  
authorization process.  
☐ ☐ ☐ ☐ 
This requirement is not eligible for the customized approach.  

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 88 
3.3.1.a If SAD is received, examine 
documented policies, procedures, and 
system configurations to verify the 
data is not retained after authorization.  Identify the evidence reference number(s) 
policies and pr ocedures  examined for 
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) 
procedures  examined for this testing

the secure data deletion processes for 
this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 89 
3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.  
☐ ☐ ☐ ☐ 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 90 
3.3.1.2 The card verification code is not retained upon completion of the authorization process.  
☐ ☐ ☐ ☐ 

3.3.1.2 Examine data sources, to 
verify that the card verification code is 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 91 
3.3.1.3 The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process.  
☐ ☐ ☐ ☐ 

3.3.1.3  Examine data sources, to 
verify that PINs and PIN blocks are 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 92 
3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 93 
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 

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

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 94 
was used. 
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

the storage of sensitive authentication 
data.  Identi fy the evidence reference number(s) 
policies  examined for this testing 
3.3.3.b  Additional testing procedure 
Examine data stores and system 
configurations to verify that the

configurations to verify that the 
sensitive authentication data is stored 
securely.  Identify the evidence refe rence number(s) 
 
3.4 Access to displays of full PAN and ability to copy PAN is restricted.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 95 
3.4.1 PAN is masked when displayed (the BIN and last four digits are the maximum number  of digits to be displayed), such that only personnel with a 
legitimate business need can see more than  the BIN and last four digits of the PAN.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 96 
3.4.1.a Examine documented policies 
and procedures for masking the 
display of PANs to verify:  
• A list of roles that need access to 
more than the BIN and last four 
digits of the PAN (includes full 
PAN) is documented, together 
with a legitimate business need 
for each role to have such 
access.  
• PAN is masked when displayed 
such that only personnel with a 
legitimate business need can see 
digits of the PAN.  
• All roles not specifically 
authorized to see the full PAN 
must only see masked PANs.  Identify the evidence reference number(s) 
policies and procedures examined for 
this testing procedure.  <Enter Response Here > 
3.4.1.b Examine system 
configurations to verify that full PAN is

access.  
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.  Identify the evidence reference number(s) 
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

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  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 97 
3.4.2 When using remote -access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with docume nted, 
explicit authorization and a legitimate, defined business need . 
Note:  This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 98 
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 
• 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) 
policies and procedures  examined for 
from Section 6  for all documented

evidence for technical controls 
3.4.2.b  Examine configurations for 
remote-access technologies to verify 
that technical controls to prevent copy 
and/or relocation of PAN for all 
personnel, unless explicitly 
authorized.  Identify the evidence reference number(s) 
from Section 6  for all configurations 
3.4.2.c  Observe processes and 
interview personnel to verify that only

interview personnel to verify that only 
personnel with documented, explicit 
authorization and a legitimat e, defined 
business need have permission to 
copy and/or relocate PAN when using 
remote-access technologies.  Identify the evidence reference number(s) 
 
Requirement Description

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 99 
3.5.1 PAN is rendered unreadable anywhere it is stored by using any of the following approaches:  
• One-way hashes based on strong cryptography of the entire PAN.  
• Truncation (hashing cannot be used to replace the truncated segment of PAN).  
– If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional 
controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.  
• Index tokens.  
• Strong cryptogr aphy with associated key -management processes and procedures.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 
If “Yes”, Identify  the aspect(s) of the requirement where the Compensating

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 100 
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.  Identify the evidence reference  number(s) 
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  

from Section 6  for all audit logs  examined 
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 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 101 
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 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 102 
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.  Identify the evidence reference number(s) 
3.5.1.1.b  Examine documentation 
about the key management 
procedures and processes associated 
with the keyed cryptographic hashes 
to verify keys are managed in 
accordance with Requirements 3.6 
and 3.7.  Identify the evidence reference number(s) 

examined for this testing procedure.  <Enter Re sponse Here>  
3.5.1.1.c  Examine data repositories to 
verify the PAN is rendered 
unreadable.  Identify the evidence reference number(s) 
3.5.1.1.d  Examine audit logs, 
including payment application logs, to 
from Section 6  for all audit logs examined

from Section 6  for all audit logs examined 
3.5.1.2 If disk -level or partition -level encryption (rather than file -, column -, or field -level database encryption) is used to render PAN unreadable, it is 
implemented only as follows:  
• On removable electronic media 
OR 
• If used for non -removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.

OR 
• If used for non -removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 103 
☐ ☐ ☐ ☐ 
3.5.1.2.a  Examine encryption

3.5.1.2.a  Examine encryption 
processes to verify that, if disk -level or 
partition- level encryption is used to 
render PAN unreadable, it is 
• On removable electronic media,  
OR 
• If used for non -removable 
electronic media, examine 
encryption processes used to 
verify that PAN is also rendered 
unreadable via another method 
that meets Requirement 3.5.1.  Identify the evidence reference number(s) 
from Section 6  for all encryption 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 104 
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 n umber(s) 
Identify the evidence referenc e number(s) 
the encryption processes for this testing 

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 authent ication 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.

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 105 
was used. 
Note:  The use of Compensating Controls must also be documented in Appendix C . <Enter Response  Here>  
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

the authentication process  for this 
3.5.1.3.b  Examine  files containing 
authentication factors (passwords, 
passphrases, or cryptographic keys) 
authentication factors  that allow

authentication factors  that allow 
access to unencrypted data are stored 
securely and are independent from 
the native operating system’s  
authentication and access control 
methods.  Identify the evidence reference number(s) 
from Section 6  for all files containing 
authentication factors examined for this 
 
© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 106 
3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure a nd misuse that include:  
• Access to keys is restricted to the fewest number of custodians necessary.  
• Key-encrypting keys are at lea st as strong as the data- encrypting keys they protect.  
• Key-encrypting keys are stored separately from data-encrypting keys.  
• Keys are stored securely in the fewest possible locations and forms.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 
Control(s) was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 107 
3.6.1 Examine documented key -
management policies and procedures 
to verify that processes to protect 
cryptographic keys used to protect 
stored account data against disclosure 
and misuse are defined to include all 
from Section 6  for all documentation 
examined for this testing procedure.  <Enter Respon se Here>  
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.

• 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

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 108 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 109 
3.6.1.1  Additional testing procedure 
for service provider assessments 
only: Interview responsible personnel 
and examine documentation to verify 
that a document exists to describe the 
cryptographic architecture that 
includes all elements specified in this 
conduct ed for this testing procedure.  <Enter Response Here>  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 110 
3.6.1.2 Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all  times:  
• Encrypted with a key -encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.  
• Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS -approved point -of-interaction device.  
• As at least two full -length key components or key shares, in accordance with an industry -accept ed method.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 111 
3.6.1.2.a Examine documented 
procedures to verify it is defined that 
cryptographic keys used to 
encrypt/decrypt stored account data 
must exist only in one (or more) of the 
forms specified in this requirement.  Identify the evidence reference number(s) 
3.6.1.2.b Examine system 
configurations and key storage 
locations to verify that cryptographic 
keys used to encrypt/decrypt stored 
account data exist in one (or more) of 
the forms specified in this 

from Section 6  for all key storage 
locations examined for this testing 
3.6.1.2.c Wherever key -encrypting 
keys are used, examine system 
locations to verify:  
• 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.  Identify the evidence reference number(s) 

locations  examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 112 
3.6.1.3 Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.  
☐ ☐ ☐ ☐ 
was used. 

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

custodians necessary.  Identify the evidence reference number(s) 
from Section 6  for all user access lists 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 113 
3.6.1.4 Cryptographic keys are stored in the fewest possible locations.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 114 
3.6.1.4 Examine key storage locations 
and observe processes to verify that 
keys are stored in the fewest possible 
locations.  Identify the evidence reference number(s) 
processes for this testing procedure.  <Enter Response Here>  
 
3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of th e key lifecycle are 
defined and implemented.  

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 115 
was used. 
3.7.1.a Examine the documented key -
for keys used for protection of stored 
account data to verify that they define 
generation of strong cryptographic

generation of strong cryptographic 
from Section 6  for all documented key -
examined for this testing procedure.  <Enter Response H ere> 
3.7.1.b Observe the method for 
generating keys to verify that strong 
keys are generated.  Identify the evidence reference number(s) 
the methods for generating keys for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 116 
3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 117 
3.7.2.a Examine the documented key -
secure distribution of cryptographic 
from Section 6  for the documented key 
3.7.2.b Observe the method for 
distributing keys to verify that keys are 
distributed securely.  Identify the evidence reference number(s) 
the method for distributing keys for this 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 118 
was used. 
3.7.3.a Examine the documented key-
account data to verify that they define

secure storage of cryptographic keys.  Identify the evidence reference number(s) 
from Section 6  for the documented key-
3.7.3.b Observe the method for 
storing keys to verify that keys are 
stored securely.  Identify the evidence reference number(s) 
the method for storing keys  for this 
testing procedure.  <Enter Response Here >

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 119 
3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of th eir 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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 120 
3.7.4.a  Examine the documented key -
changes to cryptographic keys that 
have reached the end of their 
cryptoperiod and include all elements 
examined for this testing procedur e. <Enter Response Here>  
3.7.4.b Interview personnel, examine 
documentation, and observe key 
storage locations to verify that keys 
are changed at the end of the defined 
cryptoperiod(s).  Identify the evidence reference number(s) 

key storage locations for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 121 
3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to pro tect 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 f or 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 122 
3.7.5.a Examine the documented key-
account data and verify that they 
define retirement, replacement, or 
destruction of keys in accordance with 
requirement.  Identify the evidence refe rence number(s) 
3.7.5.b Interview personnel to verify 
that processes are implemented in 

3.7.6 Where manual cleartext cryptographic key -management operations are performed by personnel, key -management policies and procedures are 
implemented include managing these operations using split knowledge and dual control.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 123 
was used. 
3.7.6.a Examine the documented key -
define using split knowledge and dual

define using split knowledge and dual 
control.  Identify the evidence reference number(s) 
3.7.6.b Interview personnel and/or 
observe processes to verify that 
manual cleartext keys are managed 
with split knowledge and dual control.  Identify the evidence reference number(s) 

processes for this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 124 
3.7.7 Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic ke ys. 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 125 
3.7.7.a Examine the documented key -
define prevention of unauthorized 
substitution of cryptographic keys.  Identify the evidence reference number(s) 
management policies and pro cedures  
3.7.7.b Interview personnel and/or 
unauthorized substitution of keys is 
prevented.  Identify the evidence reference number(s) 
from Section 6  for all observation(s) of

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 126 
3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writ ing or electronically) 
that they understand and accept their key -custodian responsibilities.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 127 
3.7.8.a Examine the documented key -
define acknowledgments for key 
custodians in accordance with all 
management policies and procedures  
3.7.8.b Examine documentation or 
other evidence showing that key 
custodians have provided 
acknowledgments in accordance with 
from Section 6  for all documentation or 
other evidence  examined for this testing 

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

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 128 
was used. 
3.7.9 Additional testing procedure 
only:  If the service provider shares 
cryptographic keys with its customers 
for transmission or storage of account

for transmission or storage of account 
data, examine the documentation that 
the service provider provides to its 
customers to verify it includes 
guidance on how to securely transmit, 
store, and update customers’ keys in 
in Requirements 3.7.1 through 3.7.8 
above.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 129 
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over 
Open, Public Networks  
4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networ ks are defined and 
documented.  
4.1.1 All security policies and operational procedures that are identified in Requirement 4 are:  
• In use.  
☐ ☐ ☐ ☐ 

• In use.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 130 
4.1.1 Examine documentation and 
4 are managed in accordance with all 

4.1.2 Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 131 
was used. 
4.1.2.a Examine documentation to 
activities in Requirement 4 are

4.1.2.b Interview personnel with 
in Requirement 4 to verify that roles 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 132 
4.2.1  Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:  
• Only trusted keys and certificates are accepted.  
• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a 
best practice until 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be fully considered during a PCI DSS assessment.  
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, ke y sizes, or 
implementations.  
• The encryption strength is appropriate for the encryption methodology in use.

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

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 133 
4.2.1.a Examine documented policies 
and procedures and interview 
personnel to verify processes are 
defined to include all elements 
from Section 6  for the documented 

4.2.1.b  Examine system 
configurations to verify that strong 
cryptography and security protocols 
are implemented in accordance with 
4.2.1.c  Examine cardholder data 
transmissions to verify that all PAN is 
encrypted with strong cryptography 
when it is transmitted over open,

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 
4.2.1.d  Examine system 
configurations to verify that keys 
and/or certificates that cannot be 
verified as trusted are rejected.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 134 
4.2.1.1  An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.  
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.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 
Assessor’s Response

was used. 
4.2.1.1.a Examine documented 
policies and procedures to verify Identify the evidence reference number(s) 
from Section 6  for the  documented  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 135 
processes are defined for the entity to 
maintain an inventory of its trusted 
keys and certificates.  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 invent ories of 
trusted keys examined for this testing 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 136 
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.  Identify the evidence reference number(s) 
4.2.2 PAN is secured with strong cryptography whenever it is sent via end -user messaging technologies.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 137 
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.  Identify the evidence reference number(s) 
4.2.2.b  Examine system 
configurations and vendor 
documentation to verify that PAN is 
secured with strong cryptography

secured with strong cryptography 
whenever it is sent via end-user 
messaging technologies.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 138 
Maintain a Vulnerability Management Program 
Requirement 5: Protect All Systems and Networks from Malicious Software 
5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.  
5.1.1 All security policies and operational procedures that are identified in Requirement 5 are:  
• In use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 139 
was used. 
5.1.1 Examine documentation and 
5 are managed in accordance with all

5 are managed in accordance with all 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 140 
5.1.2 Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 141 
5.1.2.a Examine documentation to 
5.1.2.b Interview personnel with 
in Requirement 5 to verify that roles 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 142 
5.2 Malicious software (malware) is prevented or detected and addressed.  
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.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 143 
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.  Identify the evidence reference number(s) 
components  examined for this testing 
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 

5.2.2 The deployed anti -malware solution(s):  
• Detects all known types of malware.  
• Removes, blocks, or contains all known types of malware.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 144 
was used. 
5.2.2  Examine vendor documentation 
and configurations of the anti- malware 
solution(s) to verify that the solution:  
• Detects all known types of 
malware.

malware.  
• Removes, blocks, or contains all 
known types of malware.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 145 
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.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 146 
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 all elements 
from Section 6  for all  documented 
5.2.3.b  Interview personnel to verify 
that the evaluations include all 
5.2.3.c  Examine the list of system 
components identified as not at risk of 
malware and compare to the system

malware and compare to the system 
components without an anti -malware 
solution deployed per Requirement 
5.2.1 to verify that the system 
components match for both 
requirements.  Identify the evidence reference number(s) 
from Section 6  for all lists of system 
components  examine d for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 147 
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 t argeted risk analysis, which is 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 148 
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 
5.2.3.1.b  Examine documented 
results of periodic evaluations of 
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 
from Section 6  for all documented results

from Section 6  for all documented results 
of periodic evaluations of system 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 149 
5.3 Anti-malware mechanisms and processes are active, maintained, and monitored.  
5.3.1 The anti -malware solution(s) is kept current via automatic updates.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 150 
5.3.1.a Examine anti -malware 
solution(s) configurations, including 
any master installation of the 
software, to verify the solution is 
configured to perform automatic 
updates.  Identify the evidence reference number(s) 
from Section 6  for all anti-mal ware 
solution(s) configurations  examined for 
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 logs  examined for 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 151 
5.3.2 The anti-malware solution(s):  
• Performs periodic scans and active or real- time scans.  
OR 
• Performs continuous behavioral analysis of systems or processes.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 152 
5.3.2.a Examine anti -malware 
solution(s)  configurations, including 
software, to verify the solution(s) is 
configured to perform at least one of 
the elements specified in this 
from Section 6  for all anti-malware 
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 
requirement.  Identify the evidence reference number(s ) 

5.3.2.c  Examine logs and scan results 
to verify that the solution(s) is enabled 
in accordance with at least one of the 
from Sectio n 6 for all logs examined for 
from Section 6  for all scan results 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 153 
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 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 
Note: The use of Compensating Controls must also be documented in Appendix C . <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 154 
5.3.2.1.a Examine the entity’s 
frequency of periodic malware scans 
to verify the risk analysis was 
performed in accordance with all 
elements specified in Requirement 
12.3.1.  Identify the evidence reference number(s) 
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) 
of periodic malware scans examined for 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 155 
5.3.3 For removable electronic media, the anti-malware solution (s):  
• Performs automatic scans of when the media is inserted, connected, or logically mounted,  
OR 
• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.  
Note:  This requirement is a  best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 156 
5.3.3.a Examine anti -malware 
solution(s)  configurations to verify 
that, for removable electronic media, 
the solution is configured to perform at 
least one of the elements specified in 
5.3.3.b Examine system components 
with removable electronic media 
connected to verify that the solution(s) 
is enabled in accordance with at least 
one of the elements as specified in 
5.3.3.c Examine logs and scan results

5.3.3.c Examine logs and scan results 
Identify the evidence reference numb er(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 157 
5.3.4 Audit logs for the anti-malware solution (s) are enabled and retained in accordance with Requirement 10.5.1.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
5.3.4 Examine anti -malware 
solution (s) configurations to verify logs Identify the evidence reference number(s) 
from Section 6  for all anti-malware <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 158 
are enabled and retained in 
accordance with Requirement 10.5.1.  solution(s) configurations  examined for 
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.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 159 
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) 
solution configurations  examined for this 
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.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 160 
5.4.1  Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 161 
5.4.1 Observe implemented 
processes and examine mechanisms 
to verify controls are in place to detect 
and protect personnel against 
phishing attacks.  Identify the evidence reference number(s) 
from Section 6  for all  observation(s) of  
implemented processes  for this testing 
from Section 6  for all mechanisms 
Requirement 6: Develop and Maintain Secure Systems and Software 
6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.  
6.1.1 All security policies and operational procedures that are identified in Requirement 6 are:  
• Documented.

• In use.  
• Known to all affected parties.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 162 
☐ ☐ ☐ ☐ 
was used. 

was used. 
6.1.1 Examine documentation and 
6 are managed in accordance with all 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 163 
6.1.2  Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.   
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 164 
6.1.2.a Examine documentation to 
activities in Requirement 6 are 
6.1.2.b Interview personnel 
responsible for performing activities in 
Requirement 6 to verify that roles and 
 
• 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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 165 
☐ ☐ ☐ ☐ 
was used. 

was used. 
6.2.1  Examine documented software 
development procedures to verify that 
processes are defined that include all 
software development procedures

software development procedures 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 166 
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 t echniques.  
• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 167 
6.2.2.a Examine software 
processes are defined for training of 
software development personnel 
developing bespoke and custom 
software that includes all elements 
from Section 6  for all software 
development procedures examined for 
6.2.2.b Examine training records and 
working on bespoke and custom 
software received software security 
training that is relevant to their job 
function and development languages 
specified in this requirement.  Identify the evid ence reference number(s) 
from Section 6  for all training records

from Section 6  for all training records 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 168 
6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct pote ntial coding vulnerabilities, 
• Code reviews ensure code is developed according to secure coding guidelines.  
• Code reviews  look for both existing and emerging software vulnerabilities.  
• Appropriate corrections are implemented prior to release.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 169 
6.2.3.a Examine documented 
software development procedures and 
verify that processes are defined that 
require all bespoke and custom 
software to be reviewed in 
specified in this requirement.  Identify the evidence reference numbe r(s) 
6.2.3.b Examine evidence of changes 
to bespoke and custom software to 
verify that the code changes were 
reviewed in accordance with all 
elements specified in this

from Section 6  for all evidence of 
changes  examined for this testing 
6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:  
• Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.  
• Reviewed and approved by management prior to release.  
(select one)

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 170 
was used. 
6.2.3.1.a If manual code reviews are 
performed for bespoke and custom 
software prior to release to 
production, examine documented 
software development procedures and

verify that processes are defined for 
manual code reviews to be conducted 
examined for this  testing procedure.  <Enter Response Here>  
6.2.3.1.b Examine evidence of 
changes to bespoke and custom

changes to bespoke and custom 
software and interview personnel to 
verify that manual code reviews were 
conducted in accordance with all 
changes  examined for  this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 171 
6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software 
attacks and related vulnerabilities  in bespoke and custom software, including but not limited to the following:  
• Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection- type flaws.  
• Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.  
• Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or 
modes of operation.  
• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication

• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication 
protocols and channels, client -side functionality, or other system/application functions and resources. This includes cross -site scripting (XSS) and cross -site 
request forgery (CSRF).  
• Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to 
exploit weaknesses in the implementation of such mechanisms.  
• Attacks via any "high -risk" vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.

• Attacks via any "high -risk" vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 172 
6.2.4 Examine documented 
software development personnel to 
verify that software engineering 
techniques or other methods are 
defined and in use by developers of 
bespoke and custom software to 
prevent or mitigate all common 
software attacks as specified in this  

6.3.1 Security vulnerabilities are identified and managed as follows:  
• New security vulnerabilities are identified using industry -recognized sources for security vulnerability information, including alerts from international and

• New security vulnerabilities are identified using industry -recognized sources for security vulnerability information, including alerts from international and 
national computer emergency respo nse teams (CERTs).  
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.  
• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.  
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 173 
☐ ☐ ☐ ☐ 
was used. 

was used. 
6.3.1.a Examine policies and 
procedures for identifying and 
managing security vulnerabilities to 
verify that processes are defined in 
from Section 6 for all policies and 

6.3.1.b Interview responsible 
personnel, examine documentation, 
and observe processes to verify that Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 174 
security vulnerabilitie s are identified 
and managed in accordance with all 
6.3.2 An inventory of bespoke and custom software, and third -party software components incorporated into bespoke and custom software is maintained to 
facilitate vulnerability and patch management.  
Note:  This requirement is a best practice until 31 March 2025, after  which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 175 
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.  Identify the evide nce reference number(s) 

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) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 176 
6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:  
• Critical or high -security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.  
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for  example, within three months of 
release).  
☐ ☐ ☐ ☐ 

release).  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 177 
6.3.3.a Examine policies and 
procedures to verify processes are 
defined for addressing vulnerabilities 
by installing applicable security 
patches/updates in accordance with 
6.3.3.b Examine system components 
and related software and compare the 
list of installed security 
patches/updates to the most recent 
security patch/update information to 
verify vulnerabilities are addressed in 
components and related software

components and related software 
examined  for this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 178 
6.4.1 For public -facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protect ed against known 
attacks as fo llows:  
• Reviewing public -facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:  
– At least once every 12 months and after significant changes.  
– By an entity that specializes in application security.  
– Including, at a minimum, all common software attacks in Requirement 6.2.4.  
– All vulnerabilities are ranked in accordance with requirement 6.3.1.  
– All vulnerabilities are corrected.  
– The application is re-evaluated after the corrections  
OR

OR 
• Installing an automated technical solution(s) that continually detects and prevents web- based attacks as follows:  
– Installed in front of public -facing web applications to detect and prevent web-based attacks.  
– Actively running and up to date as applicable.  
– Generating audit logs.  
– Configured to either block web -based attacks or generate an alert that is immediately investigated.  
Note:  This requirement will be superseded  by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 179 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 180 
6.4.1 For public -facing web 
applications, ensure that either one of 
the required methods is in place as 
follows:  
• 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 
elements of this requirement 
specific to the tool/method.  
OR 
• If an automated technical 
solution(s) is installed that 
continually detects and prevents 
web-based attacks, examine the 
system configuration settings and 
audit logs, and interview 
responsible personnel to verify 
that the automated technical 
solution(s) is installed in 
accordance with all elements of

OR 
accordance with all elements of 
this requirement specif ic to the 
solution(s).  Identify the evidence reference number(s) 
from Section 6  for all records of 
application security assessments

application security assessments 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 181 
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 
• Is installed in front of public -facing web applications and is configured to detect and preven t web -based attacks.  
• Actively running and up to date as applicable.  
• Generating audit logs.  
• Configured to either block web -based attacks or generate an alert that is immediately investigated.  
Note:  This requirement is a best practice until 31 March 2025, a fter 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.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 182 
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 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 183 
6.4.3 All payment page scripts that are loaded and executed in the consumer's browser are managed as follows:  
• A method is implemented to confirm that each script is authorized.  
• A method is implemented to assure the integrity of each script.  
• An inventory of all scripts is maintained with written justification as to why each is necessary.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 184 
6.4.3.a Examine policies and 
procedures to verify that processes 
are defined for managing all payment 
page scripts that are loaded and 
executed in the consumer’s browser, 
6.4.3.b  Interview responsible 
personnel and examine inventory 
records and system configurations to 
verify that all payment page scripts 
that are loaded and executed in the 
consumer’s browser are managed in 

from Section 6  for all inventory records  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 185 
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 i nto production.  
• Procedures to address failur es and return to a secure state.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 186 
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 
change control procedures  examined for 
6.5.1.b Examine recent changes to 
system components and trace those 
changes back to related change

changes back to related change 
control documentation. For each 
change examined, verify the change 
is implemented in accordance with all 
from Section 6  for all recent changes  to 
system components examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 187 
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 networ ks, 
and documentation is updated as applicable.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 188 
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) 
the affected systems/networks for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 189 
6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 190 
6.5.3.a Examine policies and 
are defined for separating the pre-
production environment from the 
production environment via access 
controls that enforce the separation.  Identify the evidence reference number(s) 
6.5.3.b Examine network 
documentation and configurations of 
network security controls to verify that 
the pre -production environment is 
separate from the production 
environment(s).  Identify the evidence reference number(s) 
from Section 6  for all configurations

6.5.3.c Examine access control 
settings to verify that access controls 
are in place to enforce separation 
between the pre-production and 
production environment(s).  Identify the evidence reference number(s) 
from Section 6  for all access control 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 191 
6.5.4 Roles and functions are separated between production and pre -production environments to provide accountability such that only reviewed and approved 
changes are deployed.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 192 
6.5.4.a Examine policies and 
are defined for separating roles and 
functions to provide accountability 
such that only reviewed and approved 
changes are deployed.  Identify the evidence reference number(s) 
6.5.4.b Observe processes and 
interview personnel to verify 
implemented controls separate roles 
and functions and provide 
accountability such that only reviewed 
and approved changes are deployed.  Identify the evidence reference number(s) 
proc esses for this testing procedure.  <Enter Response Here>  

6.5.5 Live PANs are not used in pre -production environments, except where those environments are included in the CDE and protected in accordance with all 
applicable PCI DSS requirements.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 193 
was used. 
6.5.5.a Examine policies and 
are defined for not using live PANs in 
pre-production environments, except 
where those environments are in a

where those environments are in a 
CDE and protected in accordance 
with all applicable PCI DSS 
6.5.5.b Observe testing processes 
procedures are in place to ensure live 
PANs are not used in pre-production 
environments, except where those 
environments are in a CDE and 
protected in accordance with all

protected in accordance with all 
applicable PCI DSS requirements.  Identify the evidence reference number(s) 
the testing processe s for this testing 
from Section 6  for all interview(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 194 
6.5.5.c  Examine pre -production test 
data to verify live PANs are not used 
in pre- production environments, 
except where those environments are 
in a CDE and protected in accordance 
from Section 6  for all pre-production test 
data examined for this testing procedure.  <Enter Response Here>  
6.5.6 Test data and test accounts are removed from system components before the system goes into production.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 195 
6.5.6.a  Examine policies and 
are defined for removal of test data 
and test accounts from system 
components before the system goes 
into production.  Identify the evidence reference number(s) 
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

personnel to verify test data and test 
accounts are removed before a 
system goes into production.  Identify the evidence reference number(s) 
the testing processes for this testing 
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

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 
from Section 6  for all accounts examined 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 196 
Implement Strong Access Control Measures 
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need 
to Know  
7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined  and understood.  
7.1.1 All security policies and operational procedures that are identified in Requirement 7 are:  
• In use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 197 
was used. 
7.1.1  Examine documentation and 
7 are managed in accordance with all

7 are managed in accordance with all 
Identify the evidence reference numbe r(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 198 
7.1.2 Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 199 
7.1.2.a Examine documentation to 
activities in Requirement 7 are 
7.1.2.b Interview personnel with 
in Requirement 7 to verify that roles 
and are understood.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 200 
7.2 Access to system components and data is appropriately defined and assigned.  
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 
Control(s) was used. <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 201 
Note:  The use of Compensating Controls must also be documented in Appendix C . 
7.2.1.a  Examine documented policies 
personnel to verify the access control 
model is defined in accordance with 
7.2.1.b  Examine access control model 
settings and verify that access needs 
are appropriately defined in 

model settings examined for this testing 
7.2.2 Access is assigned to users, including privileged users, based on:  
• Job classification and function.  
• Least privileges necessary to perform job responsibilities.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 202 
was used. 
7.2.2.a Examine policies and 
procedures to verify they cover 
assigning access to users in 

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 
from Section 6  for all user access 
settings  examined for this testing

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 203 
7.2.3 Required privileges are approved by authorized personnel.   
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 204 
7.2.3.a Examine policies and 
procedures to verify they define 
processes for approval of all privileges 
by authorized personnel.  Identify the evidence reference number(s) 
7.2.3.b Examine user IDs and 
assigned privileges, and compare with 
documented approvals to verify that:  
• Documented approval exists for 
the assigned privileges.  
• The approval was by authorized 
personnel.  
• Specified privileges match the 
roles assigned to the individual.  Identify the evidence reference number(s) 
from Section 6  for all user IDs and 
assig ned privileges examined for this 

approvals  examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 205 
7.2.4 All user accounts and related access privileges, including third -party/vendor accounts, are reviewed as follows:  
• At least once every six months.  
• To ensure user accounts and access remain appropriate based on job function.  
• Any inappropriate access is addressed.  
• Management acknowledges that access remains appropriate.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 206 
7.2.4.a Examine policies and 
processes to review all user accounts 
and related access privileges, 
including third-party/vendor accounts, 
7.2.4.b Interview responsible 
personnel and examine documented 
results of periodic reviews of user 
accounts to verify that all the results 
are in accordance with all elements 

accounts  examined for this testing 
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.

• Access is limited to the systems, applications, or processes that specifically require their use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 207 
was used. 
7.2.5.a Examine policies and 
processes to manage and assign 
application and system accounts and 
related access privileges in

related access privileges in 
7.2.5.b Examine privileges associated 
with system and application accounts 
to verify that application and system 
accounts and related access 
privileges are assigned and managed 

from Section 6  for all privileges 
associated with system and application 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 208 
7.2.5.1 All access by application and system accounts and related access privileges are reviewed as follows:  
• 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).  
• The application/system access remains appropriate for the function being performed.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 209 
7.2.5.1.a Examine policies and 
processes to review all application 
and system accounts and related 
access privileges in accordance with 
7.2.5.1.b Examine the entity’s 
frequency of periodic reviews of

frequency of periodic reviews of 
related access privileges to verify the 
risk analysis was performed in 
specified in Requirement 12.3.1.  Identify the evidence reference number(s) 
from Section 6  for the entity’s targeted 
risk analysis examined for this testing 
7.2.5.1.c Interview responsible 
results of periodic reviews of system 
and application accounts and related 
privileges to verify that the reviews

privileges to verify that the reviews 
occur in accordance with all elements 
of periodic reviews examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 210 
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.   
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 211 
7.2.6.a Examine policies and 
verify processes are defined for 
granting user access to query 
repositories of stored cardholder data, 
7.2.6.b Examine configuration settings 
for querying repositories of stored 
cardholder data to verify they are in 

procedure.  <Ent er Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 212 
7.3 Access to system components and data is managed via an access control system(s).  
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.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 213 
7.3.1 Examine vendor documentation 
and system settings to verify that 
access is managed for each system 
component via an access control 
system(s) that restricts access based 
on a user’s need to know and covers 
all system components.  Identify the evidence reference number(s) 
from Section 6  for all system settings  
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.  

function.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 214 
was used. 
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

individuals, applications, and systems 
based on job classification and 
function.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 215 
7.3.3 The access control system(s) is set to “deny all” by default.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 216 
7.3.3 Examine vendor documentation 
access control system(s) is set to 
“deny all” by default.  Identify the evidence reference number(s) 
 
Requirement 8: Identify Users and Authenticate Access to System Components 
8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.  
8.1.1 All security policies and operational procedures that are identified in Requirement 8 are:  

• In use.  
☐ ☐ ☐ ☐

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 217 
was used. 

was used. 
8.1.1 Examine documentation and 
procedures that are identified in 
Requirement 8 are managed in 

8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 218 
☐ ☐ ☐ ☐ 
was used. 

was used. 
8.1.2.a Examine documentation to 

8.1.2.b Interview personnel with 
respo nsibility for performing activities 
in Requirement 8 to verify that roles Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 219 
documented and are understood.  
 
8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.  
8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 220 
8.2.1.a Interview responsible 
personnel to verify that all users are 
assigned a unique ID for access to 
system components and cardholder 
data.  Identify the evidence reference number(s) 
from Section 6  for all inte rview(s)  
8.2.1.b  Examine audit logs and other 
evidence to verify that access to 
data can be uniquely identified and 
associated with individuals.  Identify the evidence reference number(s) 
from Section 6  for all audit logs  examined

from Section 6  for any other evidence  
8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception b asis, and are managed as 
follows:  
• Account use is prevented unless needed for an exceptional circumstance.

follows:  
• Account 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 indiv idual user.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 221 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 222 
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 
specified in this requirement.  Identify the evidence reference num ber(s) 
from Section 6  for all user account lists  

8.2.2.b Examine authentication 
policies and procedures to verify 
processes are defined for shared 
authentication credentials such that 
they are only used when necessary, 
on an exception basis, and are 
managed in accordance with all 
from Section 6  for all  authentication 
policies and procedures  examined for

8.2.2.c Interview system 
administrators to verify that shared 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 223 
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.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 224 
8.2.3 Additional testing procedure 
only:  Examine authentication policies 
personnel to verify that service 
providers with remote access to 
customer premises use unique 
authentication factors for remote 
access to each customer premises.  Identify the evidence reference number(s) 
from Section 6  for all authentication 
8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 225 
was used. 
8.2.4 Examine documented 
authorizations across various phases 
of the account lifecycle (additions, 
modifications, and deletions) and 
examine system settings to verify the

examine system settings to verify the 
activity has been managed in 
authorizations  examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 226 
8.2.5 Access for terminated users is immediately revoked.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
8.2.5.a Examine information sources 
for terminated users and review Identify the evidence reference number(s) 
from Section 6  for all information <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 227 
current user access lists —for both 
local and remote access —to verify 
that terminated user IDs have been 
deactivated or removed from the 
access lists.  sources  examined for this testing 
procedure.  
from Section 6  for all current user access 
lists examined for t his testing procedure.  <Enter Response Here>  
8.2.5.b  Interview responsible 
personnel to verify that all physical 
authentication factors —such as, smart 
cards, tokens, etc. —have been 
returned or deactivated for terminated 
users.  Identify the evidence reference number(s) 
8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 228 
8.2.6 Examine user accounts and last 
logon information, and interview 
personnel to verify that any inactive 
user accounts are removed or 
disabled within 90 days of inactivity.  Identify the evidence reference number(s) 
from Section 6  for all user accounts and 
last login information  examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 229 
8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:  
• Enabled only during the time period needed and disabled when not in use.  
• Use is monitored for unexpected activity.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 230 
8.2.7 Interview personnel, examine 
documentation for managing 
accounts, and examine evidence to 
verify that accounts used by third 
parties for remote access are 
managed according to all elements 
from Section 6  for any other evidence 

8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re -authenticate to re -activate the terminal or session.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 231 
was used. 
8.2.8 Examine system configuration 
settings to verify that system/session 
idle timeout features for user sessions

idle timeout features for user sessions 
have been set to 15 minutes or less.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 232 
Requirement Descripti on 
8.3 Strong authentication for users and administrators is established and managed.  
8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:  
• Something you know, such as a password or passphrase.  
• Something you have, such as a token device or smart card.  
• Something you are, such as a biometric element.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 233 
8.3.1.a Examine documentation 
describing the authentication factor(s) 
used to verify that user access to 
system components is authenticated 
via at least one authentication factor 
8.3.1.b For each type of 
authentication factor used with each 
type of system component, observe 
an authentication to verify that

an authentication to verify that 
authentication is functioning 
consistently with documented 
authentication factor(s).  Identify the evidence reference number(s) 
each type of authentication  factor used  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 234 
8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 235 
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.  Identify the evidence reference number(s) 
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  

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 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 236 
8.3.3 User identity is verified before modifying any authentication factor.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 237 
8.3.3 Examine procedures for 
modifying authentication factors and 
observe security personnel to verify 
that when a user requests a 
modification of an authentication 
factor, the user’s identity is verified 
before the authentication factor is 
modified.  Identify the evidence reference number(s) 
from Section 6  for all procedures  
security personnel  for this testing 
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.

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 238 
was used. 
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

user accounts be locked out after not 
more than 10 invalid logon attempts.  Identify the evidence reference number(s) 
from Section 6  for all system configuration 
settings examined for this testing 
8.3.4.b  Examine system configuration 
settings to verify that password 
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 nu mber(s)

confirmed.  Identify the evidence reference nu mber(s) 
8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user a s follows:  
• Set to a unique value for first -time use and upon reset.  
• Forced to be changed immediately after the first use.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 239 
☐ ☐ ☐ ☐ 
was used. 

was used. 
8.3.5 Examine procedures for setting 
and resetting passwords/passphrases 
(if used as authentication factors to 
meet Requirement 8.3.1) and observe 
security personnel to verify that 
passwords/passphrases are set and 
reset in accordance with all elements

reset in accordance with all elements 
from Section 6 for all procedures  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 240 
8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:  
• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight chara cters). 
• Contain both numeric and alphabetic characters.  
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. Until 
31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 241 
was used. 
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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 242 
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.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 243 
8.3.7 Examine system configuration 
parameters are set to require that new 
passwords/passphrases cannot be 
the same as the four previously used 
passwords/passphrases.  Identify the evidence reference number(s) 
from Sectio n 6 for all system 
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 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.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 244 
was used. 
8.3.8.a Examine procedures and 
authentication policies and 
procedures are distributed to all users.  Identify the evidence reference number(s)

procedures are distributed to all users.  Identify the evidence reference number(s) 
8.3.8.b Review authentication policies 
and procedures that are distributed to 
users and verify they include the 

8.3.8.c Interview users to verify that 
they are familiar with authentication 
policies and procedures.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 245 
8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single -factor authentication implementation) then either:  
• Passwords/passphrases are changed at least once every 90 days,  
OR 
• The security posture of accounts is dynamically analyzed, and real -time access to resources is automatically determined accordingly.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 246 
8.3.9 If passwords/passphrases are 
used as the only authentication factor 
for user access, inspect system 
passwords/passphrases are managed 
in accordance with ONE of the 
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:

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 as of 31 March 2025. 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 247 
was used. 
8.3.10 Additional testing procedure 
only:  If passwords/passphrases are 
for customer user access to

for customer user access to 
cardholder data, examine guidance 
provided to customer users to verify 
that the guidance includes all 
requirement.  Identify the evidence  reference number(s) 
from Section 6  for all guidance provided 
to customer users examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 248 
8.3.10.1 Additional requirement for service providers only:  If passwords/passphrases are used as the only authentication factor for customer user access 
(i.e., in any single- factor authentication implementation) then either:  
OR 
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.  
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. Until 
this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 249 
8.3.10.1 Additional testing 
procedure for service provider 
assessments only:  If 
passwords/passphrases are used as 
the only authentication factor for 
customer user access, inspect system 
configuration settings  examined for this

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 250 
8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:  
• Factors are assigned to an individual user and not shared among multiple users.  
• Physical and/or logical controls ensure only the intended user can use that factor to gain access.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 251 
8.3.11.a Examine authentication 
policies and procedures to verify that 
procedures for using authentication 
factors such as physical security 
tokens, smart cards, and certificates 
are defined and include all elements 
8.3.11.b Interview security personnel 
to verify authentication factors are 
assigned to an individual user and not 
shared among multiple users.  Identify the evidence reference number(s) 
conducted for this testing procedure.  <Enter Response H ere> 
8.3.11.c Examine system 
configuration settings and/or observe

configuration settings and/or observe 
physical controls, as applicable, to 
verify that controls are implemented to 
ensure only the intended user can use 
that factor to gain access.  Identify the evidence reference number(s) 
from Section 6  for all observations of 
physical controls  conducted for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 252 
8.4 Multi -factor authentication (MFA) is implemented to secure access into the CDE.  
8.4.1 MFA is implemented for all non -console access into the CDE for personnel with administrative access.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 253 
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.  Identify the evidence reference number(s) 
from Section 6  for all network and/or 
system configurations examined for this 
8.4.1.b Observe administrator 
personnel logging into the CDE and 
verify that MFA is required.  Identify the evidence reference number(s) 
administrator personnel logging into 
the CDE  for this testing procedure.  <Enter Response Here>  
8.4.2  MFA is implemented for all access into the CDE.

8.4.2  MFA is implemented for all access into the CDE.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 254 
was used. 
8.4.2.a Examine network and/or 
implemented for all access into the 
CDE.  Identify the evidence reference number(s)

CDE.  Identify the evidence reference number(s) 
system configurations  examined for this 
8.4.2.b Observe personnel logging in 
to the CDE and examine evidence to 
personnel logging into the CDE  for this 
from Section 6  for any additional 
evidence examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 255 
8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact th e CDE as follows:  
• All remote access by all personnel, both users and administrators, originating from outside the entity’s network.  
• All remote access by third parties and vendors.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 256 
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 
8.4.3.b Observe personnel (for 
example, users and administrators) 
connecting remotely to the network 
and verify that multi-factor 
authentication is required.  Identify the evidence reference num ber(s) 
personnel connecting remotely to the 
network  for this testing procedure.  <Enter Response Here>  
 
• The MFA system is not susceptible to replay attacks.  
• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by  management on an 
exception basis, for a limited time period.  
• At least two different types of authentication factors are used.

• At least two different types of authentication factors are used.  
• Suc cess of all authentication factors is required before access is granted.  
Note:  This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 257 
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 258 
8.5.1.a Examine vendor system 
documentation to verify that the MFA 
system is not susceptible to replay 
attacks.  Identify the evidence reference number(s) 
from Section 6  for all vendor system 
8.5.1.b Examine system 
configurations for the MFA 
implementation to verify it is 
configured in accordance with all 
8.5.1.c Interview responsible 
verify that any requests to bypass 
MFA are specifically documented and 
authorized by management on an 
exception basis, for a limited time

exception basis, for a limited time 
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)

successful.  Identify the evidence reference number(s) 
personnel logging into system 
components in the CDE  for this testing 
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) 
personnel connecting remotely from 
outside the entity’s network  for this

outside the entity’s network  for this 
testing procedure.  <Ent er Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 259 
8.6 Use of application and system accounts and associated authentication factors is strictly managed.  
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 circu mstance.  
• Business justification for interactive use is documented.  
• Interactive use is explicitly approved by management.  
• Individual user identity is confirmed before access to account is granted.  
• Every action taken is attributable to an individual user.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 260 
8.6.1 Examine application and system 
accounts that can be used 
interactively and interview 
administrative personnel to verify that 
from Section 6  for all application and 
system accounts examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 261 
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.   
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 262 
8.6.2.a Interview personnel and 
examine system development 
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) 
8.6.2.b  Examine scripts, 
configuration/property files, and 
bespoke and custom source code for 
application and system accounts that

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, 
bespoke and custom source code  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 263 
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:   
• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all 
elements specified in Requirement 12.3.1) and upon suspicion or confi rmation of compromise.  
• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 264 
8.6.3.a Examine policies and 
procedures to verify that procedures 
are defined to protect 
passwords/passphrases for 
application or system accounts 
against misuse in accordance with all 
8.6.3.b  Examine the entity’s targeted 
risk analysis for the change frequency 
and complexity for 
passwords/passphrases used for 
interactive login to application and 
system accounts to verify the risk 
Requirement 12.3.1 and addresses:  
• The frequency defined for periodic 
changes to application and 
system passwords/passphrases.

system passwords/passphrases.  
• The complexity defined for 
passwords/passphrases and 
appropriateness of the complexity 
relative to the frequency of 
changes.  Identify the evidence reference number(s) 
8.6.3.c Interview responsible 
personnel and examine system 
passwords/passphrases for any 
can be used for interactive login are 
protected against misuse in

protected against misuse in 
conducted for this testing procedure.  <Enter Response Her e> 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 265 
Requirement  9: Restrict Physical Access to Cardholder Data  
9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.  
9.1.1 All security policies and operational procedures that are identified in Requirement 9 are:  
• In use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 266 
9.1.1 Examine documentation and 
9 are managed in accordance with all 

9.1.2 Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.   
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 267 
was used. 
9.1.2.a Examine documentation to 
activities in Requirement 9 are

activities in Requirement 9 are 
9.1.2.b Interview personnel with 
in Requirement 9 to verify that roles 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 268 
9.2 Physical access controls manage entry into facilities and systems containing cardholder data.  
9.2.1 Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 269 
9.2.1  Observe entry controls and 
verify that physical security controls 
are in place to restrict access to 
systems in the CDE.  Identify the evidence reference number(s) 
the entry controls for this testing 
9.2.1.1  Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access contro l mechanisms (or both) as 
follows:  
• Entry and exit points to/from sensitive areas within the CDE are monitored.

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

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 270 
was used. 
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)

access control mechanisms (or both) 
are in place to monitor the entry and 
exit points.  Identify the evidence reference number(s) 
locations where individual physical 
access to sensitive areas within the 
CDE occurs  for this testing procedure.  <Enter Response Here>  
9.2.1.1.b Observe locations where 
are protected from tampering or

are protected from tampering or 
disabling.  Identify the evidence refe rence number(s) 
from Section 6  for all observations(s) of 
access to the CDE occurs for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 271 
9.2.1.1.c Observe the physical access 
control mechanisms and/or examine 
video cameras and interview 
responsible personnel to verify that:  
• Collected data from video 
cameras and/or physical access 
control mechanisms is reviewed 
and correlated with other entries.  
• Collected data is stored for at 
least three months.  Identify the evidence reference number(s) 
the physical access control 
mechanisms for this testing procedure.  <Enter Response Here>  
from Section 6  for all video cameras 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 272 
was used. 
9.2.2  Interview responsible personnel 
and observe locations of publicly 
accessible network jacks to verify that 
physical and/or logical controls are in

physical and/or logical controls are in 
place to restrict access to publicly 
accessible network jacks within the 
facility.  Identify the evidence refe rence number(s) 
the locations of publicly accessible 
network jacks for this testing procedure.  <Enter Response H ere>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 273 
9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within t he facility is restricted.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 274 
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) 
the locations of hardware and lines  for 
9.2.4 Access to consoles in sensitive areas is restricted via locking when not in use.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 275 
9.2.4 Observe a system 
administrator’s attempt to log into 
consoles in sensitive areas and verify 
that they are “locked” to prevent 
unauthorized use.  Identify the evidence reference number(s) 
from Section 6  for all observation(s) of a 
system administrator’s attempt to log 
into consoles in sensitive areas for this 
 
9.3.1 Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including:  
• Identifying personnel.  
• Managing changes to an individual's physical access requirements.  
• Revoking or terminating personnel identification.  
• Limiting access to the identification process or system to authorized personnel.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 276 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 277 
9.3.1.a Examine documented 
to authorize and manage physical 
access of personnel to the CDE are 
defined in accordance with all 
9.3.1.b  Observe identification 
methods, such as ID badges, and 
processes to verify that personnel in 
the CDE are clearly identified.  Identify the evidence reference number(s) 
from Section 6  for all observation(s) of all 
identification methods and processes 
9.3.1.c  Observe processes to verify 
that access to the identification 
process, such as a badge system, is

process, such as a badge system, is 
limited to authorized personnel.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 278 
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.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 279 
9.3.1.1.a Observe personnel in 
sensitive areas within the CDE, 
interview responsible personnel, and 
examine physical access control lists 
to verify that:  
• Access to the sensitive area is 
authorized.  
• Access is required for the 
individual’s job function.  Identify the evidence reference number(s) 
personnel in sensitive areas  for this 
from Section 6  for all physical access 
control lists  examined for this testing 
9.3.1.1.b Observe proc esses and

9.3.1.1.b Observe proc esses and 
access of all personnel is revoked 
immediately upon termination.  Identify the evidence reference number(s) 
9.3.1.1.c For terminated personnel, 
examine physical access controls lists 
to verify that all physical access

to verify that all physical access 
mechanisms (such as keys, access 
cards, etc.) were returned or disabled.  Identify the evidence reference number(s) 
from Section 6 for all physical access 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 280 
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.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 281 
9.3.2.a Examine documented 
authorizing and managing visitor 
access to the CDE in accordance with 
9.3.2.b Observe processes when 
visitors are present in the CDE and 
visitors are:  
• Authorized before entering the 
CDE.  
• Escorted at all times within the 

CDE.  
processes when visitors are present in 
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 reference number(s)

the CDE.  Identify the evidence reference number(s) 
the use of visitor badges or other 
identification for this testing procedure.  <Enter Response Here>  
9.3.2.d Observe visitors in the CDE to 
verify that:  
• Visitor badges or other 
identification are being used for 
all visitors.  
• Visitor badges or identification 
easily distinguish visitors from 
personnel.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 282 
9.3.2.e Examine visitor badges or 
other identification and observe 
evidence in the badging system to 
verify v isitor badges or other 
identification expires.  Identify the evidence reference number(s) 
from Section 6  for all visitor badges or 
other identification  examined for this 
evidence in the badging system for this 
9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 283 
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) 
visitors leaving the facility for this testi ng 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 284 
9.3.4  A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas, inclu ding:  
• 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.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 285 
9.3.4.a Examine the visitor log and 
verify that a visitor log is used to 
record physical access to the facility 
and sensitive areas.  Identify the evidence reference number(s) 
from Section 6  for all visitor logs  
9.3.4.b Examine the visitor log and 
verify that the log contains:  
• The visitor’s name and the 
organization represented.  
• The personnel authorizing 
physical access.  
• Date and time of visit.  Identify the evidence reference number(s) 
from Section 6  for all visitor logs

9.3.4.c Examine visitor log storage 
locations and interview responsible 
personnel to verify that the log is 
retained for at least three months, 
unless otherwise restricted by law.  Identify the evidence reference number(s) 
from Section 6  for all visitor log storage 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 286 
9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.  
9.4.1 All media with cardholder data is physically secured.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 287 
9.4.1 Examine documentation to verify 
that procedures defined for protecting 
cardholder data include controls for 
physically securing all media.  Identify the evidence reference number(s) 
9.4.1.1 Offline media backups with cardholder data are stored in a secure location.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 288 
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.  Identify the evidence reference number(s) 
9.4.1.1.b Examine logs or other 
responsible personnel at the storage 
location to verify that offline media 
backups are stored in a secure

backups are stored in a secure 
location.  Identify the evidence reference number(s) 
from Section 6  for all logs or other 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 289 
9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
9.4.1.2.a Examine documentation to 
reviewing the security of the offline Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 290 
media backup location(s) with 
cardholder data at least once every 12 
months.  
9.4.1.2.b Examine documented  
procedures, logs, or other 
documentation, and interview 
location(s) to verify that the storage 
location’s security is reviewed at least 
once every 12 months.  Identify the evidence reference number(s) 
9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 291 
was used. 
9.4.2.a Examine documentation to 
classifying media with cardholder data 
in accordance with the sensitivity of

in accordance with the sensitivity of 
the data.  Identify the evidence reference number(s) 
9.4.2.b Examine media logs or other 
documentation to verify that all media 
is classified in accordance with the 
sensitivity of the data.  Identify the evidence reference number(s) 
from Section 6  for all media logs or other 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 292 
9.4.3 Media with cardholder data sent outside the facility is secured as follows:  
• Media sent outside the facility is logged.  
• Media is sent by secured courier or other delivery method that can be accurately tracked.  
• Offsite tracking logs include details about media location.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 
Note: The use of Customized Approach must also be documented in Appendix E . <Enter Response Here>  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 293 
9.4.3.a Examine documentation to 
securing media sent outside the 
facility in accordance with all elements 
9.4.3.b Interview personnel and 
examin e records to verify that all 
media sent outside the facility is 
logged and sent via secured courier or 
other delivery method that can be 
tracked.  Identify the evidence reference number(s) 
from Section 6  for all records examined  

9.4.3.c Examine offsite tracking logs 
for all media to verify tracking details 
are documented.  Identify the evidence reference number(s) 
from Section 6  for all offsite tracking logs  
9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to  individuals).  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 294 
was used. 
9.4.4.a Examine documentation to 
verify that procedures are defined to 
ensure that media moved outside the 
facility is approved by management.  Identify the evidence reference number(s)

facility is approved by management.  Identify the evidence reference number(s) 
from Section 6  for all docume ntation  
9.4.4.b Examine offsite media tracking 
logs and interview responsible 
personnel to verify that proper 
management authorization is obtained 
for all media moved outside the facility 
(including media distributed to 
individuals).  Identify the evidence reference number(s) 
from Section 6  for all offsite media 
tracking logs examined for this test ing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 295 
9.4.5  Inventory logs of all electronic media with cardholder data are maintained.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 296 
9.4.5.a Examine documentation to 
maintain electronic media inventory 
logs.  Identify the evidence reference number(s) 
9.4.5.b Examine electronic media 
inventory logs and interview 
responsible personnel to verify that 
logs are maintained.  Identify the evidence reference number(s) 
from Section 6  for all electronic media 
inventory logs  examined for this testing 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 297 
9.4.5.1.a Examine documentation to 
conduct inventories of electronic 
media with cardholder data at least 
9.4.5.1.b Examine electronic media 
inventory logs and interview personnel 
to verify that electronic media 
inventories are performed at least

inventories are performed at least 
inventory logs examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 298 
9.4.6 Hard -copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:  
• Materials are cross -cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.  
• Materials are stored in secure storage containers prior to destruction.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 299 
9.4.6.a Examine the periodic media 
destruction policy to verify that 
procedures are defined to destroy 
hard-copy media with cardholder data 
when no longer needed for business 
or legal reasons in accordance with all 
from Section 6  for the periodic media 
destruction policy examined  for this 
9.4.6.b Observe processes and 
interview personnel to verify that hard -
copy materials are cross -cut 
shredded, incinerated, or pulped such 
that cardholder data cannot be 
reconstructed.  Identify the evidence  reference number(s) 

9.4.6.c Observe storage containers 
used for materials that contain 
information to be destroyed to verify 
that the containers are secure.  Identify the evidence reference number(s) 
the storage cont ainers used for 
materials that contain information to be 
destroyed  for this testing procedure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 300 
9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the followi ng:  
• The electronic media is destroyed.  
• The cardholder data is rendered unrecoverable so that it cannot be reconstructed.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 301 
9.4.7.a Examine the periodic media 
electronic media when no longer 
needed for business or legal reasons 
destruction policy examined for this 
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 
the media destruction process for this 

9.5 Point -of-interaction (POI) devices are protected from tampering and unauthorized substitution.  
9.5.1 POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected fr om tampering and 
unauthorized substitution, inc luding the following:

unauthorized substitution, inc luding the following:  
• Maintaining a list of POI devices.  
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.  
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 302 
☐ ☐ ☐ ☐ 
was used. 

was used. 
9.5.1 Examine documented policies 
from Section 6  for policies and 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 303 
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.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 304 
9.5.1.1.a Examine the list of POI 
devices to verify it includes all 
from Section 6  for all lists of POI devices 
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) 
the POI devices and device locations for 
9.5.1.1.c  Interview personnel to verify 
the list of POI devices is updated 
when devices are added, relocated, 
decommissioned, etc.  Identify the evidence reference number(s) 

9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 305 
was used. 
9.5.1.2.a Examine documented 
defined for periodic inspections of POI 
device surfaces to detect tampering

device surfaces to detect tampering 
and unauthorized substitution.  Identify the evidence reference number(s) 
9.5.1.2.b Interview responsible 
personnel and observe inspection 
processes to verify:  
• Personnel are aware of 
procedures for inspecting 
devices.  
• All devices are periodically 
inspected for evidence of 
tampering and unauthorized 
substitution.  Identify the evidence reference number(s)

devices.  
substitution.  Identify the evidence reference number(s) 
from Section 6  for all intervie w(s) 
the inspection processes for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 306 
9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is 
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 . 
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 307 
9.5.1.2.1.a Examine the entity’s 
frequency of periodic POI device 
inspections and type of inspections 
performed to verify the risk analysis 
was performed in accordance with all 
9.5.1.2.1.b Examine documented 
results of periodic device inspec tions 
the frequency and type of POI device 
inspections performed match what is 
analysis conducted for this 
from Section 6  for the documented

results of periodic device inspections 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 308 
9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:  
• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot 
devices.  
• Procedures to ensure devices are not installed, replaced, or returned without verification.  
• Being aware of suspicious behavior around devices.  
• Reporting suspicious behavior and indications of device tampering  or substitution to appropriate personnel.  
☐ ☐ ☐ ☐ 

devices.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 309 
9.5.1.3.a Review training materials for 
personnel in POI environments to 
verify they include all elements 
from Section 6  for all training materials 
9.5.1.3.b Interview personnel in POI 
environments to verify they have 
received training and know the 
procedures for all elements specified 
in this requirement.  Identify the evidence r eference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 310 
Regularly Monitor and Test Networks 
10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and docum ented.  
10.1.1 All security policies and operational procedures that are identified in Requirement 10 are:  
• In use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 311 
was used. 
10.1.1 Examine documentation and 
10 are managed in accordance with

10 are managed in accordance with 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 312 
10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and underst ood. 
☐ ☐ ☐ ☐ 
was used. 

was used. 
10.1.2.a Examine documentation to 
responsibilities for performing Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 313 
activities in Requirement 10 are 
documented and assigned.  
10.1.2.b Interview personnel with 
in Requirement 10 to verify that roles 
defined and are understood.  Identify the ev idence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 314 
10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.  
10.2.1 Interview the system administrator and examine system configurations to verify that audit logs are enabled  and active for all system components.  
☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 315 
10.2.1 Interview the system 
administrator and examine system 
configurations to verify that audit logs 
are enabled and active for all system 
from Section 6  for al l interview(s)  
10.2.1.1 Audit logs capture all individual user access to cardholder data.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 316 
was used. 
10.2.1.1 Examine audit log 
configurations and log data to verify 
that all individual user access to 
cardholder data is logged.  Identify  the evidence reference number(s)

cardholder data is logged.  Identify  the evidence reference number(s) 
from Section 6  for all audit log 
from Section 6  for all log data examined 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 317 
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.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
10.2.1.2 Examine audit log 
configurations and log data to verify Identify the evidence reference number(s)

configurations and log data to verify Identify the evidence reference number(s) 
from Section 6  for all audit log <Enter Response Here >

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 318 
that all actions taken by any individual 
with administrative access, including 
any interactive use of application or 
system accounts, are logged.  configurations  examined for this testing 
10.2.1.3 Audit logs capture all access to audit logs.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 319 
10.2.1.3 Examine audit log 
that access to all audit logs is 
captured.  Identify the evidence reference number(s) 
for this  testing procedure.  <Enter Response Here>  
10.2.1.4 Audit logs capture all invalid logical access attempts.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 320 
10.2.1.4 Examine audit log 
that invalid logical access attempts 
are captured.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 321 
10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to:  
• Creation of new accounts.  
• Elevation of privileges.  
• All changes, additions, or deletions to accounts with administrative access.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 322 
10.2.1.5 Examine audit log 
that changes to identification and 
authentication credentials are 
captured in accordance with all 
10.2.1.6 Audit logs capture the following:  
• All initialization of new audit logs, and  
• All starting, stopping, or pausing of the existing audit logs.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 323 
Note: The use of Compensating Controls must also be documented in Appendix C . <Enter Response Here>  
10.2.1.6 Examine audit log 
that all elements specified in this 
requirement are captured.  Identify the evidence reference number(s) 

10.2.1.7 Audit logs capture all creation and deletion of system -level objects.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 324 
was used. 
10.2.1.7 Examine audit log 
that creation and deletion of system 
level objects is captured.  Identify the evidence reference number(s)

level objects is captured.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 325 
10.2.2 Audit logs record the following details for each auditable event:  
• User identification.  
• Type of event.  
• Date and time.  
• Success and failure indication.  
• Origination of event.  
• Identity or name of affected data, system component, resource, or service (for example, name and protocol).  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 326 
10.2.2 Interview personnel and 
examine audit log configurations and 
log data to verify that all elements 
specified in this requirement are 
included in log entries for each 
auditable event (from 10.2.1.1 through 
10.2.1.7).  Identify the evidence reference number(s) 
configurations examined for this testing

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 327 
10.3 Audit logs are protected from destruction and unauthorized modifications.  
10.3.1 Read access to audit logs files is limited to those with a job -related need.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 328 
10.3.1 Interview system 
administrators and examine system 
configurations and privileges to verify 
that only individuals with a job- related 
need have read access to audit log 
files. Identify the evidence reference number(s) 
configurations and privileges  examined 
10.3.2 Audit log files are protected to prevent modifications by individuals.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 329 
was used. 
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

modifications by individuals via 
access control mechanisms, physical 
segregation, and/or network 
segregation.  Identify the evidence reference number(s)  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 330 
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.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 331 
10.3.3 Examine backup configurations 
or log files to verify that current 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.  Identify the evidence reference number(s) 
from Section 6  for all backup 
configurations or log files  examined for 
10.3.4 File integrity monitoring or change -detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating 
alerts.  
☐ ☐ ☐ ☐ 

alerts.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 332 
10.3.4 Examine system settings, 
monitored files, and results from 
monitoring activities to verify the use 
of file integrity monitoring or change-
detection software on audit logs.  Identify the evidence reference number(s) 
from Section 6  for all monitored files  

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 333 
10.4 Audit logs are reviewed to identify anomalies or suspicious activity.  
• 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 server s). 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 334 
10.4.1.a Examine security policies 
processes are defined for reviewing 
requirement at least once daily.  Identify the evidence reference number(s) 
from Section 6  for all security policies 
and procedures  examined for this testing 
10.4.1.b  Observe processes and 
interview personnel to verify that all 
elements specified in this requirement 
are reviewed at least once daily  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 335 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 336 
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 
10.4.2  Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 337 
10.4.2.a Examine security policies 
logs of all other system components 
periodically.  Identify the evidence reference number(s) 
10.4.2.b  Examine documented results 
of log reviews and interview personnel 
to verify that log reviews are

to verify that log reviews are 
performed periodically.  Identify the evidence reference number(s) 
of log reviews  examined for this testing 
Identify the evid ence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 338 
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 entit y’s targeted risk 
analysis, which is performed according to all elements specified in Requirement 12.3.1  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 339 
10.4.2.1.a Examine the entity’s 
frequency of periodic log reviews for 
all other system components (not 
defined in Requirement 10.4.1) to 
verify the risk analysis was performed 
specified at Requirement 12.3.1.  Identify the evidence reference number(s) 
risk analysis examined f or this testing 
10.4.2.1.b  Examine documented 
results of periodic log reviews of all 
other system components (not defined 
in Requirement 10.4.1) and interview 
personnel to verify log reviews are 
performed at the frequency specified 
in the entity’s targeted risk analysis 
performed for this requirement.  Identify the evidence reference number(s)

results of all other system components 
(not defined in Requirement 10.4.1)  
10.4.3 Exceptions and anomalies identified during the review process are addressed.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 340 
was used. 
10.4.3.a Examine security policies 
processes are defined for addressing 
exceptions and anomalies identified

exceptions and anomalies identified 
during the review process.  Identify the evidence reference number(s) 
10.4.3.b Observe pr ocesses and 
interview personnel to verify that, 
when exceptions and anomalies are 
identified, they are addressed.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 341 
10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysi s. 
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 342 
10.5.1.a Examine documentation to 
verify that the following is defined: 
• Audit log retention policies.  
• Procedures for retaining audit log 
history for at least 12 months, 
with at least the most recent three 
months immediately available 
online.  Identify the evidence reference number(s) 
10.5.1.b Examine configurations of 
audit log history, interview personnel 
and examine audit logs to verify that 
audit logs history is retained for at 
least 12 months.  Identify the evidence reference number(s) 

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) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 343 
10.6 Time -synchronization mechanisms support consistent time settings across all systems.  
10.6.1 System clocks and time are synchronized using time -synchronization technology.  
☐ ☐ ☐ ☐ 
was used. 

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 344 
10.6.1 Examine system configuration 
settings to verify that time-
synchronization technology is 
implemented and kept current.  Identify the evidence reference number(s) 
• 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.

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

☐ ☐ ☐ ☐ 
was used. <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 345 
Note:  The use of Customized Approach must also be documented in Appendix E . 
10.6.2 Examine system configuration 
settings for acquiring, distributing, and 
storing the correct time to verify the 
settings are configured in accordance 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 346 
10.6.3 Time synchronization settings and data are protected as follows:  
• Access to time data is restricted to only personnel with a business need.  
• Any changes to time settings on critical systems are logged, monitored, and reviewed.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 347 
10.6.3.a Examine system 
configurations and time -
synchronization settings to verify that 
access to time data is restricted to 
only personnel with a business need.  Identify the evidence reference number(s) 
synchronization settings  examined for 
10.6.3.b  Examine system 
configurations and time 
synchronization settings and logs and 
observe processes to verify that any 
changes to time settings on critical 
systems are logged, monitored, and 
reviewed.  Identify the evidence reference number(s) 
configurations time synchronization 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 348 
10.7 Failures of critical security control systems are detected, reported, and responded to promptly.  
10.7.1 Additional requirement for service providers only : Failures of critical security control systems are detected, alerted, and addressed promptly, 
including but not limited to failure of the following critical security control systems:  
• Network security controls.  
• IDS/IPS.  
• FIM.  
• 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.  
☐ ☐ ☐ ☐ 

• IDS/IPS.  
• FIM.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 349 
was used. 
10.7.1.a Additional testing 
assessments only:  Examine 
documentation to verify that 
processes are defined for the prompt

processes are defined for the prompt 
detection and addressing of failures of 
critical security control systems, 
including but not limited to failure of all 
10.7.1.b Additional testing 
assessments only:  Observe 
detection and alerting processes and 
failures of critical security control 
systems are detected and reported,

systems are detected and reported, 
and that failure of a critical security 
control results in the generation of an 
alert.  Identify the evidence reference number(s) 
from Section  6 for all observation(s) of 
detection and alerting processes 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 350 
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:  
• IDS/IPS. 
• Change- detection mechanisms.  
• Audit log review mechanisms.  
• Automated security testing tools (if used).  
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 and 
will supersede Requirement 10.7.1.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 351 
was used. 
10.7.2.a Examine documentation to 
the prompt detection and addressing 
of failures of critical security control 
systems, including but not limited to

systems, including but not limited to 
failure of all elements specified in this 
10.7.2.b  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)

the generation of an alert.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 352 
10.7.3 Failures of any critical security controls 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.  
Note:  This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31

Note:  This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31 
March 2025 , after which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 353 
10.7.3.a  Examine documentation and 
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 refer ence number(s) 

10.7.3.b Examine records to verify 
that failures of critical security control 
systems are documented to include:  
• Identification of cause(s) of the 
failure.  
• Duration (date and time start and 
end) of the security failure.  
• Details of the remediation 
required to address the root 
cause.  Identify the evidence reference number(s) 
from Section 6  for all records  examined 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 354 
Requirement 11: Test Security of Systems and Networks Regularly  
11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.  
11.1.1 All security policies and operational procedures that are identified in Requirement 11 are:  
• In use.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 355 
11.1.1 Examine documentation and 
procedures are managed in 

11.1.2 Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 356 
was used. 
11.1.2.a Examine documentation to 
activities in Requirement 11 are

11.1.2.b Interview personnel with 
in Requirement 11 to verify that roles 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 357 
11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.  
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 358 
11.2.1.a Examine policies and 
defined for managing both authorized 
and unauthorized wireless access 
points with all elements specified in 
11.2.1.b  Examine the 
methodology(ies) in use and the 
resulting documentation, and 
interview personnel to verify

processes are defined to detect and 
identify both authorized and 
unauthorized wireless access points 
from Section 6  for the methodology(ies) 
in use and resulting documentation 
11.2.1.c  Examine wireless

11.2.1.c  Examine wireless 
assessment results and interview 
personnel to verify that wireless 
assessments were conducted in 
assessment results examined for this 
11.2.1.d  If automated monitoring is

11.2.1.d  If automated monitoring is 
used, examine configuration settings 
to verify the configuration will 
generate alerts to notify personnel.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 359 
11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 360 
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.  Identify the evidence reference number(s) 
 
11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.  
11.3.1 Internal vulnerability scans are performed as follows:  
• At least once every three months.  
• High-risk and critical vulnerabilities (per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• High-risk and critical vulnerabilities (per 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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 361 
☐ ☐ ☐ ☐ 
used . 
was used.

used . 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 362 
11.3.1.a Examine internal scan report 
results from the last 12 months to 
verify that internal 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 internal scan report 
results examined for this testing procedure.  <Enter Response Here>  
11.3.1.b Examine internal scan report 
results from each scan and rescan run 
in the last 12 months to verify that all 
high-risk and critical vulnerabilities 
(identified in PCI DSS Requirement 
6.3.1) are resolved.  Identify the evidence reference number(s) 
from Section 6  for all internal s can report 
11.3.1.c Examine scan tool 
configurations and interview

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 
Identify the evidence refe rence number(s) 
from Section 6  for all interview(s)  conducted 
11.3.1.d Interview responsible 
personnel to verify that the scan was 
performed by a qualified internal

performed by a qualified internal 
resource(s) or qualified external third 
party and that organizational 
independence of the tester exists.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 363 
11.3.1.1 All other applicable vulnerabilities (those not ranked as high -risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are 
• 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.  
• Rescans are conducted as needed.  
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 asse ssment.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
used . 
was used.

used . 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 364 
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 or critical per the entity’s 
vulnerability risk rankings at 
Requirement 6.3.1) to verify the risk 
with all elements specified at 
from Section 6  for the entity’s targeted risk 
analysis examined for this testing pr ocedure.  <Enter Response Here>  
11.3.1.1.b  Interview responsible 
personnel and examine internal scan 
report results or other documentation 
to verify that all other applicable 
vulnerability risk rankings at

Requirement 6.3.1) are addressed 
based on the risk defined in the 
entity’s targeted risk analysis, and that 
the scan process includes rescans as 
needed to confirm the vulnerabilities 
have been addressed.  Identify the evidence re ference number(s) 
results or other documentation  examined for

results or other documentation  examined for 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 365 
11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows:  
• Systems that are unable to accept credentials for authenticated scanning are documented.  
• Sufficient privileges  are used for those systems that accept credentials for scanning.  
• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.  
Note:  This requirement is a best practice until 31 March 2025, a fter which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
used . 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 366 
11.3.1.2.a Examine scan tool 
configurations to verify that 
authenticated scanning is used for 
internal scans, with sufficient 
privileges, for those systems that 
accept credentials for scanning.  Identify the evidence reference number(s) 
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 

11.3.1.2.c  If accounts used for 
authenticated scanning can be used 
for interactive login, examine the 
accounts and interview personnel to 
verify the accounts are managed 
following all elements specified in 
Requirement 8.2.2.  Identify the evidence reference number(s) 
from Section 6  for all accounts examined for 

11.3.1.2.d Examine documentation to 
verify that systems that are unable to 
accept credentials for authenticated 
scanning are defined.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 367 
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). 
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
used . 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 368 
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 
11.3.1.3.b Interview personnel and 
examine internal scan and rescan 
reports to verify that internal scans 
were performed after significant 
changes and that high-risk and critical 
vulnerabilities as defined in 
Requirement 6.3.1 were resolved.  Identify the evidence reference number(s)

Requirement 6.3.1 were resolved.  Identify the evidence reference number(s) 
from Section 6  for all internal scan and 
rescan reports examined for this testing 
11.3.1.3.c Interview personnel to 
verify that internal scans are 
independence of the tester exists.  Identify the evidence reference number(s)

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 369 
• 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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 370 
Testing Proc edures  Reporting Instructions  Reporting Details:  
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  
11.3.2.b  Examine the ASV scan 
report from each scan and rescan run 
in the last 12 months to verify that 
vulnerabilities are resolved and the 
ASV Program Guide requirements for 
a passing scan are met.  Identify the evidence reference number(s) 
from Section 6  for all ASV scan report results 
11.3.2.c Examine the ASV scan 
reports to verify that the scans were 
completed by a PCI SSC Approved

completed by a PCI SSC Approved 
Scanning Vendor (ASV).  Identify the evidence reference number(s) 
11.3.2.1 External vulnerability scans are performed after any significant change as follows:  
• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.  

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 371 
used . 
was used. 
11.3.2.1.a Examine change control 
documentation and external scan 
components were scanned after any

was used. 
from Section 6  for all change control  
from Section 6  for all external scan reports 
11.3.2.1.b Interview personnel and 
examine external scan and rescan 
reports to verify that external scans 
changes and that vulnerabilities

changes and that vulnerabilities 
scored 4.0 or higher by the CVSS 
were resolved.  Identify the evidence reference number(s) 
from Section 6  for all external scan and 
11.3.2.1.c  Interview personnel to 
verify that external scans are 

resource(s) or qualified external third Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 372 
independence of the tester exists.  
 
11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.  
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.

• 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.  
• D ocumented 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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 373 
was used. 
11.4.1 Examine documentation and 
interview personnel to verify that the 
penetration-testing methodology 
defined, documented, and 
implemented by the entity includes all

implemented by the entity includes all 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 374 
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  
• Organizational independence of the test er exists (not required to be a QSA or ASV)  
☐ ☐ ☐ ☐ 
If “Yes”, Identify  the aspect(s) of the requirement where the Customized Approach

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 375 
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 
from Section 6  for the scope of work  
Identify the ev idence reference number(s) 
from Section 6  for the results from the 
most recent internal penetration test

most recent internal penetration test  
11.4.2.b Interview personnel to verify 
that the internal penetration test was 
resource or qualified external third-
independence of the tester exists (not 
required to be a QSA or ASV).  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 376 
11.4.3 External penetration testing is performed:  
• By a qualified internal resource or qualified external third party  
• Organizational independence of the tester exists (not required to be a QSA or ASV)  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 377 
11.4.3.a Examine the scope of work 
external penetration test to verify that 
penetration testing is performed 
according to all elements specified in 
most recent  external penetration test 
11.4.3.b Interview personnel to verify 
that the external penetration test was 
independence of the tester exists (not

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.  

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 378 
was used. 
11.4.4 Examine penetration testing 
results to verify that noted exploitable 
vulnerabilities and security 
weaknesses were corrected in 

from Section 6  for all penetration testing 
results examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 379 
11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as f ollows:  
• 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 and effective, and isolate the CDE from all out -of-scope systems  
• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3)  
• Performed by a qualified internal resource or qualified external third party  

☐ ☐ ☐ ☐ 
was used.

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 380 
11.4.5.a Examine segmentation 
controls and review penetration-
testing methodology to verify that 
penetration-testing procedures are 
defined to test all segmentation 
methods in accordance with all 
from Section 6  for all segmentation 
from Section 6  for the penetration testing

from Section 6  for the penetration testing 
methodology  examined for this testing 
11.4.5.b Examine the results from the 
most recent penetration test to verify 
the penetration test covers and 
addresses all elements specified in 
from Section 6  for all results from the 
most recent penetration test  exam ined 
11.4.5.c Interview personnel to verify 
that the test was performed by a

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).  Identify the evidence reference number(s) 
conducted for this testing procedure.  <Enter Response Her e>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 381 
11.4.6 Additional requirement for service providers only:  If segmentation is used to isolate the CDE from other networks, penetration tests are performed 
on segmentation controls as follows:  
• At least once every six 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 and effective, and isolate the CDE from all out -of-scope systems.  
• Confirming effectiv eness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).  
• Performed by a qualified internal resource or qualified external third party.  
• Organizational independence of the tester exists (not required to be a Q SA or ASV).

• Organizational independence of the tester exists (not required to be a Q SA or ASV).  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 382 
11.4.6.a Additional testing 
assessments only:  Examine the 
results from the most recent 
penetration test to verify that the 
penetration covers and addresses all 
most recent penetration test  examined 
11.4.6.b Additional testing 
procedure for service provider

assessments only:  Interview 
personnel to verify that the test was 
resource or qualified external third 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 383 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 384 
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 
 
11.5 Network intrusions and unexpected file changes are detected and responded to.  
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.

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 385 
was used. 
11.5.1.a Examine system 
configurations and network diagrams 
to verify that intrusion-detection and/or 
intrusion -prevention techniques are in 
place to monitor all traffic:

place to monitor all traffic:  
• At the perimeter of the CDE.  
• At critical points in the CDE.  Identify the evidence reference number(s) 
11.5.1.b Examine system 
intrusion -detection and/or intrusion-
prevention techniques alert personnel

prevention techniques alert personnel 
of suspected compromises.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 386 
11.5.1.c Examine system 
documentation to verify intrusion-
detection and/or intrusion-prevention 
techniques are configured to keep all 
engines, baselines, and signatures up 
to date.  Identify the evidence reference number(s) 
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.

☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 387 
11.5.1.1.a Additional testing 
documentation and configuration 
settings to verify that methods to 
detect and alert on/prevent covert 
malware communication channels are 
in place and operating.  Identify the evidence reference number(s) 
from Section 6  for all documentat ion 
11.5.1.1.b Additional testing

11.5.1.1.b Additional testing 
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 
11.5.1.1.c Additional testing 
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 n umber(s) 
processes conducted for this testing 

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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 388 
Assessment Findin gs 
☐ ☐ ☐ ☐ 
was used. 

was used. 
11.5.2.a Examine system settings, 
of a change-detection mechanism.  Identify the evidence reference number(s) 

from Section 6  for all results from <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 389 
testing procedure.  
11.5.2.b  Examine settings for the 
change-detection mechanism to verify 
it is configured in accordance with all 
elem ents specified in this 
from Section 6  for all settings for the 
change -detection mechanism examined 
 
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the 
contents of payment pages as received by the consumer browser.

contents of payment pages as received by the consumer browser.  
• The mechanism is configured to evaluate the received HTTP header and payment page.  
• The mechanism functions are performed as follows:  
– At least once every seven days  
OR 
– 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).  

OR 
12.3.1).  
☐ ☐ ☐ ☐ 
Assessment Findings  in the ROC Template Instructions.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 390 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 391 
11.6.1.a Examine system settings, 
monitored payment pages, and results 
from monitoring activities to verify the 
use of a change- and tamper -
detection mechanism.  Identify the evidence reference number(s) 
examined for this testing procedure.  <Enter Resp onse Here>  
from Section 6  for all monitoring 
activities examined for this testing 
11.6.1.b Examine configuration 
settings to verify the mec hanism is 

settin gs examined for this testing 
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 
risk analysis examined for this testing

11.6.1.d Examine configuration 
settings and interview personnel to 
verify the mechanism functions are 
performed either:  
• At least once every seven days  
OR 
• At the frequency defined in th e 
entity’s targeted risk analysis 

OR 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 392 
Maintain an Information Security Policy 
12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information as sets is known and current.  
12.1.1  An overall information security policy is:  
• Established.  
• Published.  
• Disseminated to all relevant personnel, as well as to relevant vendors and business partners.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 393 
was used. 
12.1.1 Examine the information 
security policy and interview 
personnel to verify that the overall 
information security policy is managed 
in accordance with all elements

from Section 6  for the information 
security policy examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 394 
• Reviewed at least once every 12 months.  
• Updated as needed to reflect changes to business objectives or risks to the environment.  
☐ ☐ ☐ ☐ 
was used. 
Validation Method – Defined Ap proach

was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 395 
12.1.2 Examine the information 
responsible personnel to verify the 
policy is managed in accordance with 
from Section 6  for all information 
security policies examined for this testing 
12.1.3 The securi ty policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of a nd acknowledge their 
information security responsibilities.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 396 
12.1.3.a Examine  the information 
security policy  to verify that they 
clearly define information security 
roles and responsibilities for all 
security policy  examined for this testing 
12.1.3.b  Interview perso nnel in 
various roles to verify they understand 
their information security 
responsibilities.  Identify the evidence reference number(s)

responsibilities.  Identify the evidence reference number(s) 
12.1.3.c  Examine documented 
evidence to verify personnel 
acknowledge their information security 
from Section 6  for al l documented 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 397 
12.1.4 Responsibility for information security is formally assigned to a Chief Information Security Officer or other information sec urity knowledgeable member of 
executive management.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 398 
12.1.4 Examine the information 
security polic y to verify that 
information security is formally 
assigned to a Chief Information 
Security Officer or other information 
security -knowledgeable member of 
executive management.  Identify the evidence reference number(s) 
security polic y examined for this testing 
 
12.2 Acceptable use policies for end -user technologies are defined and implemented.  
12.2.1 Acceptable use policies for end -user technologies are documented and implemented, including:  
• Explicit approval by authorized parties.  
• Acceptable uses of the technology.

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 399 
was used. 
12.2.1 Examine the acceptable use 
policies for end-user technologies and 
verify processes are documented and 
implemented in accordance with all

from Section 6  for all acceptable use 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 400 
12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed.  
12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be perfor med periodically) is 
• Identification of the assets being protected.  
• Identification of the threat(s) that the requirement is protecting against.  
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.  
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minim ize the likelihood of the threat 
being realized.

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

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 401 
was used. 
12.3.1 Examine documented policies 
and procedures to verify a process is 
defined for performing targeted risk 
analyses for each PCI DSS 
requirement that provides flexibility for

requirement that provides flexibility for 
how frequently the requirement is 
performed, and that the process 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 402 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 403 
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 
12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at leas t the following:  
• An up-to -date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.

• An up-to -date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.  
• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.  
• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 404 
was used. 
12.3.3 Examine documentation for 
cryptographic suites and protocols in 
use and interview personnel to verify 
the documentation and review is in 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 405 
12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following:  
• Analysis that the technologies continue to receive security fixes from vendors promptly.  
• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.  
• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a 
technology.  
• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors  have announced “end of 
life” plans.  

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 406 
12.3.4 Examine documentation for the 
review of hardware and software 
technologies in use and interview 
personnel to verify that the review is in 

12.4.1 Additional requirement for service providers only:  Responsibility is established by executive management for the protection of cardholder data and a 
PCI DSS compliance program to include:  
• Overal l accountability for maintaining PCI DSS compliance.  
• Defining a charter for a PCI DSS compliance program and communication to executive management.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 407 
☐ ☐ ☐ ☐ 
was used. 

was used. 
12.4.1 Additional testing procedure 
only:  Examine documentation to 
verify that executive management has 
established responsibility for the 
protection of cardholder data and a 
PCI DSS compliance program in 

specified in this requirement.  Identi fy the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 408 
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:  
• Daily log reviews.  
• Configuration reviews for network security controls.  
• Applying configuration standards to new s ystems.  
• Responding to security alerts.  
• Change- management processes.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 409 
12.4.2.a Additional testing 
assessments only:  Examine policies 
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 
from Section 6  for all policies and

12.4.2.b Additional testing 
responsible personnel  and examine 
records of reviews to verify that 
reviews are performed:  
• By personnel other than those 
responsible for performing the 
given task.  Identify the evidence reference number(s) 

from Section 6  for all records of reviews 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 410 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 411 
If “Yes”, Identify the aspect(s) of the requirement where the Compensating 
12.4.2.1 Additional testing 
documentation from the reviews 
conducted in accordance with PCI 
DSS Requirement 12.4.2 to verify the 
documentation includes all elements 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 412 
12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and k ept current.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 413 
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 reference number(s) 
from Section 6  for the inventory  examined 
12.5.1.b Interview personnel to verify 
the inventory is kept current.  Identify the evidence reference number(s) 
conducted for this testing procedure.  <Enter Response  Here>  
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:

minimum, the scoping validation includes:  
• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptanc e 
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 locati ons outside of the currently

• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locati ons outside of the currently 
defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) f ile 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.  
• Identifying all connections from third-party entities with access to the CDE.

scope.  
• Identifying all connections from third-party entities with access to the CDE.  
• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the 
CDE are included in scope.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 414 
☐ ☐ ☐ ☐ 
was used. 

was used. 
12.5.2.a Examine documented results 
of scope reviews and interview 
personnel to verify that the reviews 
are performed:  
• At least once every 12 months.  
• After significant changes to the in-
scope environment.  Identify the evidence reference number(s) 

examined  for this testing procedure.  <Enter Response Here>  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 415 
12.5.2.b Examine documented results 
of scope reviews performed by the 
entity to verify that PCI DSS scoping 
confirmation activity includes all 
of scope reviews examined for this 
12.5.2.1 Additional requirement for service providers only:  PCI DSS scope is documented and confirmed by the entity at least once every six months and 
upon significant change to t he in -scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 416 
12.5.2.1.a Additional testing 
documented results of scope reviews 
reviews per Requirement 12.5.2 are 
performed:  
• At least once every six months, 
and  
• After significant changes  Identify the evidence reference number(s) 

and  
12.5.2.1.b Additional testing 
to verify that scoping validation 
includes all elements specified in 
Requirement 12.5.2.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 417 
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.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 418 
12.5.3.a Additional testing 
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.  Identify the evidence reference number(s) 
procedures examined for this testing 
12.5.3.b Additional testing 
documentation (for example, meeting 
minutes) and interview responsible 
personnel to verify that significant 
changes to organizational structure 
resulted in documented reviews that 
included all elements specified in this 
requirement, with results

requirement, with results 
communicated to executive 
management.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 419 
12.6 Security awareness education is an ongoing activity.  
12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy an d procedures, and their 
role in protecting the cardholder data.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 420 
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 
12.6.2 The security awareness program is:  
• Reviewed at least once every 12 months, and  
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity's CDE, or the inf ormation provided to 
personnel about their role in protecting cardholder data.

personnel about their role in protecting cardholder data.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 421 
12.6.2 Examine security awareness 
program content, evidence of reviews, 
the security awareness program is in 
from Section 6  for all security awareness 
program content examined for this 

from Section 6  for all evidence of reviews 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 422 
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.  
• Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 423 
12.6.3.a Examine security awareness 
program records to verify that 
personnel attend security awareness 
training upon hire and at least once 
every 12 months.  Identify the evidence reference number(s) 
program  records  examined for this 
12.6.3.b Examine security awareness 
program materials to verify the 
program includes multiple methods of 
communicating awareness and 
educating personnel.  Identify the evidence reference number(s) 
program materials examined for this 
testing procedure.  <Enter Response Here > 
12.6.3.c Interview personnel to verify 
they have completed awareness 
training and are aware of their role in

training and are aware of their role in 
protecting cardholder data.  Identify the evidence reference number(s) 
12.6.3.d Examine security awareness 
program materials and personnel 
acknowledgments to verify that 
personnel acknowledge at least once 
every 12 months that they have read 
and understand the information 
security policy and procedures.  Identify the evidence reference number(s) 
program materials examined for this

from Section 6  for all personnel 
acknowledgments examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 424 
12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:  
• Phishing and related attacks.  
• Social engineering.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 425 
12.6.3.1 Examine security awareness 
training content to verify it includes all 
training content examined for this testing 
12.6.3.2 Security awareness training includes awareness about the acceptable use of end -user technologies in accordance with Requirement 12.2.1.  
Note:  This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.   
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 426 
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.  Identify the evidence reference number(s) 
 
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.  
☐ ☐ ☐ ☐ 
Describe why the assessment finding was selected.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 427 
table in Assessment Findings  in the ROC Template Instructions.  
was used. 
12.7.1 Interview responsible Human

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.  Identify the evidence reference number(s) 
 
12.8 Risk to information assets associated with third -party service provider (TPSP) relationships is managed.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 428 
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 mainta ined, 
including a description for each of the services provided.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
12.8.1.a Examine policies and 
procedures to verify that processes Identify the evidence reference numb er(s)

procedures to verify that processes Identify the evidence reference numb er(s) 
from Section 6  for all policies and <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 429 
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.  procedures  examined for this testing 
12.8.1.b Examine documentation to 
verify that a list of all TPSPs is 
maintained that includes a description 
of the services provided.  Identify the evidence reference number(s) 
exam ined for this testing procedure.  <Enter Response Here>  
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 are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.  
• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs po ssess or otherwise 
store, process, or transmit on behalf of the entity, or to the extent that they could impac t the security of the entity's CDE.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 430 
12.8.2.a Examine policies and 
are defined to maintain written 
agreements with all TPSPs in 
12.8.2.b Examine written agreements 
with TPSPs to verify they are 
maintained in accordance with all 
elements as specified in this

elements as specified in this 
from Section 6  for all written agreements 
12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.  
☐ ☐ ☐ ☐

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 431 
was used. 

was used. 
12.8.3.a Examine policies and 
are defined for engaging TPSPs, 
including proper due diligence prior to 
engagement.  Identify the evidence reference number(s) 
from Section 6  for al l policies and 
12.8.3.b Examine evidence and 
verify the process for engaging

verify the process for engaging 
TPSPs includes proper due diligence 
prior to engagement.  Identify the e vidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 432 
12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.  
☐ ☐ ☐ ☐ 
was used. 

was used. 
12.8.4.a Examine policies and 
procedures to verify that processes Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 433 
are defined to monitor TPSPs’ PCI 
DSS compliance status at least once 
every 12 months.  procedures  examined for this testing 
12.8.4.b Examine documentation and 
verify that the PCI DSS compliance 
status of each TPSP is monitored at 
least once every 12 month s. Identify the evidence reference number(s) 
12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any  that are shared 
between the TPSP and the entity.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 434 
12.8.5.a Examine policies and 
are defined to maintain information 
about which PCI DSS requirements 
are managed by each TPSP, which 
are managed by the entity, and any 
that are shared between both the 
TPSP and the entity.  Identify the evidence reference number(s) 
procedures  examined for this test ing 
12.8.5.b Examine documentation and

12.8.5.b Examine documentation and 
interview personnel to verify the entity 
maintains information about which 
PCI DSS requirements are managed 
by each TPSP, which are managed by 
the entity, and any that are shared 
between both entities.  Identify the evidence reference number(s) 
 
12.9 Third -party service providers (TPSPs) support their customers’ PCI DSS compliance.  
12.9.1 Additional requirement for service providers only:  TPSPs acknowledge in writing to customers that they are responsible for the security of account 
data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the 
customer’s CDE.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 435 
☐ ☐ ☐ ☐ 
was used. 

was used. 
12.9.1 Additional testing procedure 
only:  Examine TPSP policies, 
procedures, and templates used for 
written agreements to verify 
processes are defined for the TPSP to 
provide written acknowledgments to 
customers in accordance with all Identify the evidence reference number(s)

customers in accordance with all Identify the evidence reference number(s) 
from Section 6  for all TPSP policies, 
written agreements examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 436 
requireme nt. 
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 for any service the TPSP performs on behalf of customers (Requirement 12.8.4).  
• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the custo mer, including any shared 
responsibilities (Requirement 12.8.5).  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 437 
12.9.2 Additional testing procedure 
only:  Examine policies and 
defined for the TPSPs to support 
customers’ request for information to 
meet Requirements 12.8.4 and 12.8.5 
 
12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.  
12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The  plan includes, but is not 
limited to:

• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of 
payment brands and acquirers, at a minimum.  
• Incident response procedures with specific containment and mitigation activities for different types of incidents.  
• Business recovery and continuity procedures.  
• Data backup processes.  
• Analysis of legal requirements for reporting compromises.  
• Coverage and responses of all critical system components.

• Coverage and responses of all critical system components.  
• Reference or inclusion of incident response procedures from the payment brands.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 438 
Assessment Fi ndings  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 439 
12.10.1.a Examine the incident 
response plan to verify that the plan 
exists and includes at least the 
from Section 6  for all incident r esponse 
plans  examined for this testing procedure.  <Enter Response Here>  
12.10.1.b Interview personnel and 
examine documentation from 
previously reported incidents or alerts 
to verify that the documented incident 
response plan and procedures were 
followed.  Identify the evidence reference number(s) 

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 440 
was used. 
12.10.2 Interview personnel and 
review documentation to verify that, at 
least once every 12 months, the 
security incident response plan is:  
• Reviewed and updated as 
needed.

needed.  
• Tested, including all elements 
listed in Requirement 12.10.1.  Identify the evidence referen ce number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 441 
12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 442 
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.  Identify the evidence reference number(s) 
12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained  on their incident 
response responsibilities.  
In Place  Not Applicable  Not Tested  Not in Place

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 443 
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.  Identify the evidence reference number(s) 

12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which i s performed according to all 
elements specified in Requirement 12.3.1.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 444 
was used. 
12.10.4.1.a Examine the entity’s 
frequency of training for incident 
response personnel to verify the risk 
analysis was performed in accordance

12.10.4.1.b  Examine documented 
results of periodic training of incident 
response personnel and interview 
personnel to verify training is 
performed for this requirement.  Identify the evidence re ference number(s)

performed for this requirement.  Identify the evidence re ference number(s) 
from Section 6  for all documented results  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 445 
12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to:  
• Intrusion- detection and intrusion-prevention systems.  
• Change- detection mechanisms for critical files.  
• The change-and tamper -detection mechanism for payment pages. This bullet is a best practice until 31 March 2025, after which it will be required as part 
of Requirement 12.10.5 and must be fully considered during a PCI DSS assessment.  
• Detection of unauthorized wireless access points.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 446 
12.10.5 Examine documentation and 
observe incident response processes 
to verify that monitoring and 
responding to alerts from security 
monitoring systems are covered in the 
security incident response plan, 
including but not limited to the 
systems specified in this requirement.  Identify the evidenc e reference number(s) 
incident response processes for this 
12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developm ents.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 447 
12.10.6.a Examine policies and 
are defined to modify and evolve the 
security incident response plan 
according to lessons learned and to 
incorporate industry developments.  Identify the evidence reference number(s) 
12.10.6.b Examine the security 
incident response plan and interview 
responsible personnel to verify that

the incident response plan is modified 
and evolved according to lessons 
learned and to incorporate industry 
developments.  Identify the evidence reference number(s) 
from Section 6  for the security incident 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 448 
12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:  
• Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as 
applicable.  
• Identifying whether sensitive authentication data is stored with PAN.  
• Determining where the account data came from and how it ended up where it was not expected.  
• Remediating data leaks or process gaps that resulted in the account data being where it was not expected.  
Note:  This requirement is a best p ractice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.  
☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 449 
12.10.7.a Examine documented 
incident response procedures to verify 
that procedures for responding to the 
detection of stored PAN anywhere it is 
not expected to exist, ready to be 
initiated, and include all elements 
incident response procedures examined 
12.10.7.b Interview personnel and 
examine records of response actions 
to verify that incident response 
procedures are performed upon 
not expected.  Identify the evidence reference number(s) 

response actions  examined for this 
Appendix A  Additional PCI DSS Requirements 
A1 Additional PCI DSS Requirements for Multi -Tenant Service Providers 
A1.1 Multi -tenant service providers protect and separate all customer environments and data.  
A1.1.1 Logical separation is implemented as follows:  
• The provider cannot access its customers' environments without authorization.

• The provider cannot access its customers' environments without authorization.  
• Customers cannot access the provider's environment without authorization.  

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 450 
☐ ☐ ☐ ☐ 
was used. 

was used. 
A1.1.1 Examine documentation and 
system and network configurations 
logical separation is implemented in 

from Section 6  for all system and  
network configurations examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 451 
A1.1.2 Controls are implemented such that each customer only has permission to access its own cardholder data and CDE.  
☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 452 
A1.1.2.a  Examine documentation to 
verify controls are defined such that 
each customer only has permission to 
access its own cardholder data and 
A1.1.2.b Examine system 
configurations to verify that customers 
have privileges established to only 
access their own account data and 
A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.  

☐ ☐ ☐ ☐ 
was used.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 453 
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 
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.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 454 
A1.1.4  Examine the results from the 
that testing confirmed the 
effectiveness of logical separation 
controls used to separate customer 
environments.  Identify the evidence reference number(s) 
 
A1.2 Multi -tenant service providers facilitate logging and incident response for all customers.  
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 locations are clearly communicated to the owning customer.  
• Log data and availability is consistent with PCI DSS Requirement 10.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 455 
Assessment  Findings  
☐ ☐ ☐ ☐ 
was used. 

was used. 
A1.2.1 Examine documentation and 
system configuration settings to verify 
the provider has enabled audit log 
capability for each customer 
environment in accordance with all 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 456 
A1.2.2  Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspect ed or confirmed security 
incident for any customer.  
☐ ☐ ☐ ☐ 
was used. 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 457 
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) 
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.

• Customers can securely report security incidents and vulnerabilities to the provider.  
• The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 458 
A1.2.3 Examine documented 
verify that the provider has a 
mechanism for reporting and 
addressing suspected or confirmed 
security incidents and vulnerabilities, 

conducted for this testing proc edure.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 459 
A2 Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card -Present POS POI 
Terminal Connections  
A2.1 POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS exploits.  
A2.1.1 Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not 
susceptible to any known exploits for those protocols.  
☐ ☐ ☐ ☐ 

☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 460 
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.  Identif y the evidence reference number(s) 
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:

early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place that includes:  
• Descript ion of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of 
• 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.

• Overview of migration project plan to replace SSL/early TLS at a future date.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 461 
A2.1.2 Additional testing procedure 
only: Review the documented Risk 
Mitigation and Migration Plan to verify 
it includes all elements specified in 
from Section 6  for the documented Risk 
Mitigation and Migration P lan examined 
for this testing pr ocedure.  <Enter Response Here>

for this testing pr ocedure.  <Enter Response Here>  
A2.1.3  Additional  requirement for service providers only:  All service providers provide a secure service offering.  
☐ ☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 462 
A2.1.3 Additional testing procedure 
only:  Examine system configurations 
and supporting documentation to 
verify the service provider offers a 
secure protocol option for its service.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 463 
A3 Designated Entities Supplemental Validation (DESV)   
This Appendix applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of exi sting PCI DSS 
requirements.  
Entities that are required to validate to these requirements should ref er to the following documents for reporting:  
 PCI DSS v4.0 Supplemental Report on Compliance Template  - Designated Entities Supplemental Validation  
 PCI DSS v4.0 Supplemental Attestation of Compliance for Report on Compliance  - Designated Entities  Supplemental Validation  
These documents are available in the PCI SSC Document Library.  
 
Note that an entity is ONLY required to undergo an assessment according to this Appendix if instructed to do so by an acquirer or a payment 
brand.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 464 
Appendix B  Compensating Controls 
Compensating controls may be considered when an entity cannot meet a PCI DSS requirement explicitly as stated, due to legitimate and 
documented technical or business constraints but has sufficiently mitigated the risk associated with not meeting the requirement through 
implementation of other, or compensating, controls.  
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 Customize d

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

4. When evaluating “above and beyond” for compensating controls, consider the following:  
Note: All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS assessment. The 
effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented,  the surrounding 
security controls, and the configuration of the control. Entities should be aware that a given compensating control will not be effective in all 
environments.

a. Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under 
review. For example, passwords for non- console administrative access must be sent encrypted to mitigate the risk of intercepting 
cleartext administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex 
passwords, etc.) to compensate for the lack of encryp ted passwords, since those other password requirements do not mitigate the risk

passwords, etc.) to compensate for the lack of encryp ted passwords, since those other password requirements do not mitigate the risk 
of interception of cleartext passwords. Also, the other password controls are already PCI DSS requirements for the item under  review 
(passwords).  
b. Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area but are not required for the item under review.  
c. Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company i s 
unable to address a vulnerability that is exploitable through a network interface because a security update is not yet available from a

unable to address a vulnerability that is exploitable through a network interface because a security update is not yet available from a 
vendor, a compensating control could consist of controls that include all of the following: 1) internal network segmentation, 2) limiting 
network access to the vulnerable interface to only required devices (IP address or MAC address filtering), and 3) IDS/IPS mon itoring 
of all traffic destined to the vulnerable interface.  
5. Address the additional risk imposed by not adhering to the PCI DSS requirement.

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 465 
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 addr ess, per items 1- 6 above.  
To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the as sessment is 
complete. Additionally, compensating control results must be documented in the applicable re port for the assessment (for example, a Report

complete. Additionally, compensating control results must be documented in the applicable re port 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 submitted to the requesting organization.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 466 
Appendix C  Compensating Controls Worksheet 
Use this worksheet to document any instance where a compensating control is used to meet a PCI DSS defined requirement. Note that 
compensating controls must  also be documented at the corresponding PCI DSS requirement in Part II Findings and Observations . 
Note: Only entities that have legitimate and documented technological or business constraints can consider the use of compensating controls 
to achieve compliance.  
Required Number and Definition: <Enter Response Here>  
 Information Required  Explanation  
1. Constra ints Document the legitimate technical or business constraints 
precluding compliance with the original requirement.  <Enter Response Here>  
2. Definition of Compensating 
Controls  Define the compensating controls, explain how they address 
the objectives of the original control and the increased risk, if

the objectives of the original control and the increased risk, if 
any. <Enter Response Here>  
3. Objective  Define the objective of the original control (for example, the 
Customized Approach Objective).  <Enter Response Here>  
Identify the objective met by the compensating control ( note:  
this can be, but is not required to be, the stated Customized 
Approach Objective for the PCI DSS requirement ). <Enter Response Here>  
4. Identified Risk  Identify any additional risk posed by the lack of the original 
control.  <Enter Response Here>  
5. Validation of 
Compensating Controls  Define how the compensating controls were validated and

Compensating Controls  Define how the compensating controls were validated and 
tested.  <Enter Response Here>  
6. Maintenance  Define process(es) and controls in place to maintain 
compensating controls.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.   Page 467 
Appendix D  Customized Approach  
This approach is intended for entities that decide to meet a PCI DSS requirement’s stated Customized Approach Objective in a way that does 
not strictly follow the defined requirement. The customized approach allows an entity to take a strategic approach to meeting a requirement’s 
Customized Approach Objective, so it can determine and design the security controls needed to meet the objective in a manner unique for that organization.  
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 Temp late in 
Appendix E 1 of the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures .

Appendix E 1 of the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures . 
 Perform and document a targeted risk analysis (PCI DSS Requirement 12.3.2) for each customized control, including all information 
specified in the Targeted Risk Analysis Template in Appendix E2 of the Payment Card Industry Data Security Standard (PCI DSS) 
Requirements and Testing Procedures . 
 Perform testing of each customized control to prove effectiveness, and document testing performed, methods used, what was tested, 
when testing was performed, and results of testing in the controls matrix.

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 mat rix(es), targeted risk analysis, testing evidence, and evidence of customized control effectiveness to its 
assessor.  
The assessor  performing an assessment of customized controls must satisfy the following criteria:  
 Review the entity’s controls matrix(es),  targeted risk analysis, and evidence of control effectiveness to fully understand the customized

assessor.  
 Review the entity’s controls matrix(es),  targeted risk analysis, and evidence of control effectiveness to fully understand the customized 
control(s) and to verify the entity meets all Customized Approach documentation and evidence requirements.  
 Derive and document the appropriate testing procedures needed to conduct thorough testing of each customized control.  
 Test each customized control to determine whether the entity’s implementation 1) meets the requirement’s Customized Approach 
Objective and 2) results in an “in place” finding for the requir ement.

Objective and 2) results in an “in place” finding for the requir ement.  
 At all times, QSAs maintain independence requirements defined in the QSA Qualification Requirements. This means if a QSA is 
involved in designing or implementing a customized control, that QSA does not also derive testing procedures for, assess, or assist with 
the assessment of that customized control.  
 The entity and its assessor are expected to work together to ensure 1) they agree that the customized control(s) fully meets the customized approach objective, 2) the assessor fully understands the customized control, and 3) the entity understands the derived

 The entity and its assessor are expected to work together to ensure 1) they agree that the customized control(s) fully meets the customized approach objective, 2) the assessor fully understands the customized control, and 3) the entity understands the derived 
testing the assessor will perform.  
 Use of the customized approach must be completed by a QSA or ISA and documented in accordance with instructions in the Report  on 
Compliance (ROC) Template and fo llowing the instructions in the FAQs for use with PCI DSS v4.0 ROC Template available on the PCI 
SSC website.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 468 
 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

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.

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 469 
Appendix E  Customized Approach Template  
Use this template to document each instance where a customized control  is used to meet a PCI DSS requirement. Note that each use of the 
Customized Approach must  also be documented at the corresponding PCI DSS requirement  in Part II Findings and Observations . 
Requirement Number and Definition: <Enter Response Here>  
Identify  the customized control name / identifier  for each control used to 
meet the Customized Approach Objective.  
(Note : use the Customized Control name from  the assessed entity’s controls 
matrix)  <Enter Response Here>  
Describe  each  control used to meet the Customized Approach Objective.  
(Note : Refer to the Payment Card Industry Data Security Standard (PCI DSS) 
Requirements and Testing Procedures  for the Cu stomized Approach Objective)  <Enter Response Here>

Requirements and Testing Procedures  for the Cu stomized Approach Objective)  <Enter Response Here>  
Describe  how the control(s) meet the Customized Approach Objective.  <Enter Response Here>  
Identify  the Controls Matrix documentation  reviewed that supports a 
customized approach for this requirement.  <Enter Response Here>  
Identify  the Targeted Risk Analysis documentation  reviewed that supports 
the customized approach for this requirement.  <Enter Response Here>  
Identify  name(s) of the assessor(s) who attests that:  
• The entity completed the Controls Matrix including all information specified

• The entity completed the Controls Matrix including all information specified 
in the Controls Matrix Template in Appendix E1 of Payment Card Industry 
Data Security Standard (PCI DSS) Requirements and Testing Procedures  
and the results of the Controls Matrix support the customi zed approach for 
this requirement.  
• The entity completed the Targeted Risk Analysis including all information 
specified in the Targeted Risk Analysis Template in Appendix E2 of 
Payment Card Industry Data Security Standard (PCI DSS) Requirements 
and Testing Procedures , and that the results of the Risk Analysis support

and Testing Procedures , and that the results of the Risk Analysis support 
use of the customized approach for this requirement.  <Report Name(s) of Assessor(s) Here>  
Describe  the testing procedures derived and performed by the assessor to validate that the implement ed controls meet the Customized Approach 
Objective; for example, whether the customized control(s) is sufficiently robust to provide at least an equivalent level of protection as provided by the defined 
approach.

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

© 2006 - 2022 PCI Security Standards Council, LLC. All rights reserved.   Page 470 
<Assessor -derived testing 
procedure>  Identify  what was tested (for 
example, individuals interviewed, 
system components reviewed, 
processes observed, etc.)  
Note : all items tested must be 
uniquely identified.  <Enter Response Here>  
Identify  all evidence examined for this 
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 Objecti ve. <Enter Response Here>  
Document  the testing procedures derived and performed by the assessor to validate the controls are maintained to ensure ongoing effectiveness ; for 
example, how the entity monitors for control effectiveness and how control failures are detected, responded to, and the actions taken.

example, how the entity monitors for control effectiveness and how control failures are detected, responded to, and the actions taken.  
Note 2:  Add additional rows for each assess or-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.  
example, individuals interviewed,

controls are maintained to ensure 
ongoing eff ectiveness.  <Enter Response Here>

on Compliance – Service Providers  
Revision 1  
Publication Date:  December  2022

PCI DSS v4.0  Attestation of Compliance for Report on Compliance - Service Providers r1  December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page i 
 
Compliance – Service Providers 

PCI DSS  v4.0 Attestation of Compliance for Report on Compliance - Service Providers r1  December 2022  
This Attestation of Compliance  (AOC) must be completed as a declaration of the results of  the service provider’s 
Procedures  (“Assessment” ). Complete all sections. The service provider is responsible for ensuring that each section 
is completed by the relevant parties, as applicable. Contact the entity(ies) to which this AOC will be submitted for 
reporting and submission procedures.  

Part 1a. Assessed Entity   
Company main  website:        
assessor type,  enter  Not Applicable.  

Qualified Security Assessor  

Part 2a. Scope Verification   
Services that were INCLUDED in the scope of the A ssessment ( select  all that apply):  
Name of service(s) assessed:        
Type of service(s) assessed:  
Hosting Provider:  
 Applications / software  
 Hardware  
 Infrastructure / Network  
 Physical space (co-location)  
 Storage  
 Web-hosting services  
 Security services  
 3-D Secure Hosting Provider  
 Multi -Tenant Service  Provider  
 Other Hosting (specify):  
      Managed Services:  
 Systems security services  
 IT support  
 Physical security  
 Terminal Management System  
 Other services (specify):  
      
 Payment Processing:  
 POI / card present  
 Internet / e -commerce  
 MOTO / Call Center  
 ATM  
 Other processing (specify):

Infrastructure / Network  
 Storage  
 IT support  
      
 ATM  
 Other processing (specify):  
      
 Account Management   Fraud and Chargeback   Payment Gateway/Switch  
 Back -Office Services   Issuer Processing   Prepaid Services  
 Billing Management   Loyalty Programs   Records Management  
 Clearing and Settlement   Merchant Services   Tax/Government Payments  
 Network Provider  
 Others (specify):       
Note:  These categories are provided for assistance only and are not intended to limit or predetermine an entity’s

MOTO / Call Center  
 ATM  
      
Note:  These categories are provided for assistance only and are not intended to limit or predetermine an entity’s 
service description. If these categories do not apply to the assessed service, complete “Others.” If  it is not clear 
whether a category could apply to the assessed service, consult with the entity(ies) to which this AOC will be 
submitted .

Part 2a. Scope Verification  (continued)   
Services that are provided by the service provider but were NOT INCLUDED in the scope of the  
Assessment ( select  all that apply):  
Name of service(s) not assessed:        
Type of service(s) not assessed:  
 Hardware  
 Storage  
 3-D Secure Hosting Prov ider 
 IT support  
      
 Internet / e-commerce  
 ATM  

 Storage  
 IT support  
      
 ATM  
      
 Network Provider   
Provide a brief explanation  why any checked services 
were not included in the Assessment:        
 
Part 2b. Description of Role with Payment Cards  

Account Management   Fraud and Chargeback   Payment Gateway/Switch  
 
Describe how the business stores, processes, and/or 
transmits account  data.        
Describe how the business is otherwise involved in or 
has the ability to impact the security of its customers’ 
account  data.        
Describe s ystem components that could impact the 
security of account data.

Part 2 c. Description of Payment Card Environment  
(Refer to the “Segmentation” section of PCI DSS for guidance on segmentation)   Yes     No 
 
List all types of physical locations/facilities (for example, corporate offices, data centers, call centers  and mail

List all types of physical locations/facilities (for example, corporate offices, data centers, call centers  and mail 
rooms ) in scope  for this Assessment .  
Locations  
 (city, country)  
Example: Data centers  3 Boston, MA, USA

Part 2e. PCI SSC Validated Products and Solutions  
Does the entity use any item identified on any PCI SSC Lists of Validated Products and Solutions*?     
    Yes     No 
Provide the following information regarding each item the entity uses from PCI SSC's Lists of Validated 
Products and Solutions:  
validated Product  or 
Product or 
Reference 
Listing  

Product or 
Reference 
Listing  
* For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated 
products, solutions, and/or components, appearing on the PCI SSC website ( www.pcisecuritystandards.org) 
(for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Payment 
Applications (PA -DSS), Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS 
(SPoC) solutions, and Contactless Payments on COTS (CPoC) solutions).

(ROC Section 4.4 ) 
For the services being validated, does the entity have relationships with one or more third -
party service providers that:   
gateways, payment processors, payment service providers (PSPs , and off -site storage))   Yes    No 
• Manage system components included in the entity’s Assessment (for example, via 
management (SIEM), contact and call centers, web-hosting companies , and IaaS, PaaS, 
SaaS, and FaaS cloud providers )   Yes    No 
• Could impact the security of the entity’s CDE (for example, vendors providing support via

• Could impact the security of the entity’s CDE (for example, vendors providing support via 
remote access, and /or bespoke software developers ).  Yes    No 
If Yes:  
Name of Service Provider:  Description of Services Provided:  
            
Note:  Requirement 12.8 applies to all entities  in this list.

Part 2g.  Summary of Assessment  
PCI DSS 
Was Use d 
In Place  Not Applicable  Not Tested  Not in 
Controls  
Appendix A1:        

Note:  This is the last date that evidence was gathered, or observations were made.  YYYY -MM-DD 
If yes, for each testing activity below, indicate whether remo te assessment activities were 

Based on the results documented in the ROC noted above, each  signator y identified in any of Parts 3b-3d, as

 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 (Service 
Provider Company Name)  has demonstrated compliance with  all PCI DSS  requireme nts except those 
noted as Not Tested above .

noted as Not Tested above . 
marked as Not in Place, resulting in an overall NON -COMPLIANT  rating; thereby  (Service Provider 
Company Name)  has not demonstrated compliance with PCI DSS  requirements . 
An entity submitting this form with a Non-Compliant status may be required to complete the Action Plan 
in Part 4 of this document. Co nfirm with the entity to which this AOC will be submitted before 
completing Part 4.

COMPLIANT BUT WITH LEGAL EXCEPTION rating;  thereby (Service Provider Company Name)  has 
demonstrated  compliance with all PCI DSS  requirements except those noted as Not Tested above or 
as Not in Place due to a legal restriction.

as Not in Place due to a legal restriction.    
If selected, complete the following:  

Part 3a. Service Provider Acknowledgement  
 PCI DSS co ntrols will be maintained at all times , as applicable to the entity’s  environment.  
 
Part 3b. Service Provider Attestation  
 
Signature of Service Provider Executive Officer  Date: YYYY -MM-DD 
Service Provider Executive Officer Name:       Title:       
 
Assessment, indicate the role performed:   QSA performed testing procedures.

If selected, describe all role(s) performed:        
 
Signature of Duly Authorized Officer of QSA Company  Date: YYYY -MM-DD 
 
Part 3d. PCI SSC Internal Security Assessor (ISA) Involvement  
Assessment , indicate the role performed:   ISA(s) performed testing procedures.

QSA provided other assistance.  
 
© 2006 - 2022 PCI Security Standards Council, LLC . All rights reserved.  Page 11 
Only complete Part 4 upon request of the entity to which this AOC will be submitted, and only if the Assessment 
each requirement below. For any “No” responses, include the date the entity expects to be compliant with the 
requirement and provide a brief description of the actions being taken to meet the requirement.   
PCI DSS 
Requirement  Description  of Requirement  Compliant to PCI 
(Select One)  Remediation Date and 
Actions  
(If “NO” selected for any 
Requirement)  
YES NO 
controls          

PCI DSS 
Actions  
YES NO 
controls          
6 Develop and maintain secure systems and 
software          
7 Restrict access to system components and 
cardholder data by business need to know          
8 Identify  users  and authenticate acces s to 
system components

software          
9 Restrict physical access to cardholder data          
components  and cardholder data          
11 Test security systems and  networks  
regularly          
12 Support information security  with 
Appendix A1  Additional PCI DSS Requirements for Multi -
Tenant Service Providers          
Appendix A2  Additional PCI DSS Requirem ents for 

Data Security  Standard  
PCI DSS v4.0 Supplemental Report on Compliance  Template   
Revision 1  

PCI DSS v4.0 Supplemental ROC Template - Designated Entities Supplemental Validation r1 December 2022  
© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 1 
 
June 2015  For use with     
PCI DSS v3.1 
Revision  1.0 To introduce the template for submitting Supplemental Reports on Compliance for Designated Entities.  
This document is intended for use with version 1.0 of the PCI DSS Designated Entities Supplemental Validation.  
May 2016  For use with     
PCI DSS v3.2 
Revision 1.0  To update the template to align with PCI DSS v3.2.  
December 2018  For use with     
PCI DSS v3.2.1 
Revision 1.0  To update the template to align with PCI DSS v3.2.1.  
June 2022  For use with 
PCI DSS v4.0  To update the template to align with PCI D SS v4.0.  
December 2022  For use with 
PCI DSS v4.0  
Revision 1  Update d to remov e In Place with Remediation as a reporting option .

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 2 
 
Introducti on to the PCI DSS v4.0 Supplemental Report on Compliance ( ROC ) 
Template for Designated Entities Supplemental Validation  
Instructions for Submission  
This document, the PCI DSS v4.0 Supplemental Report on Compliance Template - Designated Entities  Supplemental Validation (“Supplemental 
ROC Template”  or “S -ROC” ), is the mandatory template for Qualified Security Assessors (QSAs) completing an assessment of a designated entity 
against the PCI DSS v 4.0 Appendix A3: Designated Entities Supplemental Vali dation.   
Note that an entity is ONLY  required to undergo an assessment according to this document if instructed to do so by an acquirer or a 
payment brand.   
This “Supplemental ROC Template” or “S -ROC” is to be completed according to the same instructions provided in the PCI DSS v4.0 R eport on

This “Supplemental ROC Template” or “S -ROC” is to be completed according to the same instructions provided in the PCI DSS v4.0 R eport on 
Compliance (ROC) Template . Refer to the PCI DSS v4.0 ROC Template  and the PCI DSS v4.x Report on Compliance Template –  Frequently 
Asked Questions  documents on the PCI SSC website for detailed instructions  on how to complete these reporting templates. D o not delete any 
content from any place in this document, including this section and the versioning above.  Excessive personalization and changes to sections –  
including additional sections -  may not be accepted by accepting entities, and personalization shou ld be limited to the title page.

including additional sections -  may not be accepted by accepting entities, and personalization shou ld be limited to the title page.  
The S -ROC template is an addendum to the ROC Template and is not intended to stand alone. Because of this , details related to Scope of Work, 
Details of Reviewed Environment , Remote Assessment Activities,  and so on that are applicable to the environment reviewed for the S -ROC must 
be included in the applicable sec tions in the full ROC for that entity. For example, the list of evidence in the full ROC must  also include any 
evidence reviewed during assessment of activ ities for the PCI DSS v4.0 Appendix A3: Designated Entities  Supplemental Validation.

evidence reviewed during assessment of activ ities for the PCI DSS v4.0 Appendix A3: Designated Entities  Supplemental Validation.  
While this supplemental validation would typically be done in conjunction with a full PCI DSS assessment, entities should contact their payment 
brand and/or acquirer with any questions about completing and submitting these reports.  
 
Note that an entity is ONLY  required to undergo an assessment according to this document if 
instructed to do so by an acquirer or a payment brand.

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 3 
 
Addendum to PCI DSS v4.0 ROC  Template  for Appendix A3: Designated Entities 
Supplemental Validation (DESV)  
1 Summary of DESV  Results  
Indicate all the findings and whether compensating controls were used within each DESV requirement. Select all that apply.  For example, In 
Place  and Not Applicable  must  both be selected for Requirement A3.1 if there is  at least one sub- requirement marked In P lace and one sub-
requirement marked Not Applicable . The column for Compensating Controls must be selected if there is at least one sub- requirement within 
the DESV requirement s that used a compensating control . 
DESV 
Requirement  Assessment Finding  
Select all  options that apply.  Select If Below Method W as 
Used   
In Place  Not Applicable  Not in Place  Compensating Control  
Requirement A3.1: ☐ ☐ ☐ ☐

DESV 
Used   
Requirement A3.1: ☐ ☐ ☐ ☐ 
Requirement A3.2: ☐ ☐ ☐ ☐ 
Requirement A3.3: ☐ ☐ ☐ ☐ 
Requirement A3.4: ☐ ☐ ☐ ☐ 
Requirement A3.5: ☐ ☐ ☐ ☐ 
In the sections below , identify the DESV requirements with the following results and assessment method. If there are none, enter “Not Applicable.”  
Note:  Natural grouping of requirements is allowed (for example, Req. A3.1.1, A3.1.2, A3.1.3, or A3. 1.1 through A3 .1.4, etc.) to reduce the number of individual 
Not Applicable  Not in Place Due to a Legal 
Restriction   Not in Place Not  Due to a Legal 
Restriction  Compensating Control  
<Enter Response Here>

 <Enter Response Here>  <Enter Response Here>  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 4 
 
Optional: Additional Assessor Comments  
assessment.  <Enter Response Here>  
2 Findings and Observations  
A3.1 A PCI DSS compliance program is implemented.  
A3.1.1 Responsibility is established by executive management for the protection of account data and a PCI DSS compliance program tha t includes:  
• Overall accountability for maintaining PCI DSS compliance.  
• Defining a charter for a PCI DSS compliance program.  
• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least

• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least 
once every 12 months. 
PCI DSS Reference : Requirement 12  
In Place  Not Applicable  Not in Place  
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 5 
 
Validation Method –  Customized Approach  
This requirement is not eligible for the customized ap proach.  
Validation Method –  Defined Approach  
Control(s) was used.  
Note:  The use of Compensating Controls must also be documented in Appendix C  
of the ROC Template.  <Enter Response Here>  
A3.1.1.a Examine documentation to 
verify executive management has 
assigned overall accountability for 
maintaining the entity’s PCI DSS 
compliance.  Identify the evidence reference number(s) 
from Section 6 of the ROC Template for all 
documentation  examined for this testing

A3.1.1.b Examine the company’s PCI 
DSS charter to verify it outlines the 
conditions under which the PCI DSS 
compliance program is organized.  Identify the evidence reference number(s) 
from Section 6 of the ROC Template for 
the company’s PCI DSS charter 
A3.1.1.c Examine executive 
management and board of directors 
meeting minutes and/or presentations 
to ensure PCI DSS compliance 
initiatives and remediation activities

initiatives and remediation activities 
are communicated at least once every 
12 months.  Identify the evidence reference number(s) 
executive management and board of 
directors meeting minutes and/or 
presen tations  examined for this testing 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 6 
 
A3.1.2 A formal PCI DSS compliance program is in place that includes:  
• Definition of activities for maintaining and monitoring overall PCI DSS compliance, including business -as-usual activities.  
• Annual PCI DSS assessment processes.  
• Processes for the continuous validation of PCI DSS requirements (for example, daily, weekly, every three months, as applicable per the requirement).  
• A process for performing business -impact analysis to determine potential PCI DSS impacts for strategic business decisions.  
PCI DSS Reference:  Requirements 1- 12 
☐ ☐ ☐ 
Note : Include all details as noted in the “Required Reporting” column of the table in

☐ ☐ ☐ 
Assessment Findings  in the ROC Template Instructions.  <Enter Response Here>  
Note:  The use of Compensating Controls must also be documented in Appendix C 
of the ROC Template.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 7 
 
A3.1.2.a Examine information security 
processes are defined for a formal 
PCI DSS compliance program that 
information security poli cies and 
A3.1.2.b Interview personnel and 
observe compliance activities to verify 
that a formal PCI DSS compliance 
program is implemented in 
interview(s)  conducted for this testing

observation(s) of compliance activities  

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 8 
 
A3.1.3 PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel, including:  
• Managing PCI DSS business -as-usual activities.  
• Managing annual PCI DSS assessments.  
• Managing continuous validation of PCI DSS requirements (for example, d aily, weekly, every three months, as applicable per the requirement).  
• Managing business -impact analysis to determine potential PCI DSS impacts for strategic business decisions.  
☐ ☐ ☐ 

☐ ☐ ☐ 
Note:  The use of Compensating Controls must also be documented Appendix C of 
the ROC Template.  <Enter Response Here>

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 9 
 
A3.1.3.a Examine information security 
policies and procedures and interview 
personnel to verify that PCI DSS 
compliance roles and responsibilities 
are specifically defined and formally 
assigned to one or more personnel in 
requirement.  Identify the evidence reference num ber(s) 
information security policies and 
A3.1.3.b Interview responsible 
personnel and verify they are familiar

personnel and verify they are familiar 
with and performing their designated 
PCI DSS compliance responsibilities.  Identify the evidence reference numb er(s) 
A3.1.4 Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance 
responsibilities (as identified in A3.1.3).  
PCI DSS Reference:  Requirement 12  

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 10 
 
A3.1.4.a Examine information security 
PCI DSS and/or information security 
training is required at least once every 
12 months for each role with PCI DSS 
compliance responsibilities.  Identify the evidence reference numb er(s)

compliance responsibilities.  Identify the evidence reference numb er(s) 
A3.1.4.b Interview personnel and 
examine certificates of attendance or 
other records to verify that personnel 
with PCI DSS compliance 
responsibility receive up-to -date PCI 
DSS and/or similar information 
security training at least once every 
from Section 6 of the ROC Template for all

certificates of attendance or other 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 11 
 
A3.2 PCI DSS scope is documented and validated.  
A3.2.1 PCI DSS scope is documented and confirmed for accuracy at least once every three months and upon significant changes 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 accept ance 
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to 1) any locations outside of the currently

• 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.  
• For any account data found outside of the currently defined CDE, either 1) securely delete it, 2) migrate it i nto the currently defined CDE, or 3) expand the 
currently defined CDE to include it.  
• 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 environm ent(s) from which the CDE is segmented, including justification for environments being out of 
scope.  
• Identifying all connections to third-party entities with access to the CDE.  
• Confirming that all identified data flows, account data, system components, seg mentation controls, and connections from third parties with access to the 
CDE are included in scope.  
PCI DSS Reference:  Scope of PCI DSS Requirements,  Requirement 12.  
☐ ☐ ☐

scope.  
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 12 
 
Note:  The use of Compensating Controls must also be documented in Appendix C of 
the ROC Template.  <Enter Response Here>  
A3.2.1.a Examine documented results 
personnel to verify that the reviews are 
scope environment.  Identify the evidence reference number(s)

A3.2.1.b Examine documented results 
of scope reviews occurring at least 
once every three months to verify that 
scoping validation includes all  
elements specified in this requirement.  Identify the evidence reference number(s)

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 13 
 
A3.2.2 PCI DSS scope impact for all changes to systems or networks is determined, including additions of new systems and new network  connections. 
Processes include:  
• Performing a formal PCI DSS impact assessment.  
• Identifying applicable PCI DSS requirements to the system or network.  
• Updating PCI DSS scope as appropriate.  
• Documented sign- off of the results of the impact assessment by responsible personnel (as defined in A3.1.3).  
PCI DSS Reference:  Scope of PCI DSS Requirements; Requirements 1-12 
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 14 
 
A3.2.2 Examine change 
documentation and interview personnel 
to verify that for each change to 
systems or networks the PCI DSS 
scope impact is determined, and 
change documentation  examined for this 
A3.2.2.1 Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks,

A3.2.2.1 Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks, 
PCI DSS Reference:  Scope of PCI DSS Requirements; Requirement 1-12  
☐ ☐ ☐ 
This requirement is not eligible for the customized approach.

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 15 
 
A3.2.2.1 Examine change records and 
the affected systems/networks, and 
relevant PCI DSS requirements were 
confirmed to be implemented and 
documentation updated as part of the 
change.  Identify the evidence reference nu mber(s) 
change records  examined for this testing 

affected systems/networks examined for 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 16 
 
A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.  
☐ ☐ ☐ 

A3.2.3 Examine policies and 
procedures to verify that a change to 
organizational structure results in 
formal a review of the impact on PCI 
DSS scope and applicability of 
controls.  Identify the evidence reference number(s) 
policies and procedures examined for

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 17 
 
A3.2.4 If segmentation is used, PCI DSS scope is confirmed as follows:  
• Per the entity’s methodology defined at Requirement 11.4.1.  
• Penetration testing is performed on segmentation controls at least once every six months and after any changes to segmentation controls/methods.  
• The penetration testing covers all segmentation controls/methods in use.  
• The penetration testing verifies that  segmentation controls/methods are operational and effective, and isolate the CDE from all out -of-scope systems.  
PCI DSS Reference:  Requirement 11  
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 18 
 
A3.2.4 Examine the results from the 
that the test was conducted in 
the results from the most recent 
penetration test  examined for this testing 
A3.2.5 A data -discovery methodology is implemented that:  
• Confirms PCI DSS scope.  
• Locates all sources and locations of cleartext PAN at least once every three months and upon significant changes to the CDE or processes.  
• Addresses the potential for cleartext PAN to reside on systems and networks outside the currently defined CDE.

• Addresses the potential for cleartext PAN to reside on systems and networks outside the currently defined CDE.  
PCI DS S Reference : Scope of PCI DSS Requirements  
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 19 
 
A3.2.5.a Examine the documented 
data-discovery methodology to verify it 
the documented data -discovery 
methodology  examined for this testing

A3.2.5.b Examine results from recent 
data discovery efforts, and interview 
data discovery is performed at least 
once every three months and upon 
significant changes to the CDE or 
processes.  Identify the evidence reference number(s) 
results from recent data discovery 
efforts examined for this testing 

from Section 6 of the R OC Template for all 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 20 
 
A3.2.5.1 Data discovery methods are confirmed as follows:  
• Effectiveness of methods is tested.  
• Methods are able to discover cleartext PAN on all types of system components and file formats in use.  
• The effectiveness of data-discovery methods is confirmed at least once every 12 months.  
PCI DSS Reference:  Scope of PCI DSS Requirements  
☐ ☐ ☐ 
Validation Method –  Defined Approach

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 21 
 
A3.2.5.1.a Interview personnel and 
review documentation to verify:  
• The entity has a process in place 
to test the effectiveness of 
methods used for data discovery.  
• The process includes verifying the 
methods are able to discover 
cleartext PAN on all types of 
system components and file 
formats in use.  Identify the evidence reference number(s) 
A3.2.5.1.b Examine the results of 
effectiveness tests to verify that the

effectiveness tests to verify that the 
effectiveness of data-discovery 
methods is confirmed at least once 
the results of effectiveness tests 
examined for this testing procedure.  <Enter Response Her e>

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 22 
 
A3.2.5.2 Response procedures are implemented to be initiated upon the detection of cleartext PAN outside the CDE to include:  
Determining what to do if cleartext PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, 
as applicable.  
• Determining how the data ended up outside the CDE.  
• Remediating data leaks or process gaps that resulted in the data being outside the CDE.  
• Identifying the source o f the data.  
• Identifying whether any track data is stored with the PANs.  
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 23 
 
A3.2.5.2.a Examine documented 
response procedures to verify that 
procedures for responding to the 
detection of cleartext PAN outside the 
CDE are defined and include all 
documented response procedures  
A3.2.5.2.b Interview personnel and 
to verify that remediation activities are 
performed wh en cleartext PAN is 
detected outside the CDE.  Identify the evidence reference number(s) 

records of response actions  examined 
A3.2.6 Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the CDE via an unauthorized channel, method, or process, 
including mechanisms that are:  
• Actively running.  
• Configured to detect and prevent cleartext PAN leaving the CDE via an unauthorized channel, method, or process.

• Configured to detect and prevent cleartext PAN leaving the CDE via an unauthorized channel, method, or process.  
• Generating audit logs and alerts upon detection of cleartext PAN leaving the CDE via an unauthorized channel, method, or proc ess. 
PCI DSS Reference:  Scope of PCI DSS Requirements, Requirement 12  
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 24 
 
A3.2.6.a  Examine documentation and 
observe implemented mechanisms to 
verify that the mechanisms are in 
documentation examined for this testing

observation(s) of the implemented 
A3.2.6.b Examine audit logs and 
alerts, and interview responsible 
personnel to verify that alerts are 
investigated.  Identify the evidence reference number(s) 
audit logs and alerts examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 25 
 
A3.2.6.1 Response procedures are implemented to be initiated upon the detection of attempts to remove cleartext PAN from the CDE via an unauthorized 
channel, method, or process. Response procedures include:  
• Procedures for the prompt investigation of alerts by responsible personnel.  
• Proced ures for remediating data leaks or process gaps, as necessary, to prevent any data loss.  
☐ ☐ ☐ 
Validation Method –  Customized Approach

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 26 
 
A3.2.6.1.a Examine documented 
attempted removal of cleartext PAN 
from the CDE via an unauthorized 
channel, method, or process include all 
elements specified in this requirement:  
• Procedures  for the prompt 
investigation of alerts by 
responsible personnel.  
• Procedures for remediating data 
leaks or process gaps, as 
necessary, to prevent any data 
loss. Identify the evidence reference number(s) 
A3.2.6.1.b Interview personnel and 
examine records of actions taken when 
cleartext PAN is detected leaving the

cleartext PAN is detected leaving the 
CDE via an unauthorized channel, 
method, or process and verify that 
remediation activities were performed.  Identify the evidence reference number(s) 
records of actions taken  examined for 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 27 
 
A3.3 PCI DSS is incorporated into business -as-usual (BAU) activities.  
A3.3.1 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to fai lure of:  
• Network security controls  
• IDS/IPS  
• FIM 
• Anti-malware solutions  
• Physical access controls  
• Logical access controls  
• Audit logging mechanisms  
• Segmentation controls (if used)  
• Automated audit log review mechanisms. This bullet is a best practice until 31 March 2025, after which they will be required as  part of Requirement A3.3.1 
and must be fully considered during a PCI DSS assessment.

• IDS/IPS  
• FIM 
and must be fully considered during a PCI DSS assessment.  
• Automated code review tools (if used). This bullet is a best practice until 31 March 2025, after which they will be required as part of Requirement A3.3.1 
and must be ful ly considered during a PCI DSS assessment.  
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 28 
 
A3.3.1.a Examine documented 
processes are defined to promptly 
detect, alert, and address critical 
security control failures in accordance 
requirement.  Identify the evidence referenc e number(s)

requirement.  Identify the evidence referenc e number(s) 
documented policies and procedures  
A3.3.1.b Examine detection and 
alerting processes, and interview 
implemented for all critical security 
controls specified in this requirement 
and that each failure of a critical 
security control results in the 
generation of an alert.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 29 
 
A3.3.1.2 Failures of any critical security control systems are responded to promptly. Processes for responding to failures in security  control systems include:  
• Identifying and documenting the cause(s) of failure, including root cause, and documenting remediation required to address the  root cause.  
• Resumi ng monitoring of security controls.  

☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 30 
 
A3.3.1.2.a Examine documented 
defined and implemented to respond 
promptly to a security control failure in 
A3.3.1.2.b Examine records to verify 
that security control failures are 
documented to include:  
• Identification of cause(s) of the

failure, including root cause.  

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 31 
 
A3.3.2 Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the or ganization’s PCI DSS 
PCI DSS Reference:  Requirements 2, 6, 12.  
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 32 
 
A3.3.2.a Examine documented 
defined and implemented to review 
hardware and software technologies 
to confirm whether they continue to 
meet the organization’s PCI DSS 
A3.3.2.b Review the results of the 
recent reviews of hardware and 
software technologies to verify

software technologies to verify 
reviews are performed at least once 
the results of the recent reviews 
A3.3.2.c Review documentation to 
verify that, for any technologies that 
have been determined to no longer 
requirements, a plan is in place to 
remediate the technology.  Identify the evidence reference number(s)

remediate the technology.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 33 
 
A3.3.3 Reviews are performed at least once every three months to verify BAU activities are being followed. Reviews are performed by personnel assigned to the 
PCI DSS compliance program (as identified in A3.1.3), and include:  
• Confirmation that all BAU activities, including A3.2.2, A3.2.6, and A3.3.1, are being performed.  
• Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, rules et reviews f or network security 
controls, and configuration standards for new systems).  
• Documenting how the reviews were completed, including how all BAU activities were verified as being in place.  
• Collection of documented evidence as required for the annual PCI DSS assessment.

• Collection of documented evidence as required for the annual PCI DSS assessment.  
• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program, as identified in A3.1.3.  
• Retention of records and documentation for at least 12 months, covering all BAU activities.  
PCI DSS Reference : Requirements 1- 12 
☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 34 
 
A3.3.3.a Examine policies and 
are defined for reviewing and verifying 
BAU activities in accordance with all 

A3.3.3.b  Interview responsible 
personnel and examine records of 
reviews to verify that:  
• Reviews are performed by 
personnel assigned to the PCI 
DSS compliance program.  
• Reviews are performed at least 
once every three months.  Identify the evidence reference number(s) 

from Section 6 of the ROC Template  for all 
records of reviews examined for this 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 35 
 
A3.4 Logical access to the cardholder data environment is controlled and managed.  
A3.4.1 User accounts and access privileges to in -scope system components are reviewed at least once every six months to ensure user accounts and access 
privileges remain appropriate based on job function, and that all access is authorized.  
PCI DSS Reference:  Requirement 7  
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 36 
 
A3.4.1 Interview responsible 
personnel and examine supporting 
documentation to verify that:  
• User accounts and access 
privileges are reviewed at least 
every six months.  
• Reviews confirm that access is 
appropriate based on job function 
and that all access is author ized.  Identify the evidence reference number(s) 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 37 
 
A3.5 Suspicious events are identified and responded to.  
A3.5.1 A methodology is implemented for the prompt identification of attack patterns and undesirable behavior across systems that in cludes:  
• Identification of anomalies or suspicious activity as it occurs.  
• Issuance of prompt alerts upon detection of suspicious activity or anomaly to responsible personnel.  
• Response to alerts in accordance with documented response procedures.  
PCI DSS Reference:  Requirements 10, 12  
☐ ☐ ☐ 

☐ ☐ ☐ 

© 2006 - 2022 PCI Security Standards Council, LLC . All Rights Reserved.  Page 38 
 
A3.5.1.a Examine documentation and 
interview personnel to verify a 
methodology is defined and 
implemented to identify attack 
patterns and undesirable behavior 
across systems in a prompt manner, 
and includes all elements specified in 
this requirement.  Ident ify the evidence reference number(s) 
A3.5.1.b Examine incident response 
personnel to verify that:  
• On-call personnel receive prompt 
alerts.

alerts.  
• Alerts are responded to per 
documented response 
procedures.  Identify the evidence reference number(s) 