Document Comparison

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 PCI DSS v4.0 requirements.

Added appendices to support new reporting responses.

December 2022 4.0 1 Removed “In Place with Remediation” as a reporting option from Requirement Responses table, Attestation of Compliance (AOC) Part 2g, SAQ Section 2 Response column, and AOC Section 3. Also removed former Appendix C.

Added “In Place with CCW” to AOC Section 3.

Added guidance for responding to future-dated requirements.

Added minor clarifications and addressed typographical errors.

September 2023 4.0 2 Removed erroneous SAQ Completion Guidance at Requirement 11.6.1 - it is not applicable to SAQ A-EP merchants.

Added p. 4

This SAQ is not applicable to service providers SAQ A-EP merchants will confirm that they meet the following eligibility criteria for this payment channel:

• The merchant accepts only e-commerce transactions;

• All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor;

• The merchant’s e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor;

• If the merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider);

• Each element of the payment page(s) delivered to the customer’s browser originates from either the merchant’s website or a PCI DSS compliant TPSP;

• The merchant does not electronically store, process, or transmit any account data on merchant …

Added p. 6

• Interview: The merchant converses with individual personnel. Interview objectives may include confirmation of whether an activity is performed, descriptions of how an activity is performed, and whether personnel have particular knowledge or understanding.

The testing methods are intended to allow the merchant to demonstrate how it has met a requirement. The specific items to be examined or observed and personnel to be interviewed should be appropriate for both the requirement being assessed and the entity’s particular implementation.

Full details of testing procedures for each requirement can be found in PCI DSS.

Requirement Responses For each requirement item, there is a choice of responses to indicate the merchant’s status regarding that requirement. Only one response should be selected for each requirement item.

A description of the meaning for each response and when to use each response is provided in the table below:

In Place The expected testing has been performed, and all elements of 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.

Added p. 7

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.

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 …

Added p. 10

Indicate all payment channels used by the business that are included in this assessment.

Mail order/telephone order (MOTO) E-Commerce Card-present Are any payment channels not included in this assessment? If yes, indicate which channel(s) is not included in the assessment and provide a brief explanation about why the channel was excluded.

Part 2b. Description of Role with Payment Cards For each payment channel included in this assessment as selected in Part 2a above, describe how the business stores, processes and/or transmits account data.

Channel How Business Stores, Processes, and/or Transmits Account Data Part 2c. Description of Payment Card Environment Provide a high-level description of the environment covered by this assessment. For example:

• Connections into and out of the cardholder data environment (CDE).

• Critical system components within the CDE, such as POI devices, databases, web servers, etc., and any other necessary payment components, as applicable.

• System components that could impact the security of account …

Added p. 11

Facility Type Total number of locations (How many locations of this type are in scope) Location(s) of facility (city, country) Example: Data centers 3 Boston, MA, USA Part 2e. PCI SSC Validated Products and Solutions Does the merchant use any item identified on any PCI SSC Lists of Validated Products and Solutions? Provide the following information regarding each item the merchant uses from PCI SSC’s Lists of Validated Products and Solutions.

Name of PCI SSC- validated Product or Version of Product or

PCI SSC Standard to which product or solution was validated

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

Added p. 13

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 in Place

* PCI DSS Requirements indicated above refer to the requirements in Section 2 of this SAQ.

Added p. 14

The merchant accepts only e-commerce transactions.

All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor.

The merchant’s e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor.

If merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements (for example, including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider).

Each element of the payment page(s) delivered to the customer’s browser originates from either the merchant’s website or a PCI DSS compliant TPSP.

The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions.

The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and …

Added p. 15

• Examine configurations standards.

Added p. 16

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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.

Added p. 16

• Examine change control records.

Applicability Notes 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.

Applicability Notes A current network diagram(s) or other technical or topological solution that identifies network connections and devices can be used to meet this requirement.

Added p. 16

• Shows all account data flows across systems and networks.

• Updated as needed upon changes to the environment.

• Examine data flow diagrams.

• Observe network configurations.

Applicability Notes A data-flow diagram(s) or other technical or topological solution that identifies flows of account data across systems and networks can be used to meet this requirement.

Added p. 17

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

• Examine documentation from reviews performed.

Added p. 17

• Secured from unauthorized access.

• Kept consistent with active network configurations.

• Examine NSC configuration files.

Applicability Notes 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. 17

• To only traffic that is necessary.

• To only traffic that is necessary.

• All other traffic is specifically denied.

• All other traffic is specifically denied.

Added p. 17

• Examine NSC configurations.

• Examine NSC configurations.

Added p. 17

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

Added p. 17

• Examine current network diagrams.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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 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.

Added p. 18

• Examine the data-flow diagram and network diagram.

Applicability Notes This requirement is not intended to apply to storage of account data in volatile memory but does apply where memory is being treated as persistent storage (for example, RAM disk). Account data can only be stored in volatile memory during the time necessary to support the associated business process (for example, until completion of the related payment card transaction).

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Added p. 19

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

Applicability Notes 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 to All System Components

Note: For SAQ A-EP, Requirement 2 applies to configurations and …

Added p. 20

• Cover all system components.

• Address all known security vulnerabilities.

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

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

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

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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.

Added p. 21

• Observe a system administrator logging on using vendor default accounts.

Applicability Notes 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. 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 service.

Added p. 21

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

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

• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.

Added p. 22

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 2.2.5 If any insecure services, protocols, or daemons are present:

• Business justification is documented.

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

• Examine configuration standards.

Added p. 22

Applicability Notes This includes administrative access via browser-based interfaces and application programming interfaces (APIs).

Added p. 23

Requirement 3: Protect Stored Account Data

Note: For SAQ A-EP, Requirement 3 applies only to merchants with paper records that include account data (for example, receipts or printed reports).

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.1 Processes and mechanisms for protecting stored account data are defined and understood.

