Home > Payment Card Industry (PCI)
Payment
Card Industry (PCI)
Data Security Standard
Self-Assessment Questionnaire
A-EP
and Attestation of Compliance
Partially
Outsourced E-commerce Merchants Using
a Third-Party Website for Payment Processing
Version 3.0
February 2014
Document Changes
Date | Version | Description |
N/A | 1.0 | Not used. |
N/A | 2.0 | Not used. |
February 2014 | 3.0 | New SAQ to address requirements
applicable to e-commerce merchants with a websites that do not themselves
receive cardholder data but which do affect the security of the payment
transaction and/or the integrity of the page that accepts the consumer’s
cardholder data.
Content aligns with PCI DSS v3.0 requirements and testing procedures. |
Table of Contents
Before You Begin
SAQ A-EP has been developed 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.
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 confirm that, for this payment channel:
This SAQ is applicable only to e-commerce channels.
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.
The questions contained in the “PCI DSS Question” column in this self-assessment questionnaire are based on the requirements in the PCI DSS.
Additional resources that provide guidance on PCI DSS requirements and how to complete the self-assessment questionnaire have been provided to assist with the assessment process. An overview of some of these resources is provided below:
Document | Includes: |
PCI DSS
(PCI Data Security Standard Requirements and Security Assessment Procedures) |
|
SAQ Instructions and Guidelines documents |
|
PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms |
|
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.
The instructions provided in the “Expected Testing” column are based on the testing procedures in the PCI DSS, and provide a high-level description of the types of testing activities that should be performed in order to verify that a requirement has been met. Full details of testing procedures for each requirement can be found in the PCI DSS.
For each question, there is a choice of responses to indicate your company’s status regarding that requirement. Only one response should be selected for each question.
A description of the meaning for each response is provided in the table below:
Response |
When to use this response: |
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. |
N/A
(Not Applicable) |
The
requirement does not apply to the organization’s environment.
(See Guidance for Non-Applicability of Certain, Specific Requirements
below for examples.)
All responses in this column require a supporting explanation in Appendix C of the SAQ. |
If any requirements are deemed not applicable to your environment, select the “N/A” option for that specific requirement, and complete the “Explanation of Non-Applicability” worksheet in Appendix C for each “N/A” entry.
If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, check the “No” column for that requirement and complete the relevant attestation in Part 3.
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 acquirer (merchant bank) or the payment brands to determine reporting and submission procedures.
Part 1. Merchant and Qualified Security Assessor Information | ||||||
Part 1a. Merchant Organization Information | ||||||
Company Name: | DBA (doing business as): | |||||
Contact Name: | Title: | |||||
ISA Name(s) (if applicable): | Title: | |||||
Telephone: | E-mail: | |||||
Business Address: | City: | |||||
State/Province: | Country: | Zip: | ||||
URL: |
Part 1b. Qualified Security Assessor Company Information (if applicable) | ||||||
Company Name: | ||||||
Lead QSA Contact Name: | Title: | |||||
Telephone: | E-mail: | |||||
Business Address: | City: | |||||
State/Province: | Country: | Zip: | ||||
URL: |
Part 2. Executive Summary | |||
Part 2a. Type of Merchant Business (check all that apply) | |||
☐ Retailer ☐ Telecommunication ☐ Grocery and Supermarkets | |||
☐ Petroleum ☐ E-Commerce ☐ Mail order/telephone order (MOTO) | |||
☐ Others (please specify): | |||
What
types of payment channels does your business serve?
☐ Mail order/telephone order (MOTO) ☐ E-Commerce ☐ Card-present (face-to-face) |
Which payment channels
are covered by this SAQ?
☐ E-Commerce ☐ Card-present (face-to-face) |
||
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. | |||
Part 2b. Description of Payment Card Business | |||
How and in what capacity does your business store, process and/or transmit cardholder data? |
Part 2c. Locations | |
List types of facilities and a summary of locations included in the PCI DSS review (for example, retail outlets, corporate offices, data centers, call centers, etc.) | |
Type of facility | Location(s) of facility (city, country) |
Part 2d. Payment Application | ||||
Does the organization use one or more Payment Applications? ☐ Yes ☐ No | ||||
Provide the following information regarding the Payment Applications your organization uses: | ||||
Payment Application Name | Version Number | Application Vendor |
Is application PA-DSS Listed? |
PA-DSS Listing Expiry date (if applicable) |
☐ Yes ☐ No | ||||
☐ Yes ☐ No | ||||
☐ Yes ☐ No |
Part 2e. Description of Environment | ||
Provide a
high-level description of the environment covered by this
assessment.
For example:
|
||
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) |
☐ Yes
☐ No |
Part 2f. Third-Party Service Providers | ||
Does your company share cardholder data with any third-party service providers (for example, gateways, payment processors, payment service providers (PSP), web-hosting companies, airline booking agents, loyalty program agents, etc.)? | ☐ Yes
☐ No |
|
If Yes: | ||
Name of service provider: | Description of services provided: | |
Note: Requirement 12.8 applies to all entities in this list. |
Part 2g. 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 is 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; | |
☐ | Merchant’s e-commerce website is not connected to any other systems within merchant’s environment (this can be achieved via network segmentation to isolate the website from all other systems); | |
☐ | 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); | |
☐ | All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS compliant service provider(s); | |
☐ | Merchant does not electronically store, process, or transmit any cardholder data on merchant systems or premises, but relies entirely on a third party(s) to handle all these functions; | |
☐ | Merchant has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and | |
☐ | Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically. |
Section 2: Self-Assessment Questionnaire A-EP
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.
Self-assessment completion date:
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
1.1.4 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
1.1.6 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
1.2 | Do firewall and router
configurations restrict connections between untrusted networks and any
system in the cardholder data environment as follows:
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. |
|||||
1.2.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
1.3.4 | Are anti-spoofing measures
implemented to detect and block forged sourced IP addresses from entering
the network?
(For example, block traffic originating from the internet with an internal address) |
|
☐ | ☐ | ☐ | ☐ |
1.3.5 | Is outbound traffic from the cardholder data environment to the Internet explicitly authorized? |
|
☐ | ☐ | ☐ | ☐ |
1.3.6 | Is stateful inspection, also known as dynamic packet filtering, implemented—that is, only established connections are allowed into the network? |
|
☐ | ☐ | ☐ | ☐ |
1.3.8 |
Internal use of RFC1918 address space instead of registered addresses. |
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
2.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
2.2 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
2.2.1 |
|
|
☐ | ☐ | ☐ | ☐ |
(b) If virtualization technologies are used, is only one primary function implemented per virtual system component or device? |
|
☐ | ☐ | ☐ | ☐ | |
2.2.2 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
2.2.3 | Are additional security
features documented and implemented for any required services, protocols
or daemons that are considered to be insecure?
For example, use secured technologies such as SSH, S-FTP, SSL or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc. |
|
☐ | ☐ | ☐ | ☐ |
2.2.4 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
2.2.5 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
2.3 | Is non-console administrative
access encrypted as follows:
Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access. |
|||||
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
3.2 | (c) Is sensitive authentication data deleted or rendered unrecoverable upon completion of the authorization process? |
|
☐ | ☐ | ☐ | ☐ |
(d) Do all systems adhere to the following requirements regarding non-storage of sensitive authentication data after authorization (even if encrypted): | ||||||
3.2.2 | The card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) is not stored after authorization? |
|
☐ | ☐ | ☐ | ☐ |
3.2.3 | The personal identification number (PIN) or the encrypted PIN block is not stored after authorization? |
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
4.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
4.2 | (b) Are policies in place that state that unprotected PANs are not to be sent via end-user messaging technologies? |
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||||||||
Yes | Yes with CCW | No | N/A | |||||||||
5.1 | Is anti-virus software deployed on all systems commonly affected by malicious software? |
|
☐ | ☐ | ☐ | ☐ | ||||||
5.1.1 | Are anti-virus programs capable of detecting, removing, and protecting against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits)? |
|
☐ | ☐ | ☐ | ☐ | ||||||
5.1.2 | Are periodic evaluations performed to identify and evaluate evolving malware threats in order to confirm whether those systems considered to not be commonly affected by malicious software continue as such? |
|
☐ | ☐ | ☐ | ☐ | ||||||
5.2 | Are all anti-virus mechanisms maintained as follows: | |||||||||||
|
|
☐ | ☐ | ☐ | ☐ | |||||||
|
|
☐ | ☐ | ☐ | ☐ | |||||||
|
|
☐ | ☐ | ☐ | ☐ | |||||||
5.3 | Are all anti-virus mechanisms:
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. |
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
6.1 | Is there a process to
identify security vulnerabilities, including the following:
Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score and/or the classification by the vendor, and/or type of systems affected. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process or transmit cardholder data. |
|
☐ | ☐ | ☐ | ☐ |
6.2 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
6.4.5 |
|
|
☐ | ☐ | ☐ | ☐ |
|
||||||
6.4.5.1 | Documentation of impact? |
|
☐ | ☐ | ☐ | ☐ |
6.4.5.2 | Documented approval by authorized parties? |
|
☐ | ☐ | ☐ | ☐ |
6.4.5.3 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
6.4.5.4 | Back-out procedures? |
|
☐ | ☐ | ☐ | ☐ |
6.5 |
|
|||||
6.5.1 | Do coding techniques
address injection flaws, particularly SQL injection?
Note: Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. |
|
☐ | ☐ | ☐ | ☐ |
6.5.2 | Do coding techniques address buffer overflow vulnerabilities? |
|
☐ | ☐ | ☐ | ☐ |
For web applications and application interfaces (internal or external), are applications developed based on secure coding guidelines to protect applications from the following additional vulnerabilities: | ||||||
6.5.7 | Do coding techniques address cross-site scripting (XSS) vulnerabilities? |
|
☐ | ☐ | ☐ | ☐ |
6.5.8 | Do coding techniques address improper access control such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions? |
|
☐ | ☐ | ☐ | ☐ |
6.5.9 | Do coding techniques address cross-site request forgery (CSRF)? |
|
☐ | ☐ | ☐ | ☐ |
6.5.10 | Do coding techniques
address broken authentication and session management?
Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement. |
|
☐ | ☐ | ☐ | ☐ |
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?
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2. – OR –
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with 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: | |||||
7.1.2 | Is access to privileged
user IDs restricted as follows:
|
|
☐ | ☐ | ☐ | ☐ |
7.1.3 | Are access assigned based on individual personnel’s job classification and function? |
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
8.1.1 |
|
|
☐ | ☐ | ☐ | ☐ |
8.1.3 |
|
|
☐ | ☐ | ☐ | ☐ |
8.1.5 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
8.1.6 | (a) Are repeated access attempts limited by locking out the user ID after no more than six attempts? |
|
☐ | ☐ | ☐ | ☐ |
8.1.7 | Once a user account is locked out, is the lockout duration set to a minimum of 30 minutes or until an administrator enables the user ID? |
|
☐ | ☐ | ☐ | ☐ |
8.2 | In addition to assigning
a unique ID, is one or more of the following methods employed to authenticate
all users?
|
|
☐ | ☐ | ☐ | ☐ |
8.2.1 | (a) Is strong cryptography used to render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components? |
|
☐ | ☐ | ☐ | ☐ |
8.2.3 |
|
|
☐ | ☐ | ☐ | ☐ |
8.2.4 | (a) Are user passwords/passphrases changed at least every 90 days? |
|
☐ | ☐ | ☐ | ☐ |
8.2.5 | (a) Must an individual submit a new password/phrase that is different from any of the last four passwords/phrases he or she has used? |
|
☐ | ☐ | ☐ | ☐ |
8.2.6 | Are passwords/phrases set to a unique value for each user for first-time use and upon reset, and must each user change their password immediately after the first use? |
|
☐ | ☐ | ☐ | ☐ |
8.3 | Is two-factor authentication
incorporated for remote network access originating from outside the
network by personnel (including users and administrators) and all third
parties (including vendor access for support or maintenance)?
Note: Two-factor authentication requires that 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 two-factor authentication. Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication. |
|
☐ | ☐ | ☐ | ☐ |
8.5 | Are group, shared, or
generic accounts, passwords, or other authentication methods prohibited
as follows:
|
|
☐ | ☐ | ☐ | ☐ |
8.6 | Where other authentication
mechanisms are used (for example, physical or logical security tokens,
smart cards, and certificates, etc.), is the use of these mechanisms
assigned as follows?
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with 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? |
|
☐ | ☐ | ☐ | ☐ |
9.5 | Are all media physically
secured (including but not limited to computers, removable electronic
media, paper receipts, paper reports, and faxes)?
For purposes of Requirement 9, “media” refers to all paper and electronic media containing cardholder data. |
|
☐ | ☐ | ☐ | ☐ |
9.6 |
|
|
☐ | ☐ | ☐ | ☐ |
|
||||||
9.6.1 | Is media classified so the sensitivity of the data can be determined? |
|
☐ | ☐ | ☐ | ☐ |
9.6.2 | Is media sent by secured courier or other delivery method that can be accurately tracked? |
|
☐ | ☐ | ☐ | ☐ |
9.6.3 | Is management approval obtained prior to moving the media (especially when media is distributed to individuals)? |
|
☐ | ☐ | ☐ | ☐ |
9.7 | Is strict control maintained over the storage and accessibility of media? |
|
☐ | ☐ | ☐ | ☐ |
9.8 |
|
|
☐ | ☐ | ☐ | ☐ |
(c) Is media destruction performed as follows: | ||||||
9.8.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
10.2 | Are automated audit trails implemented for all system components to reconstruct the following events: | |||||
10.2.2 | All actions taken by any individual with root or administrative privileges? |
|
☐ | ☐ | ☐ | ☐ |
10.2.4 | Invalid logical access attempts? |
|
☐ | ☐ | ☐ | ☐ |
10.2.5 | Use of and changes to identification and authentication mechanisms–including but not limited to creation of new accounts and elevation of privileges – and all changes, additions, or deletions to accounts with root or administrative privileges? |
|
☐ | ☐ | ☐ | ☐ |
10.3 | Are the following audit trail entries recorded for all system components for each event: | |||||
10.3.1 | User identification? |
|
☐ | ☐ | ☐ | ☐ |
10.3.2 | Type of event? |
|
☐ | ☐ | ☐ | ☐ |
10.3.3 | Date and time? |
|
☐ | ☐ | ☐ | ☐ |
10.3.4 | Success or failure indication? |
|
☐ | ☐ | ☐ | ☐ |
10.3.5 | Origination of event? |
|
☐ | ☐ | ☐ | ☐ |
10.3.6 | Identity or name of affected data, system component, or resource? |
|
☐ | ☐ | ☐ | ☐ |
10.5.4 | Are logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) written onto a secure, centralized, internal log server or media? |
|
☐ | ☐ | ☐ | ☐ |
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. |
|||||
10.6.1 |
|
|
☐ | ☐ | ☐ | ☐ |
10.6.2 |
|
|
☐ | ☐ | ☐ | ☐ |
10.6.3 |
|
|
☐ | ☐ | ☐ | ☐ |
10.7 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ |
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
11.2.2 |
Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc. |
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
11.2.3 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
11.3 | Does the penetration-testing
methodology include the following?
|
|
☐ | ☐ | ☐ | ☐ |
11.3.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
11.3.3 | Are exploitable vulnerabilities found during penetration testing corrected, followed by repeated testing to verify the corrections? |
|
☐ | ☐ | ☐ | ☐ |
11.3.4 | If segmentation is used
to isolate the CDE from other networks:
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
11.5 |
|
|
☐ | ☐ | ☐ | ☐ |
|
|
☐ | ☐ | ☐ | ☐ | |
11.5.1 | Is a process in place to respond to any alerts generated by the change-detection solution? |
|
☐ | ☐ | ☐ | ☐ |
Note: For the purposes of Requirement 12, “personnel” refers to full-time part-time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site or otherwise have access to the company’s site cardholder data environment.
PCI DSS Question | Expected Testing |
Response
(Check one response for each question) |
||||
Yes | Yes with CCW | No | N/A | |||
12.1 | Is a security policy established, published, maintained, and disseminated to all relevant personnel? |
|
☐ | ☐ | ☐ | ☐ |
12.1.1 | Is the security policy reviewed at least annually and updated when the environment changes? |
|
☐ | ☐ | ☐ | ☐ |
12.4 | Do security policy and procedures clearly define information security responsibilities for all personnel? |
|
☐ | ☐ | ☐ | ☐ |
12.5 |
|
|||||
12.5.3 | Establishing, documenting, and distributing security incident response and escalation procedures to ensure timely and effective handling of all situations? |
|
☐ | ☐ | ☐ | ☐ |
12.6 |
|
|
☐ | ☐ | ☐ | ☐ |
12.8 | Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows: | |||||
12.8.1 | Is a list of service providers maintained? |
|
☐ | ☐ | ☐ | ☐ |
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. |
|
☐ | ☐ | ☐ | ☐ |
12.8.3 | Is there an established process for engaging service providers, including proper due diligence prior to engagement? |
|
☐ | ☐ | ☐ | ☐ |
12.8.4 | Is a program maintained to monitor service providers’ PCI DSS compliance status at least annually? |
|
☐ | ☐ | ☐ | ☐ |
12.8.5 | Is information maintained about which PCI DSS requirements are managed by each service provider, and which are managed by the entity? |
|
☐ | ☐ | ☐ | ☐ |
12.10.1 |
|
|
☐ | ☐ | ☐ | ☐ |
|
||||||
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ | |
|
|
☐ | ☐ | ☐ | ☐ |
This appendix is not used for merchant assessments.
Use this worksheet to define compensating controls for any requirement where “YES with CCW” was checked.
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.
Refer to Appendices B, C, and D of PCI DSS for information about compensating controls and guidance on how to complete this worksheet.
Requirement Number and Definition:
Information Required | Explanation | |
|
List constraints precluding compliance with the original requirement. | |
|
Define the objective of the original control; identify the objective met by the compensating control. | |
|
Identify any additional risk posed by the lack of the original control. | |
|
Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any. | |
|
Define how the compensating controls were validated and tested. | |
|
Define process and controls in place to maintain compensating controls. |
If the “N/A” (Not Applicable) column was checked in the questionnaire, use this worksheet to explain why the related requirement is not applicable to your organization.
Requirement | Reason Requirement is Not Applicable |
3.4 | Cardholder data is never stored electronically |
Section 3: Validation and Attestation Details
Part 3. PCI DSS Validation |
Based on the results noted in the SAQ A-EP dated (completion date), 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 as of (date): (check one):
|
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. | |||
|
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.
Target Date for Compliance: 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: |
|||
Affected Requirement | Details of how legal constraint prevents requirement being met | |||
Part 3a. Acknowledgement of Status | |
Signatory(s)
confirms:
(Check all that apply) |
|
|
PCI DSS Self-Assessment Questionnaire A-EP, Version (version of SAQ), was completed according to the instructions therein. |
|
All information within the above-referenced SAQ and in this attestation fairly represents the results of my assessment in all material respects. |
|
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. |
Part 3a. Acknowledgement of Status (continued) | |
|
No evidence of full track data1, CAV2, CVC2, CID, or CVV2 data2, or PIN data3 storage after transaction authorization was found on ANY system reviewed during this assessment. |
|
ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name) |
Part 3b. Merchant Attestation | |
|
|
Signature of Merchant Executive Officer | Date: |
Merchant Executive Officer Name: | Title: |
Part 3c. QSA Acknowledgement (if applicable) | ||
If a QSA was involved or assisted with this assessment, describe the role performed: | ||
|
||
Signature of QSA | Date: | |
QSA Name: | QSA Company: |
Part 3d. ISA Acknowledgement (if applicable) | ||
If a ISA was involved or assisted with this assessment, describe the role performed: | ||
|
||
Signature of ISA | Date: | |
ISA Name: | Title: |
Part 4. Action Plan for Non-Compliant Requirements |
||||
Select the appropriate response for “Compliant
to PCI DSS Requirements” for each requirement. If you answer “No”
to any of the requirements, you may be required to provide the date
your Company expects to be compliant with the requirement and a brief
description of the actions being taken to meet the requirement.
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 | ☐ | ☐ | |
2 | Do not use vendor-supplied defaults for system passwords and other security parameters | ☐ | ☐ | |
3 | Protect stored cardholder data | ☐ | ☐ | |
4 | Encrypt transmission of cardholder data across open, public networks | ☐ | ☐ | |
5 | Protect all systems against malware and regularly update anti-virus software or programs | ☐ | ☐ | |
6 | Develop and maintain secure systems and applications | ☐ | ☐ | |
7 | Restrict access to cardholder data by business need to know | ☐ | ☐ | |
8 | Identify and authenticate access to system components | ☐ | ☐ | |
9 | Restrict physical access to cardholder data | ☐ | ☐ | |
10 | Track and monitor all access to network resources and cardholder data | ☐ | ☐ | |
11 | Regularly test security systems and processes | ☐ | ☐ | |
12 | Maintain a policy that addresses information security for all personnel | ☐ | ☐ |
1 Data encoded in the magnetic stripe or equivalent data on a chip used for authorization during a card-present transaction. Entities may not retain full track data after transaction authorization. The only elements of track data that may be retained are primary account number (PAN), expiration date, and cardholder name.
2 The three- or four-digit value printed by the signature panel or on the face of a payment card used to verify card-not-present transactions.
3 Personal identification number entered by cardholder during a card-present transaction, and/or encrypted PIN block present within the transaction message.
All Rights Reserved Powered by Free Document Search and Download
Copyright © 2011