Document Comparison

PCI-DSS-v3-2-1-SAQ-A-r2.pdf PCI-DSS-v4-0-SAQ-A-r2.pdf
36% similar
22 → 38 Pages
5174 → 10471 Words
128 Content Changes

Content Changes

128 content changes. 41 administrative changes (dates, page numbers) hidden.

Added p. 2
Rearranged, retitled, and expanded information in the “Completing the Self- Assessment Questionnaire” section (previously titled “Before You Begin”).

Aligned content in Sections 1 and 3 of Attestation of Compliance (AOC) with PCI DSS v4.0 Report on Compliance AOC.

Added PCI DSS v4.0 requirements.

Added appendices to support new reporting responses.
Added p. 2
Added “In Place with CCW” to AOC Section 3.

Added guidance for responding to future-dated requirements.

Clarified note under Eligibility Criteria on page iv that addresses applicability of Requirements 2, 6, 8, and 11 to e-commerce merchants.

Clarified notes that address applicability to e-commerce merchants for Requirements 6.4.3, 8, 11, and 11.6.1.

Added minor clarifications and addressed typographical errors.

July 2023 4.0 2 Address typographical error in Requirement 11.6.1 SAQ Completion Guidance - changed “merchant’s payment page/form” to “TPSP’s/payment processor’s payment page/form”.
Added p. 4
This SAQ is not applicable to service providers.

• The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant; and

Note: For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, 8, and 11) AND requirements that refer to the “cardholder data environment” apply to the following e-commerce merchants:

• Those that redirect customers from their website to a TPSP/payment processor for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.

• Those with a website(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame), and specifically to the merchant web server that includes the embedded payment page/form.

These PCI DSS requirements are applicable because the above merchant websites impact how the account data …
Added p. 5
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Account Data Cardholder Data includes: Sensitive Authentication Data includes:

• Primary Account Number (PAN)

• Full track data (magnetic-stripe data or equivalent on a chip)

• Card verification code

• PINs/PIN blocks Refer to PCI DSS Section 2, PCI DSS Applicability Information, for further details.

1. Confirm by review of the eligibility criteria in this SAQ and the Self-Assessment Questionnaire Instructions and Guidelines document on the PCI SSC website that this is the correct SAQ for the merchant’s environment.

2. Confirm that the merchant environment is properly scoped.

• Section 1: Assessment Information (Parts 1 & 2 of the Attestation of Compliance (AOC)

Expected Testing The instructions provided in the “Expected Testing” column …
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 merchant’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 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  For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components appearing on the PCI SSC website (www.pcisecuritystandards.org)⎯for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Payment Applications (PA- DSS), …
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.

The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transaction.

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

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 confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant.

Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.

Requirement 2: …
Added p. 14
• 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.

• Examine system configuration standards.

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. 15
Requirement 3: Protect Stored Account Data

Note: For SAQ A, 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 Not Applicable Not in Place 3.1 Processes and mechanisms for protecting stored account data are defined and understood.
Added p. 15
• Kept up to date.

• In use.

• Known to all affected parties.
Added p. 15
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.
Added p. 16
PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place with Not Applicable Not in Place 3.2 Storage of account data is kept to a minimum.
Added p. 16
• 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 data …
Added p. 18
• 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.
Added p. 18
Applicability Notes 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.

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
Added p. 19
Note: For SAQ A, Requirement 6.4.3 applies to a merchant’s website(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
Added p. 19
• A method is implemented to confirm that each script is authorized.

• Examine inventory records.

• Examine system configurations.

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

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.

Note: For SAQ A, Requirement 8 applies to merchant web servers that host the page(s) that either 1) redirects customers from the merchant website to a TPSP/payment processor for payment processing (for example, with a URL redirect) or 2) includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).

PCI DSS Requirement Expected Testing Response (Check one response …
Added p. 20
• Examine audit logs and other evidence.

Applicability Notes This requirement is not intended to apply to user accounts within 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).

Applicability Notes This requirement is not intended to apply to user accounts within 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 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 …
Added p. 21
• Something you know, such as a password or passphrase.

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

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 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 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. 22
• 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. 22
• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight 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. 22
• Examine system configuration settings.

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place Not Applicable Not in Place Applicability Notes This requirement is not intended to apply to user accounts within 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).
Added p. 23
• 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.

Applicability Notes This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements.

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 does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed.

