Document Comparison
PCI-DSS-v3-2-1-SAQ-D_ServiceProvider-r2.pdf
→
PCI-DSS-v4-0-SAQ-D-Service-Provider-r3.pdf
21% similar
92 → 147
Pages
23239 → 38131
Words
528
Content Changes
From Revision History
- October 2008 1.2
Content Changes
528 content changes. 101 administrative changes (dates, page numbers) hidden.
Added
p. 2
Rearranged, retitled, and expanded information in the “Completing the Self-Assessment Questionnaire” section (previously titled “Before You Begin”).
Aligned content in Sections 1 and 3 of Attestation of Compliance (AOC) with PCI DSS v4.0 Report on Compliance AOC.
Added Section 2a to the Self-Assessment Questionnaire to specify additional documentation required for service provider self-assessments.
Added “Describe Results” to Section 2b (previously Section 2) for each PCI DSS requirement, for service providers to describe their testing results.
Added appendices to support new reporting responses.
Aligned content in Sections 1 and 3 of Attestation of Compliance (AOC) with PCI DSS v4.0 Report on Compliance AOC.
Added Section 2a to the Self-Assessment Questionnaire to specify additional documentation required for service provider self-assessments.
Added “Describe Results” to Section 2b (previously Section 2) for each PCI DSS requirement, for service providers to describe their testing results.
Added appendices to support new reporting responses.
Added
p. 2
Added “In Place with CCW” to AOC Section 3.
Added guidance for responding to future-dated requirements.
Added minor clarifications and addressed typographical errors.
May 2023 4.0 2 Errata Change − Unlocked document in Section 2a to allow diagrams to be added.
August 2023 4.0 3 Updated AOC Part 2g to include a section to explain Not Tested and Not Applicable reporting responses.
Added guidance for responding to future-dated requirements.
Added minor clarifications and addressed typographical errors.
May 2023 4.0 2 Errata Change − Unlocked document in Section 2a to allow diagrams to be added.
August 2023 4.0 3 Updated AOC Part 2g to include a section to explain Not Tested and Not Applicable reporting responses.
Added
p. 4
This SAQ is the ONLY SAQ option for service providers.
Defining Account Data, Cardholder Data, and Sensitive Authentication Data
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). 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)
• Full track data (magnetic-stripe data or equivalent on a chip)
• Card verification code
• PINs/PIN blocks Refer to PCI DSS Section 2, PCI DSS Applicability Information, for further details.
1. Per the eligibility criteria in this SAQ and as spelled out in the Self-Assessment Questionnaire Instructions and Guidelines document on PCI SSC website, this SAQ is the ONLY SAQ OPTION for service providers.
2. Confirm that the service provider environment is properly scoped.
• Section 1: Assessment Information (Parts …
Defining Account Data, Cardholder Data, and Sensitive Authentication Data
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). 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)
• Full track data (magnetic-stripe data or equivalent on a chip)
• Card verification code
• PINs/PIN blocks Refer to PCI DSS Section 2, PCI DSS Applicability Information, for further details.
1. Per the eligibility criteria in this SAQ and as spelled out in the Self-Assessment Questionnaire Instructions and Guidelines document on PCI SSC website, this SAQ is the ONLY SAQ OPTION for service providers.
2. Confirm that the service provider environment is properly scoped.
• Section 1: Assessment Information (Parts …
Added
p. 6
Briefly describe how the testing and evidence demonstrates the requirement is In Place.
Briefly describe which aspect(s) of the requirement where a compensating control(s) was used.
Not Applicable The requirement does not apply to the entity’s environment. (See “Guidance for Not Applicable Requirements” below for examples.) Briefly describe the results of testing performed that demonstrate the requirement is Not Applicable.
All responses in this column also require a supporting explanation in Appendix C of this SAQ.
All responses in this column also require a supporting explanation in Appendix D of this SAQ.
Briefly describe how the testing and evidence demonstrates the requirement is Not in Place.
Responses in this column may require the completion of Part 4, if requested by the entity to which this SAQ will be submitted.
If the requirement is not in place due to a legal restriction, describe the statutory law or regulation that prohibits the requirement from being met and complete the …
Briefly describe which aspect(s) of the requirement where a compensating control(s) was used.
Not Applicable The requirement does not apply to the entity’s environment. (See “Guidance for Not Applicable Requirements” below for examples.) Briefly describe the results of testing performed that demonstrate the requirement is Not Applicable.
All responses in this column also require a supporting explanation in Appendix C of this SAQ.
All responses in this column also require a supporting explanation in Appendix D of this SAQ.
Briefly describe how the testing and evidence demonstrates the requirement is Not in Place.
Responses in this column may require the completion of Part 4, if requested by the entity to which this SAQ will be submitted.
If the requirement is not in place due to a legal restriction, describe the statutory law or regulation that prohibits the requirement from being met and complete the …
Added
p. 7
For each response where Not Applicable is selected in this SAQ, complete Appendix C: Explanation of Requirements Noted as Not Applicable.
If a requirement is completely excluded from review without any consideration as to whether it could apply, the Not Tested response should be selected. Examples of situations where this could occur include:
• An entity is confirming a new security control that impacts only a subset of requirements
•for example, implementation of a new encryption methodology that only requires assessment of PCI DSS Requirements 2, 3, and 4.
If any requirements are completely excluded from the entity’s self-assessment, select Not Tested for that specific requirement, and complete Appendix D: Explanation of Requirements Not Tested for each Not Tested entry. An assessment with any Not Tested responses is a “Partial” PCI DSS assessment and will be noted as such by the entity in the Attestation of Compliance in Section 3, Part 3 of this …
If a requirement is completely excluded from review without any consideration as to whether it could apply, the Not Tested response should be selected. Examples of situations where this could occur include:
• An entity is confirming a new security control that impacts only a subset of requirements
•for example, implementation of a new encryption methodology that only requires assessment of PCI DSS Requirements 2, 3, and 4.
If any requirements are completely excluded from the entity’s self-assessment, select Not Tested for that specific requirement, and complete Appendix D: Explanation of Requirements Not Tested for each Not Tested entry. An assessment with any Not Tested responses is a “Partial” PCI DSS assessment and will be noted as such by the entity in the Attestation of Compliance in Section 3, Part 3 of this …
Added
p. 8
Note: A legal restriction is one where meeting the PCI DSS requirement would violate a local or regional law or regulation.
Contractual obligations or legal advice are not legal restrictions.
Use of the Customized Approach SAQs cannot be used to document use of the Customized Approach to meet PCI DSS requirements. For this reason, the Customized Approach Objectives are not included in SAQs. Entities wishing to validate using the Customized Approach may be able to use the PCI DSS Report on Compliance (ROC) Template to document the results of their assessment.
The use of the customized approach may be regulated by organizations that manage compliance programs, such as payment brands and acquirers. Questions about use of a customized approach should always be referred to those organizations. This includes whether an entity that is eligible for an SAQ may instead complete a ROC to use a customized approach, and whether an entity is required …
Contractual obligations or legal advice are not legal restrictions.
Use of the Customized Approach SAQs cannot be used to document use of the Customized Approach to meet PCI DSS requirements. For this reason, the Customized Approach Objectives are not included in SAQs. Entities wishing to validate using the Customized Approach may be able to use the PCI DSS Report on Compliance (ROC) Template to document the results of their assessment.
The use of the customized approach may be regulated by organizations that manage compliance programs, such as payment brands and acquirers. Questions about use of a customized approach should always be referred to those organizations. This includes whether an entity that is eligible for an SAQ may instead complete a ROC to use a customized approach, and whether an entity is required …
Added
p. 9
(PCI Data Security Standard Requirements and Testing Procedures)
• Guidance on Scoping
• Guidance on the intent of all PCI DSS Requirements
• Details of testing procedures
• Guidance on Compensating Controls
• Appendix G: Glossary of Terms, Abbreviations, and Acronyms SAQ Instructions and Guidelines
• Information about all SAQs and their eligibility criteria
• How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)
• Guidance and information about SAQs.
Online PCI DSS Glossary
• PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines
• Guidance on a variety of PCI DSS topics including:
− Understanding PCI DSS Scoping and Network Segmentation − Third-Party Security Assurance − Multi-Factor Authentication Guidance − Best Practices for Maintaining PCI DSS Compliance Getting Started with PCI
• Resources for smaller merchants including:
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics These and other …
• Guidance on Scoping
• Guidance on the intent of all PCI DSS Requirements
• Details of testing procedures
• Guidance on Compensating Controls
• Appendix G: Glossary of Terms, Abbreviations, and Acronyms SAQ Instructions and Guidelines
• Information about all SAQs and their eligibility criteria
• How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)
• Guidance and information about SAQs.
Online PCI DSS Glossary
• PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines
• Guidance on a variety of PCI DSS topics including:
− Understanding PCI DSS Scoping and Network Segmentation − Third-Party Security Assurance − Multi-Factor Authentication Guidance − Best Practices for Maintaining PCI DSS Compliance Getting Started with PCI
• Resources for smaller merchants including:
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics These and other …
Added
p. 13
Indicate whether the environment includes segmentation to reduce the scope of the assessment. (Refer to “Segmentation” section of PCI DSS for guidance on segmentation.) Part 2d. In-Scope Locations/Facilities List all types of physical locations/facilities (for example, corporate offices, data centers, call centers, and mail rooms) in scope for the PCI DSS assessment.
Added
p. 14
Name of PCI SSC- validated Product or Version of Product or
PCI SSC Standard to which product or solution was
PCI SSC listing Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD 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.
PCI SSC Standard to which product or solution was
PCI SSC listing Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD 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.
Added
p. 15
• 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)
• Manage system components included in the scope of the entity’s PCI DSS 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.
• Could impact the security of the entity’s CDE⎯for example, vendors providing support via remote access, and/or bespoke software developers.
Name of service provider: Description of service(s) provided:
PCI DSS Requirement Requirement Responses More than one response may be selected for a given requirement.
Indicate all responses that apply.
In Place In Place with CCW Not Applicable Not Tested Not in Place
For any Not Tested responses, identify which sub- requirements were not tested and the reason.
• Manage system components included in the scope of the entity’s PCI DSS 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.
• Could impact the security of the entity’s CDE⎯for example, vendors providing support via remote access, and/or bespoke software developers.
Name of service provider: Description of service(s) provided:
PCI DSS Requirement Requirement Responses More than one response may be selected for a given requirement.
Indicate all responses that apply.
In Place In Place with CCW Not Applicable Not Tested Not in Place
For any Not Tested responses, identify which sub- requirements were not tested and the reason.
Added
p. 17
Section 2a: Details about Reviewed Environment 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.
<Insert diagram(s) here - one page/image at a time>
• 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.
<Insert diagram(s) here - one page/image at a time>
Added
p. 18
Data Store Database name, file server name, etc.
Data Store Database name, file server name, etc.
File name(s), Table names(s) and/or Field names Account data elements stored For example, PAN, expiry, name, etc.
How data is secured For example, what type of encryption and strength, etc.
How access to data stores is logged Description of logging mechanism used for logging access to data• for example, describe the enterprise log management solution, application-level logging, operating system logging, etc. in place 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 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.
File name(s), Table names(s) and/or Field names Is SAD stored pre- authorization? Is SAD stored as part of Issuer Functions? How data is secured …
Data Store Database name, file server name, etc.
File name(s), Table names(s) and/or Field names Account data elements stored For example, PAN, expiry, name, etc.
How data is secured For example, what type of encryption and strength, etc.
How access to data stores is logged Description of logging mechanism used for logging access to data• for example, describe the enterprise log management solution, application-level logging, operating system logging, etc. in place 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 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.
File name(s), Table names(s) and/or Field names Is SAD stored pre- authorization? Is SAD stored as part of Issuer Functions? How data is secured …
Added
p. 19
“System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include but are not limited to:
• Systems that store, process, or transmit account data (for example, payment terminals, authorization systems, clearing systems, payment middleware systems, payment back-office systems, shopping cart and store front systems, payment gateway/switch systems, fraud monitoring systems).
• 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 …
• 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).
• 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 …
Added
p. 20
Type of System Component For example, application, firewall, server, IDS, Anti-malware software, database, etc.
Total number of system components How many system components of this type are in scope Vendor Product Name and Version Role/ Function Description
Total number of system components How many system components of this type are in scope Vendor Product Name and Version Role/ Function Description
Added
p. 21
− The most recent scan result was a passing scan, − The entity has documented policies and procedures requiring quarterly scanning going forward, and − Any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan.
For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
Date of the scan(s) Name of ASV that performed the scan Were any vulnerabilities found that resulted in a failed initial scan? For all scans resulting in a Fail, provide date(s) of re-scans showing that the vulnerabilities have been corrected 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 documented policies and procedures requiring quarterly scanning going forward.
Assessor comments, if applicable:
Attestations of scan compliance Scan must cover all externally accessible (Internet-facing) IP addresses in …
For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
Date of the scan(s) Name of ASV that performed the scan Were any vulnerabilities found that resulted in a failed initial scan? For all scans resulting in a Fail, provide date(s) of re-scans showing that the vulnerabilities have been corrected 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 documented policies and procedures requiring quarterly scanning going forward.
Assessor comments, if applicable:
Attestations of scan compliance Scan must cover all externally accessible (Internet-facing) IP addresses in …
Added
p. 22
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.
Added
p. 22
Describe results as instructed in “Requirement Responses” (page v) 1.2 Network security controls (NSCs) are configured and maintained.
Added
p. 22
• Examine configurations standards.
Added
p. 23
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Changes to network connections include the addition, removal, or modification of a connection.
Changes to NSC configurations include those related to the component itself as well as those affecting how it performs its security function.
• Examine network diagrams.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) A current network diagram(s) or other technical or topological solution that identifies network connections and devices can be used to meet this requirement.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable …
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Changes to network connections include the addition, removal, or modification of a connection.
Changes to NSC configurations include those related to the component itself as well as those affecting how it performs its security function.
• Examine network diagrams.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) A current network diagram(s) or other technical or topological solution that identifies network connections and devices can be used to meet this requirement.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable …
Added
p. 24
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe results as instructed in “Requirement Responses” (page v) 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.
Describe results as instructed in “Requirement Responses” (page v) 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.
Added
p. 24
• Examine documentation from reviews performed.
Added
p. 25
• Examine network diagrams.
• Secured from unauthorized access.
• Kept consistent with active network configurations.
• Examine NSC configuration files.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.
• Secured from unauthorized access.
• Kept consistent with active network configurations.
• Examine NSC configuration files.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.
Added
p. 25
• To only traffic that is necessary.
• To only traffic that is necessary.
• All other traffic is specifically denied.
• All other traffic is specifically denied.
• To only traffic that is necessary.
• All other traffic is specifically denied.
• All other traffic is specifically denied.
Added
p. 25
Describe results as instructed in “Requirement Responses” (page v) 1.3.2 Outbound traffic from the CDE is restricted as follows:
Describe results as instructed in “Requirement Responses” (page v) 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 results as instructed in “Requirement Responses” (page v) 1.4 Network connections between trusted and untrusted networks are controlled.
Describe results as instructed in “Requirement Responses” (page v) 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 results as instructed in “Requirement Responses” (page v) 1.4 Network connections between trusted and untrusted networks are controlled.
Added
p. 25
• Examine current network diagrams.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Stateful responses to communications initiated by system components in a trusted network.
All other traffic is denied.
• Examine NSC documentation.
• Examine NSC documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols.
This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC.
Describe results as instructed in “Requirement Responses” (page v) 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.
• Examine the data-flow diagram and network diagram.
Applicability Notes Describe results as instructed in “Requirement …
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Stateful responses to communications initiated by system components in a trusted network.
All other traffic is denied.
• Examine NSC documentation.
• Examine NSC documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols.
This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC.
Describe results as instructed in “Requirement Responses” (page v) 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.
• Examine the data-flow diagram and network diagram.
Applicability Notes Describe results as instructed in “Requirement …
Added
p. 27
• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.
• Security controls are actively running.
• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.
• Examine policies and configuration standards.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active.
This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit.
Requirement 2: Apply Secure Configurations …
• Security controls are actively running.
• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.
• Examine policies and configuration standards.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active.
This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit.
Requirement 2: Apply Secure Configurations …
Added
p. 28
Describe results as instructed in “Requirement Responses” (page v) 2.2 System components are configured and managed securely.
Added
p. 28
• Address all known security vulnerabilities.
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• 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.
PCI DSS Requirement Expected Testing Response2F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Observe a system administrator logging on using vendor default accounts.
• Examine configuration files.
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription …
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• 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.
PCI DSS Requirement Expected Testing Response2F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Observe a system administrator logging on using vendor default accounts.
• Examine configuration files.
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription …
Added
p. 29
• 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.
PCI DSS Requirement Expected Testing Response2F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
Describe results as instructed in “Requirement Responses” (page v) 2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
Describe results as instructed in “Requirement Responses” (page v) 2.2.6 System security parameters are configured to prevent misuse.
Describe results as instructed in “Requirement Responses” (page v) 2.2.7 All non-console administrative access …
• 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.
PCI DSS Requirement Expected Testing Response2F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.
Describe results as instructed in “Requirement Responses” (page v) 2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
Describe results as instructed in “Requirement Responses” (page v) 2.2.6 System security parameters are configured to prevent misuse.
Describe results as instructed in “Requirement Responses” (page v) 2.2.7 All non-console administrative access …
Added
p. 31
• Default wireless encryption keys.
• Passwords on wireless access points.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other security-related wireless vendor defaults.
• 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.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.1 Processes and mechanisms for protecting stored account data are defined and understood.
• Passwords on wireless access points.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This includes, but is not limited to, default wireless encryption keys, passwords on wireless access points, SNMP defaults, and any other security-related wireless vendor defaults.
• 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.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.1 Processes and mechanisms for protecting stored account data are defined and understood.
Added
p. 33
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.2 Storage of account data is kept to a minimum.
Added
p. 33
• 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 its effective date; refer to Applicability Notes below for details.
• 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.
• Examine the data retention and disposal policies, procedures, and processes.
• Examine files and system records on system components where account data is stored.
• Observe the mechanisms used to render account data unrecoverable.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place Applicability Notes (continued) Describe results as instructed in “Requirement Responses” (page v) …
• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
• 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.
• Examine the data retention and disposal policies, procedures, and processes.
• Examine files and system records on system components where account data is stored.
• Observe the mechanisms used to render account data unrecoverable.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place Applicability Notes (continued) Describe results as instructed in “Requirement Responses” (page v) …
Added
p. 34
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement does not apply to issuers and companies that support issuing services (where SAD is needed for a legitimate issuing business need) and have a business justification to store the sensitive authentication data. Refer to Requirement 3.3.3 for additional requirements specifically for issuers.
Sensitive authentication data includes the data cited in Requirements 3.3.1.1 through 3.3.1.3.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.
• Primary account number (PAN).
Sensitive authentication data includes the data cited in Requirements 3.3.1.1 through 3.3.1.3.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.
• Primary account number (PAN).
Added
p. 35
• Examine data sources.
• Examine data sources.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The card verification code is the three- or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions.
• Examine data sources.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The card verification code is the three- or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions.
Added
p. 35
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) PIN blocks are encrypted during the natural course of transaction processes, but even if an entity encrypts the PIN block again, it is still not allowed to be stored after the completion of the authorization process.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria.
This requirement applies to all storage of SAD, even if no PAN is present in the environment.
Refer to Requirement 3.2.1 …
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria.
This requirement applies to all storage of SAD, even if no PAN is present in the environment.
Refer to Requirement 3.2.1 …
Added
p. 37
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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 its effective date; refer to Applicability Notes below for details.
• Examine documented policies.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies only to issuers and companies that support issuing services and store sensitive authentication data. Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support …
• 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 its effective date; refer to Applicability Notes below for details.
• Examine documented policies.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies only to issuers and companies that support issuing services and store sensitive authentication data. Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support …
Added
p. 38
• Examine the documented list of roles that need access to more than the BIN and last four digits of the PAN (includes full PAN).
• Examine displays of PAN (for example, on screen, on paper receipts).
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment brand requirements for point-of-sale (POS) receipts.
This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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 …
• Examine displays of PAN (for example, on screen, on paper receipts).
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment brand requirements for point-of-sale (POS) receipts.
This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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 …
Added
p. 40
• 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
• Strong cryptography with associated key- management processes and procedures.
• Examine documentation about the system used to render PAN unreadable.
• Examine controls to verify that the hashed and truncated PANs cannot be correlated to reconstruct the original PAN.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. This requirement applies to PANs stored in primary storage (databases, or …
• 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
• Strong cryptography with associated key- management processes and procedures.
• Examine documentation about the system used to render PAN unreadable.
• Examine controls to verify that the hashed and truncated PANs cannot be correlated to reconstruct the original PAN.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. This requirement applies to PANs stored in primary storage (databases, or …
Added
p. 45
In cloud HSM implementations, responsibility for the cryptographic architecture according to this Requirement will be shared between the cloud provider and the cloud customer.
The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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 …
The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment.
PCI DSS Requirement Expected Testing Response3F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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 …
Added
p. 47
• Observe the method for generating keys.
Describe results as instructed in “Requirement Responses” (page v) 3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.
• Observe the method for distributing keys.
Describe results as instructed in “Requirement Responses” (page v) 3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.
Describe results as instructed in “Requirement Responses” (page v) 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.
PCI DSS Requirement Expected Testing Response3F (Check one response for each …
Describe results as instructed in “Requirement Responses” (page v) 3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.
• Observe the method for distributing keys.
Describe results as instructed in “Requirement Responses” (page v) 3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.
Describe results as instructed in “Requirement Responses” (page v) 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.
PCI DSS Requirement Expected Testing Response3F (Check one response for each …
Added
p. 52
• 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 its effective date; refer to Applicability Notes below for details.
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) There could be occurrences where an entity receives cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.
A self-signed certificate may also be acceptable if the certificate is …
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) There could be occurrences where an entity receives cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.
A self-signed certificate may also be acceptable if the certificate is …
Added
p. 53
Describe results as instructed in “Requirement Responses” (page v) 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.
• Examine system configurations and vendor documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data.
• Examine system configurations and vendor documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data.
Added
p. 54
PCI DSS Requirement Expected Testing Response5F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
Describe results as instructed in “Requirement Responses” (page v) 5.2 Malicious software (malware) is prevented, or detected and addressed.
Describe results as instructed in “Requirement Responses” (page v) 5.2 Malicious software (malware) is prevented, or detected and addressed.
Added
p. 54
• Examine the periodic evaluations.
Describe results as instructed in “Requirement Responses” (page v) 5.2.2 The deployed anti-malware solution(s):
• Detects all known types of malware.
• Removes, blocks, or contains all known types of malware.
PCI DSS Requirement Expected Testing Response5F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine the list of system components not at risk for malware and compare against the system components without an anti-malware solution deployed.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) System components covered by this requirement are those for …
Describe results as instructed in “Requirement Responses” (page v) 5.2.2 The deployed anti-malware solution(s):
• Detects all known types of malware.
• Removes, blocks, or contains all known types of malware.
PCI DSS Requirement Expected Testing Response5F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine the list of system components not at risk for malware and compare against the system components without an anti-malware solution deployed.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) System components covered by this requirement are those for …
Added
p. 55
• Examine documented results of periodic evaluations.
Added
p. 56
• Performs periodic scans and active or real-time scans OR
• Performs continuous behavioral analysis of systems or processes.
• Examine logs and scan results.
• Examine logs and scan results.
Describe results as instructed in “Requirement Responses” (page v) 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Examine documented results of periodic malware scans.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2.
• Performs continuous behavioral analysis of systems or processes.
• Examine logs and scan results.
• Examine logs and scan results.
Describe results as instructed in “Requirement Responses” (page v) 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Examine documented results of periodic malware scans.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2.
Added
p. 56
• 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.
• Examine anti-malware solution(s) configurations.
• Examine anti-malware solution(s) configurations.
• Examine system components with removable electronic media.
• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.
• Examine anti-malware solution(s) configurations.
• Examine anti-malware solution(s) configurations.
• Examine system components with removable electronic media.
Added
p. 57
PCI DSS Requirement Expected Testing Response5F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti- malware protection is not active.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti- malware protection is not active.
Added
p. 57
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as e-mail servers) are brought into scope for PCI DSS. The focus of this requirement is on protecting personnel with access to system components in-scope for PCI DSS. Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not also meet the requirement for providing personnel with security awareness training, and vice versa.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
Known to all affected parties.
Describe results …
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
Known to all affected parties.
Describe results …
Added
p. 58
• Incorporating consideration of information security issues during each stage of the software development lifecycle.
Added
p. 58
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software.
Added
p. 59
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
• On software security relevant to their job function and development languages.
• Including secure software design and secure coding techniques.
• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Software development personnel remain knowledgeable about secure development practices; software security; and attacks against the languages, frameworks, or applications they develop. Personnel are able to access assistance and guidance when required.
• Code reviews look for both existing and emerging software vulnerabilities.
• On software security relevant to their job function and development languages.
• Including secure software design and secure coding techniques.
• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Software development personnel remain knowledgeable about secure development practices; software security; and attacks against the languages, frameworks, or applications they develop. Personnel are able to access assistance and guidance when required.
• Code reviews look for both existing and emerging software vulnerabilities.
Added
p. 59
• Examine evidence of changes to bespoke and custom software.
Code reviews may be performed using either manual or automated processes, or a combination of both.
• Examine evidence of changes to bespoke and custom software.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
• Reviewed and approved by management prior to release.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel.
An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management.
Code reviews may be performed using either manual or automated processes, or a combination of both.
• Examine evidence of changes to bespoke and custom software.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
• Reviewed and approved by management prior to release.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel.
An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management.
Added
p. 60
• Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
• Interview responsible software development personnel.
• 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. (continued)
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software.
• 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 …
• Interview responsible software development personnel.
• 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. (continued)
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software.
• 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 …
Added
p. 62
• 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.
• 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
• 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
Added
p. 63
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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).
Describe results as instructed in “Requirement Responses” (page v) 6.4 Public-facing web applications are protected against attacks.
• 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).
Describe results as instructed in “Requirement Responses” (page v) 6.4 Public-facing web applications are protected against attacks.
Added
p. 63
• 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
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.4.1 (cont.) (continued)
• 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.
• Actively running and up to date as applicable.
• Generating audit logs.
• Generating audit logs.
• Configured to either block web-based …
• 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
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.4.1 (cont.) (continued)
• 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.
• Actively running and up to date as applicable.
• Generating audit logs.
• Generating audit logs.
• Configured to either block web-based …
Added
p. 65
• 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.5 Changes to all system components are managed securely.
• 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.5 Changes to all system components are managed securely.
Added
p. 66
• Reason for, and description of, the change.
• Documentation of security impact.
• Documented change approval by authorized parties.
• Procedures to address failures and return to a secure state.
• Examine documented change control procedures.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine documentation for significant changes.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2.
• Examine network documentation and configurations of network security controls.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.5.4 Roles and functions are separated between production …
• Documentation of security impact.
• Documented change approval by authorized parties.
• Procedures to address failures and return to a secure state.
• Examine documented change control procedures.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine documentation for significant changes.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2.
• Examine network documentation and configurations of network security controls.
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.5.4 Roles and functions are separated between production …
Added
p. 67
• Observe testing processes for both off-the-shelf software and in-house applications.
• Examine data and accounts for recently installed or updated off-the-shelf software and in-house applications.
Known to all affected parties.
• Examine data and accounts for recently installed or updated off-the-shelf software and in-house applications.
Known to all affected parties.
Added
p. 68
PCI DSS Requirement Expected Testing Response7F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.
Describe results as instructed in “Requirement Responses” (page v) 7.2 Access to system components and data is appropriately defined and assigned.
• Appropriate access depending on the entity’s business and access needs.
PCI DSS Requirement Expected Testing Response7F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 7.2.2 Access is assigned to users, including privileged users, based on:
• Job classification and function.
• Examine user access settings, including for privileged users.
• Interview responsible management personnel.
• Interview personnel responsible for assigning access.
Describe results as instructed in “Requirement Responses” (page v) 7.2.3 Required privileges are approved by authorized personnel.
Describe …
Describe results as instructed in “Requirement Responses” (page v) 7.2 Access to system components and data is appropriately defined and assigned.
• Appropriate access depending on the entity’s business and access needs.
PCI DSS Requirement Expected Testing Response7F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 7.2.2 Access is assigned to users, including privileged users, based on:
• Job classification and function.
• Examine user access settings, including for privileged users.
• Interview responsible management personnel.
• Interview personnel responsible for assigning access.
Describe results as instructed in “Requirement Responses” (page v) 7.2.3 Required privileges are approved by authorized personnel.
Describe …
Added
p. 70
• 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.
• Examine documented results of periodic reviews of system and application accounts and related privileges.
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts.
PCI DSS Requirement Expected Testing Response7F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• The application/system access remains appropriate for the function being performed.
• Examine documented results of periodic reviews of system and application accounts and related privileges.
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts.
PCI DSS Requirement Expected Testing Response7F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 7.2.6 All user access to query repositories of stored cardholder data is restricted as follows:
• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.
• Only the responsible administrator(s) can directly access or query repositories of stored CHD.
Added
p. 71
• Examine configuration settings for querying repositories of stored cardholder data.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to controls for user access to query repositories of stored cardholder data.
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe how the results of the testing performed support the selected response †:
Describe how the results of the testing performed support the selected response †:
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to controls for user access to query repositories of stored cardholder data.
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe how the results of the testing performed support the selected response †:
Describe how the results of the testing performed support the selected response †:
Added
p. 72
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.
Describe results as instructed in “Requirement Responses” (page v) 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
• Examine audit logs and other evidence.
Describe results as instructed in “Requirement Responses” (page v) 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
• Examine audit logs and other evidence.
Added
p. 73
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
• Account use is prevented unless needed for an exceptional circumstance.
• Use is limited to the time needed for the exceptional circumstance.
• Business justification for use is documented.
• Use is explicitly approved by management.
• Individual user identity is confirmed before access to an account is granted.
• Every action taken is attributable to an individual user.
• 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 individual user.
Added
p. 73
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies only when the entity being assessed is a service provider. This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted.
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions).
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all user accounts, …
If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions).
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all user accounts, …
Added
p. 75
• 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.
• Examine documentation describing the authentication factor(s) used.
• For each type of authentication factor used with each type of system component, observe the authentication process.
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements.
A digital certificate is a valid option for “something you have” if it is unique for a particular user
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
• Examine repositories of authentication factors.
Describe results as instructed in “Requirement Responses” (page v) 8.3.3 User identity …
• Something you have, such as a token device or smart card.
• Something you are, such as a biometric element.
• Examine documentation describing the authentication factor(s) used.
• For each type of authentication factor used with each type of system component, observe the authentication process.
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements.
A digital certificate is a valid option for “something you have” if it is unique for a particular user
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
• Examine repositories of authentication factors.
Describe results as instructed in “Requirement Responses” (page v) 8.3.3 User identity …
Added
p. 76
• Set to a unique value for first-time use and upon reset.
• Forced to be changed immediately after the first use.
• Examine procedures for setting and resetting passwords/passphrases.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) 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 (such as IDs used by cashiers on point-of-sale terminals).
• Application or system …
• Forced to be changed immediately after the first use.
• Examine procedures for setting and resetting passwords/passphrases.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) 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 (such as IDs used by cashiers on point-of-sale terminals).
• Application or system …
Added
p. 78
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.3.8 Authentication policies and procedures are documented and communicated to all users including:
• Guidance on selecting strong authentication factors.
• Guidance for how users should protect their authentication factors.
• Instructions not to reuse previously used passwords/passphrases.
• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
• Examine procedures.
Describe results as instructed in “Requirement Responses” (page v) 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single- factor authentication implementation) then either:
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to in-scope system components that …
• Guidance on selecting strong authentication factors.
• Guidance for how users should protect their authentication factors.
• Instructions not to reuse previously used passwords/passphrases.
• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
• Examine procedures.
Describe results as instructed in “Requirement Responses” (page v) 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single- factor authentication implementation) then either:
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to in-scope system components that …
Added
p. 79
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.3.10 Additional requirement for service providers only:
If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including:
• Guidance for customers to change their user passwords/passphrases periodically.
• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
• Examine guidance provided to customer users.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective.
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
PCI …
If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including:
• Guidance for customers to change their user passwords/passphrases periodically.
• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
• Examine guidance provided to customer users.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective.
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
This requirement does not apply to accounts of consumer users accessing their own payment card information.
PCI …
Added
p. 80
• 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.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement for MFA for non-console administrative access applies to all personnel with elevated or increased privileges accessing the CDE via a non-console connection• that is, via logical access occurring over a network interface rather than via a direct, physical connection.
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
• User accounts on point-of-sale terminals that have access to only one card number …
• Physical and/or logical controls ensure only the intended user can use that factor to gain access.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement for MFA for non-console administrative access applies to all personnel with elevated or increased privileges accessing the CDE via a non-console connection• that is, via logical access occurring over a network interface rather than via a direct, physical connection.
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
• User accounts on point-of-sale terminals that have access to only one card number …
Added
p. 84
• The MFA system is not susceptible to replay attacks.
• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
• At least two different types of authentication factors are used.
• Success of all authentication factors is required before access is granted.
• Examine system configurations for the MFA implementation.
• Interview responsible personnel and observe processes.
• Observe personnel logging into system components in the CDE.
• Every action taken is attributable to an individual user.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.6 Use of application and system accounts and associated authentication factors is strictly managed.
• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
• At least two different types of authentication factors are used.
• Success of all authentication factors is required before access is granted.
• Examine system configurations for the MFA implementation.
• Interview responsible personnel and observe processes.
• Observe personnel logging into system components in the CDE.
• Every action taken is attributable to an individual user.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 8.6 Use of application and system accounts and associated authentication factors is strictly managed.
Added
p. 85
• Interactive use is prevented unless needed for an exceptional circumstance.
• Interactive use is limited to the time needed for the exceptional circumstance.
• Business justification for interactive use is documented.
• Interactive use is explicitly approved by management.
• Individual user identity is confirmed before access to account is granted.
• Examine application and system accounts that can be used interactively.
• Interview administrative personnel.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Stored passwords/passphrases are required …
• Interactive use is limited to the time needed for the exceptional circumstance.
• Business justification for interactive use is documented.
• Interactive use is explicitly approved by management.
• Individual user identity is confirmed before access to account is granted.
• Examine application and system accounts that can be used interactively.
• Interview administrative personnel.
PCI DSS Requirement Expected Testing Response8F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine scripts, configuration/property files, and bespoke and custom source code for application and system accounts that can be used for interactive login.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Stored passwords/passphrases are required …
Added
p. 86
• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
Describe results as instructed in “Requirement Responses” (page v) 9.2 Physical access controls manage entry into facilities and systems containing cardholder data.
• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
Describe results as instructed in “Requirement Responses” (page v) 9.2 Physical access controls manage entry into facilities and systems containing cardholder data.
Added
p. 88
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.2.1.1 Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows:
• Entry and exit points to/from sensitive areas within the CDE are monitored.
• Collected data is reviewed and correlated with other entries.
• Observe locations where individual physical access to sensitive areas within the CDE occurs.
• Observe the physical access control mechanisms and/or examine video cameras.
Describe results as instructed in “Requirement Responses” (page v) 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
• Observe locations of publicly accessible network jacks.
Describe results as instructed in “Requirement Responses” (page v) 9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the …
• Entry and exit points to/from sensitive areas within the CDE are monitored.
• Collected data is reviewed and correlated with other entries.
• Observe locations where individual physical access to sensitive areas within the CDE occurs.
• Observe the physical access control mechanisms and/or examine video cameras.
Describe results as instructed in “Requirement Responses” (page v) 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
• Observe locations of publicly accessible network jacks.
Describe results as instructed in “Requirement Responses” (page v) 9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the …
Added
p. 89
• 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.
Describe results as instructed in “Requirement Responses” (page v) 9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled as follows:
• Access is revoked immediately upon termination.
• Observe personnel in sensitive areas within the CDE.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Observe processes when visitors are present in the CDE.
Describe results as instructed in “Requirement Responses” (page v) 9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.
PCI DSS Requirement Expected …
• 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.
Describe results as instructed in “Requirement Responses” (page v) 9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled as follows:
• Access is revoked immediately upon termination.
• Observe personnel in sensitive areas within the CDE.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Observe processes when visitors are present in the CDE.
Describe results as instructed in “Requirement Responses” (page v) 9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration.
PCI DSS Requirement Expected …
Added
p. 90
Describe results as instructed in “Requirement Responses” (page v) 9.4.1.1 Offline media backups with cardholder data are stored in a secure location.
• Interview responsible personnel at the storge location(s).
Describe results as instructed in “Requirement Responses” (page v) 9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.
• Examine documented procedures, logs, or other documentation.
• Interview responsible personnel at the storage location(s).
Describe results as instructed in “Requirement Responses” (page v) 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.
• Examine media logs or other documentation.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.4.3 Media with cardholder data sent outside the facility is secured as follows:
• Media sent outside the facility is logged.
• Offsite tracking logs include details …
• Interview responsible personnel at the storge location(s).
Describe results as instructed in “Requirement Responses” (page v) 9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.
• Examine documented procedures, logs, or other documentation.
• Interview responsible personnel at the storage location(s).
Describe results as instructed in “Requirement Responses” (page v) 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.
• Examine media logs or other documentation.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.4.3 Media with cardholder data sent outside the facility is secured as follows:
• Media sent outside the facility is logged.
• Offsite tracking logs include details …
Added
p. 92
• The electronic media is destroyed.
• The cardholder data is rendered unrecoverable so that it cannot be reconstructed.
• Examine the periodic media destruction policy.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.
• The cardholder data is rendered unrecoverable so that it cannot be reconstructed.
• Examine the periodic media destruction policy.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.
Added
p. 93
• Maintaining a list of POI devices.
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards.
This requirement is recommended, but not required, for manual PAN key-entry components such as computer keyboards.
This requirement does not apply to commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards.
This requirement is recommended, but not required, for manual PAN key-entry components such as computer keyboards.
This requirement does not apply to commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.
Added
p. 93
• Make and model of the device.
• Location of device.
• Device serial number or other methods of unique identification.
• Examine the list of POI devices.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.
Describe results as instructed in “Requirement Responses” (page v) 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Examine documented results of periodic device inspections.
• Location of device.
• Device serial number or other methods of unique identification.
• Examine the list of POI devices.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.
Describe results as instructed in “Requirement Responses” (page v) 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Examine documented results of periodic device inspections.
Added
p. 95
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
Describe results as instructed in “Requirement Responses” (page v) 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
Describe results as instructed in “Requirement Responses” (page v) 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
Added
p. 95
• Interview the system administrator.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.1 Audit logs capture all individual user access to cardholder data.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.3 Audit logs capture all access to audit logs.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.1 Audit logs capture all individual user access to cardholder data.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.3 Audit logs capture all access to audit logs.
Added
p. 96
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.4 Audit logs capture all invalid logical access attempts.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to:
• Creation of new accounts.
• All changes, additions, or deletions to accounts with administrative access.
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.7 Audit logs capture all creation and deletion of system-level objects.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.2.2 Audit logs record the following details for each auditable event:
• User identification.
Describe results as instructed in “Requirement Responses” (page …
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to:
• Creation of new accounts.
• All changes, additions, or deletions to accounts with administrative access.
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe results as instructed in “Requirement Responses” (page v) 10.2.1.7 Audit logs capture all creation and deletion of system-level objects.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.2.2 Audit logs record the following details for each auditable event:
• User identification.
Describe results as instructed in “Requirement Responses” (page …
Added
p. 98
• Examine documented results of log reviews.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine documented results of periodic log reviews.
Describe results as instructed in “Requirement Responses” (page v) 10.5 Audit log history is retained and available for analysis.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine documented results of periodic log reviews.
Describe results as instructed in “Requirement Responses” (page v) 10.5 Audit log history is retained and available for analysis.
Added
p. 99
• Examine documented audit log retention policies and procedures.
• Examine configurations of audit log history.
Describe results as instructed in “Requirement Responses” (page v) 10.6 Time-synchronization mechanisms support consistent time settings across all systems.
• Examine configurations of audit log history.
Describe results as instructed in “Requirement Responses” (page v) 10.6 Time-synchronization mechanisms support consistent time settings across all systems.
Added
p. 99
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Keeping time-synchronization technology current includes managing vulnerabilities and patching the technology according to PCI DSS Requirements 6.3.1 and 6.3.3.
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.6.2 Systems are configured to the correct and consistent time as follows:
• One or more designated time servers are in use.
• Only the designated central time server(s) receives time from external sources.
• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).
• The designated time server(s) accept time updates only from specific industry-accepted external sources.
• Examine system configuration settings for acquiring, distributing, and storing the correct time.
Describe results as instructed in “Requirement Responses” (page v) 10.6.3 Time synchronization settings and data are protected as follows:
• Examine system configurations and time-synchronization …
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.6.2 Systems are configured to the correct and consistent time as follows:
• One or more designated time servers are in use.
• Only the designated central time server(s) receives time from external sources.
• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).
• The designated time server(s) accept time updates only from specific industry-accepted external sources.
• Examine system configuration settings for acquiring, distributing, and storing the correct time.
Describe results as instructed in “Requirement Responses” (page v) 10.6.3 Time synchronization settings and data are protected as follows:
• Examine system configurations and time-synchronization …
Added
p. 101
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Added
p. 101
• Anti-malware solutions.
• Physical access controls.
• Logical access controls.
• Segmentation controls (if used).
This requirement will be superseded by Requirement 10.7.2 once as of 31 March 2025.
• Anti-malware solutions.
• Physical access controls.
• Logical access controls.
• Segmentation controls (if used).
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
• Change-detection mechanisms.
• Audit logging mechanisms.
• Audit log review mechanisms.
• Automated security testing tools (if used).
• Examine documented processes.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
PCI DSS Requirement Expected …
• Physical access controls.
• Logical access controls.
• Segmentation controls (if used).
This requirement will be superseded by Requirement 10.7.2 once as of 31 March 2025.
• Anti-malware solutions.
• Physical access controls.
• Logical access controls.
• Segmentation controls (if used).
PCI DSS Requirement Expected Testing Response10F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
• Change-detection mechanisms.
• Audit logging mechanisms.
• Audit log review mechanisms.
• Automated security testing tools (if used).
• Examine documented processes.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
PCI DSS Requirement Expected …
Added
p. 104
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
Added
p. 105
• The presence of wireless (Wi-Fi) access points is tested for.
• Testing, detection, and identification occurs at least once every three months.
• If automated monitoring is used, personnel are notified via generated alerts.
• Examine the methodology(ies) in use and the resulting documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement applies even when a policy exists that prohibits the use of wireless technology since attackers do not read and follow company policy.
Methods used to meet this requirement must be sufficient to detect and identify both authorized and unauthorized devices, including unauthorized devices attached to devices that themselves are authorized.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
• At least once every three months.
• High-risk and critical vulnerabilities (per the …
• Testing, detection, and identification occurs at least once every three months.
• If automated monitoring is used, personnel are notified via generated alerts.
• Examine the methodology(ies) in use and the resulting documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement applies even when a policy exists that prohibits the use of wireless technology since attackers do not read and follow company policy.
Methods used to meet this requirement must be sufficient to detect and identify both authorized and unauthorized devices, including unauthorized devices attached to devices that themselves are authorized.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
• At least once every three months.
• High-risk and critical vulnerabilities (per the …
Added
p. 107
• Examine internal scan report results or other documentation.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized.
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine scan report results.
• Examine accounts used for authenticated scanning.
• Sufficient privileges are used for those systems that accept credentials for scanning.
• If accounts used for authenticated scanning can be used for …
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized.
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
• Examine scan report results.
• Examine accounts used for authenticated scanning.
• Sufficient privileges are used for those systems that accept credentials for scanning.
• If accounts used for authenticated scanning can be used for …
Added
p. 108
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
• Examine internal scan and rescan report as applicable.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Authenticated internal vulnerability scanning per Requirement 11.3.1.2 is not required for scans performed after significant changes.
• At least once every three months.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
• Examine ASV scan reports.
However, for subsequent years after the initial PCI DSS assessment, passing …
• Examine internal scan and rescan report as applicable.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Authenticated internal vulnerability scanning per Requirement 11.3.1.2 is not required for scans performed after significant changes.
• At least once every three months.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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.
Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
• Examine ASV scan reports.
However, for subsequent years after the initial PCI DSS assessment, passing …
Added
p. 110
• Industry-accepted penetration testing approaches.
• Coverage for the entire CDE perimeter and critical systems.
• Testing from both inside and outside the network.
• Testing to validate any segmentation and scope-reduction controls.
• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
• Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
• Review and consideration of threats and vulnerabilities experienced in the last 12 months.
• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
• Retention of penetration testing results and remediation activities results for at least 12 months.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.4.1 (cont.) Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into …
• Coverage for the entire CDE perimeter and critical systems.
• Testing from both inside and outside the network.
• Testing to validate any segmentation and scope-reduction controls.
• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
• Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
• Review and consideration of threats and vulnerabilities experienced in the last 12 months.
• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
• Retention of penetration testing results and remediation activities results for at least 12 months.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 11.4.1 (cont.) Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into …
Added
p. 111
• Per the entity’s defined methodology.
• Per the entity’s defined methodology.
• At least once every 12 months.
• At least once every 12 months.
• After any significant infrastructure or application upgrade or change.
• After any significant infrastructure or application upgrade or change.
• By a qualified internal resource or qualified external third-party
• By a qualified internal resource or qualified external third-party
• Per the entity’s defined methodology.
• At least once every 12 months.
• At least once every 12 months.
• After any significant infrastructure or application upgrade or change.
• After any significant infrastructure or application upgrade or change.
• By a qualified internal resource or qualified external third-party
• By a qualified internal resource or qualified external third-party
Added
p. 111
• Examine scope of work.
• Examine scope of work.
Describe results as instructed in “Requirement Responses” (page v) 11.4.3 External penetration testing is performed:
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine penetration testing results.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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
• According to the entity’s defined penetration testing methodology.
• Confirming effectiveness of any use of isolation to …
• Examine scope of work.
Describe results as instructed in “Requirement Responses” (page v) 11.4.3 External penetration testing is performed:
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine penetration testing results.
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 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
• According to the entity’s defined penetration testing methodology.
• Confirming effectiveness of any use of isolation to …
Added
p. 117
• 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.
• Examine system settings and mechanism configuration settings.
• Examine monitored payment pages.
• Examine the mechanism configuration settings.
• If applicable, examine the targeted risk analysis.
• 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
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column to prevent and detect unexpected script activities.
• Examine system settings and mechanism configuration settings.
• Examine monitored payment pages.
• Examine the mechanism configuration settings.
• If applicable, examine the targeted risk analysis.
• 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
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column to prevent and detect unexpected script activities.
Added
p. 118
Requirement 12: Support Information Security with Organizational Policies and Programs
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.
Added
p. 118
• Disseminated to all relevant personnel, as well as to relevant vendors and business partners.
Added
p. 118
Describe results as instructed in “Requirement Responses” (page v) 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
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine documented evidence.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.2 Acceptable use policies for end-user technologies are defined and implemented.
• List of products approved by the company for employee use, including hardware and software.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Examples of end-user technologies for which acceptable use policies are expected include, but are not limited to, remote …
• Reviewed at least once every 12 months.
• Updated as needed to reflect changes to business objectives or risks to the environment
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine documented evidence.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.2 Acceptable use policies for end-user technologies are defined and implemented.
• List of products approved by the company for employee use, including hardware and software.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) Examples of end-user technologies for which acceptable use policies are expected include, but are not limited to, remote …
Added
p. 120
• Identification of the assets being protected.
• Identification of the threat(s) that the requirement is protecting against.
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed
• Performance of updated risk analyses when needed, as determined by the annual review.
• Identification of the threat(s) that the requirement is protecting against.
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed
• Performance of updated risk analyses when needed, as determined by the annual review.
Added
p. 121
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.
• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.
• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.3.4 Hardware and software technologies in use are …
• 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.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.3.4 Hardware and software technologies in use are …
Added
p. 125
• Examine the inventory.
Describe results as instructed in “Requirement Responses” (page v) 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.
Describe results as instructed in “Requirement Responses” (page v) 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.
Added
p. 125
At a minimum, the scoping validation includes:
• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).
• Updating all data-flow diagrams per requirement 1.2.4. (continued)
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
• 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 …
• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).
• Updating all data-flow diagrams per requirement 1.2.4. (continued)
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
• 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 …
Added
p. 128
• Reviewed at least once every 12 months, and
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data.
• Examine evidence of reviews.
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data.
• Examine evidence of reviews.
Added
p. 128
• Upon hire and at least once every 12 months.
• Multiple methods of communication are used.
• Interview applicable personnel.
• Examine personnel acknowledgements.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine security awareness training content.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) See Requirement 5.4.1 in PCI DSS for guidance on the difference between technical and automated controls to detect and protect users from phishing attacks, and this requirement for providing users security awareness training about phishing and social engineering. These are two separate and distinct requirements, and one is not met by implementing controls required by the other one.
• Examine security awareness training content.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place …
• Multiple methods of communication are used.
• Interview applicable personnel.
• Examine personnel acknowledgements.
Describe results as instructed in “Requirement Responses” (page v) 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.
• Examine security awareness training content.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) See Requirement 5.4.1 in PCI DSS for guidance on the difference between technical and automated controls to detect and protect users from phishing attacks, and this requirement for providing users security awareness training about phishing and social engineering. These are two separate and distinct requirements, and one is not met by implementing controls required by the other one.
• Examine security awareness training content.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place …
Added
p. 129
• Examine list of TPSPs.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) 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.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.8.2 Written agreements with TPSPs are maintained as follows:
• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Applicability Notes Describe results as instructed in “Requirement …
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) 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.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.8.2 Written agreements with TPSPs are maintained as follows:
• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Applicability Notes Describe results as instructed in “Requirement …
Added
p. 134
• 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 its effective date; refer to Applicability Notes below for details.
• Detection of unauthorized wireless access points.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The bullet above (for monitoring and responding to alerts from a change- and tamper- detection mechanism for payment pages) 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.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
• Examine the security incident response plan.
Describe results as instructed …
• Change-detection mechanisms for critical files.
• The change-and tamper-detection mechanism for payment pages. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
• Detection of unauthorized wireless access points.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) The bullet above (for monitoring and responding to alerts from a change- and tamper- detection mechanism for payment pages) 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.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
• Examine the security incident response plan.
Describe results as instructed …
Added
p. 142
Note: This can be, but is not required to be, the stated Customized Approach Objective listed for this requirement in PCI DSS.
Added
p. 143
Requirement 3.5.1 Account data is never stored electronically
Added
p. 145
Indicate below whether a full or partial PCI DSS assessment was completed:
Full
• All requirements have been assessed therefore no requirements were marked as Not Tested in the SAQ.
Partial
• One or more requirements have not been assessed and were therefore marked as Not Tested in the SAQ. Any requirement not assessed is noted as Not Tested in Part 2g above.
Compliant but with Legal exception: One or more assessed requirements in the PCI DSS SAQ 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 1) In Place, 2) In Place with CCW, or 3) Not Applicable, resulting in an overall COMPLIANT BUT WITH LEGAL EXCEPTION rating; thereby (Service Provider Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ except those noted as Not Tested above or as Not …
Full
• All requirements have been assessed therefore no requirements were marked as Not Tested in the SAQ.
Partial
• One or more requirements have not been assessed and were therefore marked as Not Tested in the SAQ. Any requirement not assessed is noted as Not Tested in Part 2g above.
Compliant but with Legal exception: One or more assessed requirements in the PCI DSS SAQ 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 1) In Place, 2) In Place with CCW, or 3) Not Applicable, resulting in an overall COMPLIANT BUT WITH LEGAL EXCEPTION rating; thereby (Service Provider Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ except those noted as Not Tested above or as Not …
Added
p. 147
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 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 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 …
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 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 …
Removed
p. 1
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers SAQ-Eligible Service Providers For use with PCI DSS Version 3.2.1 Revision 2
Removed
p. 2
This document aligns with PCI DSS v3.2.1 r1.
Removed
p. 4
While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. See the guidance below for information about the exclusion of certain, specific requirements.
Section 2
• PCI DSS Self-Assessment Questionnaire (SAQ D)
Section 3 (Parts 3 & 4 of the AOC)
• Validation and Attestation Details and Action Plan for Non-Compliant Requirements (if applicable) Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation
•such as ASV scan reports
•to the payment brand, or other requester.
Understanding the Self-Assessment Questionnaire The questions contained in the “PCI DSS Question” column in this self-assessment questionnaire are based on the requirements in the PCI DSS.
Additional resources that provide guidance on PCI DSS requirements and how to complete the self- assessment questionnaire have been provided to assist with the assessment process. An overview of some of …
Section 2
• PCI DSS Self-Assessment Questionnaire (SAQ D)
Section 3 (Parts 3 & 4 of the AOC)
• Validation and Attestation Details and Action Plan for Non-Compliant Requirements (if applicable) Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation
•such as ASV scan reports
•to the payment brand, or other requester.
Understanding the Self-Assessment Questionnaire The questions contained in the “PCI DSS Question” column in this self-assessment questionnaire are based on the requirements in the PCI DSS.
Additional resources that provide guidance on PCI DSS requirements and how to complete the self- assessment questionnaire have been provided to assist with the assessment process. An overview of some of …
Modified
p. 4 → 5
PCI DSS Self-Assessment Completion Steps Confirm that your environment is properly scoped.
PCI DSS Self-Assessment Completion Steps
Modified
p. 4 → 5
Assess your environment for compliance with PCI DSS requirements.
3. Assess environment for compliance with PCI DSS requirements.
Modified
p. 4 → 5
Complete all sections of this document:
4. Complete all sections of this document:
Modified
p. 4 → 5
•
• Contact Information and Executive Summary).
Removed
p. 5
Completing the Self-Assessment Questionnaire For each question, there is a choice of responses to indicate your company’s status regarding that requirement. Only one response should be selected for each question.
(Not Applicable) The requirement does not apply to the organization’s environment. (See Guidance for Non-Applicability of Certain, Specific Requirements below for examples.) All responses in this column require a supporting explanation in Appendix C of the SAQ.
Guidance for Non-Applicability of Certain, Specific Requirements While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology. Similarly, an organization that does not store any cardholder data electronically at any …
(Not Applicable) The requirement does not apply to the organization’s environment. (See Guidance for Non-Applicability of Certain, Specific Requirements below for examples.) All responses in this column require a supporting explanation in Appendix C of the SAQ.
Guidance for Non-Applicability of Certain, Specific Requirements While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology. Similarly, an organization that does not store any cardholder data electronically at any …
Modified
p. 5 → 6
A description of the meaning for each response is provided in the table below:
A description of the meaning for each response and how to report the testing performed is provided in the table below:
Modified
p. 5 → 6
Service Provider Required Reporting In Place The expected testing has been performed, and all elements of the requirement have been met as stated.
Modified
p. 5 → 6
In Place with (Compensating Controls Worksheet) The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.
Modified
p. 5 → 6
All responses in this column require completion of a Compensating Control Worksheet (CCW) in Appendix B of the SAQ.
All responses in this column also require completion of a Compensating Controls Worksheet (CCW) in Appendix B of this SAQ.
Modified
p. 5 → 6
Information on the use of compensating controls and guidance on how to complete the worksheet is provided in the PCI DSS.
Information on the use of compensating controls and guidance on how to complete the CCW is provided in PCI DSS Appendices B and C.
Modified
p. 5 → 6
Not in Place Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before the entity can confirm they are in place. This response is also used if a requirement cannot be met due to a legal restriction. (See “Legal Exception” below for more guidance).
Modified
p. 5 → 6
Not Tested The requirement was not included for consideration in the assessment, and was not tested in any way. (See Understanding the difference between Not Applicable and Not Tested below for examples of when this option should be used.) All responses in this column require a supporting explanation in Appendix D of the SAQ.
Not Tested The requirement was not included for consideration in the assessment and was not tested in any way. (See “Understanding the Difference between Not Applicable and Not Tested” below for examples of when this option should be used.) Briefly describe why this requirement was excluded from the assessment.
Removed
p. 6
The questions specific to securing wireless technologies (for example, Requirements 1.2.3, 2.1.1, and 4.1.1) only need to be answered if wireless is present anywhere in your network. Note that Requirement 11.1 (use of processes to identify unauthorized wireless access points) must still be answered even if you don’t use wireless technologies in your network, since the process detects any rogue or unauthorized devices that may have been added without your knowledge.
The questions specific to application development and secure coding (Requirements 6.3 and 6.5) only need to be answered if your organization develops its own custom applications.
The questions for Requirements 9.1.1 and 9.3 only need to be answered for facilities with “sensitive areas” as defined here: “Sensitive areas” refers to 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 …
The questions specific to application development and secure coding (Requirements 6.3 and 6.5) only need to be answered if your organization develops its own custom applications.
The questions for Requirements 9.1.1 and 9.3 only need to be answered for facilities with “sensitive areas” as defined here: “Sensitive areas” refers to 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 …
Modified
p. 6 → 7
Understanding the difference between Not Applicable and Not Tested Requirements that are deemed to be not applicable to an environment must be verified as such. Using the wireless example above, for an organization to select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, the organization would first need to confirm that there are no wireless technologies used in their cardholder data environment (CDE) or that connect to their CDE. Once this has been confirmed, the organization may select “N/A” for those …
Understanding the Difference between Not Applicable and Not Tested Requirements that are deemed to be not applicable to an environment must be verified as such. Using the wireless example above, for an entity to select “Not Applicable” for Requirements 1.3.3, 2.3.1, 2.3.2, and 4.2.1.2, the entity first needs to confirm that there are no wireless technologies used in their cardholder data environment (CDE) or that connect to their CDE. Once this has been confirmed, the organization may select “Not Applicable” …
Modified
p. 6 → 7
An organization may be asked by their acquirer to validate a subset of requirements•for example: using the prioritized approach to validate certain milestones.
• An entity is asked by their acquirer to validate a subset of requirements
•for example, using the PCI DSS Prioritized Approach to validate only certain milestones.
•for example, using the PCI DSS Prioritized Approach to validate only certain milestones.
Modified
p. 6 → 7
A service provider organization might offer a service which covers only a limited number of PCI DSS requirements•for example, a physical storage provider may only wish to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.
• A service provider organization offers a service which covers only a limited number of PCI DSS requirements
•for example, a physical storage provider that is only confirming the physical security controls per PCI DSS Requirement 9 for their storage facility.
•for example, a physical storage provider that is only confirming the physical security controls per PCI DSS Requirement 9 for their storage facility.
Modified
p. 6 → 7
In these scenarios, the organization only wishes to validate certain PCI DSS requirements even though other requirements might also apply to their environment.
In these scenarios, the entity’s assessment only includes certain PCI DSS requirements even though other requirements might also apply to their environment.
Modified
p. 6 → 8
Legal Exception If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, check the “No” column for that requirement and complete the relevant attestation in Part 3.
Legal Exception If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, select Not in Place for that requirement and complete the relevant attestation in Section 3, Part 3 of this SAQ.
Removed
p. 7
Part 1. Service Provider and Qualified Security Assessor Information Part 1a. Service Provider Organization Information Company Name: DBA (doing business as):
Business Address: City:
Business Address: City:
State/Province: Country: Zip:
State/Province: Country: Zip:
Lead QSA Contact Name: Title:
Business Address: City:
Business Address: City:
State/Province: Country: Zip:
State/Province: Country: Zip:
Lead QSA Contact Name: Title:
Modified
p. 7 → 10
Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the service provider’s self-assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS). Complete all sections: The service provider is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact the requesting payment brand for reporting and submission procedures.
Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the entity’s self-assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures. Complete all sections: The entity is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact the entity(ies) to which the Attestation of Compliance (AOC) will be submitted for reporting and submission procedures.
Modified
p. 7 → 10
Qualified Security Assessor Company name:
Removed
p. 8
Managed Services (specify):
Modified
p. 8 → 11
Applications / software Infrastructure / Network Physical space (co-location) Security services 3-D Secure Hosting Provider Shared Hosting Provider Other Hosting (specify):
Applications / software Infrastructure / Network Physical space (co-location) Web-hosting services Security services 3-D Secure Hosting Provider Multi-Tenant Service Provider Other Hosting (specify):
Modified
p. 8 → 11
POI / card present Internet / e-commerce MOTO / Call Center Other processing (specify):
Modified
p. 8 → 11
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 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.
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.
Removed
p. 9
Managed Services (specify):
Part 2c. Locations List types of facilities (for example, retail outlets, corporate offices, data centers, call centers, etc.) and a summary of locations included in the PCI DSS review.
Part 2c. Locations List types of facilities (for example, retail outlets, corporate offices, data centers, call centers, etc.) and a summary of locations included in the PCI DSS review.
Modified
p. 9 → 12
Applications / software Hardware Infrastructure / Network Physical space (co-location) Storage Web Security services 3-D Secure Hosting Provider Shared Hosting Provider Other Hosting (specify):
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):
Modified
p. 9 → 12
POI / card present Internet / e-commerce MOTO / Call Center ATM Other processing (specify):
Modified
p. 9 → 12
Part 2b. Description of Payment Card Business Describe how and in what capacity your business stores, processes, and/or transmits cardholder data.
Part 2b. Description of Role with Payment Cards Describe how the business stores, processes, and/or transmits account data.
Modified
p. 9 → 12
Describe how and in what capacity your business is otherwise involved in or has the ability to impact the security of cardholder data.
Describe how the business is otherwise involved in or has the ability to impact the security of its customers’ account data.
Modified
p. 9 → 13
Type of facility Number of facilities of this type Location(s) of facility (city, country) Example: Retail outlets 3 Boston, MA, USA
Facility Type Total number of (How many locations of this type are in scope) Location(s) of facility (city, country) Example: Data centers 3 Boston, MA, USA
Removed
p. 10
Payment Application Version Number Application Is application PA-DSS Listed? PA-DSS Listing Expiry date (if applicable) Part 2e. Description of 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). Critical system components within the CDE, such as POS devices, databases, web servers, etc., and any other necessary payment components, as applicable.
Does your business use network segmentation to affect the scope of your PCI DSS environment? (Refer to “Network Segmentation” section of PCI DSS for guidance on network segmentation.) Part 2f. Third-Party Service Providers Does your company have a relationship with a Qualified Integrator Reseller (QIR) for the purpose of the services being validated? Description of services provided by QIR:
For example: Connections into and out of the cardholder data environment (CDE). Critical system components within the CDE, such as POS devices, databases, web servers, etc., and any other necessary payment components, as applicable.
Does your business use network segmentation to affect the scope of your PCI DSS environment? (Refer to “Network Segmentation” section of PCI DSS for guidance on network segmentation.) Part 2f. Third-Party Service Providers Does your company have a relationship with a Qualified Integrator Reseller (QIR) for the purpose of the services being validated? Description of services provided by QIR:
Removed
p. 12
Full
• The requirement and all sub-requirements were assessed for that Requirement, and no sub- requirements were marked as “Not Tested” or “Not Applicable” in the SAQ.
Partial
• One or more sub-requirements of that Requirement were marked as “Not Tested” or “Not Applicable” in the SAQ.
None
• All sub-requirements of that Requirement were marked as “Not Tested” and/or “Not Applicable” in the SAQ.
Details of specific sub-requirements that were marked as either “Not Tested” and/or “Not Applicable” in the SAQ Reason why sub-requirement(s) were not tested or not applicable
• The requirement and all sub-requirements were assessed for that Requirement, and no sub- requirements were marked as “Not Tested” or “Not Applicable” in the SAQ.
Partial
• One or more sub-requirements of that Requirement were marked as “Not Tested” or “Not Applicable” in the SAQ.
None
• All sub-requirements of that Requirement were marked as “Not Tested” and/or “Not Applicable” in the SAQ.
Details of specific sub-requirements that were marked as either “Not Tested” and/or “Not Applicable” in the SAQ Reason why sub-requirement(s) were not tested or not applicable
Modified
p. 12 → 16
For all requirements identified as either “Partial” or “None,” provide details in the “Justification for Approach” column, including:
For all requirements identified as either “Not Applicable” or “Not Tested,” complete the “Justification for Approach” table below.
Modified
p. 12 → 16
Justification for Approach For any Not Applicable responses, identify which sub- requirements were not applicable and the reason.
Removed
p. 13
Is there a process to ensure the diagram is kept current? Interview responsible personnel.
Modified
p. 13 → 22
Section 2: Self-Assessment Questionnaire D for Service Providers
Section 2b: Self-Assessment Questionnaire D for Service Providers
Modified
p. 13 → 22
Note: The following questions are numbered according to PCI DSS requirements and testing procedures, as defined in the PCI DSS Requirements and Security Assessment Procedures document.
Note: The following requirements mirror the requirements in the PCI DSS Requirements and Testing Procedures document.
Modified
p. 13 → 22
Self-assessment completion date: Build and Maintain a Secure Network and Systems
Self-assessment completion date: YYYY-MM-DD Build and Maintain a Secure Network and Systems
Modified
p. 13 → 22
Requirement 1: Install and maintain a firewall configuration to protect data
Requirement 1: Install and Maintain Network Security Controls
Modified
p. 13 → 25
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 1.1 Are firewall and router configuration standards established and implemented to include the following:
PCI DSS Requirement Expected Testing Response1F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 1.2.8 Configuration files for NSCs are:
Removed
p. 14
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 1.1.4 Is a firewall required and implemented at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone? Review firewall configuration standards.
Is the current network diagram consistent with the firewall configuration standards? Compare firewall configuration standards to current network diagram.
Is the current network diagram consistent with the firewall configuration standards? Compare firewall configuration standards to current network diagram.
Removed
p. 14
Are all insecure services, protocols, and ports identified, and are security features documented and implemented for each identified service? Review firewall and router configuration standards.
Removed
p. 14
(b) Are firewall and router rule sets reviewed at least every six months? Examine documentation from firewall reviews.
Removed
p. 14
Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity’s ability to control or manage.
Modified
p. 14 → 24
Observe network configurations to verify that a firewall(s) is in place.
• Observe network configurations.
Modified
p. 14 → 36
Examine firewall and router configurations.
• Examine data stores and system configurations.
Removed
p. 15
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 1.2.1 Is inbound and outbound traffic restricted to that which is necessary for the cardholder data environment? Review firewall and router configuration standards.
Is all other inbound and outbound traffic specifically denied (for example by using an explicit “deny all” or an implicit deny after allow statement)? Review firewall and router configuration standards.
Is all other inbound and outbound traffic specifically denied (for example by using an explicit “deny all” or an implicit deny after allow statement)? Review firewall and router configuration standards.
Modified
p. 15 → 37
Examine firewall and router configurations.
• Examine data stores and system configurations.
Modified
p. 15 → 75
Examine router configuration files and router configurations.
• Examine system configuration settings.
Modified
p. 15 → 106
Examine firewall and router configurations.
• Examine scan tool configurations.
Modified
p. 15 → 108
Examine firewall and router configurations.
• Examine scan tool configurations.
Removed
p. 16
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 1.3.4 Is outbound traffic from the cardholder data environment to the Internet explicitly authorized? Examine firewall and router configurations.
Removed
p. 16
Network Address Translation (NAT) Placing servers containing cardholder data behind proxy servers/firewalls, Removal or filtering of route advertisements for private networks that employ registered addressing, Internal use of RFC1918 address space instead of registered addresses.
Is any disclosure of private IP addresses and routing information to external entities authorized? Examine firewall and router configurations.
Is any disclosure of private IP addresses and routing information to external entities authorized? Examine firewall and router configurations.
Removed
p. 16
(b) Is the personal firewall software (or equivalent functionality) configured to specific configuration settings, actively running, and not alterable by users of mobile and/or employee-owned devices? Review policies and configuration standards.
Examine mobile and/or employee- owned devices.
Examine mobile and/or employee- owned devices.
Modified
p. 16 → 81
Examine firewall and router configurations.
• Examine network and/or system configurations.
Modified
p. 17 → 56
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 1.5 Are security policies and operational procedures for managing firewalls:
PCI DSS Requirement Expected Testing Response5F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 5.3.2 The anti-malware solution(s):
Removed
p. 18
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Are unnecessary default accounts removed or disabled before installing a system on the network? Review policies and procedures.
Are encryption keys changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes positions? Review policies and procedures.
Are default SNMP community strings on wireless devices changed at installation? Review policies and procedures.
Are default passwords/passphrases on access points changed at installation? Review policies and procedures.
Are unnecessary default accounts removed or disabled before installing a system on the network? Review policies and procedures.
Are encryption keys changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes positions? Review policies and procedures.
Are default SNMP community strings on wireless devices changed at installation? Review policies and procedures.
Are default passwords/passphrases on access points changed at installation? Review policies and procedures.
Modified
p. 18 → 29
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults.
Modified
p. 18 → 31
Review vendor documentation.
• Review vendor documentation.
Modified
p. 18 → 76
Examine system configurations and account settings.
• Examine system configuration settings.
Modified
p. 18 → 78
• Inspect system configuration settings.
Removed
p. 19
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 2.1.1 (cont.) Is firmware on wireless devices updated to support strong encryption for authentication and transmission over wireless networks? Review policies and procedures.
Removed
p. 19
Are system configuration standards applied when new systems are configured? Review policies and procedures.
Modified
p. 19 → 28
• Examine system configuration standards.
Modified
p. 19 → 28
Review industry-accepted hardening standards.
• Review industry-accepted hardening standards.
Modified
p. 19 → 28
• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
Modified
p. 19 → 31
• SNMP defaults. Any other security-related wireless vendor defaults.
Removed
p. 20
Changing of all vendor-supplied defaults and elimination of unnecessary default accounts? Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server? Enabling only necessary services, protocols, daemons, etc., as required for the function of the system? Implementing additional security features for any required services, protocols or daemons that are considered to be insecure? Configuring system security parameters to prevent misuse? Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers? Review system configuration standards.
Removed
p. 20
If virtualization technologies are used, is only one primary function implemented per virtual system component or device? Examine system configurations.
Modified
p. 20 → 61
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 2.2 (cont.) Do system configuration standards include all of the following:
PCI DSS Requirement Expected Testing Response6F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 6.2.4 (cont.)
Removed
p. 21
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 2.2.2 Are only necessary services, protocols, daemons, etc. enabled as required for the function of the system (services and protocols not directly needed to perform the device’s specified function are disabled)? Review configuration standards.
(b) Are all enabled insecure services, daemons, or protocols justified per documented configuration standards? Review configuration standards Interview personnel. Examine configuration settings. Compare enabled services, etc. to documented justifications.
(b) Are all enabled insecure services, daemons, or protocols justified per documented configuration standards? Review configuration standards Interview personnel. Examine configuration settings. Compare enabled services, etc. to documented justifications.
Removed
p. 21
Are common system security parameters settings included in the system configuration standards? Review system configuration standards.
Are security parameter settings set appropriately on system components? Examine system components.
Are security parameter settings set appropriately on system components? Examine system components.
Removed
p. 21
Are enabled functions documented and do they support secure configuration? Review documentation.
Modified
p. 21 → 29
• Examine system configuration standards.
Modified
p. 21 → 54
Examine security parameters on system components.
• Examine system components.
Modified
p. 21 → 56
Examine security parameters on system components.
• Examine system components.
Modified
p. 21 → 74
Examine security parameter settings.
• Examine system settings.
Removed
p. 22
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 2.3 Is non-console administrative access encrypted as follows:
Is all non-console administrative access encrypted with strong cryptography, and is a strong encryption method invoked before the administrator’s password is requested? Examine system components.
Are system services and parameter files configured to prevent the use of Telnet and other insecure remote login commands? Examine system components.
Is administrator access to web-based management interfaces encrypted with strong cryptography? Examine system components.
For the technology in use, is strong cryptography implemented according to industry best practice and/or vendor recommendations? Examine system components.
Is all non-console administrative access encrypted with strong cryptography, and is a strong encryption method invoked before the administrator’s password is requested? Examine system components.
Are system services and parameter files configured to prevent the use of Telnet and other insecure remote login commands? Examine system components.
Is administrator access to web-based management interfaces encrypted with strong cryptography? Examine system components.
For the technology in use, is strong cryptography implemented according to industry best practice and/or vendor recommendations? Examine system components.
Removed
p. 22
(b) Is the documented inventory kept current? Interview personnel.
Modified
p. 22 → 30
Observe an administrator log on.
• Observe an administrator log on.
Modified
p. 22 → 52
Examine services and files.
• Examine keys and certificates.
Modified
p. 22 → 67
• Observe testing processes.
Modified
p. 22 → 81
Observe an administrator log on.
• Observe administrator personnel logging into the CDE.
Removed
p. 23
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.1 Are data-retention and disposal policies, procedures, and processes implemented as follows:
Are there defined processes in place for securely deleting cardholder data when no longer needed for legal, regulatory, and/or business reasons? Review policies and procedures.
Is there a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements? Review policies and procedures.
Does all stored cardholder data meet the requirements defined in the data-retention policy? Examine files and system records.
Are there defined processes in place for securely deleting cardholder data when no longer needed for legal, regulatory, and/or business reasons? Review policies and procedures.
Is there a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements? Review policies and procedures.
Does all stored cardholder data meet the requirements defined in the data-retention policy? Examine files and system records.
Modified
p. 23 → 32
Requirement 3: Protect stored cardholder data
Requirement 3: Protect Stored Account Data
Modified
p. 23 → 33
• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
Modified
p. 23 → 33
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
Modified
p. 23 → 42
Observe deletion processes.
• Observe encryption processes.
Modified
p. 23 → 57
Examine deletion mechanism.
• Examine mechanisms.
Modified
p. 23 → 59
Examine retention requirements.
• Examine training records.
Modified
p. 23 → 74
Review documented business justification.
• Review current user access lists.
Removed
p. 24
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested For all other entities: Is sensitive authentication data deleted or rendered unrecoverable upon completion of the authorization process? Review policies and procedures.
(d) Do all systems adhere to the following requirements regarding non-storage of sensitive authentication data after authorization (even if encrypted):
(d) Do all systems adhere to the following requirements regarding non-storage of sensitive authentication data after authorization (even if encrypted):
Removed
p. 24
Incoming transaction data All logs History files Trace files Database schema Database contents 3.2.2 The card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) is not stored after authorization? Examine data sources including:
Incoming transaction data All logs History files Trace files Database schema Database contents
Incoming transaction data All logs History files Trace files Database schema Database contents
Modified
p. 24 → 35
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) In the normal course of business, the following data elements from the track may need to be retained:
Modified
p. 24 → 35
To minimize risk, store securely only these data elements as needed for business.
Modified
p. 24 → 35
Examine data sources including:
• Examine data sources.
Modified
p. 24 → 63
Examine deletion processes.
• Examine documented processes.
Removed
p. 25
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.2.3 The personal identification number (PIN) or the encrypted PIN block is not stored after authorization? Examine data sources including:
Incoming transaction data All logs History files Trace files Database schema Database contents 3.3 Is the PAN masked when displayed (the first six and last four digits are the maximum number of digits to be displayed) such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN? Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
Review roles that need access to displays of full PAN.
Observe displays of PAN.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not …
Incoming transaction data All logs History files Trace files Database schema Database contents 3.3 Is the PAN masked when displayed (the first six and last four digits are the maximum number of digits to be displayed) such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN? Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
Review roles that need access to displays of full PAN.
Observe displays of PAN.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not …
Removed
p. 26
Note: This requirement applies in addition to all other PCI DSS encryption and key management requirements.
Modified
p. 26 → 40
Examine data repositories.
• Examine data repositories.
Modified
p. 26 → 40
Examine audit logs, including payment application logs.
• Examine audit logs, including payment application logs.
Modified
p. 26 → 42
• On removable electronic media. OR
Modified
p. 26 → 43
• Logical access is managed separately and independently of native operating system authentication and access control mechanisms.
Modified
p. 26 → 43
Observe the authentication process.
• Observe the authentication process.
Removed
p. 27
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.4.1 (cont.) Is cardholder data on removable media encrypted wherever stored? Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys. Such key- encrypting keys must be at least as strong as the data- encrypting key.
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys. Such key- encrypting keys must be at least as strong as the data- encrypting key.
Removed
p. 27
• Inventory of any HSMs and other SCDs used for key management? Review documentation.
Modified
p. 27 → 45
• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date,
• Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.
Modified
p. 27 → 45
• Description of the key usage for each key,
• Description of the key usage for each key.
Removed
p. 28
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.5.3 Are secret and private cryptographic keys used to encrypt/decrypt cardholder data 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 (such as a hardware (host) security module (HSM) or PTS-approved point-of- interaction device) As at least two full-length key components or key shares, in accordance with an industry-accepted method.
Removed
p. 28
For service providers only: If keys are shared with customers for transmission or storage of cardholder data, is documentation provided to customers that includes guidance on how to securely transmit, store and update customer’s keys, in accordance with requirements 3.6.1 through 3.6.8 below? Review documentation provided to customers.
Modified
p. 28 → 21
Note: It is not required that public keys be stored in one of these forms.
Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:
Modified
p. 28 → 23
• Examine documented procedures.
Modified
p. 28 → 42
Observe key-generation procedures.
• Observe encryption processes.
Modified
p. 28 → 46
Examine system configurations and key storage locations, including for key-encrypting keys.
• Examine system configurations and key storage locations, including for key- encrypting keys.
Removed
p. 29
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.6.2 Do cryptographic key procedures include secure cryptographic key distribution? Review key management procedures.
Removed
p. 29
Do cryptographic key procedures include replacement of known or suspected compromised keys? Review key-management procedures.
(c) If retired or replaced cryptographic keys are retained, are these keys only used for decryption/verification purposes, and not used for encryption operations? Review key-management procedures.
(c) If retired or replaced cryptographic keys are retained, are these keys only used for decryption/verification purposes, and not used for encryption operations? Review key-management procedures.
Modified
p. 29 → 47
Observe the method for secure storage of keys.
• Observe the method for storing keys.
Modified
p. 29 → 92
Observe the key-distribution method.
• Observe the media destruction process.
Removed
p. 30
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 3.6.6 If manual clear-text key-management operations are used, do cryptographic key procedures include split knowledge and dual control of cryptographic keys as follows:
Do split knowledge procedures require that key components are under the control of at least two people who only have knowledge of their own key components?
Do dual control procedures require that at least two people are required to perform any key management operations and no one person has access to the authentication materials (for example, passwords or keys) of another? Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.
Do split knowledge procedures require that key components are under the control of at least two people who only have knowledge of their own key components?
Do dual control procedures require that at least two people are required to perform any key management operations and no one person has access to the authentication materials (for example, passwords or keys) of another? Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.
Modified
p. 30 → 22
Interview personnel and/or.
• Interview personnel.
Modified
p. 30 → 44
• Examine documented key- management policies and procedures.
Removed
p. 31
Requirement 4: Encrypt transmission of cardholder data across open, public networks
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 4.1 (a) Are strong cryptography and security protocols used to safeguard sensitive cardholder data during transmission over open, public networks? Note: Examples of open, public networks include but are not limited to the Internet; wireless technologies, including 802.11 and Bluetooth; cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA); and General Packet Radio Service (GPRS).
Review all locations where CHD is transmitted or received.
(c) Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? Examine system configurations.
(e) For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? For example, for browser-based implementations:
“HTTPS” appears as the browser Universal Record Locator (URL) protocol, and Cardholder data is only …
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 4.1 (a) Are strong cryptography and security protocols used to safeguard sensitive cardholder data during transmission over open, public networks? Note: Examples of open, public networks include but are not limited to the Internet; wireless technologies, including 802.11 and Bluetooth; cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA); and General Packet Radio Service (GPRS).
Review all locations where CHD is transmitted or received.
(c) Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? Examine system configurations.
(e) For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? For example, for browser-based implementations:
“HTTPS” appears as the browser Universal Record Locator (URL) protocol, and Cardholder data is only …
Removed
p. 31
Review wireless networks.
Modified
p. 31 → 52
• Only trusted keys and certificates are accepted.
Modified
p. 31 → 52
• The encryption strength is appropriate for the encryption methodology in use.
Modified
p. 31 → 53
Examine keys and certificates.
• Examine the inventory of trusted keys and certificates.
Modified
p. 31 → 69
• Examine documented approvals.
Modified
p. 31 → 76
Examine system configurations.
• Examine system configuration settings.
Modified
p. 31 → 77
Examine system configuration settings.
• Examine system configuration settings.
Removed
p. 32
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 4.2 Are PANs rendered unreadable or secured with strong cryptography whenever they are sent via end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.)? Review outbound transmissions.
Are policies in place that state that unprotected PANs are not to be sent via end-user messaging technologies? Review policies and procedures.
Are policies in place that state that unprotected PANs are not to be sent via end-user messaging technologies? Review policies and procedures.
Removed
p. 33
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 5.1 Is anti-virus software deployed on all systems commonly affected by malicious software? Examine system configurations.
Removed
p. 33
Are all anti-virus software and definitions kept current? Examine policies and procedures.
Are all anti-virus mechanisms generating audit logs, and are logs retained in accordance with PCI DSS Requirement 10.7? Examine anti-virus configurations.
Are all anti-virus mechanisms generating audit logs, and are logs retained in accordance with PCI DSS Requirement 10.7? Examine anti-virus configurations.
Modified
p. 33 → 28
• Cover all system components.
Modified
p. 33 → 34
• Observe the secure data deletion processes.
Modified
p. 33 → 54
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 5: Protect All Systems and Networks from Malicious Software
Modified
p. 33 → 55
Examine anti-virus configurations, including the master installation.
• Examine anti-malware solution(s) configurations, including any master installation.
Modified
p. 33 → 55
Examine system components.
• Examine system components and logs.
Modified
p. 33 → 56
• Examine anti-malware solution(s) configurations, including any master installation.
Modified
p. 33 → 77
Examine system configurations.
• Examine system configuration settings.
Removed
p. 34
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 5.3 Are all anti-virus mechanisms:
Unable to be disabled or altered by users? Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.
Unable to be disabled or altered by users? Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.
Modified
p. 34 → 57
Examine anti-virus configurations.
• Examine anti-malware configurations.
Modified
p. 34 → 86
Examine system components.
• Examine system configuration settings.
Removed
p. 35
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.1 Is there a process to identify security vulnerabilities, including the following:
Assigning a risk ranking to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities? Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score and/or the classification by the vendor, and/or type of systems affected.
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result …
Assigning a risk ranking to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities? Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score and/or the classification by the vendor, and/or type of systems affected.
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result …
Modified
p. 35 → 58
Requirement 6: Develop and maintain secure systems and applications
Requirement 6: Develop and Maintain Secure Systems and Software
Modified
p. 35 → 106
• Scan tool is kept up to date with latest vulnerability information.
Removed
p. 36
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.2 (cont.) Are critical security patches installed within one month of release? Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.
Is information security included throughout the software- development life cycle? Review software development processes.
Do software development processes ensure the following at 6.3.1 - 6.3.2:
Is information security included throughout the software- development life cycle? Review software development processes.
Do software development processes ensure the following at 6.3.1 - 6.3.2:
Modified
p. 36 → 58
• In accordance with PCI DSS (for example, secure authentication and logging).
Modified
p. 36 → 63
Compare list of security patches installed to recent vendor patch lists.
• Compare list of security patches installed to recent vendor patch lists.
Modified
p. 36 → 99
Examine system components.
• Examine system configuration settings.
Removed
p. 37
Is access control in place to enforce the separation between the development/test environments and the production environment? Review change control processes and procedures.
Modified
p. 37 → 23
Examine recent changes and change records.
• Examine change control records.
Modified
p. 37 → 59
• Code reviews ensure code is developed according to secure coding guidelines.
Modified
p. 37 → 59
Appropriate corrections are implemented prior to release.
Modified
p. 37 → 59
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement for code reviews applies to all bespoke and custom software (both internal and public-facing), as part of the system development lifecycle. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.4.
Modified
p. 37 → 60
• Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.
Modified
p. 37 → 66
Examine access control settings.
• Examine access control settings.
Modified
p. 37 → 82
Examine network documentation and network device configurations.
• Examine network and/or system configurations.
Removed
p. 38
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.4.2 Is there separation of duties between personnel assigned to the development/test environments and those assigned to the production environment? Review change control processes and procedures.
Removed
p. 38
Are the following performed and documented for all changes:
Modified
p. 38 → 66
Examine change control documentation.
• Examine change control documentation.
Modified
p. 38 → 67
Examine production systems.
• Examine pre-production test data.
Removed
p. 39
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.4.5.2 Documented approval by authorized parties? Trace changes to change control documentation.
Modified
p. 39 → 22
Examine change control documentation.
• Examine documentation.
Modified
p. 39 → 22
Examine change control documentation.
• Examine documentation.
Modified
p. 39 → 31
Examine change control documentation.
• Examine key-management documentation.
Modified
p. 39 → 66
• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
Modified
p. 39 → 66
Observe affected systems or networks.
• Observe the affected systems/networks.
Modified
p. 39 → 76
Examine change control documentation.
• Examine vendor documentation
Modified
p. 39 → 108
Examine change control documentation.
• Examine change control documentation.
Removed
p. 40
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.5 Do software-development processes address common coding vulnerabilities? Review software-development policies and procedures.
Are developers trained at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities? Examine software-development policies and procedures.
Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities:
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are update d (for example, the Open Web Application Security Project (OWASP) Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.
Are developers trained at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities? Examine software-development policies and procedures.
Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities:
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are update d (for example, the Open Web Application Security Project (OWASP) Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.
Modified
p. 40 → 34
Examine software-development policies and procedures.
• Examine documented policies and procedures.
Modified
p. 40 → 65
Examine training records.
• Examine inventory records.
Removed
p. 41
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.5.5 Do coding techniques address improper error handling? Examine software-development policies and procedures.
For web applications and application interfaces (internal or external), are applications developed based on secure coding guidelines to protect applications from the following additional vulnerabilities:
For web applications and application interfaces (internal or external), are applications developed based on secure coding guidelines to protect applications from the following additional vulnerabilities:
Removed
p. 42
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 6.6 For public-facing web applications, are new threats and vulnerabilities addressed on an ongoing basis, and are these applications protected against known attacks by applying either of the following methods? Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, as follows:
At least annually After any changes By an organization that specializes in application security That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment That all vulnerabilities are corrected That the application is re-evaluated after the corrections Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
Is situated in front of public-facing web applications to detect and prevent web-based attacks. Is actively running and up to date as applicable. Is generating audit logs. Is configured to …
At least annually After any changes By an organization that specializes in application security That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment That all vulnerabilities are corrected That the application is re-evaluated after the corrections Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
Is situated in front of public-facing web applications to detect and prevent web-based attacks. Is actively running and up to date as applicable. Is generating audit logs. Is configured to …
Modified
p. 42 → 63
Examine records of application security assessments.
• Examine records of application security assessments
Modified
p. 42 → 64
Examine system configuration settings.
• Examine the system configuration settings.
Modified
p. 42 → 101
• Examine documented processes.
Removed
p. 43
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 7.1 Is access to system components and cardholder data limited to only those individuals whose jobs require such access, as follows:
Is there a written policy for access control that incorporates the following? Defining access needs and privilege assignments for each role Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities, Assignment of access based on individual personnel’s job classification and function Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved Examine written access control policy.
Assigned only to roles that specifically require that privileged access? Interview management.
Is there a written policy for access control that incorporates the following? Defining access needs and privilege assignments for each role Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities, Assignment of access based on individual personnel’s job classification and function Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved Examine written access control policy.
Assigned only to roles that specifically require that privileged access? Interview management.
Modified
p. 43 → 68
Requirement 7: Restrict access to cardholder data by business need to know
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Modified
p. 43 → 68
• Access to system components and data resources that is based on users’ job classification and functions.
Modified
p. 43 → 68
• The least privileges required (for example, user, administrator) to perform a job function.
Modified
p. 43 → 69
• Least privileges necessary to perform job responsibilities.
Modified
p. 43 → 96
• Elevation of privileges.
Removed
p. 44
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 7.1.4 Is documented approval by authorized parties required, specifying required privileges? Compare with documented approvals.
Modified
p. 44 → 74
• Implemented with only the privileges specified on the documented approval.
Removed
p. 45
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.1 Are policies and procedures for user identification management controls defined and in place for non- consumer users and administrators on all system components, as follows:
Removed
p. 45
Review current access lists.
Modified
p. 45 → 46
Examine terminated users accounts.
• Examine user access lists.
Modified
p. 45 → 47
Observe user accounts.
• Observe key storage locations.
Modified
p. 45 → 69
Examine privileged and general user IDs and associated authorizations.
• Examine user IDs and assigned privileges.
Modified
p. 45 → 72
Requirement 8: Identify and authenticate access to system components
Requirement 8: Identify Users and Authenticate Access to System Components
Modified
p. 45 → 87
Observe returned physical authentication devices.
• Observe physical entry controls.
Modified
p. 45 → 97
• Examine system settings.
Removed
p. 46
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.1.6 Are repeated access attempts limited by locking out the user ID after no more than six attempts? Review password procedures.
For service providers only: Are non-consumer customer passwords temporarily locked-out after not more than six invalid access attempts? Review policies and procedures.
For service providers only: Are non-consumer customer passwords temporarily locked-out after not more than six invalid access attempts? Review policies and procedures.
Removed
p. 46
In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users? 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 Review password procedures.
Modified
p. 46 → 24
• Examine documentation.
Modified
p. 46 → 52
• Examine cardholder data transmissions.
Modified
p. 46 → 76
• Examine data transmissions.
Modified
p. 46 → 84
• Examine vendor system documentation.
Modified
p. 46 → 92
Observe password files.
• Observe storage containers.
Modified
p. 46 → 94
Observe authentication processes.
• Observe inspection processes.
Removed
p. 47
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.2.2 Is user identity verified before modifying any authentication credential (for example, performing password resets, provisioning new tokens, or generating new keys)? Review authentication procedures.
Removed
p. 47
For service providers only: Are non-consumer customer passwords required to meet the following minimum length and complexity requirements? A minimum password length of at least seven characters Contain both numeric and alphabetic characters Review customer/user documentation.
For service providers only: Are non-consumer customer passwords required to be changed periodically, and are non-consumer customers given guidance as to when, and under what circumstances, passwords must change.
For service providers only: Are new, non-consumer customer passwords required to be different from any of the last four passwords used? Review customer/user documentation.
For service providers only: Are non-consumer customer passwords required to be changed periodically, and are non-consumer customers given guidance as to when, and under what circumstances, passwords must change.
For service providers only: Are new, non-consumer customer passwords required to be different from any of the last four passwords used? Review customer/user documentation.
Modified
p. 47 → 57
Observe internal processes.
• Observe implemented processes.
Modified
p. 47 → 63
Examine system configuration settings to verify password parameters.
• Examine the system configuration settings and audit logs.
Modified
p. 47 → 90
• Examine logs or other documentation.
Modified
p. 47 → 98
• Logs of all critical system components.
Modified
p. 47 → 101
Observe internal processes.
• Observe detection and alerting processes.
Modified
p. 47 → 102
Observe internal processes.
• Observe detection and alerting processes.
Removed
p. 48
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.2.6 Are passwords/passphrases set to a unique value for each user for first-time use and upon reset, and must each user change their password immediately after the first use? Review password procedures.
Removed
p. 48
Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see PCI DSS Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.
Removed
p. 48
Review distribution method.
Modified
p. 48 → 76
Observe security personnel.
• Observe security personnel.
Modified
p. 48 → 82
Observe administrator logging into CDE.
• Observe personnel logging in to the CDE.
Modified
p. 48 → 84
Observe personnel connecting remotely.
• Observe personnel connecting remotely from outside the entity’s network.
Removed
p. 49
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested Do authentication policies and procedures include the following? Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials Instructions not to reuse previously used passwords Instructions that users should change passwords if there is any suspicion the password could be compromised Review policies and procedures.
Removed
p. 49
Generic user IDs and accounts are disabled or removed; Shared user IDs for system administration activities and other critical functions do not exist; and Shared and generic user IDs are not used to administer any system components? Review policies and procedures.
Modified
p. 49
Review documentation provided to users.
• Review documentation or other evidence of key custodian acknowledgments.
Modified
p. 49 → 64
Examine user ID lists.
• Examine audit logs.
Removed
p. 50
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, and certificates, etc.), is the use of these mechanisms assigned as follows? Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access Review policies and procedures.
Removed
p. 50
Is all user access to, user queries of, and user actions on (for example, move, copy, delete), the database through programmatic methods only (for example, through stored procedures)? Review database authentication policies and procedures.
Is user direct access to or queries to of databases restricted to database administrators? Review database authentication policies and procedures.
(c) Are application IDs only able to be used by the applications (and not by individual users or other processes)? Review database authentication policies and procedures.
Is user direct access to or queries to of databases restricted to database administrators? Review database authentication policies and procedures.
(c) Are application IDs only able to be used by the applications (and not by individual users or other processes)? Review database authentication policies and procedures.
Modified
p. 50 → 27
Examine database and application configuration settings.
• Examine device configuration settings.
Modified
p. 50 → 31
Examine database application configuration settings.
• Examine wireless configuration settings.
Modified
p. 50 → 68
Examine database access control settings.
• Examine access control model settings.
Modified
p. 50 → 80
Examine system configuration settings and/or physical controls.
• Examine system configuration settings and/or observe physical controls, as applicable.
Modified
p. 50 → 89
Examine database access control settings.
• Examine physical access control lists.
Modified
p. 50 → 105
Examine database application configuration settings.
• Examine configuration settings.
Removed
p. 51
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 8.8 Are security policies and operational procedures for identification and authentication:
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.1 Are appropriate facility entry controls in place to limit and monitor physical access to systems in the cardholder data environment? Observe physical access controls.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.1 Are appropriate facility entry controls in place to limit and monitor physical access to systems in the cardholder data environment? Observe physical access controls.
Removed
p. 52
(c) Is data collected from video cameras and/or access control mechanisms reviewed and correlated with other entries? Review policies and procedures.
Observe data storage.
Observe data storage.
Modified
p. 52 → 76
Observe security features.
• Observe security personnel.
Modified
p. 52 → 80
Interview security personnel.
• Interview security personnel.
Modified
p. 52 → 87
Requirement 9: Restrict physical access to cardholder data
Requirement 9: Restrict Physical Access to Cardholder Data
Modified
p. 52 → 88
• Monitoring devices or mechanisms are protected from tampering or disabling.
Modified
p. 52 → 88
• Collected data is stored for at least three months, unless otherwise restricted by law.
Modified
p. 52 → 101
• Audit logging mechanisms.
Removed
p. 53
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.1.3 Is physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines restricted? Review policies and procedures.
Removed
p. 53
Observe visitor processes.
Do identification methods (such as ID badges) clearly identify visitors and easily distinguish between onsite personnel and visitors? Observe identification methods.
(c) Is access to the badge system limited to authorized personnel? Observe physical controls and access controls for the badge system.
Do identification methods (such as ID badges) clearly identify visitors and easily distinguish between onsite personnel and visitors? Observe identification methods.
(c) Is access to the badge system limited to authorized personnel? Observe physical controls and access controls for the badge system.
Removed
p. 53
Compare lists of terminated employees to access control lists.
Modified
p. 53 → 58
• Interview responsible personnel.
Modified
p. 53 → 89
Observe identification methods (e.g. badges).
• Observe identification methods, such as ID badges.
Modified
p. 53 → 89
• Access is authorized and based on individual job function.
Modified
p. 53 → 89
• All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.
Removed
p. 54
Observe visitor processes.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.4 Is visitor identification and access handled as follows:
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.4 Is visitor identification and access handled as follows:
Removed
p. 54
Does the visitor log contain the visitor’s name, the firm represented, and the onsite personnel authorizing physical access? Review policies and procedures.
(c) Is the visitor log retained for at least three months? Review policies and procedures.
(c) Is the visitor log retained for at least three months? Review policies and procedures.
Removed
p. 54
Review policies and procedures for physically securing media.
Modified
p. 54 → 24
Examine identification.
• Examine documentation.
Modified
p. 54 → 24
Examine identification.
• Examine documentation.
Modified
p. 54 → 27
Examine log retention.
• Examine documentation.
Modified
p. 54 → 89
Observe visitor processes including how access is controlled.
• Observe visitors leaving the facility
Modified
p. 54 → 89
• Observe the use of visitor badges or other identification.
Modified
p. 54 → 90
Examine the visitor log.
• Examine the visitor log.
Modified
p. 54 → 90
Examine visitor log retention.
• Examine visitor log storage locations.
Modified
p. 54 → 93
Observe visitors and badge use.
• Observe POI devices and device locations.
Modified
p. 54 → 99
Examine the visitor log.
• Examine audit logs.
Removed
p. 55
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.5.1 Is the location where media back-ups are stored reviewed at least annually to confirm storage is secure? Review policies and procedures for reviewing offsite media locations.
Removed
p. 55
Do controls include the following:
Removed
p. 55
Are periodic media inventories conducted at least annually? Examine inventory logs.
Removed
p. 56
Is there a periodic media destruction policy that defines requirements for the following? Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.
Storage containers used for materials that are to be destroyed must be secured.
Cardholder data on electronic media must be rendered unrecoverable (e.g., via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).
(c) Is media destruction performed as follows:
Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents? Examine security of storage containers.
Storage containers used for materials that are to be destroyed must be secured.
Cardholder data on electronic media must be rendered unrecoverable (e.g., via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).
(c) Is media destruction performed as follows:
Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents? Examine security of storage containers.
Modified
p. 56 → 92
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.8 Is all media destroyed when it is no longer needed for business or legal reasons? Review periodic media destruction policies and procedures.
PCI DSS Requirement Expected Testing Response9F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:
Modified
p. 56 → 92
• Examine the periodic media destruction policy.
Removed
p. 57
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.9 Are devices that capture payment card data via direct physical interaction with the card protected against tampering and substitution as follows? Note: This requirement applies to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.
Do policies and procedures require that a list of such devices be maintained? Review policies and procedures.
Do policies and procedures require that devices are periodically inspected to look for tampering or substitution? Review policies and procedures.
Do policies and procedures require that a list of such devices be maintained? Review policies and procedures.
Do policies and procedures require that devices are periodically inspected to look for tampering or substitution? Review policies and procedures.
Removed
p. 57
Is the list accurate and up to date? Observe devices and device locations and compare to list.
Modified
p. 57 → 93
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.
Removed
p. 58
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.9.2 Are device surfaces periodically inspected to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device) as follows? Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.
Observe inspection processes and compare to defined processes.
Are personnel aware of procedures for inspecting devices?
Observe inspection processes and compare to defined processes.
Are personnel aware of procedures for inspecting devices?
Modified
p. 58 → 94
• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.
Modified
p. 58 → 94
• Procedures to ensure devices are not installed, replaced, or returned without verification.
Modified
p. 58 → 94
• Being aware of suspicious behavior around devices.
Modified
p. 58 → 94
• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel.
Modified
p. 58 → 94
Review training materials.
• Review training materials for personnel in POI environments.
Removed
p. 59
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 9.9.3 (cont.) (b) Have personnel at point-of-sale locations received training, and are they aware of procedures to detect and report attempted tampering or replacement of devices? Interview personnel at POS locations.
Removed
p. 60
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 10.1 Are audit trails enabled and active for system components? Observe processes.
Modified
p. 60 → 73
Interview system administrator.
• Interview system administrators.
Modified
p. 60 → 95
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Modified
p. 60 → 97
Interview system administrator.
• Interview system administrators.
Removed
p. 61
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 10.2.6 Initialization, stopping, or pausing of the audit logs? Interview personnel.
Modified
p. 61 → 95
Examine audit log settings.
• Examine audit log configurations.
Modified
p. 61 → 96
Examine audit log settings.
• Examine audit log configurations.
Removed
p. 62
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 10.4 Are all critical system clocks and times synchronized through use of time synchronization technology, and is the technology kept current? Note: One example of time synchronization technology is Network Time Protocol (NTP).
Removed
p. 62
Do only designated central time server(s) receive time signals from external sources, and are time signals from external sources based on International Atomic Time or UTC? Review time configuration standards and processes.
Modified
p. 62 → 30
• Examine configuration standards.
Modified
p. 62 → 63
Examine time-related system parameters.
• Examine system components and related software.
Modified
p. 62 → 86
Examine time-related system parameters.
• Examine system development procedures.
Modified
p. 62 → 100
Where there is more than one designated time server, do the time servers peer with each other to keep accurate time? Review time configuration standards and processes.
• Where there is more than one designated time server, the time servers peer with one another to keep accurate time.
Modified
p. 62 → 100
• Internal systems receive time information only from designated central time server(s).
Modified
p. 62 → 100
• Access to time data is restricted to only personnel with a business need.
Modified
p. 62 → 100
• Any changes to time settings on critical systems are logged, monitored, and reviewed.
Modified
p. 62 → 105
Examine time-related system parameters.
• Examine wireless assessment results.
Removed
p. 63
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested Are time settings received from specific, industry-accepted time sources? (This is to prevent a malicious individual from changing the clock).
Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).
Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).
Removed
p. 63
Are logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) written onto a secure, centralized, internal log server or media? Interview system administrators.
Modified
p. 63 → 29
Examine system configurations.
• Examine system configuration standards.
Modified
p. 63 → 30
Examine system configurations and permissions.
• Examine system configuration standards.
Modified
p. 63 → 30
Examine system configurations and permissions.
• Examine system configuration standards.
Modified
p. 63 → 97
Examine system configurations and permissions.
• Examine system configurations and privileges.
Modified
p. 63 → 97
Examine system configurations and permissions.
• Examine system configurations and privileges.
Removed
p. 64
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 10.6 Are logs and security events for all system components reviewed to identify anomalies or suspicious activity as follows? Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.
Removed
p. 64
Are reviews of all other system components performed in accordance with organization’s policies and risk management strategy? Review risk assessment documentation.
Is follow up to exceptions and anomalies performed? Observe processes.
Is follow up to exceptions and anomalies performed? Observe processes.
Removed
p. 65
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 10.7 Are audit log retention policies and procedures in place and do they require that logs are retained for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup)? Review security policies and procedures.
Are audit logs retained for at least one year? Interview personnel.
Are at least the last three months’ logs immediately available for analysis? 10.8 For service providers only: Is a process implemented for the timely detection and reporting of failures of critical security control systems as follows:
(a) Are processes implemented for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used) …
Are audit logs retained for at least one year? Interview personnel.
Are at least the last three months’ logs immediately available for analysis? 10.8 For service providers only: Is a process implemented for the timely detection and reporting of failures of critical security control systems as follows:
(a) Are processes implemented for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used) …
Modified
p. 66 → 103
• Restoring security functions.
Modified
p. 66 → 103
• Identifying and documenting the duration (date and time from start to end) of the security failure.
Modified
p. 66 → 103
• Identifying and documenting the cause(s) of failure and documenting required remediation.
Modified
p. 66 → 103
• Identifying and addressing any security issues that arose during the failure.
Modified
p. 66 → 103
• Implementing controls to prevent the cause of failure from reoccurring.
Modified
p. 66 → 103
• Resuming monitoring of security controls.
Removed
p. 67
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.1 Are processes implemented for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis? Note: Methods that may be used in the process include, but are not limited to, wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.
Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.
Does the methodology detect and identify any unauthorized wireless access points, including at least the following? WLAN cards inserted into system components; Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.); and Wireless devices attached to a network port or network device.
Evaluate the methodology.
(c) If wireless scanning is utilized to identify authorized and unauthorized wireless access …
Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.
Does the methodology detect and identify any unauthorized wireless access points, including at least the following? WLAN cards inserted into system components; Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.); and Wireless devices attached to a network port or network device.
Evaluate the methodology.
(c) If wireless scanning is utilized to identify authorized and unauthorized wireless access …
Modified
p. 67 → 104
Requirement 11: Regularly test security systems and processes
Requirement 11: Test Security of Systems and Networks Regularly
Removed
p. 68
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.1.2 Does the incident response plan define and require a response in the event that an unauthorized wireless access point is detected? Examine incident response plan (see Requirement 12.10).
Inspect recent wireless scans and related responses.
Inspect recent wireless scans and related responses.
Removed
p. 68
Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.
Modified
p. 68 → 105
• All authorized and unauthorized wireless access points are detected and identified.
Modified
p. 68 → 109
For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re- scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred.
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
Removed
p. 69
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.2.1 (cont.) Are quarterly internal scans performed by a qualified internal resource(s) or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)?
Removed
p. 69
Do external quarterly scan and rescan results satisfy the ASV Program Guide requirements for a passing scan (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures)? Review results of each external quarterly scan and rescan.
Are quarterly external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV? Review results of each external quarterly scan and rescan.
Does the scan process include rescans until: For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS, For internal scans, a passing result is obtained or all “high- risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved?
Are quarterly external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV? Review results of each external quarterly scan and rescan.
Does the scan process include rescans until: For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS, For internal scans, a passing result is obtained or all “high- risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved?
Modified
p. 69 → 109
Examine and correlate change control documentation and scan reports.
• Examine change control documentation.
Modified
p. 69 → 111
• Examine results from the most recent external penetration test.
Removed
p. 70
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.3 Does the penetration-testing methodology include the following? Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) Includes coverage for the entire CDE perimeter and critical systems Includes testing from both inside and outside the network Includes testing to validate any segmentation and scope- reduction controls Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 Defines network-layer penetration tests to include components that support network functions as well as operating systems Includes review and consideration of threats and vulnerabilities experienced in the last 12 months Specifies retention of penetration testing results and remediation activities results Examine penetration-testing methodology.
Modified
p. 70 → 109
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 70 → 111
Examine results from the most recent external penetration test.
• Examine results from the most recent external penetration test.
Removed
p. 71
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.3.2 Is internal penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)? Examine scope of work.
Removed
p. 71
If segmentation is used to isolate the CDE from other networks:
Does penetration testing to verify segmentation controls meet the following? Performed at least annually and after any changes to segmentation controls/methods.
Does penetration testing to verify segmentation controls meet the following? Performed at least annually and after any changes to segmentation controls/methods.
Modified
p. 71 → 112
Examine results from the most recent internal penetration test.
• Examine the results from the most recent penetration test.
Modified
p. 71 → 112
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of- scope systems.
Modified
p. 71 → 112
Review penetration-testing methodology.
• Review penetration-testing methodology.
Modified
p. 71 → 112
• Covering all segmentation controls/methods in use.
Modified
p. 71 → 113
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of- scope systems.
Modified
p. 71 → 113
Examine results from the most recent penetration test.
• Examine the results from the most recent penetration test.
Removed
p. 72
Is PCI DSS scope confirmed by performing penetration tests on segmentation controls at least every six months and after any changes to segmentation controls/methods? Examine results of penetration tests on segmentation controls.
Does penetration testing cover all segmentation controls/methods in use? Examine results of penetration tests on segmentation controls.
Does penetration testing verify that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE Examine results of penetration tests on segmentation controls.
At the perimeter of the cardholder data environment, and At critical points in the cardholder data environment.
Does penetration testing cover all segmentation controls/methods in use? Examine results of penetration tests on segmentation controls.
Does penetration testing verify that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE Examine results of penetration tests on segmentation controls.
At the perimeter of the cardholder data environment, and At critical points in the cardholder data environment.
Modified
p. 72 → 115
Examine network diagrams.
• Examine system configurations and network diagrams.
Modified
p. 72 → 115
Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.
Modified
p. 72 → 115
• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.
Modified
p. 72 → 128
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.3.4.1 For service providers only: If segmentation is used:
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.6.2 The security awareness program is:
Removed
p. 73
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 11.5 Is a change-detection mechanism (for example, file-integrity monitoring tools) deployed to detect unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files? Examples of files that should be monitored include:
System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log, and audit files Additional critical files determined by entity (for example, through risk assessment or other means) Observe system settings and monitored files.
Is the change-detection mechanism configured to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files or content files, and do the tools perform critical file comparisons at least weekly? Note: For change detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a …
System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log, and audit files Additional critical files determined by entity (for example, through risk assessment or other means) Observe system settings and monitored files.
Is the change-detection mechanism configured to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files or content files, and do the tools perform critical file comparisons at least weekly? Note: For change detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a …
Removed
p. 73
Documented Known to all affected parties? Examine security policies and operational procedures.
Modified
p. 73 → 116
• Examine monitored files.
Modified
p. 73 → 116
• Examine results from monitoring activities.
Modified
p. 73 → 137
Examine system configuration settings.
• Examine system configuration settings.
Removed
p. 75
Requirement 12: Maintain a policy that addresses information security for all personnel
Note: For the purposes of Requirement 12, “personnel” refers to full-time part-time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site or otherwise have access to the company’s site cardholder data environment.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.1 Is a security policy established, published, maintained, and disseminated to all relevant personnel? Review the information security policy.
Note: For the purposes of Requirement 12, “personnel” refers to full-time part-time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site or otherwise have access to the company’s site cardholder data environment.
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.1 Is a security policy established, published, maintained, and disseminated to all relevant personnel? Review the information security policy.
Removed
p. 75
(b) Is the risk assessment process performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)? Review risk assessment documentation.
Removed
p. 75
Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.
Modified
p. 75 → 124
• Change-management processes.
Removed
p. 76
For personnel with proper authorization, does the policy require the protection of cardholder data in accordance with PCI DSS Requirements? Review usage policies.
Modified
p. 76 → 119
• Examine acceptable use policies.
Modified
p. 76 → 126
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.3.2 Authentication for use of the technology? Review usage policies.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.5.2 (cont.)
Removed
p. 77
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.4 Do security policy and procedures clearly define information security responsibilities for all personnel? Review information security policy and procedures.
(b) Has executive management defined a charter for the
Are the following information security management responsibilities formally assigned to an individual or team:
(b) Has executive management defined a charter for the
Are the following information security management responsibilities formally assigned to an individual or team:
Modified
p. 77 → 123
• Overall accountability for maintaining PCI DSS compliance.
Modified
p. 77 → 123
PCI DSS compliance program and communication to executive management? Examine PCI DSS charter.
• Defining a charter for a PCI DSS compliance program and communication to executive management.
Modified
p. 77 → 133
Interview a sample of responsible personnel.
• Interview responsible personnel.
Removed
p. 78
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.6 Is a formal security awareness program in place to make all personnel aware of the cardholder data security policy and procedures? Review security awareness program.
Removed
p. 78
Are personnel educated upon hire and at least annually? Examine security awareness program procedures and documentation.
Have employees completed awareness training and are they aware of the importance of cardholder data security?
Have employees completed awareness training and are they aware of the importance of cardholder data security?
Modified
p. 78 → 127
• Examine the security awareness program.
Modified
p. 78 → 128
• Examine security awareness program content.
Modified
p. 78 → 128
• Examine security awareness program records.
Modified
p. 78 → 128
• Examine the security awareness program materials.
Modified
p. 78 → 129
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) For those potential personnel to be hired for positions such as store cashiers, who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.
Modified
p. 78 → 129
Interview Human Resource department management.
• Interview responsible Human Resource department management personnel.
Removed
p. 79
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.8 Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:
Removed
p. 79
Review list of service providers.
Modified
p. 79 → 130
• Examine written agreements with TPSPs.
Removed
p. 80
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.9 For service providers only: Do service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment? Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.
Removed
p. 80
Does the plan address the following, at a minimum:
Modified
p. 80 → 120
• Examine documented policies and procedures.
Modified
p. 80 → 131
• Examine templates used for written agreements.
Modified
p. 80 → 133
Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum? Review incident response plan procedures.
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
Modified
p. 80 → 133
• Reference or inclusion of incident response procedures from the payment brands.
Modified
p. 80 → 133
Business recovery and continuity procedures? Review incident response plan procedures.
• Business recovery and continuity procedures.
Modified
p. 80 → 134
• Observe incident response processes.
Removed
p. 81
Reference or inclusion of incident response procedures from the payment brands? Review incident response plan procedures.
Modified
p. 81 → 123
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested 12.10.1(b) (cont.) Data backup processes? Review incident response plan procedures.
PCI DSS Requirement Expected Testing Response12F (Check one response for each requirement) In Place In Place with CCW Not Applicable Not Tested Not in Place 12.4 PCI DSS compliance is managed.
Modified
p. 81 → 133
Analysis of legal requirements for reporting compromises? Review incident response plan procedures.
• Analysis of legal requirements for reporting compromises.
Modified
p. 81 → 133
Coverage and responses of all critical system components? Review incident response plan procedures.
• Coverage and responses of all critical system components.
Modified
p. 81 → 134
Interview responsible personnel.
• Interview incident response personnel.
Removed
p. 82
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested (a) Do reviews cover the following processes:
Daily log reviews Firewall rule-set reviews Applying configuration standards to new systems Responding to security alerts Change management processes Examine policies and procedures for performing quarterly reviews.
(b) Are reviews performed at least quarterly? Interview personnel.
Daily log reviews Firewall rule-set reviews Applying configuration standards to new systems Responding to security alerts Change management processes Examine policies and procedures for performing quarterly reviews.
(b) Are reviews performed at least quarterly? Interview personnel.
Modified
p. 82 → 124
Examine records of reviews.
• Examine records of reviews.
Modified
p. 82 → 125
• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.
Removed
p. 83
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested A1 Is each entity’s (that is, a merchant, service provider, or other entity) hosted environment and data protected, per A1.1 through A1.4 as follows:
A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.
Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.
A1.1 Does each entity run processes that have access to only that entity’s cardholder data environment, and are these application processes run using the unique ID of the entity? No entity on the system can use a shared web server user ID.
All CGI scripts used by an entity must be created and run as the entity’s …
A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.
Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.
A1.1 Does each entity run processes that have access to only that entity’s cardholder data environment, and are these application processes run using the unique ID of the entity? No entity on the system can use a shared web server user ID.
All CGI scripts used by an entity must be created and run as the entity’s …
Modified
p. 83 → 136
Examine system configurations and file permissions for hosted entities.
• Examine system configurations.
Removed
p. 84
PCI DSS Question Expected Testing Response (Check one response for each question) Yes with CCW No N/A Not Tested A1.2 (cont.) Do all entities’ users not have write access to shared system binaries? Examine system configurations and file permissions for shared system binaries.
Is viewing of log entries restricted to the owning entity? Examine system configurations and file permissions for viewing log entries.
(e) Are restrictions in place for the use of these system resources? Disk space, Bandwidth, Memory, CPU This ensures that each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions, resulting in, for example, buffer overflows).
Examine system configurations and file permissions for use of: Disk space Bandwidth Memory CPU A1.3 Are logging and audit trails enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10? Examine log settings.
Is logging enabled as follows, for each merchant and service …
Is viewing of log entries restricted to the owning entity? Examine system configurations and file permissions for viewing log entries.
(e) Are restrictions in place for the use of these system resources? Disk space, Bandwidth, Memory, CPU This ensures that each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions, resulting in, for example, buffer overflows).
Examine system configurations and file permissions for use of: Disk space Bandwidth Memory CPU A1.3 Are logging and audit trails enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10? Examine log settings.
Is logging enabled as follows, for each merchant and service …
Modified
p. 84 → 137
Logs are enabled for common third-party applications? Examine log settings.
• Logs are enabled for common third-party applications.
Modified
p. 84 → 137
Logs are active by default? Examine log settings.
• Logs are active by default.
Modified
p. 84 → 137
Logs are available for review by the owning entity? Examine log settings.
• Logs are available for review only by the owning customer.
Modified
p. 84 → 137
Log locations are clearly communicated to the owning entity? Examine log settings.
• Log locations are clearly communicated to the owning customer.
Removed
p. 85
Description of usage, including; what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment; Risk assessment results and risk reduction controls in place; Description of processes to monitor for new vulnerabilities associated with SSL/early TLS; Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments; Overview of migration project plan to replace SSL/early TLS at a future date? Review the documented Risk Mitigation and Migration Plan.
A2.3 For service providers only: Is there a secure service offering in place? Examine system configurations and supporting documentation.
A2.3 For service providers only: Is there a secure service offering in place? Examine system configurations and supporting documentation.
Modified
p. 85 → 139
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.
Modified
p. 85 → 139
Applicability Notes Describe results as instructed in “Requirement Responses” (page v) This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.1.2 and A2.1.3 apply to POS POI service providers.
Modified
p. 85 → 139
• Examine documentation (for example, vendor documentation, system/network configuration details) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.
Modified
p. 85 → 140
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:
Modified
p. 87 → 142
Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Note: Only entities that have a legitimate and documented technological or business constraint can consider the use of compensating controls to achieve compliance.
Modified
p. 87 → 142
Refer to Appendices B, C, and D of PCI DSS for information about compensating controls and guidance on how to complete this worksheet.
Refer to Appendices B and C in PCI DSS for information about compensating controls and guidance on how to complete this worksheet.
Modified
p. 87 → 142
1. Constraints Document the legitimate technical or business constraints precluding compliance with the original requirement.
Modified
p. 87 → 142
Objective Define the objective of the original control; identify the objective met by the compensating control.
3. Objective Define the objective of the original control.
Modified
p. 87 → 142
Identified Risk Identify any additional risk posed by the lack of the original control.
4. Identified Risk Identify any additional risk posed by the lack of the original control.
Modified
p. 87 → 142
Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any.
2. Definition of Compensating Controls Define the compensating controls: explain how they address the objectives of the original control and the increased risk, if any.
Modified
p. 87 → 142
Validation of Compensating Controls Define how the compensating controls were validated and tested.
5. Validation of Compensating Controls Define how the compensating controls were validated and tested.
Modified
p. 87 → 142
Maintenance Define process and controls in place to maintain compensating controls.
6. Maintenance Define process(es) and controls in place to maintain compensating controls.
Modified
p. 88 → 143
Requirement Reason Requirement is Not Applicable 3.4 Cardholder data is never stored electronically
Requirement Reason Requirement is Not Applicable
Modified
p. 89 → 144
Requirement Describe which part(s) of the requirement was not tested Describe why requirements were not tested
Requirement Description of Requirement(s) Not Tested Describe why the Requirement was Excluded from the Assessment
Modified
p. 89 → 144
Requirement 12 Requirement 12.2 was the only requirement tested. All other requirements from Requirement 12 were excluded.
Requirement 10 No requirements from Requirement 10 were tested.
Removed
p. 90
Compliant but with Legal exception: One or more requirements are marked “No” due to a legal restriction that prevents the requirement from being met. This option requires additional review from acquirer or payment brand.
If checked, complete the following:
I have confirmed with my payment application vendor that my payment system does not store sensitive authentication data after authorization.
I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.
If my environment changes, I recognize I must reassess my environment and implement any additional PCI DSS requirements that apply.
If checked, complete the following:
I have confirmed with my payment application vendor that my payment system does not store sensitive authentication data after authorization.
I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.
If my environment changes, I recognize I must reassess my environment and implement any additional PCI DSS requirements that apply.
Modified
p. 90 → 145
Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ D (Section 2), dated (SAQ completion date).
Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ D (Section 2), dated (Self-assessment completion date YYYY-MM-DD).
Modified
p. 90 → 145
Based on the results documented in the SAQ D noted above, the signatories identified in Parts 3b-3d, as applicable, assert(s) the following compliance status for the entity identified in Part 2 of this document: (check one):
Based on the results documented in the SAQ D noted above, each signatory 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.
Modified
p. 90 → 145
Compliant: All sections of the PCI DSS SAQ are complete, all questions answered affirmatively, resulting in an overall COMPLIANT rating; thereby (Service Provider Company Name) has demonstrated full compliance with the PCI DSS.
Compliant: All sections of the PCI DSS SAQ are complete, and all assessed requirements are marked as being either 1) In Place 2) In Place with CCW, or 3) Not Applicable, resulting in an overall COMPLIANT rating; thereby (Service Provider Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ except those noted as Not Tested above.
Modified
p. 90 → 145
Non-Compliant: Not all sections of the PCI DSS SAQ are complete, or not all questions are answered affirmatively, resulting in an overall NON-COMPLIANT rating, thereby (Service Provider Company Name) has not demonstrated full compliance with the PCI DSS.
Non-Compliant: Not all sections of the PCI DSS SAQ are complete, or one or more requirements are marked as Not in Place, resulting in an overall NON-COMPLIANT rating, thereby (Service Provider Company Name) has not demonstrated compliance with the PCI DSS requirements included in this SAQ.
Modified
p. 90 → 145
An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document. Check with the payment brand(s) before completing Part 4.
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.
Modified
p. 90 → 145
Affected Requirement Details of how legal constraint prevents requirement being met Part 3a. Acknowledgement of Status Signatory(s) confirms:
Affected Requirement Details of how legal constraint prevents requirement from being met
Modified
p. 90 → 146
(Select all that apply)
Modified
p. 90 → 146
PCI DSS Self-Assessment Questionnaire D, Version (version of SAQ), was completed according to the instructions therein.
PCI DSS Self-Assessment Questionnaire D, Version 4.0, was completed according to the instructions therein.
Modified
p. 90 → 146
All information within the above-referenced SAQ and in this attestation fairly represents the results of my assessment in all material respects.
All information within the above-referenced SAQ and in this attestation fairly represents the results of the entity’s assessment in all material respects.
Removed
p. 91
ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name).
Modified
p. 91 → 146
Part 3b. Service Provider Attestation Signature of Service Provider Executive Officer Date:
Part 3b. Service Provider Attestation Signature of Service Provider Executive Officer Date: YYYY-MM-DD Service Provider Executive Officer Name: Title:
Modified
p. 91 → 146
Part 3c. Qualified Security Assessor (QSA) Acknowledgement (if applicable) If a QSA was involved or assisted with this assessment, describe the role performed:
Part 3c. Qualified Security Assessor (QSA) Acknowledgement If a QSA was involved or assisted with this assessment, indicate the role performed:
Modified
p. 91 → 146
Signature of Duly Authorized Officer of QSA Company Date:
Signature of Duly Authorized Officer of QSA Company Date: YYYY-MM-DD Duly Authorized Officer Name: QSA Company:
Modified
p. 91 → 146
Part 3d. Internal Security Assessor (ISA) Involvement (if applicable) If an ISA(s) was involved or assisted with this assessment, identify the ISA personnel and describe the role performed:
Part 3d. PCI SSC Internal Security Assessor (ISA) Involvement If an ISA(s) was involved or assisted with this assessment, indicate the role performed:
Removed
p. 92
Check with the applicable payment brand(s) before completing Part 4.
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 a firewall configuration to protect cardholder data.
Do not use vendor-supplied defaults for system passwords and other security parameters.
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 a firewall configuration to protect cardholder data.
Do not use vendor-supplied defaults for system passwords and other security parameters.
Removed
p. 92
Protect all systems against malware and regularly update anti-virus software or programs.
Removed
p. 92
Appendix A1 Additional PCI DSS Requirements for Shared Hosting Providers.
Appendix A2 Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card- Present POS POI Terminal Connections.
Appendix A2 Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card- Present POS POI Terminal Connections.