Here we continue our discussion of “what happens when a Merchant outsources their e-commerce environment.” In Part I, we touched on the types of e-commerce operators, including those that are purely e-tailers and those that are mixed brick-and-mortar and online retailers. We began a discussion about scoping the e-commerce environment for PCI, what is clearly in scope and what is clearly out of scope. Now we will examine what is NOT clearly in or out of scope, as well as the implications of different combinations of in-house and hosted environments, and their implications on PCI scope.

But first, let’s review from last time our basic scoping argument for a typically e-commerce environment:
We are all familiar with the large e-tailer environment – the ones with the popular web pages that have categories upon categories of items for sales, shopping carts and secure transaction pages for placing orders. We also touched on the retail sites that allow you to purchase gift cards, or to order merchandise or to pre-order items for in-store fulfillment. Clearly, these are also e-commerce operations. In all of these cases, a website at some point completes a purchase by collecting cardholder data from a buyer and then enters order information into some type of an order fulfillment or an order management system. This much is clear. What is also clear is what most often is NOT an e-commerce site: Any site that does not prompt for payment, and doesn’t allow you to purchase anything. There may be catalog items, and pricing information, even product availability information that lets you look up store stock in real-time – but the site never handles any cardholder data. Lots of content and pretty pictures, perhaps flashy videos, but no cardholder data. No, not within scope of PCI.

But what about the web site that has a combination of both? It has all of the flash, the ads, the interactive product guides and also allows for you to purchase items – right from your browser. Definitely an e-commerce site and definitely in scope for PCI? Right?

Once again, the answer is “It depends” and “It varies.”

Let’s take a step back and see what happens on that xyzinc.com website: we start on a “landing” or “splash” page, use certain navigational elements to make our way through the site, and eventually end up with a shopping cart and/or a screen to complete an online purchase. Despite our web-surfing perception that all sites look and act basically the same way, the variability of web site architecture belies what our browser displays to us.

In one scenario, all of the content may be hosted on a single web server (or cluster of web servers with server persistence) environment. Clearly, the server and the applications running on it are within scope for PCI.

In another scenario, the server acting as an agent to complete the online transaction is physically hosted on a different machine, and might even lie in a completely separate network, segmented from the environment that hosts the content web server that brought you here in the first place. Thus the browser experience is seamless – you looked at products and flashy ads on one server, and when you were ready to buy you were handed off to another server that handles the cardholder data and communicates through middleware to a database back end - and the payment processing environment. If the Merchant organization segmenting things adequately, the PCI assessor would rule the first batch of web servers out of PCI scope, and the second batch within scope – as the former does not handle any cardholder data and the latter surely are within the path of cardholder data flow.

OK, now we seem to be getting somewhere. But exactly where? Yes, the question is “where” – where are these machines hosted? Where do they live?

It is entirely possible that the payment processing applications reside in a hosted environment that does not belong to the merchant that owns the website. Thus, the merchant can claim that they e-commerce environment is out off scope. Once again – it depends and it varies. The key to understanding the scope is to understand the flow of cardholder data. What happens to the cardholder data after it is accepted by the e-commerce server?

As a QSA, I have seen cases where the transaction data is sent back to the merchant’s mainframe environment and processed just like any other in-store retail purchase. I have seen others where cardholder data is sent directly from the hosting environment to the payment processor/gateway for authorization. At one retailer, I had witnessed two extreme examples of this – one e-commerce environment that was hosted by a third-party but owned, maintained and developed in-house by the merchant – and a second e-commerce environment that was hosted and managed by yet another third-party provider, as a turn-key solution offered on a “soup to nuts” basis.

Here was a case where both of the retailer’s sites were hosted by a third-party, with one out of scope and one definitely in-scope for their PCI assessment.

Clearly then, hosting of an e-commerce environment by a third-party does not automatically equate to “out of scope” for the retailer. As a matter of fact, the litmus test for scope greatly depends on who operates the website – if it is completely external to the retailer’s environment, if it is developed, maintained and operated by the third-party, and is hosted on equipment that is not owned by the retailer, then the environment is most likely out of scope for the retailer’s PCI assessment. If the site is hosted off-site, but the equipment belongs to the retailer, its web payment applications are developed/maintained by the retailer’s development staff, and the servers it runs on are in fact managed and patched by the retailer’s IT staff, then the site is most likely 100% in scope for PCI.

Some interesting variations: Site is hosted by a third-party, equipment is owned and managed by the same third-party, cardholder data transactions flow directly to the Acquiring Bank’s gateway – and the applications are developed in-house by the retailer (e-commerce environment is largely out of scope, but some elements of this ARE in scope – particularly the e-commerce development processes); Code is maintained by the third-party, a “web hosting” company and the servers are also hosted at the same facility – but the servers are owned by the retailer and the OS is patched and maintained by the retailer remotely (applications most likely out of scope, as is the development environment – but the hardware is in scope for PCI along with the remote access methods and IT administrative procedures. And likely so is the entire e-commerce environment – but not necessarily).

The preceding accounts for some gray shade areas that the QSA must wrestle with when determining the scope for a mixed-responsibility e-commerce environment. As a rule of thumb, the best approach is to consider an e-commerce environment in scope, then determine which pieces of it are outside the scope. As different pieces of the environment are excluded from scope, the blurred boundaries of responsibility begin to sharpen and soon the areas that lie within scope become apparent, as do the areas that can remain excluded from scope. In the end, the scoping section of the Executive Summary of the resulting ROC will read to the effect “In scope: The e-commerce environment, with the exception of the following: <…>” If all areas of the e-commerce environment can be excluded from PCI scope, then a valid argument can be made that the e-commerce environment is out of scope for the assessment. If not, then the exercise results in a narrowing of scope for the e-commerce environment and the fulfillment of our ultimate goal.