What is Toluu?
Toluu is a free service for sharing the feeds you read and discovering new ones.		 Get Invite

PCI DSS Compliance Demystified

PCI DSS and Regulatory Compliance Blog


Society going globalDecember 26 2008

Even though we have already trained thousands of merchants, acquiring banks, and service providers in many countries around the world, we have not yet trained these groups in Africa - until now.

The Society of Payment Security Professionals (SPSP) is both attending and presenting an educational PCI conference in Johannesburg, South Africa.  This event will be 27 January 2009 at the Hyatt Regency Hotel. The Society will expand the current educational, training, association and certification opportunities to participants from South Africa.

I met a friend last year who attended one of the PCI training sessions we put on in Prague.  He said, “this is the kind of training we need in South Africa.”  That conversation and many other fortunate events have brought the Society to ZA.  I’m excited about this event because over the past year Africa has put itself on the map as a place for more secure payments.  In addition to South Africa, merchants and banks from other countries have become interested in the Payment Card Industry.  These countries include: Egypt, Algeria, and even Rwanda.

Also, the Society will also be keynoting the ITWeb Security Summit in Johannesburg on 26-28 May 2008.

(In addition to these inter


PCI already addresses VirtualizationDecember 9 2008

I’ve written about how PCI already addresses virtualization here, here, and here.  A recent article discusses how PCI needs to address this technology.  My question is why?  Does PCI also need to clearly outline how you should use HSMs, IDS, FIM, user authentication, and firewalls?  Where do we stop?

Some people often complain about how specific the PCI DSS standard is and that it should be more generic to enable flexibility.  But when it comes to technologies they wish to promote, suddenly it is not specific enough.  Why are the current requirements not enough?  I did a podcast on PCI compliance for cloud computing environments and outlined the current rules that already address virtualization.  Instead of pushing for more information around one technology, which will surely change over time, how about simply clarifying the current requirements, such as 2.2.1 the infamous and misused “only one primary function per device”.

I like less complexity and not more.  If the PCI Council did start a SIG on virtualization then there would be an

Payment Security Professional of the Year NominationsDecember 9 2008

I can’t belive the year is almost over.  The Society of Payment Security Professionals (SPSP) has seen great success with a membership of almost 500 and several hundres of those being certified CPISM and CPISA individuals.  The Society board members have put together working groups on Application Security, Network Segmentation, and Legal Issues. Each of these groups is made up on individuals who work to help raise the awareness and clarity on these issues.

The PCI Answers blog had about 200,000 hits.  We keep getting a stream of emails and phone calls for more information and clarification.

Since you have made the Society such great success, we’ve decided to give back to you!  That’s right, the Society is now taking nominations for the Payment Security Professional (PSP) of the year.  Nominations will be collected over the next six weeks and the winner will be chosen by Advisory Board and announced on January 30, 2008.  Here is what you could win:

  • 15 in MacBook Pro
  • Feature article in Secure Payments, the SPSP magazine set to debut in Q1 2009.
  • Highlighted profile on the Payment Security P
SaaS Compliance and LevelsDecember 7 2008

A reader recently wrote in and asked about Software as a Service (SaaS) companies and their need for PCI DSS compliance.  Let’s begin by discussing a few terms and then a few reminders about ‘levels’.

A SaaS firm, by definition, is a service provider.  The question is what kind of service provider are they.  If the software the firm provides is not involved in aggregating transactions (i.e. connectivity or remote access software) then they are a generic service provider.  If the SaaS firm does aggregate transactions (i.e. payment processor or shared e-commerce provider) then they are a specific type of service provider called a ‘gateway’.

The most basic definition of a gateway is anyone who sits between the merchant/customer and acquirer/processors for the purposes of authorization/settlement of transactions.  The typical example of this would be a shared e-commerce provider or independent sales organization (ISO) that aggregates transactions.  All service providers that “store, process, or transmit” cardholder data need to comply with the PCI DSS requirements.  One way to avoid this was documented in another post.

Up until recently this definition has been critical, but in February 2009 that is all changing.  Visa Inc. (all regions except Europe) has de

Service Provider or PA-DSS?December 7 2008

Chris asks,

Our company doesn’t do any credit card transactions whatsoever.  However,
some of our clients need to install our software on their back office
computers.  And some of those clients are worried that we aren’t PCI
“Certified”.  How do we assure them that we are OK with PCI compliance
rules?  Is there a certification we can get for our application?

If your company does not store, process, or transmit cardholder data then you do not need to be PCI compliant.  One question for you is if your software is used for the storage, processing, or transmission of cardholder data. Two things:

  • If you resell software that is used by others for transaction processing then you may want to look into PA-DSS compliance for your software.
  • If you remotely manage that software, such that you could negatively impact the security of cardholder data, then you may be considered a service provider and thus need to comply with the PCI DSS.

If your software is not used for handling payments and you do not have access to your client’s cardholder data environment then you may not need to be PCI compliant.  The question is, are you a Service Provider or do you create PA-DSS applications.

The PCI SSC has language that defines the PA-DSS as it pertains to software vendors:

The PA-DSS applies to software vendors and others who develop payment applications that