PCI-DSS-v4-0-ROC-Template-r1-docx - Ideas

### **Table of Contents** [[#ROC Template Instructions]] [[#ROC Sections]] [[#Assessment Findings]] [[#What Is the Difference between Not Applicable and Not Tested?]] [[#Dependence on Another Service Provider’s Compliance]] [[#Assessment Approach Reporting Options]] [[#Understanding the Reporting Instructions]] [[#Dos and Don’ts Reporting Expectations]] [[#PCI DSS v4.0 Report on Compliance Template]] --- --- ### ROC Template Instructions This document, the PCI DSS v4.0 Report on Compliance Template (“ROC Template”), is the mandatory template for Qualified Security 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 may be added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos to the title page below, is acceptable. Do not delete any content from Part I or Part II of this document. The Instruction pages may be deleted; however, the assessor must follow these instructions while documenting the assessment. The addition of text or rows is acceptable, within reason, as noted above. Refer to the _PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions_ document on the PCI SSC website for further guidance. The ROC is completed during PCI DSS assessments as part of an entity’s validation process. The ROC provides details about the entity’s environment and assessment methodology and documents the entity’s assessment results for each PCI DSS requirement. A PCI DSS compliance assessment involves thorough testing and assessment activities, from which the assessor will generate evidence (assessment workpapers). These workpapers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, 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 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]] - [[#1 Contact Information and Summary of Results|Section 1: Contact Information and Summary of Results]] - [[#2 Business Overview|Section 2: Business Overview]] - [[#3 Description of Scope of Work and Approach Taken|Section 3: Description of Scope of Work and Approach Taken]] - [[#4 Details About Reviewed Environments|Section 4: Details about Reviewed Environment]] - [[#5 Quarterly Scan Results|Section 5: Quarterly Scan Results]] - [[#6 Evidence (Assessment Workpapers)|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 provide proper context for the assessment findings in Part II. The ROC Template includes tables with reporting instructions built-in to help assessors provide all required information throughout the document. Responses must be specific and focus on concise quality of detail, rather than lengthy, repeated verbiage. Use of template language for descriptions is discouraged and details must be specifically relevant to the assessed entity. --- ### Assessment Findings There are four possible assessment findings: 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_.](#_bookmark3) Refer to the following table when considering which selection to make. Only one assessment finding may be selected at the sub-requirement level and reporting associated with that assessment finding must be consistent across all required documents, including the AOC. Refer to the _[PCI DSS v4.x Report on Compliance Template - Frequently Asked Questions]_ document on the PCI SSC website for further guidance. | | | | | |---|---|---|---| |**Assessment Finding**|**When to Use This Assessment Finding**|**Using Figure 1**|**Required Reporting**| |In Place|The expected testing has been performed, and all elements of the requirement have been met.|In _Figure 1_, the Assessment Finding at 1.1.1 is In Place if all report findings are In Place for 1.1.1.a and 1.1.1.b or a combination of In Place and Not Applicable.|Describe how the testing and evidence demonstrates the requirement is In Place.| |Not Applicable|The requirement does not apply to the organization’s environment. Not Applicable responses require reporting on testing performed to confirm 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 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 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 Not Applicable. A requirement is applicable if any aspects of the requirement apply to the environment being assessed, and a Not Applicable designation in the Assessment Findings should not be used in this scenario. **_Note:_** _Requirements and/or individual bullets within a requirement noted as a best practice until its effective date are considered Not Applicable until the future date has passed. While it is true that the requirement is likely not tested (hence the original instructions), it is not required to be tested until the future date has passed, and the requirement is therefore not applicable until that date. As such, a Not Applicable response to future-dated requirements is accurate, whereas a Not Tested response would imply there was not any consideration as to whether it could apply._ 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.| |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 met, are in the process of being implemented, or require further testing before it will be known if they are In Place. This response is also used if a requirement cannot be met due to a legal restriction, meaning that meeting the requirement would contravene a local or regional law or regulation. The assessor must confirm that a statutory law or regulation exists that prohibits the requirement from being met. **_Note:_** _Contractual obligations or legal 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 in Place. If the requirement is Not in Place due to a legal restriction, the assessor must describe the statutory law or regulation that prohibits the requirement from being met.| --- --- #### **Figure 1. Example Requirement** | | | | | |---|---|---|---| |**Assessment Findings (select one)**| | | | |**In Place**|**Not Applicable**|**Not Tested**|**Not in Place**| |☐|☐|☐|☐| |Describe why the assessment finding was selected. **_Note_**_: Include all details as noted in the “Required Reporting” column of the table in_ [_Assessment Findings_](#_bookmark2) _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__._](#_bookmark82)|<Enter Response Here>| | | | |---|---| |**Validation Method – Defined Approach**| | |**Indicate** whether a Compensating Control was used:|☐ Yes ☐ No| |**If “Yes”, Identify** the aspect(s) of the requirement where the Compensating Control(s) was used. **_Note:_** _The use of Compensating Controls must also be documented in_ [_Appendix C__._](#_bookmark80)|<Enter Response Here>| --- --- ### 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 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 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 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 service provider organization might offer a service that covers only a limited number of PCI DSS requirements—for example, a physical storage provider may want only to validate the physical security controls per PCI DSS Requirement 9 for their storage facility. In these scenarios, the organization wants only to validate certain PCI DSS requirements, even though other requirements might also apply to their environment. The resulting AOC(s) must be clear in what was tested and not tested. 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. --- ### 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 selected” section and the corresponding evidence is identified in the evidence section of the requirement. An acceptable response for an In 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 against PCI DSS vX.X for all applicable requirements, and that it covers the scope of the services used by the assessed entity._ That response could vary, but what’s important is that it is noted as In Place, and that there has been a level of testing by the assessor to support the conclusion that this responsibility is verified and that the responsible party has been tested against the requirement and found to be compliant. --- ### 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. | | | | |---|---|---| |**Assessment Approach**|**When to Use This Approach**|**Using Figure 2**| |**Customized Approach**|Focuses on the Customized Approach Objective of each PCI DSS Requirement (if applicable), allowing entities to implement controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. The customized approach supports innovation in security practices, allowing entities greater flexibility to show how their current security controls meet PCI DSS requirements. Refer to the _Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures_ for the Customized Approach Objective. **_Note:_** _Compensating Controls are not an option for the Customized Approach_|**For “Validation Method – Customized Approach”** · If the Customized Approach is not used, select “No” for Customized Approach acknowledgement check box, and mark the relevant reporting instruction as Not Applicable. · If the Customized Approach is used, complete the following: o Select “Yes” for Customized Approach acknowledgement check box. o Identify the aspects of the requirement where the Customized Approach was used. o Complete the Customized Approach Template in [_Appendix E_](#_bookmark82) (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 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 submission.|**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, complete 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_](#_bookmark80) (not pictured).| #### **Figure 2. Assessment Approach Reporting Options** | | | | |---|---|---| |**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__._](#_bookmark82)| |<Enter Response Here>| |**Validation Method – Defined Approach**| | | |**Indicate** whether a Compensating Control was used:| |☐ Yes ☐ No| |**If “Yes”, Identify** the aspect(s) of the requirement where the Compensating Control(s) was used. **_Note:_** _The use of Compensating Controls must also be documented in_ [_Appendix C__._](#_bookmark80)| |<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>| --- ### 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 should avoid generic templated language. Assessor responses generally fall into categories, such as the following: | | | | |---|---|---| |**Reporting** **Instruction Term**|**Example Usage**|**Description of Response**| |Indicate|Indicate whether the assessed entity is an issuer or supports issuing services.|The response would be either “Yes” or “No” as shown: ☐ 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 will direct the assessor to a subsequent instruction based on the yes/no answer._| |Identify|Identify the evidence reference number(s) from [Section 6](#_bookmark50) 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](#_bookmark50) for all documentation examined for this testing procedure.” Example Response: Doc-01 OR Doc-01 (Company XYZ Information Security Policy) **_Note:_** _When a reference number is available, it is required; however, the assessor also has the option to list individual items in addition to the reference number._| |Describe|Describe why the assessment finding was selected.|The response would include a detailed description of the item or activity in question — for example, details of how the 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 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.| --- ### 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 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 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. # Part I Assessment Overview ## 1 Contact Information and Summary of Results ### 1.1 Contact Information ### 1.2 Date and Timeframe of Assessment ### 1.3 Remote Assessment Activities #### 1.3.1 **_Overview of Remote Testing Activity_** #### 1.3.2 **_Summary of Testing Performed Remotely_** #### 1.3.3 **_Assessor Assurance in Assessment Result_** #### 1.3.4 **_Requirements That Could Not be Fully Verified_** ### 1.4 Additional Services Provided by QSA Company ### 1.5. Use of Subcontractors ### 1.6 Additional Information/Reporting ### 1.7 Overall Assessment Result ### 1.8 Summary of Assessment #### 1.8.1 **_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 the 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. #### 1.8.2 **_Optional: Additional Assessor Comments_** ### 1.9 Attestation Signatures ## 2 Business Overview ### 2.1 Description of the Entity’s Payment Card Business ## 3 Description of Scope of Work and Approach Taken ### 3.1 Assessor’s Validation of Defined Scope Accuracy ### 3.2 Segmentation ### 3.3 PCI SSC Validated Products and Solutions ### 3.4 Sampling ## 4 Details About Reviewed Environments ### 4.1 Network Diagrams Provide one or more network diagrams that: - Shows all connections between the CDE and other networks, including any wireless networks. - Is accurate and up to date with any changes to the environment. - Illustrates all network security controls that are defined for connection points between trusted and untrusted networks. - Illustrates how system components storing cardholder data are not directly accessible from the untrusted networks. - Includes the techniques (such as intrusion-detection systems and/or intrusion-prevention systems) that are in place to monitor all traffic: - At the perimeter of the cardholder data environment. - At critical points in the cardholder data environment. **_Note:_** _This section must align with networks identified in [[#4.5 In-Scope Networks]]._ ### 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. #### 4.2.1 Description of account Data Flows ### 4.3 Storage of Account Data #### 4.3.1 Storage of SAD ### 4.4 In-scope Third-Party Service Providers (TPSPs) ### 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 in [[#4.1 Network Diagrams]]._ Describe all networks that store, process, and/or transmit Account Data: ### 4.6 In-scope Locations/Facilities ### 4.7 In-scope Business Functions ### 4.8 In-scope System Component Types ### 4.9 Sample Sets for Reporting ## 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. ### 5.2 Attestation of Scan Compliance The scans **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. ### 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: - The entity has documented policies and procedures requiring quarterly scanning going forward, and - Any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans **must** have occurred. ## 6 Evidence (Assessment Workpapers) ### 6.1 Evidence Retention ### 6.2 Documentation Evidence ### 6.3 Interview Evidence ### 6.4 Observation Evidence ### 6.5 System Evidence # Part II Findings and Observations ## Build and Maintain a Secure Network and Systems ### Requirement 1: Install and Maintain Network Security Controls ### Requirement 2: Apply Secure Configurations to All System Components ## Protect Account Data ### Requirement 3: Protect Stored Account Data ### Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks ## Maintain a Vulnerability Management Program ### Requirement 5: Protect All Systems and Networks from Malicious Software ### Requirement 6: Develop and Maintain Secure Systems and Software ## Implement Strong Access Control Measures ### Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know ### Requirement 8: Identify Users and Authenticate Access to System Components ### Requirement 9: Restrict Physical Access to Cardholder Data ## Regularly Monitor and Test Networks ### Requirement 10: Log and Monitor All Access to System Components and Card Holder Data ### Requirement 11: Test Security of Systems and Networks Regularly ## Maintain an Information Security Policy ### Requirement 12: Support Information Security with Organizational Policies and Programs --- --- ## Appendix A Additional PCI DSS Requirements ### A1 Additional PCI DSS Requirements for Multi-Tenant Service Providers --- ### A2 Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card-Present POS POI Terminal Connections --- ### 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 existing PCI DSS requirements. Entities that are required to validate to these requirements should refer 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. --- ## 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 Customized Approach Objective for most PCI DSS requirements. If a requirement is not eligible for the Customized Approach and therefore does not have a Customized Approach Objective, refer to the Purpose in the Guidance column for that requirement. 3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) 4. When evaluating “above and beyond” for compensating controls, consider the following: 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 encrypted 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 is 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 monitoring of all traffic destined to the vulnerable interface. >[!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. 5. Address the additional risk imposed by not adhering to the PCI DSS requirement. 6. Address the requirement currently and in the future. A compensating control cannot address a requirement that was missed in the past (for example, where the performance of a task was required two quarters ago, but that task was not performed). The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to confirm that each compensating control adequately addresses the risk that the original PCI DSS requirement was designed to address, per items 1-6 above. To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete. Additionally, compensating control results must be documented in the applicable report for the assessment (for example, a Report on Compliance or a Self-Assessment Questionnaire) in the corresponding PCI DSS requirement section, and included when the applicable report is submitted to the requesting organization. --- ## 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. Constraints**|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 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 tested.|<Enter Response Here>| |**6. Maintenance**|Define process(es) and controls in place to maintain compensating controls.|<Enter Response Here>| --- --- ## 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 Template in [Appendix E](#_bookmark82)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. - Monitor and maintain evidence about the effectiveness of each customized control. - Provide completed controls matrix(es), targeted risk analysis, testing evidence, and evidence of customized control effectiveness to its assessor. **The assessor** performing an assessment of customized controls must satisfy the following criteria: - 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 requirement. - 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 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 following the instructions in the _FAQs for use with PCI DSS v4.0 ROC Template_ available on the PCI SSC website. - Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach; however, these entities may elect to have a QSA or ISA perform their assessment and document it in a ROC Template. - The use of the customized approach may be regulated by organizations that manage compliance programs (for example, payment brands and acquirers). Therefore, questions about use of a customized approach must be referred to those organizations, including, for example, whether an entity is required to use a QSA, or may use an ISA to complete an assessment using the customized approach. >[!Note] Compensating controls are not an option with the customized approach. Because the customized approach allows an entity to determine and design the controls needed to meet a requirement’s Customized Approach Objective, the entity is expected to effectively implement the controls it designed for that requirement without needing to also implement alternate, compensating controls. --- ## 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 Customized Approach Objective)_|<Enter Response Here>| |**Describe how** the control(s) meet the Customized Approach Objective.|<Enter Response Here>| |**Identify** the **Controls Matrix documentation** reviewed that supports a customized approach for this requirement.|<Enter Response Here>| |**Identify** the **Targeted Risk Analysis documentation** reviewed that supports the customized approach for this requirement.|<Enter Response Here>| |**Identify** name(s) of the assessor(s) who attests that: · The entity completed the Controls Matrix including all information specified in the Controls Matrix Template in Appendix E1 of _Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures_ and the results of the Controls Matrix support the customized 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 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 **implemented 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. **_Note 1:_** _Technical reviews (for example, reviewing configuration settings, operating effectiveness, etc.) should be performed where possible and appropriate._ **_Note 2:_** _Add additional rows for each assessor-derived testing procedure, as needed. Ensure that all rows to the right of the “Assessor-derived testing procedure” are copied for each assessor-derived testing procedure that is added._| | |<Assessor-derived testing procedure>|**Identify** what 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 testing procedure.|<Enter Response Here>| | |**Describe** the results of the testing performed by the assessor for this testing procedure and how these results verify the implemented controls meet the Customized Approach Objective.|<Enter Response Here>| |**Document** the testing procedures derived and performed by the assessor to validate **the controls are maintained to ensure ongoing effectiveness**; for example, how the entity monitors for control effectiveness and how control failures are detected, responded to, and the actions taken. **_Note 1:_** _Technical reviews (for example, reviewing configuration settings, operating effectiveness, etc.) should be performed where possible and appropriate._ **_Note 2:_** _Add additional rows for each assessor-derived testing procedure, as needed. Ensure that all rows to the right of the “Assessor-derived testing procedure” are copied for each assessor-derived testing procedure that is added._| | | |<Assessor-derived testing procedure>|**Identify** what 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 testing procedure.|<Enter Response Here>| | |**Describe** the results of the testing performed by the assessor for this testing procedure and how these results verify the implemented controls are maintained to ensure ongoing effectiveness.|<Enter Response Here>|