The SAQ A-EP PCI assessment is for merchants who have an e-commerce card data flow that is not entirely outsourced to a PCI validated third-party service provider. This can be confusing for merchants who are not sure if they qualify for the SAQ A or SAQ A-EP scope of requirements. The big difference between the SAQ A report and the SAQ A-EP are the qualifying criteria. Notice the differences in bold font in the table below:
SAQ A and SAQ A-EP Qualifying Criteria, with differences in bold font.
Table Test:
| PCI v4.0 SAQ A | PCI v4.0 SAQ A-EP |
| :--- | :--- |
| The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions. | The merchant accepts only e-commerce transactions. |
| All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor. | 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 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 does not electronically store, process, or transmit any account data on the 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. | The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and has confirmed that the TPSP(s) are PCI DSS compliant for the services 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. | Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically. |
| 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. | 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. |
| No additional SAQ A qualifying criteria | **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.** |
| No additional SAQ A qualifying criteria | **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).** |
As shown in the table above the main differences between the SAQ A and SAQ A-EP is that the merchant’s payment page is not entirely outsourced to a third-party service provider, or that the merchants website controls how customers or their account data are redirected to a PCI DSS compliant payment processor.
So if your e-commerce card data flow fits the SAQ A criteria, then you would qualify to attest to the SAQ A set of PCI requirements. If your e-commerce card data flow and website fits the SAQ A-EP criteria, then you would qualify to attest to the SAQ A-EP set of PCI requirements. Because there are only 33 v4.0 SAQ A requirements and 151 v4.0 SAQ A-EP requirements most all merchants try and find a way to outsource all processing of cardholder data to a validated third-party service providers so that they don’t have to attest to the nearly 120 requirements beyond the SAQ A requirements.
If we look at the qualifying criteria between the SAQ A-EP v3.2.1 and SAQ A-EP v4.0 we see that there have been some slight changes.
Qualifying Criteria
SAQ A-EP v3.2.1 vs. SAQ A-EP v4.0
| SAQ A-EP v3.2.1 | SAQ A-EP v4.0 | Changes |
| :--- | :--- | :---- |
| Your company accepts only e-commerce transactions. | The merchant accepts only e-commerce transactions. | Since only merchants can qualify for the SAQ A-EP, the word “company” was changed to “merchant” in v4.0. |
| All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor. | 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. | This one is interesting because they changed the wording from “cardholder data” to “account data”. Cardholder data means, at a minimum, the full the primary account number. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. Account data on the other hand consists of cardholder data and/or sensitive authentication data. Sensitive authentication data consists of Security-related information including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions. So changing the wording from cardholder data to account data now means that SAD is included. |
| 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. | 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. | The difference here is similar to the two above, where the words “merchant” and “account data” are used in context. The TPSP acronym just means “third-party service provider”. One other difference is that it says “validated” in v3.2.1 and in v4.0 it says “compliant”. These words basically mean the same thing but were a little confusing because the word “validated” is typically used in the context of being third-party validated when self-validation is the same as self-attestation. |
| If a 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). | 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). | Nothing different here other than the acronym TPSP (e.g. third-party service 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). | 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. | Nothing different here other than the acronym TPSP (e.g. third-party service provider). |
| 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. | Nothing different here other than the acronym TPSP, and usage of the word “merchant”. |
| Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant. | The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and has confirmed that the TPSP(s) are PCI DSS compliant for the services used by the merchant. | What is different here is that an attestation of compliance is now required for the service provider evidence of compliance as opposed to the merchant just “confirming” the service provider is PCI compliant. |
| 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. | The only difference here is the usage of the words “account data” and “merchant”, which significance has been described in the rows above. |
If you do qualify for the v4.0 SAQ A-EP set of PCI requirements then there are some changes from v3.2.1 that you should know about. The PCI DSS v4.0 summary of changes document provided by the PCI SSC gives detailed information on these version changes and which requirements were affected or are new.
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r2.pdf
Most notable are the new requirements for the v4.0 SAQ A-EP
| New Requirement | Description |
| :---: | :--- |
| 3.2.1, second bullet point | Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that includes coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. |
| 4.2.1 | Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks. |
| 5.2.3.1 | The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. |
| 5.3.2.1 | If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. |
| 5.3.3 | For removable electronic media, the anti-malware solution(s): - 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.
|
| 5.4.1 | Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. |
| 6.3.2 | An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.|
| 6.4.2 | For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: - Is installed in front of public-facing web applications and is configured 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.
|
| 6.4.3 | All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: - A method is implemented to confirm that each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
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. |
| 7.2.4 | 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. |
| 7.2.5 | All application and system accounts and related access privileges are assigned and managed as follows:- 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.
|
| 8.3.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: - A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
- Contain both numeric and alphabetic characters.
Note: 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.
|
| 8.4.2 | MFA is implemented for all access into the CDE. Note: 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 a single transaction (such as IDs used by cashiers on point-of-sale terminals).
|
| 8.5.1 | MFA systems are implemented as follows:- 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.
|
| 8.6.1 | If accounts used by systems or applications can be used for interactive login, they are managed as follows:- 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.
- Every action taken is attributable to an individual user.
|
| 8.6.2 | Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. |
| 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.
|
| 10.4.1.1 | Automated mechanisms are used to perform audit log reviews. |
| 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. |
| 11.6.1 | Note: For SAQ A-EP, Requirement 11.6.1 applies to webservers that host the payment page(s) provided from the merchant’s website to the customer’s browser. A change- and tamper-detection mechanism is deployed as follows: - 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.
- The mechanism is configured to evaluate the received HTTP header and payment page.
- The mechanism is configured to evaluate the received HTTP header and payment page.
- The mechanism functions are performed as follows: – At least once every seven days OR – 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).
|
| 12.3.1 | Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes: - 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.
|
| 12.6.3.1 | Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:- Phishing and related attacks.
- Social engineering.
|
These 22 new requirements in the v4.0 SAQ A-EP report all have a sunset date of March 31, 2025 when they will no longer be a best practice and will then be required as part of the merchant PCI assessment.
If you have questions about how your cardholder data environment may be impacted by these new requirements it is a great idea to purchase some consulting hours from a QSA to be a resource and work through the card data flows and networking to help determine the appropriate scope of compliance burden as well as to help identify any gaps in compliance.
.svg)
