thePCI Portal

SAQ A vs A-EP – lots of links

April 2015: SAQ A-EP v3.1

Although the council removed this from the table in the “Understanding the SAQs for PCI DSS v3″ doc, it was not removed from the criteria for SAQ A-EP v3.1:
“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;”

And:

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

Ad below this line:

SAQ A V3.1 April 2015

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

From SAQ AOC v3.0:

“I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.”

From SAQ A-EP v3.0:

“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.”

…”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.”

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;
Your e-commerce website is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate the website from all other systems);

 April 2015: New Council Guidance:  “PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v3.1” from here

“All merchants and service providers are required to comply with the PCI DSS as applicable to their environments at all times.”

SAQ  a aep 31

From above graphic:  “a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction”


 

“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);”

Is the total to be paid considered an “element”?


And then the guidance flowchart:

SAQ A AEP Understanding SAQs v3.1 April2015

Picture from the September 2014 North American Community Meeting

 

PCI Community Meeting WP_20140909_012

 

 PCI DSS V3.1 – the Scoping section

PCI DSS v31 scope web redirection servers

From graphic above:  “may impact the security of (for example, name resolution or web redirection servers) the CDE”.  Web redirection servers are in scope.

PCI FAQ

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-there-a-different-approach-for-Direct-Post-implementations-than-for-iFrame-and-URL-redirect-what-are-the-technical-differences-and-how-do-they-impact-the-security-of-e-commerce-transactions/?utm_content=7191612&utm_medium=social&utm_source=twitter

“The Council understands that the various ways that merchants can make e-commerce transactions is continually evolving. Merchants and QSAs receive often conflicting advice from vendors which can be especially confusing when the difference between using an iFrame and embedding a payment form in a <DIV> appears to be minimal. However, the difference in security is substantial: fully-hosted payment pages and payment pages loaded into an iFrame are resistant to the transparent theft of cardholder data as it is entered by the consumer; techniques such as Direct Post and JavaScript forms are not. The Council is aware that a MITM attack against a redirect or iFrame is viable, but in the payment brands’ experience these are detected before significant volumes of cardholder data are lost. The Council is working with Payment Service Providers to encourage tamper-resistance and tamper-detection which will also reduce the viability of a MITM-type attack.”

August 2014: Visa Europe’s Guidance

Thanks to Todd Roseman (‏@lukydesigns) for pointing me to this website which analyzes Visa Europe’s validation requirements for hosted payment pages.  Direct link to Visa Europe’s document here.

May 2014: Council Guidance:  “Understanding the SAQs for PCI DSS v3.0”

Graphic below from council guidance:  “Understanding the SAQs for PCI DSS v3.0” Section:  How does SAQ A-EP compare to SAQ A?

pci saq a and ep

 

The row “Control of Cardholder Data” says:

“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

April 2015 Council Guidance:  “Understanding the SAQs for PCI DSS v3”

Curiously this doc is updated from May 2014, but still doesn’t reference PCI DSS v3.1.

The excerpted chart did change though:

SAQ A AEP Understanding SAQs v3 2015-04

The “Control of Cardholder Data” row is removed.


The ecommerce implementation examples remain the same between the two May 2014 and April 2015 documents:

SAQ A AEP Understanding SAQs v3 2015-04 compare eligibility

 

May 2014:  Understanding SAQs PCI DSS V3

SAQ A AEP Understanding SAQs v3 may 2014

SAQ A AEP Understanding SAQs v3 may 2014-2

From graphic above:

“Prior to the release of SAQ A-EP, many e-commerce merchants with web sites that impacted the security of payment transactions may have felt they were eligible for SAQ A because their web server does not store, process, or transmit cardholder data. As a result, these web servers did not have sufficient security controls applied to them and have become common targets for attackers as a means to compromise cardholder data.
SAQ A-EP is intended to identify the controls needed to secure merchant web sites that control or manage the payment transaction, and reduce the likelihood a breach of the web site can be used to compromise cardholder data.”

Old V2 ecommerce Guidelines

PCI Security Standards Council E-commerce Special Interest Group published their PCI DSS (v2) ecommerce guidance in January 2013.  It says:

“No option completely removes a merchant’s PCI DSS responsibilities. Regardless of the extent of outsourcing to third parties, the merchant retains responsibility for ensuring that payment card data is protected. Connections and redirections between the merchant and the third party can be compromised, and the merchant should monitor its systems to ensure that no unexpected changes have occurred and that the integrity of the connection/redirection is maintained.”

Monitor its systems to ensure that the integrity of the redirection is maintained?  that no unexpected changes have occurred?  Sounds inscope-ish to me.

Feb 2012: MasterCard on Hosted Payment Pages

MasterCard on Hosted Payment Pages

Guidance from DRUPAL

The good folks at Drupal have also done some SAQ comparison and have published a report with some great guidance for their customers.  Actually the guidance is so good, it could be applicable to any e-commerce merchant or service provider.

CoalFire’s ISACA presentation from May 2014

http://www.isaca.org/chapters1/pugetsound/education/Documents/AShnider_PCI_3_0_and_EmergingTechnology_ISACAMay2014.pdf

Spreedly (payment solution vendor) Dec 2014 Guidance

http://blog.spreedly.com/2014/12/18/pci-dss-v3-0-for-online-merchants/#.VUfHqf9FDvU

Northcloud (ecommerce solution) Guidance Feb 2015

http://www.northcloud.com/pci-dss-3-0-changes-payment-providers/#comment-146

 

Ad below this line:

 

 

2 comments for “SAQ A vs A-EP – lots of links

  1. Raul Ramos
    August 24, 2015 at 1:08 pm

    Hi Shawn,

    The discussion about SAQ A vs SAQ A-EP above confirmed that my understanding is correct. But this is for merchants how about Service Providers?

    I have encountered service providers who denied to be PCI compliant because they don’t have anything to do with credit card information as they redirect to their payment processor. I have contacted SilkStart, a Canadian Service provider but they told me that they don’t need to be PCI compliant because they don’t collect or store credit card information and pass it to 3rd party payment providers that they integrate with.

    I thought service providers are SAQ A-EP based on version 3.0/1.

    Thanks,
    Raul (UBC)

    • shawn@lukaschuk.com
      September 17, 2015 at 2:53 pm

      Hi Raul,
      Lots of service providers have no obligation to PCI compliance from an acquirer like Merchants do. Some are obligated to compliance through an agreement with the card brands directly. Most do not, as yours told you!.

      Their obligation to compliance comes from YOU, their customer. Your policy should be to only deal with service providers who protect your information the way you specify. Lots of Merchants are now specifying that all of their service providers must complete an onsite assessment and ROC. I would inform any service provider who tells you that they don’t have to be PCI compliant, that they do to work with your data! 🙂

      This article http://thepciportal.com/2015/08/27/my-service-provider-just-sent-me-their-saq-a/ is likely relevant. The ONLY self assessment method for a service provider is the SAQ D for Service Providers. All of the other SAQs are for MERCHANTS. A service provider who self assesses might not meet your requirements, maybe you would require them to complete a ROC assessment or engage a QSA in other ways.

      Hope that helps. SL.

Leave a Reply

Your email address will not be published. Required fields are marked *