This week saw the release of the new PCI DSS 2.0 eCommerce Guidelines, one of the latest work products from a Special Interest Group in the PCI Community. Before you go clicking on the links above, there are a few things I wanted to outline for you here.

Doctor Tom Saves the Day, by Murray Barnes

Doctor Tom Saves the Day, by Murray Barnes

First, remember that this is a GUIDANCE document, and is not an official extension of PCI DSS. That said, there is some valuable things in here to consider as well as a few misleading statements that I wanted to comment on. Keep in mind, I am not an official mouthpiece of the Council, but I’ve been involved in the community for a long time. I have submitted my feedback to the Council as well, so I hope they will take the time to clarify this document.

Second, follow the contracting process. That’s all I will say on that, but just ensure that any agreements you have with people who handle cardholder data clearly line out who is doing what, who is responsible for what, and how disputes are handled.

In the introduction, there are a few statements that may be misleading to a consumer of the document. It’s relatively easy to fix if you consider the term “merchant” refers to someone who owns and leverages their own “merchant ID.” If you have outsourced your payments to a third party and you can prove that no payments ever enter your network, item “B” does not apply. I also disagree with item “D.” The one-size-fits-all method is to completely outsource your payments. If the goal is to reduce the impact PCI DSS has on your environment, do this. Just get pick lists and wire transfers with no access to an original card number. Hand keying things are a bit different, but that will be a great question for your provider on how they want to handle your compliance obligations (and it should be in your contract).

The next paragraph describes some of the limitations, but they specifically call out B2C. Make no mistake, B2B merchants that accept payment cards in eCommerce transactions are just as liable to protect payment data as B2C merchants. Don’t let this fool you into thinking you are exempt.

Section 3.1.1 details some definitions of third-party entities, but leaves out that some E-commerce Payment Gateways or Payment Processors also offer completely outsourced payment solutions. Check with your vendor to understand if they offer such a solution.

Please Pay Here 3-14-09 19, by stevendepolo

Please Pay Here 3-14-09 19, by stevendepolo

Section 3.4 attempts to talk about some common eCommerce implementations, but classifies things incorrectly. the last two bullets under the shared-management e-commerce implementations should really be bumped down to wholly-outsourced pending a thorough examination of your business processes. There are different kinds of risks associated with those (as listed later in the doc), but again your contracts will dictate what you need to do. The recommendations are good practices for anyone, not just those with shared infrastructure. What I think they are trying to define are eBusiness implementations, not eCommerce implementations. But if that is the case, those two bullets still need their own parent category. Same with the last two bullets at the top of section 3.4.3. The guidance information in that section is also misleading (as is, though compromises CAN occur in some unique situations. Go look through your contracts.

For the rest of my comments in and 3.4.4, go read your contracts. It’s really going to come down to who owns the merchant ID and what is written in the contracts. These sections could spark some pretty heated techie-debate because the terms could apply in multiple scenarios. Make no mistake, payment systems are complex; any guidance around them is bound to have issues like this. For example, depending on how things are set up you may be completely exempt from any PCI DSS obligations. This concept is missing from the document.

Finally, be sure you understand your business and payment flows—COMPLETELY. Section 3.4.5’s inset box is essentially redundant and really should have been covered above. The scope of the document does not include these “out of band” type flows, but they are critical to understanding your overall responsibilities to PCI DSS.

Definitely take a look at Section 5 if you have any responsibility for PCI DSS due to contracts or flows. There is some good stuff in here, albeit repurposed phrases that have become mantras for PCI professionals. The Appendices have some good information as well, but I didn’t review them in their entirety. Just understand that this is guidance and does not translate to requirements (as in you should, not you must).

This post originally appeared on

Possibly Related Posts: