In 2009 we were seeing a lot of uptake on the standard. Since it's a global standard, we're seeing it throughout the world. We're doing lots of training and lots of awareness-type seminars for literally every place around the world. All of our training is pretty much sold out. This year we've had to add training sessions so people can understand what the standard is and get better prepared for an assessment. So overall 2009 was a very good year for the Council, but 2010 is a very busy year for us. We're releasing three standards this year in eight different languages, so we're working hard. The PCI Security Standards Council recently undertook a study examining emerging technologies that could be used in future versions of the standard. Can you talk about some of those technologies that we may see in the future?
We're studying a couple [of technologies] right now to give additional guidance on them hopefully this year when we release the standard. Chip (chip and PIN) [is being studied] as an initial technology, because chip is a mature technology. There's a lot known about the technology. We have a lot of experience with it outside the United States, so we're looking at chip and we're actually mapping how chip would compare with the standard. We certainly don't think that there's a silver bullet in any of these technologies, whether it is chip and PIN, end-to-end encryption as the buzz word goes, tokenization or anything of that nature.
The second [technology being studied] will be some form of encryption. I don't like the term end-to-end encryption. Whether it is point-to-point encryption, account data encryption or transaction-based encryption, whatever it ends up being, we will be mapping that as well. Then we'll be moving on to other technologies including tokenization and virtualization.
We're creating a framework right now where we map these technologies out and lay them next to the standards, so if somebody is using one of these technologies, [the framework] will let them know if they would satisfy certain requirements.
The standard is due for a revision in 2010. Can you give merchants an idea of what may be addressed?
At this point we're going through a ton of feedback. Our feedback analysis closes at the end of April. We're finding this feedback fits into three categories: additional guidance, clarifications and then these emerging trends or emerging requirements. With a couple of thousand pieces of feedback that we're looking through, there's conflicting types of things there. We have conflicting opinions on what certain things should be. … The biggest thing that will affect the standard going forward is: how to best protect the data and then how much will this cost a merchant, the return on investment and whether there's anything that changes fundamentally the way the merchant actually will have to comply with the standard in the way they do business. If there's something that changes fundamentally the way they do business, certainly we can't put that in initially and have people go out of compliance. In some cases that would have to be a best practice for a certain period of time. In the last version of the standard, requirement 6.6 was a best practice for 18 months, so people had the opportunity to back into it because it was a big change in the way they complied. It's still too early to tell if this will be a version 2 or a version 1.3. After the Heartland breach, there's been a push for end-to-end encryption, not only from Heartland but from other payment processors. Is that something the council will look at?
With end-to-end encryption one of the questions we have is: From what end to what end? That's an issue. It's a very big buzz word. There are no standards yet for this type of encryption and how the keys are handled. In many cases you can end up making things less secure based on how you do this. You mentioned Heartland's [E3 product], that's one solution. There are probably a dozen solutions out there. Do they talk to each other? Are they interoperable? What if a merchant is using more than one? These are things that will have to be considered when looking at this. What we'll be studying is an encryption solution and the minimum level of things that need to be done with an encryption solution. Once we've got that we'll put out some guidance, probably nothing specific within the standard. The standard won't change, but there will be guidance based on using these things. Tokenization is also making its way in some encryption products. Can that make its way in the next version of the standard?
Certainly [tokenization] guidance could make its way in. I don't see us requiring any kind of tokenization, end-to-end encryption or chip technology in this version, but certainly [we will issue] guidance on these things. If a merchant has already started down a path and spent some dollars on one technology, certainly it would not be in our best interest to say "you chose the wrong technology now you need to use this technology." So there will be guidance on each one of these things that we roll out.