Note: For SAQ A, Requirements at 9.4 only apply to …
Added p. 24
• Examine logs or other documentation.

• Interview responsible personnel at the storge location(s).
Added p. 24
• Examine offsite tracking logs for all media.

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

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:

• 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 …
Added p. 26
• At least once every three months.

• By PCI SSC Approved Scanning Vendor (ASV).

• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.

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

• 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. Any …
Added p. 28
• 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 results from monitoring activities.

• Examine the mechanism configuration settings.

• Examine 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 The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column (of PCI DSS Requirements and Testing …
Added p. 29
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.

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.8.2 Written agreements with TPSPs are maintained as follows:

• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.

• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.

Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and …
Added p. 30
Applicability Notes Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.

PCI DSS Requirement Expected Testing Response (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

Selection of any of the In Place responses for requirements at 12.8.1 through 12.8.5 means that the merchant has a list of, and agreements with, service providers they share account data with or that …
Added p. 31
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.

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

• Business recovery and continuity procedures.

• Data backup processes.

• Analysis of legal requirements for reporting compromises.

• Coverage and responses of all critical system components.

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

• 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 …
Added p. 33
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. 36
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 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, complete …
Added p. 37
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. 38
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.
Removed p. 2
September 2022 3.2.1 2.0 Updated to reflect the inclusion of UnionPay as a Participating Payment Brand.

This document aligns with PCI DSS v3.2.1 r1.
Removed p. 4
• Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
Modified p. 4
SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.
SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present) and do not store, process, or transmit any account data in electronic format on their systems or premises.
Modified p. 4
Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
Modified p. 4
• All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers;
• All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor;
Modified p. 4
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;
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;
Modified p. 4
• Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically.
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.
Modified p. 4
• All elements of the payment page(s) delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s).
• All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
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 this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, and 8) apply to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located. Mail order/telephone order (MOTO) or e-commerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the third party) and therefore …
Mail order/telephone order (MOTO) or e-commerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the TPSP/payment processor and no embedded payment form from a TPSP/payment processor) and therefore do not have any systems in scope for this SAQ, would consider these requirements to be “not applicable.” Refer to guidance on the following pages for how to report requirements that are not applicable.
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)
• Self-Assessment Questionnaire A.
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 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 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 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:

Merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions); All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers; 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 Any cardholder data the merchant retains is on paper (for example, printed reports or receipts), and these documents are not received electronically.
Modified p. 9 → 13
Part 2g. Eligibility to Complete SAQ A Merchant certifies eligibility to complete this shortened version of the Self-Assessment Questionnaire because, for this payment channel:
Part 2h. Eligibility to Complete SAQ A Merchant certifies eligibility to complete this Self-Assessment Questionnaire because, for this payment channel:
Modified p. 9 → 13
All elements of the payment page(s) delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s).
All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
Removed p. 10
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.).

• Review policies and procedures.

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