Added p. 23

Selection of any of the In Place responses for Requirement 3.1.1 means that, if the merchant has paper storage of account data, the merchant has policies and procedures in place that govern merchant activities for Requirement 3. This helps to ensure personnel are aware of and following security policies and documented operational procedures for managing the secure storage of any paper records with account data.

If merchant does not store paper records with account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.2 Storage of account data is kept to a minimum.

Added p. 24

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

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

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

• Processes for secure deletion 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 …

Added p. 25

• Observe the secure data deletion processes.

Applicability Notes Part of this Applicability Note was intentionally removed for this SAQ as it does not apply to merchant assessments.

Sensitive authentication data includes the data cited in Requirements 3.3.1.2 through 3.3.1.3.

Added p. 25

• Examine data sources.

Applicability Notes 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.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place SAQ Completion Guidance:

Selection of any of the In Place responses for Requirement 3.3.1.2 means that if the merchant writes down the card verification code while a transaction is being conducted, the merchant either securely destroys the paper (for example, with a shredder) immediately after the transaction is complete, or obscures the code (for example, by “blacking it out” with a marker) before the paper is stored.

If the merchant never requests the three-digit or four-digit number printed on the front or back of a payment card (“card verification code”), mark this requirement as Not Applicable and …

Added p. 26

Applicability Notes 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.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public

Note: For SAQ A-EP, Requirement 4 applies to merchants when sending payment related data to their TPSP.

PCI DSS Requirement Expected Testing (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.

Added p. 28

PCI DSS Requirement Expected Testing (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.2 PAN is protected with strong cryptography during transmission.

Added p. 28

• Only trusted keys and certificates are accepted.

• Examine cardholder data transmissions.

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

• The encryption strength is appropriate for the encryption methodology in use.

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

Added p. 30

Requirement 5: Protect All Systems and Networks from Malicious Software

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.

Added p. 30

• Examine the periodic evaluations.

Added p. 30

• Detects all known types of malware.

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

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable 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 System components covered by this requirement are those for which there is no anti-malware solution deployed per Requirement 5.2.1.

Added p. 31

• Examine documented results of periodic evaluations.

Added p. 31

• Examine anti-malware solution(s) configurations, including any master installation.

• Examine system components and logs.

• Examine anti-malware solution(s) configurations, including any master installation.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 5.3.2 The anti-malware solution(s):

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

• Performs continuous behavioral analysis of systems or processes.

• Examine logs and scan results.

• Examine logs and scan results.

Added p. 32

• Examine documented results of periodic malware scans.

Applicability Notes This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2.

Added p. 32

• 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 system components with removable electronic media.

• Examine anti-malware solution(s) configurations.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.

Added p. 33

• Examine anti-malware configurations.

Applicability Notes 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. 33

• Observe implemented processes.

• Examine mechanisms.

Applicability Notes 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.

Requirement 6: Develop and Maintain Secure Systems and Software

Note: For SAQ A-EP, Requirement 6 applies to webservers that host the payment page(s) provided from the merchant's website to the customer's browser.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place …

Added p. 34

Note: For SAQ A-EP, requirements at 6.2 apply to merchants with bespoke software (developed to the entity's specifications by a third party) or custom software (developed by the entity). If merchant does not have such software, mark these requirements as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.

Added p. 34

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

Added p. 34

• Examine documented software development procedures.

Applicability Notes 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.

• Examine documented software development procedures.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable 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.

Added p. 35

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

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

Applicability Notes 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.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in …

Added p. 36

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

Added p. 37

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 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. 37

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

• Examine system components and related software.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 6.4 Public-facing web applications are protected against attacks.

Added p. 38

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

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

• By an entity that specializes in application security.

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

• All vulnerabilities are ranked in accordance with Requirement 6.3.1.

• All vulnerabilities are corrected.

• The application is re-evaluated after the corrections. OR

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

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

• Actively running and up to date as applicable.

• Generating audit logs.

• Configured to either block web-based attacks or generate an alert that is immediately investigated.

• Examine documented processes.

• Examine the system configuration settings and audit logs.

• Actively running and up to date as applicable.

• Generating audit logs.

• Configured to either block web-based attacks or generate …

Added p. 39

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

• Examine the system configuration settings.

Applicability Notes This new requirement will replace Requirement 6.4.1 once its effective date is reached. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place

Note: For SAQ A-EP, Requirement 6.4.3 applies to the payment page(s) provided from the merchant's website to the customer's browser.

Added p. 40

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

• Examine inventory records.

• 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 This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.

Added p. 40

• Reason for, and description of, the change.

• Documentation of security impact.

• Documented change approval by authorized parties.

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

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

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

• Examine documented change control procedures.

• Examine recent changes to system components and trace changes to change control documentation.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 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.

• Observe the affected systems/networks.

Applicability Notes This Applicability Note was intentionally removed as it does not …

Added p. 42

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 7.2 Access to system components and data is appropriately defined and assigned.

Added p. 42

• Job classification and function.

• Least privileges necessary to perform job responsibilities.

• Examine user access settings, including for privileged users.

• Interview responsible management personnel.

• Interview personnel responsible for assigning access.

Added p. 42

• Examine user IDs and assigned privileges.

• Examine documented approvals.

Added p. 42

• At least once every six months.

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

• Any inappropriate access is addressed.

• Management acknowledges that access remains appropriate.

• Examine documented results of periodic reviews of user accounts.

Applicability Notes (continued) ♦ Refer to the “Requirement Responses” section (page v) for information about these response options.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 7.2.4 (cont.) This requirement applies to all user accounts and related access privileges, including those used by personnel and third parties/vendors, and accounts used to access third-party cloud services.

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.

Added p. 43

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

• Access is limited to the systems, applications, or processes that specifically require their use.

• Examine privileges associated with system and application accounts.

Requirement 8: Identify Users and Authenticate Access to System Components

Note: For SAQ A-EP, Requirement 8 applies to merchant webservers that host the payment page(s) provided from the merchant’s website to the customer’s browser.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

Added p. 44

• Examine audit logs and other evidence.

Added p. 45

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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.

• Examine user account lists on system components and applicable documentation.

• Examine authentication policies and procedures.

Added p. 45

• Authorized with the appropriate approval.

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

• Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions).

• Examine system settings.

Applicability Notes This requirement applies to all user accounts, including employees, contractors, consultants, temporary workers, and third-party vendors.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.2.5 Access for terminated users is immediately revoked.

• Examine information sources for terminated users.

• Review current user access lists.

Added p. 46

• Examine user accounts and last logon information.

Added p. 46

• Enabled only during the time period needed and disabled when not in use.

• Use is monitored for unexpected activity.

• Examine documentation for managing accounts.

Added p. 46

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

This requirement is not meant to prevent legitimate activities from being performed while the console/PC is unattended.

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

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3 Strong authentication for users and administrators is established and managed.

Added p. 47

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

Added p. 47

• Examine repositories of authentication factors.

• Examine data transmissions.

Added p. 47

• Examine procedures for modifying authentication factors.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3.4 Invalid authentication attempts are limited by:

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

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

Added p. 48

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

Added p. 48

• 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 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 accounts, which are governed by requirements in section 8.6. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Added p. 49

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.

Added p. 49

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

• Review authentication policies and procedures that are distributed to users.

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

• Passwords/passphrases are changed at least once every 90 days,

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

• Inspect system configuration settings.

• Examine authentication policies and procedures.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3.9 (cont.) This requirement applies to in-scope system components that are not in the CDE because …

Added p. 50

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

• Examine system configuration settings and/or observe physical controls, as applicable.

Added p. 50

• Examine network and/or system configurations.

• Observe administrator personnel logging into the CDE.

Applicability Notes 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.

• Examine network and/or system configurations.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.2 MFA is implemented for all access into the CDE.

• Observe personnel logging in to the CDE.

Applicability Notes This requirement does not apply to:

• Application or system accounts performing automated functions.

• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate …

Added p. 53

• 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 vendor system documentation.

• Examine system configurations for the MFA implementation.

• Interview responsible personnel and observe processes.

• Observe personnel logging into system components in the CDE.

• Observe personnel connecting remotely from outside the entity’s network.

• Every action taken is attributable to an individual user.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.6 Use of application and system accounts and associated authentication factors is strictly managed.

Added p. 54

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

Added p. 54

• Examine system development procedures.

• 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 Stored passwords/passphrases are required to be encrypted in accordance with PCI DSS Requirement 8.3.2.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:

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

• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.2 Physical access controls manage …

Added p. 56

• Observe physical entry controls.

Added p. 56

Note: For SAQ A-EP, Requirements at 9.4 only apply to merchants with paper records (for example, receipts or printed reports) with account data, including primary account numbers (PANs).

Added p. 56

• Examine logs or other documentation.

• Interview responsible personnel at the storge location(s).

Added p. 56

• Examine media logs or other documentation.

Added p. 56

• Media is sent by secured courier or other delivery method that can be accurately tracked.

• Examine offsite tracking logs for all media.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals).

• Examine offsite media tracking logs.

Applicability Notes Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have “manager” as part of their title.

Added p. 57

• Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.

• Materials are stored in secure storage containers prior to destruction.

• Examine the periodic media destruction policy.

• Observe storage containers.

Applicability Notes These requirements for media destruction when that media is no longer needed for business or legal reasons are separate and distinct from PCI DSS Requirement 3.2.1, which is for securely deleting cardholder data when no longer needed per the entity’s cardholder data retention policies.

Selection of any of the In Place responses for Requirements at 9.4 means that the merchant securely stores any paper media with account data, for example by storing the paper in a locked drawer, cabinet, or safe, and that the merchant destroys such paper when no longer needed for business purposes. This includes a written document or policy for employees, so they know how to secure paper with account data and how …

Added p. 58

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

Added p. 58

• Interview the system administrator.

Added p. 58

• Creation of new accounts.

• Elevation of privileges.

• All changes, additions, or deletions to accounts with administrative access.

Added p. 58

• All initialization of new audit logs, and

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

• Examine system settings.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 10.2.1.7 Audit logs capture all creation and deletion of system- level objects.

Added p. 59

• User identification.

• Success and failure indication.

• Origination of event.

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

Added p. 59

• Examine system configurations and privileges.

• Examine system configurations and privileges.

Added p. 59

• Examine backup configurations or log files.

Added p. 59

• Examine monitored files.

Added p. 60

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 10.4 Audit logs are reviewed to identify anomalies or suspicious activity.

Added p. 60

• All security events.

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

• Logs of all critical system components.

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

Added p. 60

• Examine log review mechanisms.

Added p. 60

• Examine documented results of log reviews.

Applicability Notes This requirement is applicable to all other in-scope system components not included in Requirement 10.4.1.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable 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.

Added p. 61

• Examine documented audit log retention policies and procedures.

• Examine configurations of audit log history.

Added p. 61

Applicability Notes 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 Response♦ (Check one response for each requirement) In Place In Place Not Applicable 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.

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

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

• Examine system configuration settings for acquiring, distributing, and storing the correct time.

Added p. 62

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

• Any changes to time settings on critical systems are logged, monitored, and reviewed.

Requirement 11: Test Security of Systems and Networks Regularly

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.

Added p. 63

• At least once every three months.

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

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

However, for subsequent years after the initial PCI DSS assessment, passing scans at least every three months must have occurred.

ASV scanning tools can scan a vast array of network types and topologies. …

Added p. 64

• 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 Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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 the …

Added p. 65

• Per the entity’s defined methodology.

• At least once every 12 months.

• After any significant infrastructure or application upgrade or change.

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

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

Added p. 65

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

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

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable 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.

• Covering all segmentation controls/methods in use.

• According to the entity’s defined penetration testing methodology.

• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.

• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).

