Within the PCI DSS, to qualify for the Self-Assessment Questionnaire (SAQ) A, a merchant must be “completely outsourced” to a validated, compliant third-party service provider, which typically means an e-commerce site, or an outsourced mail order/telephone order partner. In most cases, the SAQ A applies solely to e-commerce.
All activity is customer-driven, meaning it is always the cardholder who enters their payment information on a personal device (laptop, workstation, mobile phone, etc.) that is not controlled or provided by the merchant. This cannot be a staff member entering in payments on an e-commerce website for customers and also does not apply to kiosks or workstations in an office that you direct customers to for payments.
Taking a closer look at the specific requirements, the SAQ A currently only supports full URL re-direction or embedded payment pages (e.g., iframes). Requirements 2, 6, 8, and 11 apply to the web server environment that is handling the URL redirection or the embedded payment form. The responsibility for these requirements will be with either your organization or a third party that administers this front-end web server.
These requirements always applied before PCI DSS v4.0, however, there have been new requirements added, including:
- 6.4.3: Payment page scripts are authorized, integrity checked, and inventoried. This requirement applies to pages redirected from or containing an iframe (best practice until 31st March 2025, then required).
- 11.3.2: Quarterly external vulnerability scans performed by an ASV, with re-scans as required until passing scans.
- 11.6.1: For use of iframes hosting the payment service provider’s payment page, a change and tamper detection mechanism to alert personnel to changes to HTTP headers or payment page contents; the mechanism must work at least every seven days (best practice until 31st March 2025, then required).
As organizations transition to PCI DSS v4.0, the questions we receive most from our customers are:
How do I know if scanning now applies to my e-commerce merchants? What exactly do we scan?
When we are reviewing a website to determine if and what requirements from the SAQ A are applicable, four different models can apply:
-
Fully-fully outsourced: Reputational risk only.
This means a third party, such as a ticketing or parking vendor, is the merchant of record (MID owner) instead of your organization. The third party hosts any e-commerce front end in its server environment, not yours. We often see this type of scenario within a campus bookstore environment.
Your infrastructure has to abstract two or more user actions/clicks away from the page where payment information is entered. So, if you host a link that re-directs to the beginning of a multi-step checkout process which is all hosted by the third party, you would still fall into this category.
Under a fully-outsourced model, in which the third party owns the MID, you do not have a formal PCI responsibility, and just manage the relationship considering the reputational risk to your organization. Scanning is not required.
CampusGuard still recommends collecting the third-party’s compliance documentation (AoC) annually, so you can trust they have implemented the appropriate security controls within their environment. As stated above, it is also always important to ensure that staff are not processing transactions online on behalf of other users/customers on organizational equipment.
-
Fully outsourced: Your organization’s infrastructure is not in scope.
In this model, your organization is the merchant (MID owner). As with the scenario above, a third party hosts the e-commerce front-end in its environment, or your organization’s environment hosts a link that is the beginning of a multi-step check-out process hosted by a third party. This scenario is more common within areas like parking, event ticketing, etc.
However, in this example, you own the MID, so you do have a PCI responsibility and would be required to complete an SAQ A. Because your technical infrastructure/environment is not in technical scope, Requirements 2, 6, 8, and 11 within the SAQ A can be answered as non-applicable (N/A). Scanning is not required.
-
URL re-direction from your environment
In this scenario, you own the MID, but you also host the re-direct link that goes straight to the outsourced payment form (just one action/click moves the user from your site to the page where cardholder information is entered). This is commonly seen when your organization has an internal website for services like course registration, library fees, software purchases, etc. and the customer selects services or products to add to their shopping cart, but before entering payment card information they are re-directed to a payment processor like Authorize.net or other.
Requirements 2, 6, 8, and 11 are now applicable to your organization and will need to be answered as Yes (and the necessary controls implemented) to complete a compliant SAQ. Within PCI DSS v4.0, there are two requirements (6.4.3 and 11.6.1) that are future-dated until March 31, 2025. In this example, these two requirements can always be answered N/A as they apply to embedded payment pages/forms.
In this scenario, you will need to scan the server hosting the re-direct link.
-
Embedded payment form hosted in your environment.
This example is again when your organization owns the MID, but instead of a re-direct link, your hosted environment contains an embedded payment form or iframe. Requirements 6.4.3 and 11.6.1 can be N/A up to March 31, 2025, but after that timeframe, organizations will be responsible for meeting those requirements in this embedded payment form scenario, along with the other requirements in the SAQ A.
In this scenario, you are responsible for scanning the server that hosts the page with the embedded payment form.
Quarterly external vulnerability scans performed by an Approved Scanning Vendor (ASV) are required in both examples 3 and 4 from above. With the migration to PCI DSS v4.0, your organization technically only needs 1 passing scan in the quarter prior to your annual attestation date, but we recommend starting any necessary scans sooner rather than later so you can ensure any remediation is completed and you are able to obtain a passing scan prior to completing your SAQs/attesting to the bank.
Work with your dedicated QSA and CRM teams to review your current e-commerce inventory (a template inventory spreadsheet is available from CampusGuard!) and categorize your SAQ A merchants into each of the four categories above. Partnering with your QSA on this effort can ensure you are categorizing each merchant correctly and defining your PCI scope accurately. They will also help identify potential ways to reduce scope and streamline operations.
As discussed in a previous blog post, use this effort as an opportunity to review current payment flows with your merchants, identify any third parties in use, and ensure the organization is obtaining updated compliance documentation from any involved third-party service providers.
Once you have your list of identified sites and web servers from your SAQ A merchants, you may need to loop in your IT teams to confirm all hosted sites. They can also help provide the more technical details that will be needed to configure your scans like the IP addresses, involvement of load balancers, use of Cloudflare, etc.
What’s next? How do you start the required scans?
Go to Part Two: Getting Started: CampusGuard’s ASV Scanning