• Review policies and procedures.
Modified p. 10 → 14
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 → 14
Self-assessment completion date: Build and Maintain a Secure Network and Systems
Self-assessment completion date: YYYY-MM-DD Build and Maintain a Secure Network and Systems
Modified p. 10 → 14
• Observe system configurations and account settings.
• Observe a system administrator logging on using vendor default accounts.
Modified p. 10 → 14
• Examine system configurations and account settings.
• Examine configuration files.
Modified p. 10 → 15
Review vendor documentation.
Examine documentation.
Removed p. 11
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 6.2 (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches?

• Review policies and procedures.
Modified p. 11 → 18
Requirement 6: Develop and maintain secure systems and applications
Requirement 6: Develop and Maintain Secure Systems and Software
Modified p. 11 → 19
(b) Are critical security patches installed within one month of release?

• Review policies and procedures.
• Critical or high-security patches/updates are installed within one month of release.
Modified p. 11 → 19
• Examine system components.
• Examine system components and related software.
Removed p. 12
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.1.1 Are all users assigned a unique ID before allowing them to access system components or cardholder data?

• Review password procedures.

• Observe returned physical authentication devices.

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
Modified p. 12 → 19
Review password procedures.
Examine policies and procedures.
Modified p. 12 → 20
Requirement 8: Identify and authenticate access to system components
Requirement 8: Identify Users and Authenticate Access to System Components
Modified p. 12 → 21
• Examine terminated users accounts.
• Examine information sources for terminated users.
Modified p. 12 → 21
• Review current access lists.
• Review current user access lists.
Modified p. 12 → 21
• Something you have, such as a token device or smart card
• Something you have, such as a token device or smart card.
Modified p. 12 → 21
• Something you are, such as a biometric
• Something you are, such as a biometric element.
Modified p. 12 → 21
Observe authentication processes.
Examine authentication policies and procedures.
Modified p. 12 → 22
• Contain both numeric and alphabetic characters Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.
• Contain both numeric and alphabetic characters.
Modified p. 12 → 22
• Examine system configuration settings to verify password parameters.
• Examine system configuration settings.
Removed p. 13
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 8.5 Are group, shared, or generic accounts, passwords, or other authentication methods prohibited as follows:

• Generic user IDs and accounts are disabled or removed;

• Shared user IDs for system administration activities and other critical functions do not exist; and

• Shared and generic user IDs are not used to administer any system components?

• Review policies and procedures.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 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.
Removed p. 13
(b) Do controls include the following:
Modified p. 13 → 22
Interview security personnel.
Observe security personnel.
Modified p. 13 → 24
Requirement 9: Restrict physical access to cardholder data
Requirement 9: Restrict Physical Access to Cardholder Data
Modified p. 13 → 29
• Examine user ID lists.
• Examine list of TPSPs.
Modified p. 13 → 29
Review policies and procedures for physically securing media.
Examine policies and procedures.
Removed p. 14
(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.
Modified p. 14 → 24
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.6.2 Is media sent by secured courier or other delivery method that can be accurately tracked?

• Interview personnel.
• Media is sent by secured courier or other delivery method that can be accurately tracked.
Modified p. 14 → 24
• Examine media distribution tracking logs and documentation.
• Examine media logs or other documentation.
Modified p. 14 → 27
• Examine media distribution tracking logs and documentation.
• Examine change control documentation.
Modified p. 14 → 28
(c) Is media destruction performed as follows:
• The mechanism functions are performed as follows:
Removed p. 15
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.8 Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:
Removed p. 15
• Review list of service providers.
Modified p. 15 → 30
Observe written agreements.
Examine written agreements with TPSPs.
Modified p. 15 → 30
Review policies and procedures.
Examine policies and procedures.
Removed p. 16
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 12.8.4 Is a program maintained to monitor service providers’ PCI DSS compliance status at least annually?

• Review policies and procedures and supporting documentation.
Modified p. 16 → 31
Review incident response plan procedures.
Examine the incident response plan.
Modified p. 17 → 32
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 merchant assessments 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 …
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 merchant assessments.
Modified p. 18 → 33
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. 18 → 33
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. 18 → 33
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. 18 → 33
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. 18 → 33
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. 18 → 33
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. 18 → 33
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. 19 → 34
Requirement Reason Requirement is Not Applicable 3.4 Cardholder data is never stored electronically
Requirement Reason Requirement is Not Applicable
Removed p. 20
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. 20 → 36
Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ A (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 (Section 2), dated (Self-assessment completion date YYYY-MM-DD).
Modified p. 20 → 36
Based on the results documented in the SAQ A 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 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. 20 → 36
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. 20 → 36
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. 20 → 36
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. 20 → 37
(Check all that apply)
(Select all that apply)
Modified p. 20 → 37
PCI DSS Self-Assessment Questionnaire A, Version (version of SAQ), was completed according to the instructions therein.
PCI DSS Self-Assessment Questionnaire A, Version 4.0, was completed according to the instructions therein.
Modified p. 20 → 37
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. 21
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. 21 → 37
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. 21 → 37
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. 21 → 37
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. 22
Check with your acquirer or the payment brand(s) before completing Part 4.
Removed p. 22
Maintain a policy that addresses information security for all personnel.

* PCI DSS Requirements indicated here refer to the questions in Section 2 of the SAQ.
Modified p. 22 → 38
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 Do not use vendor-supplied defaults for system passwords and other security parameters.
PCI DSS Requirement* Description of Requirement Compliant to PCI DSS Requirements (Select One) Remediation Date and Actions (If “NO” selected for any Requirement) YES NO 2 Apply secure configurations to all system components 3 Protect stored account data 6 Develop and maintain secure systems and software 8 Identify users and authenticate access to system components 9 Restrict physical access to cardholder data 11 Test security systems and networks regularly 12 Support information security with organizational policies and programs * PCI …