• Performed by a qualified …

Added p. 66

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

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

• Personnel are alerted to suspected compromises.

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

• Examine system configurations and network diagrams.

• Examine monitored files.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:

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

• To perform critical file comparisons at least once weekly.

• Examine system settings for the change-detection mechanism.

Applicability Notes For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change- detection mechanisms such as file integrity …

Added p. 68

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

• At least once every seven days OR

• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

Applicability Notes E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Anti-skimming measures cannot be removed from payment pages without a prompt alert being generated.

The intention of this requirement is not that an entity installs software in the systems or browsers …

Added p. 69

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

Added p. 69

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

Selection of any of the In Place responses for Requirements 12.1.1 and 12.1.2 means that the merchant has a security policy that is reasonable for the size and complexity of the merchant’s operations, and that the policy is reviewed at least once every 12 months and updated if needed.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 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.

Selection of any of the In Place responses for Requirement 12.1.3 means that the merchant’s security policy defines basic security responsibilities for all personnel, consistent with the size and complexity of the merchant’s operations. For example, security responsibilities could be …

Added p. 70

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

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place Applicability Notes This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Added p. 71

Selection of any of the In Place responses for Requirement 12.6.1 means that the merchant has a security awareness program in place, consistent with the size and complexity of the merchant’s operations. For example, a simple awareness program could be a flyer posted in the back office, or a periodic e-mail sent to all employees. Examples of awareness program messaging include descriptions of security tips all employees should follow, such as how to lock doors and storage containers.

Added p. 71

• Phishing and related attacks.

• Social engineering.

Applicability Notes 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.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

Added p. 72

Applicability Notes 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.

Added p. 72

• 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 The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.

Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 12.8.4 A program …

Added p. 74

• Incident response procedures with specific containment and mitigation activities for different types of incidents.

• Examine documentation from previously reported incidents.

Selection of any of the In Place responses for Requirement 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. For example, such a plan could be a simple document posted in the back office that lists who to call in the event of various situations with an annual review to confirm it is still accurate, but could extend all the way to a full incident response plan including backup “hotsite” facilities and thorough annual testing. This plan should be readily available to all personnel as a resource in an emergency.

Added p. 76

Note: This can be, but is not required to be, the stated Customized Approach Objective listed for this requirement in PCI DSS.

Requirement 3.5.1 Account data is never stored electronically

Added p. 79

Target Date for Compliance: YYYY-MM-DD A merchant submitting this form with a Non-Compliant status may be required to complete the Action Plan in Part 4 of this document. Confirm with the entity to which this AOC will be submitted before completing Part 4.

Compliant but with Legal exception: One or more assessed requirements in the PCI DSS SAQ are marked as Not in Place due to a legal restriction that prevents the requirement from being met and all other 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 (Merchant Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ except those noted as Not in Place due to a legal restriction.

This option requires additional review from the entity to which this AOC will be submitted. If selected, …

Added p. 80

PCI DSS controls will be maintained at all times, as applicable to the merchant’s environment.

Part 3b. Merchant Attestation Signature of Merchant Executive Officer  Date: YYYY-MM-DD Merchant Executive Officer Name: Title:

QSA performed testing procedures.

QSA provided other assistance.

If selected, describe all role(s) performed:

If selected, describe all role(s) performed:

Signature of Lead QSA  Date: YYYY-MM-DD Lead QSA Name:

ISA(s) performed testing procedures.

ISA(s) provided other assistance.

Added p. 81

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

Removed p. 2

This document aligns with PCI DSS v3.2.1 r1.

Modified p. 2

February 2014 3.0 New SAQ to address requirements applicable to ~~e- commerce~~ merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

February 2014 3.0 New SAQ to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

Removed p. 4

SAQ A-EP merchants confirm that, for this payment channel:

• Your company accepts only e-commerce transactions;

• All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;

• Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;

• If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);

• Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s);

• Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;

• …

Modified p. 4

SAQ A-EP merchants are e-commerce merchants ~~who~~ partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any ~~cardholder~~ data on their systems or premises.

SAQ A-EP merchants are e-commerce merchants that partially outsource their e-commerce payment channel to PCI DSS validated and compliant third parties and do not electronically store, process, or transmit any account data on their systems or premises.

Modified p. 4

This ~~shortened version of the~~ SAQ includes ~~questions~~ that apply to a specific type of ~~small~~ merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to ~~your~~ environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for ~~your~~ environment. ~~Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.~~

This SAQ includes only those requirements that apply to a specific type of merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to the cardholder data environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for the merchant’s environment.

Modified p. 4

Note: For the purposes of this SAQ, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how ~~the payment card~~ data is transmitted, even though the website itself does not receive ~~cardholder~~ data.

Note: For the purposes of this SAQ, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how account data is transmitted, even though the website itself does not receive account data.

Removed p. 5

1. Identify the applicable SAQ for your environment⎯refer to the Self-Assessment Questionnaire Instructions and Guidelines document on PCI SSC website for information.

2. Confirm that your environment is properly scoped and meets the eligibility criteria for the SAQ you are using (as defined in Part 2g of the Attestation of Compliance).

• Section 3 (Parts 3 & 4 of the AOC)

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.

PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms

• Descriptions and definitions of terms used in the PCI DSS and self-assessment questionnaires These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org). Organizations are encouraged to review the PCI DSS and other supporting documents before beginning an assessment.

Expected Testing The instructions provided in the “Expected Testing” column are based on the testing procedures …

Modified p. 5

