Depending on how you outsource, you may be able to decrease your PCI scope and business risk.
Creating an easy-to-navigate, customer friendly e-commerce solution is challenging. Building an e-commerce website that conforms to Payment Card Industry Data Security Standard (PCI DSS) requirements is even more difficult. That’s why many e-commerce merchants choose to outsource some or all of their website content.
Depending on how you outsource, you may be able to decrease your PCI validation scope and reduce business risk. PCI scope determines how PCI DSS applies to your business. Specifically, any system, application, or process that has access to credit card information is considered in-scope.
When PCI DSS version 3.0 was introduced, it included a new SAQ: A-EP. This changed which PCI requirements need to be validated for some types of e-commerce merchants. Then, PCI DSS 3.2 brought some big changes, like more frequent penetration testing for some service providers and industry-wide guidelines for multi-factor authentication. The most recent version of the standard, PCI DSS 3.2.1, builds on 3.0 and was released mainly for clarification.
As we anticipate the release of PCI DSS 4.0, how do you know which method of e-commerce outsourcing reduces the most validation scope?
See also: PCI DSS Version 4.0: What You Need to Know
Of course, outsourcing payment pages does not eliminate all of your PCI DSS responsibility. Even if you outsource to a third party, there is the point of redirection that needs to be protected. You also have the responsibility to choose a partner that will protect the data you will send their way. That’s why I can’t overemphasize the importance of choosing a PCI DSS-compliant service provider who takes security seriously. Consider choosing a Visa-approved PCI compliant e-commerce website host with validated dedication to payments security. If a provider is attempting to pitch you on a cheaper, simpler e-commerce solution that downplays security or claims to be secure, don’t fall prey.
If you outsource the entire e-commerce website to a third party, no e-commerce payment data should flow through your company systems. If you choose to outsource your entire website (this means no web servers at your company at all and no other processes that deal with card data), your main responsibility would be in the selection of a good partner and some internal documentation–essentially you would need to meet the requirements in PCI DSS section 12 that apply to you. Do note that there is a price tag involved with an entire site’s creation, and you will have less flexibility in regards to design changes, but you’ll have essentially outsourced almost all of your PCI DSS responsibility to that third party, and you need to know they accept that role.
Outsourcing links or just pages from your existing website that involve the collection and/or viewing of credit card information is very popular among small to medium merchants. There are about five different ways an e-commerce payment page could be outsourced. The method used will determine your PCI Self-Assessment Questionnaire (SAQ). The key is to understand where the payment data fields actually reside, and to whom that information is transferred throughout the payment process.
In this very common process, customers are passed from the merchant website to a separate third party site to process the card transaction by clicking on a link or button that fully redirects to a third party site. Traditionally, small merchants use redirection links to minimize scope and reduce liability.
The risk of compromise is reduced to an attacker accessing your website and changing the link destination to one of their choosing. Since this is a fairly overt attack that shows up as a change to your website content, it should be easily detected using file integrity monitoring (FIM); therefore, the impact related to a redirection breach is low. This is part of the reason the PCI Security Standards Council (SSC) classifies redirection processing to use the validation method shown in SAQ-A.
An IFRAME (inline frame) element on a merchant web page can be used to view a third-party hosted payment page through a seamless window in the source page.
This solution is very similar to a redirection link since there is no HTML code hosted on the merchant website that is taking any payment data. The biggest advantage of IFRAMEs is they allow the merchant site to maintain branding while outsourcing all card data collection and processing to a third party.
Like redirection, payment pages viewed through IFRAMEs are seen as a low risk and as such, the PCI SSC classifies merchants utilizing IFRAME to validate using an SAQ-A form.
In a direct client post (i.e., client side redirect), the payment data input fields originate from the merchant website, but are collected by the user’s browser and sensitive data input is sent directly to the processing destination. This allows the merchant more control over the look and feel of the payment process, and results in no credit card data coming back to the merchant website.
Credit card data is posted directly from the user’s browser to the third-party payment service provider (PSP). However, the merchant is still in charge of protecting the payment form HTML or script code as delivered by their web server to the client.
Because the code that processes the card data is delivered by the merchant web server to the client, there is more responsibility than just an outsourced third-party page link and hence higher risk. Because of this additional security responsibility, the PCI Council has required this processing method to validate using SAQ A-EP which has more security requirements than the SAQ A.
The JavaScript method is a bit unique in that the customer browser executes code, which comes from the PSP, to create the payment form or operate on payment data in some other way (such as client side data encryption).
Similar to direct post, JavaScript is a moderate-risk e-commerce processing method, and merchants processing in this manner are required to validate to SAQ A-EP.
There’s always the option to find or write your own shopping cart, but taking the full burden of PCI DSS on your shoulders is quite demanding. With traditional e-commerce architecture, the merchant controls nearly the entire payment process, which may even include storing credit card data.
It may seem attractive upfront because of lower costs and increased control over the payment process, but after considering the effort to develop and maintain full PCI compliance for all e-commerce systems, it may often represent more cost to the merchant in the long run.
Hackers are always looking for the biggest bang for their buck. In e-commerce processing, traditional e-commerce can be the Holy Grail. Because this approach can lead to a larger breach footprint, it is considered a high-risk processing method and requires a full SAQ D validation. This method of e-commerce processing is becoming less and less popular as the years go by.
Hopefully now, the reasoning behind certain SAQ e-commerce qualifications is a little clearer. The outsourcing method you use dictates both your risk and the security controls you must implement in order to protect card data and stay compliant to PCI DSS.
The PCI DSS makes it very clear that merchants hold the responsibility to protect e-commerce transactions that originate from their website.
Whichever way is best for your business, third-party outsourcing means you have a few tasks to achieve PCI DSS compliance.
.svg)
