SAQ A: Merchants who have outsourced all account data functions to PCI DSS compliant third parties.

Several changes have been made to clarify eligibility for and applicability within SAQ A, including:

• To be eligible, all processing of account data must be outsourced to a PCI DSS compliant third-party service provider (TPSP). Account data includes both cardholder data and sensitive authentication data.
• Merchants must review the PCI DSS Attestation of Compliance form(s) for its third-party service provider(s) and confirm they’re PCI DSS compliant for the services being used.
• The updated note on page iii of the PCI DSS SAQ A document, clarifies the applicability of Requirements 2, 6, 8 and 11 and Requirements that refer to the “cardholder data environment”. These Requirements apply to e-commerce merchants whose website redirects customers to a third-party service provider /payment processor for payment processing, or that include a third-party service provider / payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
• Further notes and completion guidance throughout SAQ A explain how Requirements apply to merchant web servers.

The SAQ A includes 9 new requirements that are effective immediately and 4 future dated requirements. While 2 consolidated, redundant or no longer applicable version 3.2.1 SAQ Requirements have been removed from SAQ A: 9.6 a, 9.7. The most significant of the new or additional Requirements are highlighted below:

Effective Immediately

• Quarterly External Vulnerability Scans (11.3.2, 11.3.2.1)
  • Applicable only to ecommerce merchants whose website remains in scope because it can impact the security of account data. This includes merchant webservers that host the page(s) that either 1) redirects customers from the merchant website to a third-party service provider / payment processor for payment processing (for example, with a URL redirect) or 2) includes a third-party service provider/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
  • Not applicable to other SAQ A merchants that have entirely outsourced their ecommerce website to a PCI DSS compliant third-party service provider as ASV scanning of the in-scope environment will be included in the third-party service provider’s assessment.
• Additional requirements for use of passwords/passphrases for authentication of users and administrators (8.3.5, 8.3.7, 8.3.9)
  • Applicable to merchant webservers that host the page(s) that either 1) redirects customers from the merchant website to a third-party service provider/payment processor for payment processing (for example, with a URL redirect) or 2) includes a third-party service provider’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).

Future-dated

• Manage payment page scripts to ensure each script is necessary, its use authorized, and its integrity assured (6.4.3)
  • Applicable to ecommerce merchant websites that includes a third-party service provider/payment processor’s embedded payment page/form (for example, an inline frame or iFrame). 
For example, merchant websites that integrate the third-party service provider’s JavaScript in the payment page which is called to create a hosted iFrame payment form displayed in the container specified by the merchant webpage.
• Implement a change- and tamper-detection mechanism to detect and alert on unauthorized modification to the HTTP headers and the contents of payment pages as received by the consumer browser (11.6.1) The PCI DSS provides guidance on some of the mechanisms available to detect and report on changes to the http headers and content of the payment page.
• Minimum of 12-character alphanumeric password length, if passwords/passphrases are used for authentication of users and administrators (8.3.6)
• Or minimum 8 characters if the system does not support 12 characters.
  • Applicable to merchant webservers that host the page(s) that either 1) redirects customers from the merchant website to a third-party service provider /payment processor for payment processing (for example, with a URL redirect) or 2) includes a third-party service provider’s/payment processor’s embedded payment page/ form (for example, an inline frame or iFrame).
  • Not applicable to application or system accounts.