3. Assess ~~your~~ environment for compliance with ~~applicable~~ PCI DSS requirements.

3. Assess the environment for compliance with PCI DSS requirements.

Modified p. 5

• Section 1 (Parts 1 & 2 of the ~~AOC)~~

• Section 3: Validation and Attestation Details (Parts 3 & 4 of the AOC

Modified p. 5

• ~~Assessment~~ Information and Executive ~~Summary.~~

• Contact Information and Executive Summary).

Modified p. 5

• ~~PCI DSS Self-Assessment~~ Questionnaire ~~(SAQ A-EP)~~

• Section 2

•Self-Assessment Questionnaire A-EP.

Modified p. 5

• Validation ~~and Attestation Details~~ and Action Plan for Non-Compliant Requirements (if ~~applicable)~~

• PCI DSS Validation and Action Plan for Non-Compliant Requirements (if Part 4 is applicable)).

Modified p. 5

5. Submit the SAQ and ~~Attestation of Compliance (AOC),~~ along with any other requested documentation

•such as ASV scan reports

•to your acquirer, payment ~~brand or other requester.~~

5. Submit the SAQ and AOC, along with any other requested documentation•such as ASV scan reports•to the requesting organization (those organizations that manage compliance programs such as payment brands and acquirers).

Modified p. 5 → 8

~~(PCI~~ Data Security Standard Requirements and ~~Security Assessment Procedures)~~

PCI Data Security Standard Requirements and Testing Procedures (PCI DSS)

Modified p. 5 → 8

• Guidance on Compensating Controls ~~SAQ Instructions and Guidelines documents~~

• Guidance on Compensating Controls

Modified p. 5 → 8

• How to determine which SAQ is right for your organization

• How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)

• Guidance and information about SAQs.

Removed p. 6

A description of the meaning for each response is provided in the table below:

Yes The expected testing has been performed, and all elements of the requirement have been met as stated.

Yes with CCW (Compensating Control Worksheet) The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.

All responses in this column require completion of a Compensating Control Worksheet (CCW) in Appendix B of the SAQ.

Information on the use of compensating controls and guidance on how to complete the worksheet is provided in the PCI DSS.

No Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before it will be known if they are in place.

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

Modified p. 7 → 9

Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the merchant’s self-assessment ~~with~~ the Payment Card Industry Data Security Standard Requirements and ~~Security Assessment Procedures (PCI DSS).~~ Complete all ~~sections:~~ The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact ~~your acquirer (merchant bank) or~~ the ~~payment brands~~ to ~~determine~~ reporting and submission procedures.

Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the merchant’s self-assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures. Complete all sections. The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact the entity(ies) to which the Attestation of Compliance (AOC) will be submitted for reporting and submission procedures.

Modified p. 7 → 9

~~Part 1b.~~ Qualified Security Assessor Company ~~Information (if applicable) Company Name:~~

Qualified Security Assessor Company name:

Modified p. 7 → 10

Note: If ~~your~~ organization has a payment channel ~~or process~~ that is not covered by this SAQ, consult ~~your acquirer or payment brand~~ about validation for the other channels.

Note: If the organization has a payment channel that is not covered by this SAQ, consult with the entity(ies) to which this AOC will be submitted about validation for the other channels.

Removed p. 8

Type of facility Number of facilities of this type Location(s) of facility (city, country) Example: Retail outlets 3 Boston, MA, USA Part 2d. Payment Applications Does the organization use one or more Payment Applications? Yes No Provide the following information regarding the Payment Applications your organization uses:

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.

Modified p. 8 → 10

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

Indicate whether the environment includes segmentation to reduce the scope of the assessment. (Refer to “Segmentation” section of PCI DSS for guidance on segmentation.)

Removed p. 9

Description of services provided by QIR:

Does your company share cardholder data with any third-party service providers (for example, Qualified Integrator & Resellers (QIR), gateways, payment processors, payment service providers (PSP), web-hosting companies, airline booking agents, loyalty program agents, etc.)? Name of service provider: Description of services provided:

Part 2g. Eligibility to Complete SAQ A-EP Merchant certifies eligibility to complete this shortened version of the Self-Assessment Questionnaire because, for this payment channel:

Merchant accepts only e-commerce transactions; All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor; Merchant’s e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor; If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the …

Removed p. 10

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 1.1 Are firewall and router configuration standards established and implemented to include the following:

Removed p. 10

(b) Is there a process to ensure the diagram is kept current?

• Interview responsible personnel.

Removed p. 10

(b) Is there a process to ensure the diagram is kept current?

• Interview personnel.

Removed p. 10

• Observe network configurations to verify that a firewall(s) is in place.

(b) Is the current network diagram consistent with the firewall configuration standards?

• Compare firewall configuration standards to current network diagram.

Modified p. 10 → 15

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. 10 → 15

Self-assessment completion date: Build and Maintain a Secure Network

Self-assessment completion date: YYYY-MM-DD Build and Maintain a Secure Network and Systems

Modified p. 10 → 15

Requirement 1: Install and maintain ~~a firewall configuration to protect data~~

Requirement 1: Install and maintain network security controls

Removed p. 11

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 1.1.6 (a) Do firewall and router configuration standards include a documented list of services, protocols, and ports, including business justification and approval for each?

• Review firewall and router configuration standards.

(b) 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. 11

(b) Are firewall and router rule sets reviewed at least every six months?

• Examine documentation from firewall reviews.

Removed p. 11

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.

Removed p. 11

(b) 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. 11 → 20

• Examine ~~router~~ configuration ~~files and router configurations.~~

• Examine system configuration standards.

Removed p. 12

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 1.2.3 Are perimeter firewalls installed between all wireless networks and the cardholder data environment, and are these firewalls configured to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment?

• Review firewall and router configuration standards.

Modified p. 12 → 19

