Vegas is in the books, baby!  I’d call it a successful community meeting.  The networking opportunities were fantastic, and the sights were awesome ((including seeing Russo dress up like Elvis which I did not take a picture of… see Bob? I can play within the rules :).  More on the handling of social media later…. it was not handled well.)).  For those staying in THEhotel, we got to walk off calories consumed with the long walk from the room to the conference center that we made at least twice daily.  Of course, it is Las Vegas.  It’s REALLY hard to concentrate when you know that you don’t have to walk far to be bombarded by flashing lights, bells, whistles, and other sensory delights designed to make you give money to the casino.  I came out about even.


The first posts and stories have already started coming out; I’ve submitted my feedback on the meeting, and now it’s time to analyze!

One of the first things that I wanted to address follows the same theme that traditionally spawns some of my most popular posts about the community meetings.

I think we’ve gotten to the point where it’s time to split out the Q/A into two groups.  Some of the same questions are being asked in the Q/A session that have been asked for the last two years.  These questions are still valid, but do we need to stop down a room of 700 folks for them?  Probably not.  The new professionals responsible for working on PCI NEED this information, but maybe we can do a basic Q/A first while other attendees can do something else, then do the advanced one later with everyone.  That way everyone has the benefit of listening to the advanced questions with some set baseline.

Most questions provoked nothing from the audience, but there was ONE question that garnered a HUGE round of applause from the room.  Bless the attendee who asked when issuers will be required to comply.  You’d have thought that someone took over the PA at Fenway and screamed “YANKEES SUCK” into a live microphone.

Aung San Suu Kyi Lecture, by Foreign and Commonwealth Office

Aung San Suu Kyi Lecture, by Foreign and Commonwealth Office

I like sitting in these sessions because I need to know the pulse of the PCI community.  This year is by far the most sophisticated crowd.  There were no questions like “Uhh, what’s a Web Application Firewall, and what do I do with it?” ((Yes, we had one like that in 2007.))  Instead, we had some great technical questions that, unfortunately, left many people wanting based on the answers they got back from the Council.

I’m seeing a trend that I’m not sure how to fix.  Many questions that were asked had answers available to them either on the PCI SSC website or FAQ, or on the payment brand website itself.  The sites are easy for me to navigate, but I’ve been doing this for many years now and I’m a bad benchmark on the availability of information.  In fact, we’re so used to Google telling us exactly what we want the first time, that few people actually know how to harness its power.  The information available to PCI stakeholders is, for the most part, accessible.  There is a LOT of it, but it’s there.  Becoming a Google power user might help people find the information as well.

Like in most things, you get out of this process what you put into it.  Spend a little time thinking of your questions BEFORE you come to the meeting to make sure you will get an answer other than:

  1. Read PCI DSS.
  2. It’s up to your QSA.
  3. Ask your Acquirer.
  4. Read the PCI DSS FAQ.
  5. It’s on the website.

This trend and frustration gave me an idea. I’d like to present to you a guide by which you can get your questions answered.  So here’s How to Ask a PCI Question (any key stakeholders that want to add or suggest changes to this, please drop me a line).

Before you can ask the question, you need to make sure you are talking to the right people!  Missing this step will almost guarantee you will end up with one of the five answers listed above.

  • The PCI Council (Intent): Only answers questions about the intent of PCI DSS.  Don’t ask about fines, complain about Level 2 Merchants having to get a QSA or ISA, or ask if Bit9 will comply with Requirement 5.  Those will lead you into one of the five buckets above.
  • The Payment Brands (Enforcement): Only answers questions about their specific compliance program.  Visa’s CISP, MasterCard’s SDP, American Express’s DSOP, Discover’s DISC, and JCB’s DSP all refer to PCI as the common set of controls, but all have different requirements to comply ((Look for more on this topic in coming days)).  You should ask them about fines or when to submit an SAQ.  Don’t ask them about the intent of a PCI requirement (though they will likely answer to assist you) or if RSA’s SecurID is the only thing that will satisfy Requirement 8.2.  While they may try to assist, I typically see (with one exception) payment brands avoid those discussions, especially when their competitors are present.
  • Your Acquirer (Enforcement): Most compliance questions are better suited for your acquirer because they are responsible for your actions on the payment network.  Acquirers don’t have all the answers, and you should not ask them if <Insert Whatever Vendor Here> EV-SSL will comply with Requirement 4.1 (hint… it will) or the intent behind a particular requirement.  Again, they may try to point you in the right direction, but Payment Brands are responsible for enforcement of PCI, and they enforce it on your Acquirer who then enforces it on you.
  • Your QSA (Interpretation): Your QSA, or ISA if you have gone that route, is an important step in the PCI DSS process.  If you don’t like her, the process is going to be a pain.  Alternatively, if she works well with your company, things will work out much better for everyone in the end.  It’s your QSAs job to weigh all the guidance from the Council and apply it to your individual environment to determine it’s compliance with PCI DSS.  Ask her questions about specific technologies and their compliance in your environment.  Don’t forget to tell her EVERYTHING about the solution.  Context is a real issue with these types of questions.

Now you know the roles played by each player, and you know only to ask the Council about intent related questions.  So how do you get the biggest bang for your buck at the community meeting?  Stick to the intent.

Never-ever-never-ever-ever-not-ever-never start a question with something like “I have a client that …” or “I deployed Microsoft Sharepoint…”  Those questions are probably too specific, smell of someone fishing for free consulting, and do not get to the intent of a requirement.  Even if you have a valid question on the intent of PCI DSS, starting your inquiry off this way will cause members of the Council to get a little skittish.  Let’s walk through an example.

Christopher is the compliance manager for a regional, medium size retailer. For some of his stores, he is considering installing a single beefy server that will run some kind of bare metal hypervisor and multiple guest instances to replace the existing four servers in each store.  Some of these servers must comply with PCI DSS, some may not.  Christopher read PCI DSS Requirement 2.2.1 and is wondering if his virtualization strategy will comply with PCI DSS.

Here’s how Christopher can ask the question to guarantee he will get one of the five answers above:

Can I run VMWare ESXi in my store and comply with PCI DSS?

The answer will be #2 from the list above if you ask the Council.  If you ask a QSA, they would likely say “Yes, but it depends on how you set it up.”

Here’s how the question SHOULD be asked.

Is the intent of PCI DSS 1.2 to define a server as a physical machine or would virtualization work?

The answer you will get back is probably something like “Virtualization can definitely be considered for PCI DSS Requirement 2.2.1, and the implementation should be validated by your QSA.”

Excellent!  An answer that is meaningful!  The first of those two questions is best asked of a PCI Expert, the second is one where you have done your basic research, and are really trying to understand the intent of the controls so you can design a compliant solution.

So when you go to ask the Council a question, be sure that they are the correct group to ask, and that you ask it in a way they can answer it.  More posts coming soon including my next installment, How To Define Cardholder Data!

This post originally appeared on

Possibly Related Posts: