PCI DSS is the acronym for the Payment Card Industry Data Security Standard, a set of security standards designed to ensure that companies that accept, process, store or transmit credit card information, maintain a secure environment. PCI- DSS follows common-sense steps that mirror security best practices. PCI-DSS applies globally to all organizations that accept, transmit and store any cardholder data, regardless of size or number of transactions.

Below are highlighted questions from the whitepaper that we feel should be front of mind. Download the full whitepaper by submitting the form for more frequently asked questions about PCI compliance.

  • What are the PCI compliance ‘merchant levels’ and how are they determined?
  • What is tokenization and how can it be used for PCI compliance?
  • How do I know if a cloud service provider (CSP) or other third-party vendor is PCI compliant?
  • What does my organization need to do to get ready for a PCI DSS assessment?
  • What are the main updates in PCI 3.2?

The PCI DSS merchant level is a ranking of merchant transactions per year ranges broken down into four levels. Merchant levels are used to determine risk and ascertain the appropriate level of security for businesses. Specifically, merchant levels determine the amount of assessment and security validation that is required for the merchant to pass assessment.

Tokenization is the process of replacing the personal account number (PAN) with random numbers, or tokens that have no extrinsic or exploitable meaning or value after transmittal to the payments processor.

Tokenization helps with PCI compliance in many ways. Mainly, the use of tokenization means your company does not store or transmit cardholder data (CHD). The responsibility for securing the CHD lies with the payments processor, which reduces the scope of your PCI compliance requirements. Unlike encrypted credit card numbers and cryptographic tokens, which are still considered in-scope for PCI, non-cryptographic tokens can be used in customer service and other internal systems without causing those applications to be subject to PCI.

Many CSPs tout being “PCI compliant” or “PCI certified.” Those that have undergone an independent PCI audit should be willing to provide their report on compliance (ROC), which attests that all processes and components under their control are PCI DSS compliant.

You can learn more about Compliance in the Cloud here.

Every organization is different, but the following are general steps to take in preparing for an assessment.

  • Gather documentation.
  • Schedule resources.
  • Describe your cardholder data environment (CDE).
  • Consult with third-party vendors.

Get more detail on how to prepare for an assessment by downloading our whitepaper.

The primary updates in PCI DSS 3.2, which was released April 28, 2016, include:

  1. -Revised Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) sunset dates as outlined in the Bulletin on Migrating from SSL and Early TLS.
  2. -Expansion of requirement 8.3 to include use of multi-factor authentication for administrators accessing the cardholder data environment.
  3. -Additional security validation steps for service providers and others, including the “Designated Entities Supplemental Validation” (DESV) criteria, which was previously a separate document.

You can learn more about PCI 3.2 here.