• Examine ~~firewall~~ and ~~router configurations.~~

• Examine policies and configuration standards.

Removed p. 13

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 1.3.7 (a) Are methods in place to prevent the disclosure of private IP addresses and routing information to the Internet? Note: Methods to obscure IP addressing may include, but are not limited to:

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

Removed p. 13

• Examine mobile and/or employee- owned devices.

• Examine mobile and/or employee- owned devices.

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

Modified p. 13 → 19

• Examine ~~firewall and router configurations.~~

• Examine device configuration settings.

Modified p. 13 → 20

• Known to all affected parties?

• Review security policies and operational procedures.

• Known to all affected parties.

Removed p. 14

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 2.1 (a) Are vendor-supplied defaults always changed before installing a system on the network? This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).

Removed p. 14

(b) Are unnecessary default accounts removed or disabled before installing a system on the network?

• Review policies and procedures.

• Review vendor documentation.

Removed p. 14

• Review system configuration standards.

(b) Are system configuration standards updated as new vulnerability issues are identified, as defined in Requirement 6.1?

• Review policies and procedures.

(c) Are system configuration standards applied when new systems are configured?

• Review policies and procedures.

Modified p. 14 → 21

• ~~Observe~~ system ~~configurations and account settings.~~

• Examine system configuration standards.

Modified p. 14 → 21

• Examine ~~system configurations and account settings.~~

• Examine configuration files.

Removed p. 15

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 2.2 (cont.) (d) Do system configuration standards include all of the following:

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

(b) If virtualization technologies are used, is only one primary function implemented per virtual system component or device?

• Examine system configurations.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 2.2.2 (a) 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.

• Compare enabled services, etc. to documented justifications.

Removed p. 16

(b) Are common system security parameters settings included in the system configuration standards?

• Review system configuration standards.

(c) Are security parameter settings set appropriately on system components?

• Examine system components.

• Compare settings to system configuration standards.

Removed p. 16

(b) Are enabled functions documented and do they support secure configuration?

• Review documentation.

(c) Is only documented functionality present on system components?

• Review documentation.

• Examine security parameters on system components.

Modified p. 16 → 71

• Examine security ~~parameter settings.~~

• Examine security awareness training content.

Modified p. 16 → 74

• ~~Examine security parameters on~~ system components.

• Coverage and responses of all critical system components.

Removed p. 17

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 2.3 Is non-console administrative access encrypted as follows:

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

(b) Are system services and parameter files configured to prevent the use of Telnet and other insecure remote login commands?

• Examine system components.

(c) Is administrator access to web-based management interfaces encrypted with strong cryptography?

• Examine system components.

(d) For the technology in use, is strong cryptography implemented according to industry best practice and/or vendor recommendations?

• Examine system components.

Modified p. 17 → 72

• Examine ~~services~~ and ~~files.~~

• Examine policies and procedures.

Modified p. 17 → 73

• ~~Review vendor~~ documentation.

• Examine documentation.

Removed p. 18

Requirement 3: Protect stored cardholder data

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 3.2 (c) 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):

Removed p. 18

- Incoming transaction data - All logs - History files - Trace files - Database schema - Database contents 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

Modified p. 18 → 70

• Examine ~~deletion processes.~~

• Examine documented policies and procedures.

Removed p. 19

Requirement 4: Encrypt transmission of cardholder data across open, public networks

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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.

(b) Are only trusted keys and/or certificates accepted?

• Observe inbound and outbound transmissions.

(c) Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations?

• Examine system configurations.

(d) Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)?

• Review vendor documentation.

(e) For TLS implementations, is …

Modified p. 19 → 70

• ~~Review~~ documented ~~standards.~~

• Examine documented evidence.

Modified p. 19 → 72

• Examine ~~keys~~ and ~~certificates.~~

• Examine policies and procedures.

Modified p. 19 → 72

• Examine ~~system configurations.~~

• Examine list of TPSPs.

Removed p. 20

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 4.3 Are security policies and operational procedures for encrypting transmissions of cardholder data:

Removed p. 21

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 5.1 Is anti-virus software deployed on all systems commonly affected by malicious software?

• Examine system configurations.

Removed p. 21

(a) Are all anti-virus software and definitions kept current?

• Examine policies and procedures.

• Examine anti-virus configurations, including the master installation.

(b) Are automatic updates and periodic scans enabled and being performed?

• Examine anti-virus configurations, including the master installation.

(c) Are all anti-virus mechanisms generating audit logs, and are logs retained in accordance with PCI DSS Requirement 10.7?

• Examine anti-virus configurations.

• Review log retention processes.

Modified p. 21 → 73

• Examine ~~system configurations.~~

• Examine documentation.

Modified p. 21 → 74

• Examine ~~system components.~~

• Examine documentation.

Removed p. 22

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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.

• Examine anti-virus configurations.

Removed p. 23

Requirement 6: Develop and maintain secure systems and applications

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 6.1 Is there a process to identify security vulnerabilities, including the following:

• Using reputable outside sources for vulnerability information?

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

Removed p. 23

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

Removed p. 24

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 6.4.5 (a) Are change-control procedures documented and require the following? - Documentation of impact - Documented change control approval by authorized parties - Functionality testing to verify that the change does not adversely impact the security of the system - Back-out procedures

• Review change control processes and procedures.

(b) Are the following performed and documented for all 6.4.5.1 Documentation of impact?

• Trace changes to change control documentation.

Removed p. 24

(b) For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production?

• Trace changes to change control documentation.

Modified p. 24 → 74

• Examine ~~change control documentation.~~

• Examine the incident response plan.

Removed p. 25

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 6.4.6 Upon completion of a significant change, are all relevant PCI DSS requirements implemented on all new or changed systems and networks, and documentation updated as applicable?

• Trace changes to change control documentation.

• Observe affected systems or networks.

Removed p. 25

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.

(c) Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities:

Removed p. 25

• Examine software-development policies and procedures.

Removed p. 26

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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. 27

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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.

• Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) as follows:

- Is situated in front of public-facing web applications to detect …

Modified p. 27 → 71

• Examine ~~records of application~~ security ~~assessments.~~

• Examine the security awareness program.

Modified p. 27 → 74

• ~~Review documented~~ processes.

• Data backup processes.

Removed p. 28

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 6.7 Are security policies and operational procedures for developing and maintaining secure systems and applications:

Removed p. 29

Requirement 7: Restrict access to cardholder data by business need to know

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 7.1 Is access to system components and cardholder data limited to only those individuals whose jobs require such access, as follows:

Removed p. 29

• To least privileges necessary to perform job responsibilities?

• Assigned only to roles that specifically require that privileged access?

• Examine written access control policy.

• Interview management.

• Interview management.

• Review privileged user IDs.

Removed p. 29

• Compare assigned privileges with documented approvals.

Requirement 8: Identify and authenticate access to system components

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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. 30

• Examine privileged and general user IDs and associated authorizations.

• Observe system settings.

Removed p. 30

• Examine terminated users accounts.

• Review current access lists.

• Observe returned physical authentication devices.

Removed p. 30

• Observe user accounts.

Removed p. 30

(b) Are third-party remote access accounts monitored when in use?

• Interview personnel.

Removed p. 31

• Review vendor documentation.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.1.8 If a session has been idle for more than 15 minutes, are users required to re-authenticate (for example, re-enter the password) to re-activate the terminal or session?

• Review password procedures.

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

• Review password procedures.

• Observe authentication processes.

Removed p. 31

• Observe password files.

• Observe data transmissions.

Removed p. 31

• Examine system configuration settings to verify password parameters.

Removed p. 32

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.2.5 (a) Must an individual submit a new password/phrase that is different from any of the last four passwords/passphrases he or she has used?

• Review password procedures.

• Sample system components.

Removed p. 32

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

• Observe administrator logging into CDE.

Removed p. 32

• Observe personnel connecting remotely.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.4 (a) Are authentication policies and procedures documented and communicated to all users?

• Review policies and procedures.

• Review distribution method.

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 documentation provided to users.

Removed p. 33

• Generic user IDs and accounts are disabled or

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

• Examine user ID lists.

Removed p. 33

• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access

• Examine system configuration settings and/or physical controls.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.8 Are security policies and operational procedures for identification and authentication:

• Known to all affected parties?

• Examine security policies and operational procedures.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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. 35

• Review policies and procedures for physically securing media.

Removed p. 35

(b) Do controls include the following:

Removed p. 35

• Examine media distribution tracking logs and documentation.

• Examine media distribution tracking logs and documentation.

Modified p. 35 → 68

~~(c) Is media destruction~~ performed as follows:

• The mechanism functions are performed as follows:

Removed p. 36

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.8.1 (a) Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed?

• Review periodic media destruction policies and procedures.

(b) Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents?

• Examine security of storage containers.

Removed p. 37

Requirement 10: Track and monitor all access to network resources and cardholder data

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 10.1 Are audit trails enabled and active for system components?

• Interview system administrator.

Is access to system components linked to individual users?

• Interview system administrator.

Removed p. 37

• and all changes, additions, or deletions to accounts with root or administrative privileges?

• Interview personnel.

Removed p. 38

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 10.3 Are the following audit trail entries recorded for all system components for each event:

Removed p. 38

• Review time configuration standards and processes.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 10.4.1 Are the following processes implemented for critical systems to have the correct and consistent time:

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

Removed p. 39

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

(c) Do systems receive time only from designated central time server(s)?

• Review time configuration standards and processes.

Removed p. 39

(a) Is access to time data restricted to only personnel with a business need to access time data?

• Examine system configurations and time-synchronization settings.

(b) Are changes to time settings on critical systems logged, monitored, and reviewed?

• Examine system configurations and time-synchronization settings and logs.

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

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 10.5 Are audit trails secured so they cannot be altered, as follows:

Removed p. 40

• Examine system configurations and permissions 10.5.2 Are audit trail files protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation?

• Interview system administrators.

Removed p. 40

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.

Removed p. 41

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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. 41

• Review security policies and procedures.

Removed p. 41

• Review risk assessment documentation.

Removed p. 41

(c) Are at least the last three months’ logs immediately available for analysis?

• Interview personnel.

Requirement 11: Regularly test security systems and processes

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 11.2.2 (a) Are quarterly external vulnerability scans performed? Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

• Review results from the four most recent quarters of external vulnerability scans.

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

(c) Are quarterly external vulnerability scans performed by a

PCI SSC Approved Scanning Vendor (ASV?

• Review results of each external quarterly scan and rescan.

Removed p. 42

• Examine and correlate change control documentation and scan reports.

(b) 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?

• Review scan reports.

(c) Are 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)?

• Interview personnel.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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- …

Removed p. 43

(b) Are tests performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)?

• Interview responsible personnel.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 11.3.3 Are exploitable vulnerabilities found during penetration testing corrected, followed by repeated testing to verify the corrections?

• Examine penetration testing results.

Removed p. 44

(a) Are penetration-testing procedures defined to test all segmentation methods, to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE?

• Examine segmentation controls.

(b) Does penetration testing to verify segmentation controls meet the following? - Performed at least annually and after any changes to segmentation controls/methods. - Covers all segmentation controls/methods in use. - Verifies that segmentation methods are operational and effective, and isolate all out-of- scope systems from systems in the CDE.

• Examine results from the most recent penetration test.

(c) Are tests performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)?

• Interview responsible personnel.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 11.4 (a) Are intrusion-detection and/or intrusion-prevention techniques that detect and/or prevent intrusions into the network …

Removed p. 45

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

• Observe system settings and monitored files.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 11.5 (cont.) (b) 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 compromise or risk of compromise. Change detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for …

Removed p. 47

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) CCW No N/A 12.1 Is a security policy established, published, maintained, and disseminated to all relevant personnel?

• Review the information security policy.

Removed p. 47

• Interview a sample of responsible personnel.

Modified p. 47 → 69

• ~~Review list of service providers.~~

• Reviewed at least once every 12 months.

Removed p. 48

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 12.8.2 Is a written agreement maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s 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.

Modified p. 48 → 72

• ~~Observe~~ written ~~agreements.~~

• Examine written agreements with TPSPs.

Removed p. 49

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 12.10.1 (a) Has an incident response plan been created to be implemented in the event of system breach?

• Review the incident response plan.

(b) Does the plan address the following, at a minimum:

- Specific incident response procedures?

• Review incident response plan procedures.

- Data backup processes?

• Review incident response plan procedures.

- Coverage and responses of all critical system components?

• Review incident response plan procedures.

- Reference or inclusion of incident response procedures from the payment brands?

• Review incident response plan procedures.

Modified p. 49 → 74

• ~~Review~~ incident response ~~plan procedures.~~

• Reference or inclusion of incident response procedures from the payment brands.

Modified p. 49 → 74

- 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. 49 → 74

- Business recovery and continuity procedures?

• Review incident response plan procedures.

• Business recovery and continuity procedures.

Modified p. 49 → 74

- Analysis of legal requirements for reporting compromises?

• Review incident response plan procedures.

• Analysis of legal requirements for reporting compromises.

Removed p. 50

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A A2.1 For POS POI terminals (at the merchant or payment- acceptance location) using SSL and/or early TLS: Are the devices confirmed to not be susceptible to any known exploits for SSL/early TLS? Note: This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.2 and A2.3 apply to POS POI service providers.

• Review documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies POS POI devices are not susceptible to any known exploits for SSL/early TLS.

Modified p. 50 → 75

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 This Appendix is not used for SAQ A-EP merchant assessments.

Modified p. 50 → 75

Appendix A3: Designated Entities Supplemental Validation (DESV) This Appendix applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements. Entities required to validate to this Appendix should use the DESV Supplemental Reporting Template and Supplemental Attestation of Compliance for ~~reporting,~~ and consult with the applicable payment brand and/or acquirer for submission procedures.

Appendix A3: Designated Entities Supplemental Validation (DESV) This Appendix applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements. Entities required to validate to this Appendix should use the DESV Supplemental Reporting Template and Supplemental Attestation of Compliance for reporting and consult with the applicable payment brand and/or acquirer for submission procedures.

Modified p. 51 → 76

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. 51 → 76

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. 51 → 76

1. Constraints ~~List~~ constraints precluding compliance with the original requirement.

1. Constraints Document the legitimate technical or business constraints precluding compliance with the original requirement.

Modified p. 51 → 76

2. Objective Define the objective of the original ~~control; identify the objective met by the compensating~~ control.

3. Objective Define the objective of the original control.

Modified p. 51 → 76

3. Identified Risk Identify any additional risk posed by the lack of the original control.

4. Identified Risk Identify any additional risk posed by the lack of the original control.

Modified p. 51 → 76

4. Definition of Compensating Controls Define the compensating ~~controls and~~ explain how they address the objectives of the original control and the increased risk, if any.

2. Definition of Compensating Controls Define the compensating controls: explain how they address the objectives of the original control and the increased risk, if any.

Modified p. 51 → 76

6. Maintenance Define ~~process~~ and controls in place to maintain compensating controls.

6. Maintenance Define process(es) and controls in place to maintain compensating controls.

Modified p. 52 → 77

Requirement Reason Requirement is Not Applicable ~~3.4 Cardholder data is never stored electronically~~

Requirement Reason Requirement is Not Applicable

Removed p. 53

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 your acquirer or the payment brand(s) before completing Part 4.

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.

Modified p. 53 → 79

Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ A-EP (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 A-EP (Section 2), dated (Self-assessment completion date YYYY-MM-DD).

Modified p. 53 → 79

Based on the results documented in the SAQ A-EP 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 A-EP noted above, each signatory identified in any of Parts 3b- 3d, as applicable, assert(s) the following compliance status for the merchant identified in Part 2 of this document.

Modified p. 53 → 79

Compliant: All sections of the PCI DSS SAQ are ~~complete,~~ all ~~questions answered affirmatively,~~ resulting in an overall COMPLIANT rating; thereby (Merchant Company Name) has demonstrated ~~full~~ compliance with ~~the~~ PCI ~~DSS.~~

Compliant: All sections of the PCI DSS SAQ are complete and all 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 (Merchant Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ.

Modified p. 53 → 79

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 (Merchant 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 (Merchant Company Name) has not demonstrated compliance with the PCI DSS requirements included in this SAQ.

Modified p. 53 → 79

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. 53 → 80

~~(Check~~ all that apply)

(Select all that apply)

Modified p. 53 → 80

PCI DSS Self-Assessment Questionnaire A-EP, Version ~~(version of SAQ),~~ was completed according to the instructions therein.

PCI DSS Self-Assessment Questionnaire A-EP, Version 4.0, was completed according to the instructions therein.

Modified p. 53 → 80

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 merchant’s assessment in all material respects.

Removed p. 54

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name) Part 3b. Merchant Attestation Signature of Merchant Executive Officer  Date:

Modified p. 54 → 80

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. 54 → 80

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. 54 → 80

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

Check with your acquirer or the 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.

Removed p. 55

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

Removed p. 55

Appendix A2 Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card- Present POS POI Terminal Connections.

* PCI DSS Requirements indicated here refer to the questions in Section 2 of the SAQ.

Document Comparison

Content Changes